W3C home > Mailing lists > Public > public-hydra@w3.org > June 2014

Re: How to avoid that collections "break" relationships (ISSUE-41)

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Mon, 2 Jun 2014 10:37:21 -0700
Message-Id: <02D32A58-3B8A-4CDE-8D49-6C79EDDAB77D@greggkellogg.net>
Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, "public-hydra@w3.org" <public-hydra@w3.org>
To: Ruben Verborgh <ruben.verborgh@ugent.be>
On Jun 2, 2014, at 1:17 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> 
> Hi Markus,
> 
> As you've asked for my feedback on this issue before,
> below are my thoughts on the wiki page (for which I thank you again).
> It's written from the perspective of clients,
> i.e., what things clients would be able to do as a result of the chosen solution.
> Additionally, I'll comment on things from my Semantic Web background.
> 
> TL;DR: linking through generic properties is the way to go.
> 
> 
> LINK TO THE COLLECTION VIA A GENERIC PROPERTY
> 
>    </alice> schema:knows </alice/friends/>.
> 
> rdfs:seeAlso is too generic and doesn't mean anything.
> So clients cannot conclude anything from this;
> it doesn't really add any functionality.
> 
> foaf:topic in that regard is not helpful;
> i.e., I would say that
>    </alice/friends/> foaf:topic </alice>.
> but NOT that
>    </alice/friends/> foaf:topic schema:knows.
> 
> hydra:hasCollection with "property" and "subject" seems better;
> it allows clients to derive that (all?) "allice :knows" triples will be there.
> However, "hasCollection" is unnecessary in that case,
> because "subject" already gives the needed information.
> Hence, the following is sufficient (1):
>    </alice/friends> :manages [
>        :subject </alice>;
>        :property schema:knows;
>    ].
> (where "manages" might not be the best term).

This is pretty much what Markus and I came up with, and makes manages look like LD Fragments, to me.

> However, do we need the extra "manages" indirection?
> Can't we just add the properties directly to </alice/friends>?
> Benefit of "manages": on thing could manage multiple other things.

Perhaps, but the indirection seems reasonable to me, and your point about using it for things other than collections illustrates this.

> In that regards, the "hasRelationShipIndirection" works too (2):
>    </alice> :hasRelationshipIndirection </alice/friends>.
>    </alice/friends> :property schema:knows.
> 
> The benefit of option (1) is that it is subject-centered.
> It says "this is a document with these properties",
> which seems easier to reuse in other contexts than a chain (2).
> On the other hand, (2) will show up if you enumerate all properties of </alice>.
> (But hey, we can equally enumerate all properties where </alice> is object.)
> 
> The first contra about "bigger payloads" doesn't really seem an issue.
> The second contra, well… that's what libraries are for. It's not _that_ hard.
> 
> 
> 
> USE OF A BLANK NODE COLLECTION MEMBER TO INDIRECTLY POINT TO THE COLLECTION
> 
>    </alice> schema:knows [ hydra:isMemberOf </alice/friends/> ].    (3)
> 
> From the client perspective, it allows to fiend friends of Alice.
> However, the semantics are not explicit about this.
> It could be that
> 
>    </alice> schema:knows [ hydra:isMemberOf </NationalSoccerTeamOfBrazil> ].
> 
> In all fairness, the second would not be as "interesting" to include in the response.

The other problem with this is that a BNode is more like an existential quantified, when a universal quantified is more appropriate. But, in RDF, it's not a variable, and a graph containing both this and an IRI with the same isMemberOf relationship would not resolve to the same node.

> Extra con: this breaks if </alice/friends> has no members,
> because (3) implies there is at least one member.
> 
> About the con "introduces an undesired triple": let's not forget it is an open world.
> If you see:
>    </alice> schema:knows </bob>, </conny>, </dennis>, </edna>.
> How many friends does Alice have?
> Only correct answer: "at least one",
> because those 4 URIs could point to the same resource.
> 
> 
> 
> USE OF A SEPARATE PROPERTY TO REFERENCE COLLECTIONS
> 
> This unnecessarily creates a lot of properties.
> I'm not in favor of this solution.
> Clients that can interpret "foaf:knows"
> should now find a way to interpret an additional property.
> 
> (Sidenote: it does emphasize how difficult it is to talk about collections in RDF.
> RDF was really designed for individuals.
> I would love if RDF 2.0 or something extends the model with collections, like so:
>    </alice> foaf:knows </bob>.
>    </alice> *foaf:knows </alice/friends>.
> But until that happens, let's not invent *foaf:knows ourselves.)

Maybe we can come back to that in 2023? :P RDF lists are also unsatisfactory for ordering property values.

> As far as the "use plural properties names" is concerned: no.
> URIs on the Web are opaque, end of story.
> Clients should not attempt dangerous things.
> 
> 
> USE OF AN OPERATION WITH AN EXPLICITLY DEFINED TARGET
> 
> No. We should be describing the declarative semantics here,
> not the operational semantics, for similar reasons including this one:
> operational can be inferred from declarative, but not the other way round.
> The only thing clients can do here is GET the thing,
> but nothing more interesting. We shouldn't write the scenarios for clients.
> 
> 
> 
> 
> MY PERSONAL CONCLUSION
> 
> It is my opinion that these two solutions are the best:
> 
>    </alice/friends> :manages [
>        :subject </alice>;
>        :property schema:knows;
>    ].
> 
>    </alice> :hasRelationshipIndirection </alice/friends>.
>    </alice/friends> :property schema:knows.
> 
> Both allow clients to find the friends easily
> based on a property that they are interested in.
> 
> I'm in favor of the first, as the blank node there
> describes a resource that is reusable and extensible.
> However, in both cases, we have to find the optimal terminology.
> In the first case, this comes down to identifying what the blank node is.
> 
> Terminology suggestion (just to help us think):
>    </alice/friends> :isCollectionOf [
>        rdf:type :CollectionItemTemplate;
>        :subject </alice>;
>        :property schema:knows;
>    ].
> (Note that the rdf:type could be hidden.)

I don't see that isCollectionOf does more than manages, and does bind it topic hotly to collections. I also don't see what a CollectionItemTemplate is, and even though property/subject/object should have a domain, it should probably be more generic, such as IndirectResourceManager, but in common practice it would be omitted.

> This would also account for cases where </alice> is the object:
>    </alice/followers> :isCollectionOf [
>        rdf:type :CollectionItemTemplate;
>        :property schema:follows;
>        :object </alice>;
>    ].
> 
> The semantics would then mandate be that:
> - for a given template, minimum 1 and maximum 2 components should be used
> - the collection contains all items of the dataset that match the template (possibly paged)

+1, although subject and object may be inferred from other statements.

Gregg

> Best,
> 
> Ruben
Received on Monday, 2 June 2014 17:39:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:53:59 UTC