RE: hydra:Link

On Saturday, March 15, 2014 1:03 AM, Gregg Kellogg wrote:
> 
> 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.

Exactly


> 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.

My current take at this is to put information which is specific to a certain
Web API in a ApiDescription document and reference it via an HTTP Link
header:

  Link: </api-doc>; rel="http://www.w3.org/ns/hydra/core#apiDocumentation"

It's important to not merge the inferred triples with the data you retrieved
from the Web API if you don't want to "pollute" your data.

Putting this information in a named graph doesn't have much advantages IMO
but, as you know, a couple of quite severe disadvantages. In any case, you
need to careful about what data to trust in a given context and how to
process it. Publishing named graphs don't really help here, but using them
to partition your data locally might.


> 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.

Yeah, you know my opinion about that :-) IMO, the consumer needs to be able
to reliably work with both forms (and cases that the plural instead of the
singular form and vice versa). If so, it actually becomes simpler to just
have to deal with a single property instead of two.


> 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 .

Yeah.. in principle this is quite similar as lists in RDF. They also
introduce intermediary nodes which "break" the direct link between the
nodes. It might make sense to discuss this in the spec.


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 18 March 2014 22:14:23 UTC