Re: RESTful API for the Entityhub

[Rupert Westenthaler <ru...@gmail.com>]

Hi all,

I have decided to delay the implementation of the RESTful interface
discussed in this thread until later.
In the short term I will add support for creating and updating
Entities current RESTful API.

The new plan is to start the development in July (after the IKS
Workshop in Paris[1]) and in an own branch. This would also provide
the possibility to discuss the RESTful interface of the Contenthub.
Maybe this two component can share some parts of the implementation.

best
Rupert Westenthaler

On Tue, May 24, 2011 at 2:36 PM, Rupert Westenthaler
<ru...@gmail.com> wrote:
> On Tue, May 24, 2011 at 11:08 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> Hi Rupert,
>>
>> On Mon, May 23, 2011 at 11:45 PM, Rupert Westenthaler
>> <ru...@gmail.com> wrote:
>>> ...Yesterday I published a document [1] that describes how to adopt
>>> Linked Data / Linked Media principles for the RESTful API of the
>>> Entityhub....
>>
>> Cool - I like the Linked Data intro, could be its own document IMO -
>> but maybe later, no hurry.
>>
>> IIUC the proposed URI scheme:
>>
>>  http://{host}/entityhub/{site}/entity/{localname}
>>
> {site} refers to the ID of the referenced Site as configured for the Entityhub.
>
>> The http://mpii.de/yago/resource/Berlin entity, for example, would map to
>>
>>  http://example.com/entityhub/mpii.de/entity/Berlin
>>
>
> Thats correct if "mupii.de" is configured as ID for the Referenced Site
> Given your example I would rather expect users to choose "yago" as ID.
> In that case the URI would be
>
>  http://example.com/entityhub/yago/entity/Berlin
>
>> If I'm correct, why not use a more direct mapping like
>>
>>  http://example.com/hub/entity/mpii.de/yago/resource/Berlin
>>
>> by simply replacing http:// from the original ID with the constant
>> prefix "http://example.com/hub/entity" ?
>>
>> Locally-defined entities would then be something like
>> http://example.com/hub/entity/local/people/rupert
>>
>> (but maybe I didn't get it ;-)
>
> I like the general idea because it would allow for a unique URI space
> for all Entities managed by the Entityhub. Especially the "/local"
> prefix for entity sets that are managed locally and therefore can
> support rear/write access. Assuming that a typical user will not be so
> interested in what site is actually managing an Entity this is a good
> idea.
>
> However adopting this pattern would also require to rethink the URI
> scheme of other functionalities provided by the Entityhub because
> currently each referenced site has it's own JAX-RS resource that is
> bound to an URI.
>
>    http://example.com/entityhub/site/{siteId} ... for Referenced Sites
>    http://example.com/entityhub/sites/ ... for the Referenced Sites Manager
>    http://example.com/entityhub/symbol/ ... for locally managed entities
>
> Functionalities like retrieval and search are bound to sub paths
> e.g. for a referenced site to:
>
>    http://example.com/entityhub/site/{siteId}/entity?uri={uri} for
> retrieving entities by id
>    http://example.com/entityhub/site/{siteId}/find?name={pattern} for
> simple label based searches
>    http://example.com/entityhub/site/{siteId}/query?query={query} to
> parse other queries.
>
> The current URI scheme would therefore conflict with the URI scheme
> proposed by Bertrand's because it would not allow to insert "/entity",
> "/find", ... between the {site} and the {entityID}. IMHO to go in line
> with Bertrand's proposal one would need to encode such functionalities
> within the "prefix".
> See the examples below.
>
>    http://example.com/entityhub/entity/{entityID}[?uri={uri}]
>
> for retrieving entities either by parsing the local {entityID} or the
> remote {uri} of the entity as parameter.
>
>
>    http://example.com/entityhub/find{siteSelector}?name={pattern}[&site={siteId}]
>
> for searching Entities by name on all sites confirming to {siteSelector}.
> The {siteSelector} could be used as a prefix to select sites to be
> included within the search. e.g. "/local" would only search within
> locally managed entities.
> As an option one could also support to specify the site to search as parameter
>
>
>    http://example.com/entityhub/query{siteSelector}?query={query}
>
> for parsing queries.
>
>    http://example.com/entityhub/mapping  ... for defining mappings
>    http://example.com/entityhub/import ... for importing remote entities
>    http://example.com/entityhub/{futureFeature} ... extension point
>
>
> any opinions, suggestions?
>
> best
> Rupert
>
>>
>> -Bertrand
>>
>>> [1] http://incubator.apache.org/stanbol/docs/trunk/entityhub/entityhubandlinkeddata.html
>>
>
>
>
> --
> | Rupert Westenthaler             rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11                             ++43-699-11108907
> | A-5500 Bischofshofen
>



-- 
| Rupert Westenthaler             rupert.westenthaler@gmail.com
| Bodenlehenstraße 11                             ++43-699-11108907
| A-5500 Bischofshofen