Re: Issue-71: the first bug tracking example

El 29/05/13 14:53, John Arwe escribió:
>  > R1.- IF no membership predicate from server THEN SHOULD use rdfs:member
>  > R2.- IF membership predicate not rdfs:member THEN MUST use
>  > ldp:membershipPredicate or ldp:membershipPredicateInverse
>  >
>  > In a more simplified way:
>  > R1'.- IF not A THEN SHOULD B
>  > R2'.- IF not B THEN MUST C
>  >
>  > This has some problems:
>  > a) Even if in the mailing list people has been mentioned in several
>  > times that the specification is totally understandable and without
>  > ambiguity, for me statements such as these are quite difficult to
> interpret.
> It's not just you.  The language is tortured.  Sometimes it's hard to
> avoid, but I think in this case it is avoidable with some editorial
> attention [points to self, scribbles down to-do].

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

>  > b) In the case of R1', we are not really forcing an LDP server to behave
>  > in any way.
> That's true of any imperative other than MUST/MUST NOT, so not scary on
> its own.
> It's always a balancing act; every MUST/MUST NOT excludes
> something/someone.  That is their intent.  OTOH, every point of
> variability introduces complexity of at least one kind, and often
> several kinds.
>  > c) It is difficult (or even more than difficult) to define a test that
>  > is able to check these rules. And, without test, it is not possible to
>  > show that at least two implementations successfully satisfy our
>  > requirements.
> Not all requirements are testable.  That does not stop us from making
> them.  Eric P pointed this out explicitly during F2F2; I don't know if
> that was the first or last time, but I at least remember that one.  All
> other things being equal, of course, testable requirements are
> preferable.  The trick is agreeing with the antecedent.

Then we have to decide whether we want to have testable requirements in 
the specification or not.

Not having them prevents us from:
a) testing tools with them and showing that we have at least two 
implementations that satisfy those requirements
b) having a full coverage of the specification in terms of tests

>  > In this case, what we are doing is creating two profiles of servers
>  > (again, not invented by me, W3C terminology [2]): those with their own
>  > membership predicate and those without it.
>  >
>  > This is what we are right now doing in the specification, and it is
>  > something that I think we must not do in this working group.
> Having read the cited text's definition of profile, it's a stretch to
> say that's what we have here.  "Discretionary item" is a better fit IMO.
>   And BTW [2] is a Note not a Rec.

I'm not going to argue regarding whether we should follow W3C notes or 
terminology in this WG. But the fact is that they are there.

> So is it 'profile' in particular you are against, or this specific point
> of variability?

I'm not against anything. The point is to try to minimize variability 
for the sake of simplicity and to clearly describe the variability that 
we are defining so that it can be understood by a third party.

>  > Let's forget about profiles and just write the intuition that everyone
>  > has in their minds:
>  >
>  > R4'.- MUST B xor C
>  >
>  > Simpler, understandable and testable.
> I agree it's simpler in the abstract.  Less clear how well XOR renders
> in prose, but let's assume it's no worse.
> You've lost the current recommendation (SHOULD) to use rdfs:member, or
> your re-write is incomplete when it omits R1'.
> You've said that my server cannot both use rdfs:member and also assert
> the same via ldp:membershipPredicate ... which is not a crisis, but a
> subtle change.

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.

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.

>  > The drawback here is that we are making LDP clients quite difficult to
>  > implement. Note that these are the requirements only for membership
>  > predicates; just taking into account also those for membership subject
>  > will add another D (use itself as subject) and E (use
>  > ldp:membershipSubject). For the most simple interaction with a container
>  > the client will have to analyse 4 scenarios:
>  > Subject Predicate
>  > D       B
>  > E       B
>  > D       C
>  > E       C
> That's interesting; it doesn't seem nearly as complex to me.  I think if
> it as:
> ms = ( c, ldp:membershipSubject   ,?   exists ) ? ( c,
> ldp:membershipSubject   , ms ) : (c);
> mp = ( c, ldp:membershipPredicate ,?   exists ) ? ( c,
> ldp:membershipPredicate , mp ) : (rdfs:member);
> membershipTriples = ( ms, mp, ?)

Here complexity is not absolute, meaning that it is a hard problem to 
solve, it is relative regarding the case below.

>  > Let's drop profiles and ldp:membershipPredicate from LDP 1.0 and let's
>  > put ldp:membershipPredicate in the wishlist for LDP 1.1.
>  >
>  > R5'.- MUST B
>  >        (= MUST use rdfs:member)
>  >
>  > Simpler, understandable, testable, and straightforward to implement by
>  > clients.
>  > And, taking into account another relevant factor, this is the one that
>  > can lead to a smoother path for application interoperability.
> Sure, fewer choices makes interop easier.  Also reduces the number of
> implementations able to even attempt it.
>  > Note that here we also maintain variability:
>  > Subject Predicate
>  > D       B
>  > E       B
>  > but this is is something for another discussion: the need to define a
>  > clear conformance model for the specification that clearly specifies
>  > classes of products covered, variability, etc.
> Are you asserting a need in the conformance model for any division
> beyond LDPR/C clients/servers?

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

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.

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

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.

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

Kind regards,


Dr. Raúl García Castro

Ontology Engineering Group
Departamento de Inteligencia Artificial
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19

Received on Thursday, 30 May 2013 07:56:00 UTC