On Tue, May 24, 2011 at 11:08 AM, Bertrand Delacretaz <[email protected]> wrote: > Hi Rupert, > > On Mon, May 23, 2011 at 11:45 PM, Rupert Westenthaler > <[email protected]> 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 [email protected] | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
