Re: Issue-71: the first bug tracking example

El 22/05/13 20:00, Alexandre Bertails escribió:
> On 05/22/2013 11:14 AM, Henry Story wrote:
>>
>> On 22 May 2013, at 16:41, Arnaud Le Hors <lehors@us.ibm.com> wrote:
>>
>>> Henry Story <henry.story@bblfish.net> wrote on 05/22/2013 06:27:17 AM:
>>>
>>>> ...
>>>> I have no idea what you mean "define containers without forcing
>>>> people to change their vocabulary".
>>>> The question is what is the UC&R for this functionality? Where does
>>>> it come from? What is the
>>>> need? (I mean for the protocol)
>>>
>>> This is about allowing people to expose existing data in which they
>>> have been using something like Nandana's bt:hasBugReport predicate or
>>> something similar without forcing them to change the representation
>>> of their data to use rdf:member.
>>
>> I don't see how we are forcing people to change their data given that
>> the LDP spec
>> is not finished and this is in flux.
>
> Henry may have some crazy ideas from time to time, but I have to admit
> that on this one, I'm on his side.
>
> My biggest fear is LDP to become a mini-language whose semantics
> (eg. container membership) would depend on an external domain
> model. There should be *only one way* to speak about membership.

Dear all,

Here comes my point of view, which is different from those mentioned up 
to now.

In the current specification, I think that we are not successfully 
managing variability and this is leading us to plenty of discussions and 
problems (when defining examples, use cases, tests, etc.).

A correct management of variability is not something I would like to 
see, but a requirement from W3C [1].

One aspect related to this is the writing of conformance requirements; 
in this case we are writing them using the RFC 2199 keywords (MUST, 
MAY, etc.).

In this concrete case (shortening the text to simplify the email in a 
semantically-equivalent format), here you have the conformance 
requirements that we are imposing for membership properties in the 
current specification:

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.
b) In the case of R1', we are not really forcing an LDP server to behave 
in any way.
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.

We have to possible solutions here, and in this group we like 
alternatives, so here they are:

Alternative 1
-------------

A way of rewriting the previous requirements maintaining their meaning is:
R1'.- IF not A THEN SHOULD B
R3'.- IF A THEN MUST C

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.

Alternative 2
-------------

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.

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

Alternative 3
-------------

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.

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.

Kind regards,


[1] http://www.w3.org/TR/qaframe-spec/#variability
[2] http://www.w3.org/TR/spec-variability/#subdivision-profile

-- 

Dr. Raúl García Castro
http://delicias.dia.fi.upm.es/~rgarcia/

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, 23 May 2013 07:51:28 UTC