Re: Issue-71: the first bug tracking example

>From http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0176.html

> So this is a first reason why this type of modelling is not 
> standard, and not a good
> idea. And another reason why the ldp:membershipPredicate is going to
> walks straight
> into the -1 of a lot of people at the w3c if it is kept like that.

I don't understand your reasoning here Henry; how does "non-standard" 
modelling ... in informative examples ... result in anything more than 
comments that the examples need to be updated?  I have read through this 
entire thread w/o seeing the link.

I see plenty of opinion, and perhaps an implied threat, but not a logical 
argument.


>From http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0186.html

> Not at all. The current spec is pushing people to make bad modelling 
> decisions, which is why I think it is very problematic.

Again you lost me.  Where is the spec "pushing" any particular modeling 
decision? 


> Clearly part of the point of ldp:membershipPredicate is to tell people
> that by POSTing to the container they will be creating a new resource
> and they will be adding this new relation from the container to the 
> created resource. The idea is that a client is then supposed to 
understand
> what this relation means and agree to the addition of this relation, on 
> POSTing the content.
> 
> I think that this way of doing things is confusing three things:
> 
>  1. the role of containers as creators of resources
>  2. the role of restrictions on what can be POSTed
>  3. the meaning of POSTing a resource ( a new 
>     relation gets added somewhere )

ldp:membershipPredicate gives no (zero) guarantee that a container 
supports create.  Issue 32 et al. is to sort out the means of 
introspection.  A read-only container would still have to expose this 
predicate if it wanted clients to be able to tell which triples are part 
of the container's membership triples.

ldp:membershipPredicate says nothing (zero) about what can be POSTed. 
Period.  Cite counter-examples, because they're spec bugs.

ldp:membershipPredicate says something (incomplete, because it omits 
subject) about the pattern by which a client recognizes membership 
triples.  It happens to be true that if the container ALSO supports 
create, then (since a create implies addition of a membership triple) it 
says something about create.  But this is in implication relation, not 
equivalence.

You seem to be viewing the membership triple descriptions only through the 
lens of create.  I'm not sure what would lead to that behavior, but it's 
not the whole story and so it leaves you vulnerable to false conclusions.


> yes. Since the member is something created by LDPC it is somthing 
> that one should
> be able to GET, DELETE, etc. That is always going to be a document 
> of some form: ie
> something with a log:semantics or an atom:content .

Container membership is not limited to what was created via POST to the 
container.  PUT, PATCH, out of band means can all change membership.  So 
all conclusions starting with that premise are (at best) suspect.  The one 
above, specifically, is flat out wrong.


>From http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0208.html

> words of wisdom. representations always should be self-describing for 
the
> service domain. if i need a vocabulary to interpret the vocabulary (need
> the membershipPredicate info to be able to tell how membership is
> represented), this violates one of the main principles of REST. 

How is that?  REST does not allow indirection in definitions?  If the 
definition of the media type allows one to unambiguously define terms, and 
some clients behave differently based on how much of that vocabulary they 
understand, what is violated exactly?

> it also
> makes it virtually impossible to aggregate/combine resources, because 
when
> i start doing this, now what do i do? 

I think that's called a mapping.

> do i have two membershipPredicates
> and they apply to different members? can there be conflicts in these
> mappings? 

This sounds like you want to union two containers, or know a priori that 
two arbitrary containers are unionable.  Is that in UC&R already?  If not 
do we need to add it?

> if cannot take a LDP resource from one container and simply POST
> it to another container, then something is fishy. 

If you are saying that the POSTed-to container MUST accept an arbitrary 
container an input, I think you're outside today's spec (we do not require 
containers to create containers... we were silent on it and IIRC there is 
a resolution in the editor's queue to be more explicit about how it would 
work if the server supports it, but neither is a MUST).  Same UC&R 
question.

> can i do that with the
> current membershipPredicate model? how would a container keep track of
> various membershipPredicate mappings in various resources?

I could read your intent too many different ways to hazard an precise 
answer with any confidence.  General thoughts: since two containers 
(especially in the absence of ldp:membershipSubject) would always have 
membership triples with different subjects, in the absence of some 
alteration to the triples during the "combining" process I don't think 
you'd consider the result a single container.  Once you admit alteration 
during combination, assuming its nature is fairly arbitrary what problem 
is insoluble? 


>From http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0179.html

> If you use membershipPredicate without using membershipSubject, then you 

> are relating the container to the created resource, the thing that 
> can be DELETEd,
> PATCHed, etc... That is an information resource, or what you'd call 
> a document,
> which is a URL that does not end in #xxx as per the URI definition.

MAY be, not is.  See above.  Not all members were created by POSTing to a 
container.

> Since we can solve this bug tracking use case without 
ldp:membershipSubject
> at least as elegantly, it cannot be used as an argument to keep it.

The converse is also true.  Saying that a new greenfield example can be 
done without it is insufficient cause for removing it.  Especially when it 
was added for a different scenario - mapping containers existing resources 
non-disruptively.  Steve works on a product with exactly that intended 
usage in mind.  It sounds like sharing that concrete example would help 
people better understand it.  I got it from the reading, but I've been 
traveling in "change the server with NO client code changes required" land 
for more years than I care to admit so it would not surprise me if others 
needed it to be more concrete.  While brownfield scenarios sometimes cause 
one to make different choices than one would in an equivalent greenfield 
scenario, accommodating the additional scenarios is a really good way to 
jumpstart adoption.




Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario