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

On Saturday, June 07, 2014 5:54 PM, Ruben Verborgh wrote:
> > So, if we would like to describe that an HTTP LINK operation supports
> > the creation of certain links, how would we describe that?
> 
> FWIW, this is better modelled using a collection and I would simply do it
that way.

Right. I should have used UNLINK instead. Consider a "knows" collection.
It's trivial to add people. But how do you remove them again? If you don't
use reified statements it becomes messy:

    /markus knows /ruben

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. 


> > It is a tradeoff, do we want to keep the vocabulary small at the cost of
> > vaguer names or do we prefer to have more explicit names at the cost of
a
> > bigger vocabulary? I generally lean towards the former.
> 
> As a general strategy, yes.
> But that's a heuristic, things have to be evaluated on a case-by-case
basis.
> 
> 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?


> >>> We might decide to reuse it at a later point to
> >>> describe operations in more detail. It could for instance also be used
to
> >>> indicate that an HTTP Link operation can be used to manage certain
> >>> subject/property pairs.
> >>
> >> But that's not aligned with what you wanted to express above:
> >>
> >>> it indicates what kind of triples can be found in the collection.
> >
> > Why not? Doesn't the information about "what kind of triples can be
found in
> > the collection" help clients to decide "why they might or might not be
> > interested in a collection"?
> 
> 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?

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?

  /markus/friends/ a Collection
      relationshipTemplate [
          subject /markus
          property schema:knows
      ]


  [ a Operation
      method "UNLINK"
      relationshipTemplate [
          subject /markus
          property schema:knows
      ]
  ]


> > Summarized, I think we found a pattern for collections which everyone
can
> > live with. AFAICT, there are three open issues:
> >
> >  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?


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 9 June 2014 19:32:27 UTC