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

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 :-)

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

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

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 12:25:58 UTC