- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Tue, 18 Mar 2014 23:13:31 +0100
- To: <public-hydra@w3.org>
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