Re: Issue-71: the first bug tracking example

> That's totally my point: the specification is not correct as is.

That is not what I said.  Tortured = hard to reliably interpret as 
intended.  "not correct" = applying the rules as stated leads to results 
*other than* the intended ones.  It might be both though.
If R1' doesn't force any behavior, then it allows B or !B.
B => C or !C
!B => C
Presumably since you like the B XOR C formulation, you see no problem with 
B && !C or !B && C, so we'll put those aside.
B&&C  might be consistent (both rdfs:member ... redundant, but consistent) 
or not (values disagree).  I read 5.2.4 to say that (when present) the 
ldp:membershipSubject fully determines the membership triples' subject 
URI; 5.2.5 lacks the equivalent final sentence from 5.2.4, which looks 
"not correct".  If they both had that sentence, I'd say correct in the end 
but still tortured.

> > You've lost the current recommendation (SHOULD) to use rdfs:member, or
> > your re-write is incomplete when it omits R1'.
...
> That change eliminates any ambiguity that the SHOULD brings, supports 
> the different use cases mentioned in this mailing list, and allows 
> defining a concrete test.

That 'should' really belongs in the deployment materials, it's for (yes, 
newbie) ontologists.
We've seen people who feel bad if they don't use Absolutely Every Feature 
in specs they exploit, even if they don't need to.

> In prose (omitting the three fist sentences that simply describe the 
> requirements below):
> 5.2.3 An LDPC representation MUST either use the rdfs:member predicate 
> or contain one triple with the ldp:membershipPredicate or 
> ldp:membershipPredicateInverse predicate when the membership predicate 
> comes from the server application vocabulary. An LDPC representation 
> MUST NOT use as membership predicate both rdfs:member and 
> application-specific membership predicates.

Generally works for me.  I think the original could be adjusted too, no 
strong preference since I think the intent is fundamentally the same.
Weeding out the deployment guidance is a Genuinely Useful Result in my 
mind whether or not the rest changes.

> I am asserting the need for a conformance model. :)

I actually thought we had an open issue for that, but checking the 
archives I see that -31 and the matching editors action -31 have closed.

> As an example, from your sentence, in your mind the specification is 
> covering four classes of products: LDPR clients, LDPR servers, LDPC 
> clients, and LDPC servers.

Actually, I was intending to assert nothing beyond the client/server 
distinction.  I intended to expose our loose language, since I have 
observed myself people saying all 4 (most commonly, R/C "server" pair). 
Prior to the submission I whined about it enough to get the language 
changed to levy requirements predominantly on implementations (client or 
server, I don't care, just be clear which) ... I tried for exclusively but 
things like that rdfs:member guidance (SHOULD) persisted in spots.  As you 
might imagine, resolving issue 32 requires nailing this down too.

>  From my point of view the specification does not cover clients (i.e., 
> we are not defining at all the behaviour of clients with the current 
> requirements in the specification, and we have no concrete use cases for 

> clients or test cases).

I'm pretty sure we do make one or two, MAYs IIRC, to render some 
implications explicit.  We found that devs writing clients were not always 
picking out the implications for client behavior for some scenarios when 
it was phrased only as server-side language.  Example: a GET-PUT round 
trip to update something when PATCH is not implemented - client should 
preserve content it does not recognize.  Maybe zero of those have survived 
this far, not sure.

> The point is not whether one of us is correct or not, but that two 
> different persons have different interpretations. And this does not 
> impede another person to come with a third one.

With you in theory; in practice I 80-20 it (some say at best I 95-5 it, 
but still...).

> That's where I see the need for a conformance model.

I thought -31 was still open (implicit WG +1 in that case), but since it's 
not open +1 to that.


Best Regards, John

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