Re: hydra:Link (ISSUE-41)

On Mar 21, 2014, at 7:52 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On Wednesday, March 19, 2014 10:44 PM, Gregg Kellogg wrote:
>> Vering in to N3 syntax (and changing vocabularies), for the moment, an
>> alternative way of referencing a collection could be through a BNode:
>> 
>>    </GreggKellogg> a foaf:Person;
>>      foaf:knows [is hydra:member of </GreggKellogg/colleagues>]
>> 
>> Alternatively, if we mint a hydra:isMemberOf property as the inverse of
>> hydra:member:
>> 
>>   </GreggKellogg> a foaf:Person;
>>      foaf:knows [hydra:isMemberOf </GreggKellogg/colleagues>]
>> 
>> (JSON-LD and RDFa both have nice support for reversed properties, so
>> creating such a property probably isn't necessary.
>> 
>> This ends up using the BNode as an existential quantifier for any
>> member of the colleagues collection, so doesn't create anything which
>> would be inconsistent. Dereferencing the is member of relation gets a
>> collection (or possibly, paged collection), which doesn't assert that
>> it is, itself, a colleague. After pulling in the collection, and
>> performing RDFS entailment, you'd get the following:
>> 
>> </GreggKellogg> a foaf:Person;
>>  foaf:knows
>>    [a foaf:Person; is hydra:member of </GreggKellogg/colleagues>],
>>    </MarkusLanthaler> .
>> 
>> <MarkusLanthaler> a foaf:Person .
> 
> Hmm... I think this is a bit too clever and still creates a triple that you
> don't want.

The notation is clever, just because Turtle doesn't allow me to express this. The notation in JSON-LD is straightforward IMO.

The concept of indirecting through another resource is basically a property path; it may be sophisticated, but it avoids asserting unnecessary triples (at least with IRI subjects). It does create additional BNode-subject triples, but in the context of Linked Data, these can be seen as necessary "semantic glue", and are easily filtered.

>> These statements are entirely consistent, and the BNode is rather more
>> easily ignored than a collection IRI.
> 
> This is a case where we should look at LDP [1], as Paul suggested some time
> ago. LDP allow you to describe a "DirectContainer" (I find the naming quite
> confusing) as follows:
> 
>    </GreggKellogg> a foaf:Person ;
>        foaf:knows </MarkusLanthaler> .
> 
>    </GreggKellogg/friends> a ldp:DirectContainer;
>        dcterms:title "Gregg's friends";
>        ldp:membershipResource </GreggKellogg>;
>        ldp:hasMemberRelation foaf:knows;
>        ldp:contains </MarkusLanthaler> .
> 
> The problem I have with LDP is that it hardcodes the complete interaction
> model. It's also kind of tricky to "find" such a container. You have to
> traverse the graph along non-materialized, reverse properties which is not
> exactly straightforward IMHO.
> 
> 
>> In JSON-LD, it could look like the following:
>> 
>>    {
>>      "@context": {
>>        "foaf": "http://xmlns.com/foaf/0.1/",
>>        "hydra": "<http://www.w3.org/ns/hydra/",
>>        "memberOf": {"@reverse": "hydra:member"}
>>      },
>>      "@id" "GreggKellogg",
>>      "foaf:knows": {"memberOf": "GreggKellogg/colleagues"}
>>    }
>> 
>> It does mean that saying foaf:knows is a hydra:Link isn't sufficient,
>> but saying hydra:isMemberOf is a hydra:Link would be, and wouldn't need
>> to be asserted on any other property for an API to be able to perform
>> reasonable dereferencing.
> 
> While I don't really like the specific blank node solution you are
> proposing, I find the principle quite interesting. We could avoid the blank
> node, and thus a triple we don't want, entirely but just including a member
> of collection directly:
> 
>    {
>      "@context": {
>        "foaf": "http://xmlns.com/foaf/0.1/",
>        "hydra": "http://www.w3.org/ns/hydra/core",
>        "memberOf": { "@reverse": "hydra:member" }
>      },
>      "@id" "GreggKellogg",
>      "foaf:knows": {
>        "@id": "MarkusLanthaler,
>        "memberOf": "GreggKellogg/colleagues"
>      }
>    }
> 
> WDYT?

This would work fine, except for empty collections. I would settle on this as a compromise if the BNode-based relationship I suggested is not palatable. Personally, I think the use of a BNode is a better call to dereference the memberOf relation to get values, whereas filling in on value might not make it clear that it is just a single representative member of such a collection.

Considered as a SPARQL query, the use of a BNode indirection is something like the following:

SELECT ?member ?p ?o
WHERE {
  </GreggKellogg> a foaf:Person .
  ?container hydra:member ?member .
  ?member ?p ?o .
}

Which has a certain appeal to me.

I'd like to hear other people's thoughts on the merits of a direct collection relationship vs. an indirect relationship, and the problem that asserting a Collection as the value of a property who's range is something else presents.

Gregg

> --
> Markus Lanthaler
> @markuslanthaler
>

Received on Friday, 21 March 2014 16:45:14 UTC