- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Fri, 14 Mar 2014 17:03:03 -0700
- To: public-hydra@w3.org
The hydra:Link class is applied to a property URI to indicate that it is a de-referencable link. For example, if we had the following in a vocabulary: schema:colleague a rdf:Property, hydra:Link . A client would know that when it sees an IRI value of schema:colleague, it could be dereferenced, either to return a specific colleague (schema:Person), or perhaps a collection of colleagues (hydra:Collection) with hydra:member values which are the Person entities. The problem is, if I add this type to the predicate IRI, I'm making a universal assertion, and some other application might not support this as a link. In my particular application, In my application, I'm solving this (both for hydra:Class and hydra:Link) by asserting that information in a named graph, rather than the default graph, but you might equally well say that the hydra:Link should go someplace in the SupportedProperty description. For that matter, if I have a property that I've described as being a hydra:Link, the value of that property is presumably to a resource returning a collection, rather than the resource directly described as being, e.g., a colleague. If you build a graph from following these indirections, it leads to a graph which co-mingles entities of type hydra:Collection and schema:Person, in this example. I've also addressed this by using different properties (schema:colleagues vs schema:colleague), but this is probably controversial. Here's an example: </GreggKellogg> a schema:Person; schema:colleagues </GreggKellogg/colleagues>; schema:colleague </MarkusLanthaler>, ... </GreggKellogg/colleagues> a hydra:Collection; hydra:member </MarkusLanthaler>, ... </MarkusLanthaler> a schema:Person . Gregg Kellogg gregg@greggkellogg.net
Received on Saturday, 15 March 2014 00:03:34 UTC