Re: About the ldp:xyz relationship

Henry Story <henry.story@bblfish.net> wrote on 12/05/2013 09:13:58 AM:

> ...
> The point of ldp:member is to relate the resources created by the 
> container and those that when
> deleted or PATCHed change the container. The comment next to the 
> rdfs:range line makes this clear: 
> "this is intended to refer to the set  of LDPRs and LDP Binaries. 
> Find a name for it."

Ok. Then it really should be called something else, like 
ldp:memberResource as in the "information resource of the member", because 
as I said this may be the member or not.

> 
> rdfs:Resource will not do as a range of ldp:member. It covers much 
> to large a field: it covers 
> every possible object, where we only want ldp:Containers, 
> ldp:Resources and ldp Binaries.

Who's "we"? Surely not everyone. The whole point about 
insertedContentRelation was to do exactly that: allow members to be 
anything. That "anything" is to be found by the server by looking for the 
predicate specified via insertedContentRelation in the content that is 
POSTed.

> ...
> So the point of ldp:member is clearly  much closer to what ldp:xyz 
> is trying to get at,
> since it is trying to tie Information resources together that the 
> container is managing.
> I'd like to think the server is not managing SteveS above.
> 
> 
> > If we were to replace ldp:memberResource by ldp:member we would 
> wrongly imply that <http://example.org/steves> is the member when itis 
not. <
> http://example.org/steves#me> is the member. 
> 
> I'd say you'd completely rightly infer that  <http://example.org/steves
> > is the ldp:member ,
> and completely wrong to say that <http://example.org/steves#me> is 
> the ldp:member .
> 

Since we agree on that we should agree that calling <
http://example.org/steves> the ldp:member  and <
http://example.org/steves#me> the member is bound to confuse people. This 
is why I said ldp:member is a bad choice.

> ...
> The problem came way before that. Calling these relations 
> "membership triples", then allowing the subject to point
> to any object in the universe, then allowing any relations and 
> allowing their inverses. That lead to the obvious 
> question why the only object of these triples were information 
resources.
> 
> I don't have any trouble with ldp:insertedContentRelation .
> 
> But ldp:member is not a relation that relates ANY object to any 
> OBJECT. It is exactly
> to the contrary the relation that relates ldp:Container-s to 
> ldp:Resource-s Union ldp:Binaries .
> 
> > 
> > If anything this tells me that it's a bad idea to use ldp:member 
> the way we do with SimpleContainer because it's going to be 
> misleading people into believing that a member is necessarily an 
> ldp:Resource when it's not. rdfs:member would be better suited. 
> 
> the problem is your use of "member" in "membership triples" in a 
> completely unintuitive way, 
> and has nothing to do with the english word member.  In english a 
> member is always a member OF
> something. In the membership triples one has no idea what is the 
> member relation, what object
> is the member of what. (unless one then consults the rules, which 
> can tell one what the ldp:xyz
> (a.k.a ldp:member ) is.
> 
> This is argued by ISSUE-85 "membership triples misnamed"
>   https://www.w3.org/2012/ldp/track/issues/86
> 

This isn't my use of "member". I'm merely going by what's in the spec and 
this wasn't designed by me.

I understand that this isn't what _you_ would referred to as membership. 
And you may not be the only one but it's not like everyone else agrees 
with you either.

I know of several other people who have no problem with it. Including 
Martin Nally who is British and therefore a native English speaker, and 
who happens to be one of the most pedantic persons I know when it comes to 
the use of the English language, including in APIs. So I can say with 
confidence that not all native English speakers would agree with you on 
whether this is a proper use of the term "member". :-)

Eric also clearly stated on Monday's call that he didn't have a problem 
with it and actually liked the idea of being able to specify membership 
based on domain specific vocabularies.

Let's agree that people have different views on that point and let's stop 
arguing on what can legitimately be referred to as "member" and 
"membership", be cause this conversation is going nowhere. 

To clarify, I don't see the problem you see but I don't have a personal 
preference. As chair, my interest is in driving the group towards a 
solution that works for everyone. The only reason I got so involved in 
this conversation is to try and bridge the gap I see in the group and try 
to clarify what I think is in the spec hoping this would make the 
conversation easier.

> 
> Anyway on the definition that was accepted of ldp:member,

There may have been some misunderstanding on what we were agreeing on 
here. I for one thought we were agreeing to define ldp:member in the spec, 
for the sake of being able to use it with SimpleContainer, not necessarily 
as you proposed to define it. The resolution was simply to "add ldp:member 
to the spec". But, I have no problem starting with your proposal for a 
definition.

> ...
> ldp:xyz goes beyond ldp:memberResource. 
> As I understand ldp:memberResource replaces ldp:created. And ldp:created
> was just linking an LDPC to an ldpr that was created via POST. 
> 
> ldp:xyz goes beyond that in that it also covers resources that may not
> have been created by a POST. As long as the expectation of the client 
> that interacting with them is the same as if they had, it is an 
> ldp:xyz element
> of the LDPC.
> ...

Ah. I see what you mean. Because we decided to make ldp:created mandatory 
in the case of an IndirectContainer I took it as meaning that it would be 
there independently of how the resource is created. But you're right, this 
was not clearly stated though. Now that we separated the different types 
of containers I wouldn't expect anyone to object to it but we should 
check. If that's the case then they really are the same.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group