Re: hydra:Link

On Mar 18, 2014, at 3:13 PM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

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

Okay, if it's kept separate, then a client could conceivably simultaneously use two different Hydra-based services and not confuse the claims about the first with those of the second. If I were implementing such a system using RDF, I would likely keep information separate by placing either in different datastores, or in different named graphs, but this is different than the provider using named graphs for the same purpose, as it gives more license to the client.

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

It's an issue that others will face, so I think it's a good idea to recognize this in the spec, and perhaps suggest some best practices for dealing with the potential confusion. However, note the potential for RDFS inference confusion, if the range of schema:colleague is schema:Person, then </GreggKellogg/colleagues> could be inferred to have the type schema:Person, where it might be declared as hydra:Collection. Saying that hydra:Collection is disjoint with schema:Person might solve this, but it might also create a contradiction (Ruben?). (This is not really a problem if using the schema.org vocabulary, as they use schema:rangeIncludes instead of rdfs:range, which has unspecified inference semantics. Practically speaking, the Structured-data linter treats schema:rangeIncludes as equivalent to rdfs:range, if there is only one such statement on a given predicate, as type inference can be quite powerful, but that's only my own take).

Gregg

> --
> Markus Lanthaler
> @markuslanthaler
> 
>

Received on Wednesday, 19 March 2014 17:35:26 UTC