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: Tue, 10 Jun 2014 10:16:04 -0700
Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, public-hydra@w3.org
Message-Id: <E7C97376-345F-43DD-8973-B99CBEA61FE3@greggkellogg.net>
To: Ruben Verborgh <ruben.verborgh@ugent.be>
On Jun 10, 2014, at 5:25 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:

> Hi Markus,
> 
>> You can't DELETE /ruben because that would remove all information about
>> /ruben. An UNLINK "knows /ruben" on /markus is thus the most design IMO. 
> 
> I'm unsure; LINK and UNLINK usage is still too premature.
> A PATCH would be clearer to me.
> (But anyways, we're losing track of the original point I'm afraid.)
> 
>>> In this particular case, my judgment is that "manages" is too vague
>>> and is better served by a more specific property.
>> 
>> OK, let's try it. What other terms apart from isCollectionOf would be fine
>> for for you?
> 
> Brainstorm below (not necessarily all valid options, just to keep ideas flowing):
> 
> - </alice/friends> :collects [ :subject </alice> :property foaf:knows ]
> - </alice/friends> :collectionTemplate [ :subject </alice> :property foaf:knows ]
> - </alice/friends> :hasCollectionTemplate [ :subject </alice> :property foaf:knows ]
> - </alice/friends> :contains [ :subject </alice> :property foaf:knows ]
> - </alice/friends> :containsTemplate [ :subject </alice> :property foaf:knows ]
> - </alice/friends> :consistsOf [ :subject </alice> :property foaf:knows ]
> - </alice/friends> :provides [ :subject </alice> :property foaf:knows ]
> - </alice/friends> :lists [ :subject </alice> :property foaf:knows ]
> - </alice/friends> :organizes [ :subject </alice> :property foaf:knows ]
> - </alice/friends> :handles [ :subject </alice> :property foaf:knows ]
> 
> (Note that these last proposals go in the direction of manages;
> I'm trying to pinpoint the term more precisely—not saying I'm succeeding :-)

In the spirit of not trying to bind this too closely to collections:

contains – Probably not quite right. This seems more like an enumeration, rather than a template.
containsTemplate – This seems to satisfy the criteria of a template describing things which are contained in a collection (or something else)
consistsOf – same as contains
provides – This is reasonable
lists – hmm
organizes – pretty much equivalent to manages IMO
handles – pretty much equivalent to manages IMO

So, I'd go with one of containsTemplate, provides, organizes, handles, or manages. The containsTemplate probably has the most meaning, but is a mouth-full. Provides might actually be the best.

containsTemplate: +0.5
provides: +0.6
organizes: 0
handles: 0
manages: 0


>>> Miscommunication, sorry-I was referring to the non-alignment of:
>>> - "it indicates what kind of triples can be found in the collection."
>>> - "It could for instance also be used to indicate that an HTTP Link operation
>>> can be used to manage certain subject/property pairs."
>>> 
>>> Those are different things.
>> 
>> Really? If I understand you correctly, you don't like "manages" that much
>> because it implies some form of activity/behavior/interaction even though
>> the collection could be completely static, i.e., not support any
>> state-changing operations. Is that correct?
> 
> No, because it (only) emphasizes the action,
> and IMHO far less expresses the intent that X is simply a collection of Y
> (which seems to be the intended primary semantics,
> cfr. "it indicates what kind of triples can be found in the collection.").
> 
>> Let's say the "manages block" (as it was called in a different thread) is a
>> "triple template", a "relationship", or a "relationship template". Would you
>> agree that both the collection and the LINK operation "deal" with such
>> templates? Does something like relationshipTemplate look any better for you?
> 
> It emphasizes the collection membership more, yes.

It could also be considered to be a relationship constraint or expression.

>>>> 1) Do we want to introduce something like hasCollection?
>>>> 2) Should we rename "manages"?
>>> 
>>> For me those, two belong together:
>>> drop manages and have a clearer name for
>>>  "it indicates what kind of triples can be found in the collection."
>>> 
>>> But to simplify:
>>> 
>>> 1) +1
>>> 2) no, drop it
>> 
>> Sorry, you lost me here. Isn't dropping manages and have a clear name for...
>> exactly the same as renaming manages?
> 
> Yeah, another way would be 1) no 2) yes; doesn't really matter :-)
> 
>>> Note: whatever the property is going to be,
>>> we must definitely also ensure the "manages block" has a name.
>>> Right now, it's hard to say what a "manages block" is and isn't.
>> 
>> Anyway, do you think "triple template", "relationship", or "relationship
>> template" would be reasonable names for this?
> 
> Sure! Although it depends on the eventual property name.
> "manages" and "triple template" don't combine well;
> "relationshipTemplate" and "relationship template" of course do.

I could live with that.

Gregg

> Cheers,
> 
> Ruben
> 
> PS I don't feel as strongly about this particular issue as some e-mails seem to indicate;
> I just want to help ensure that we pick the right names for terms.
Received on Tuesday, 10 June 2014 17:16:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:42 UTC