- From: Arnaud Le Hors <lehors@us.ibm.com>
- Date: Tue, 21 May 2013 18:52:17 -0700
- To: Henry Story <henry.story@bblfish.net>
- Cc: public-ldp-wg@w3.org
- Message-ID: <OF6C9C1951.808FE4A6-ON88257B73.0002C891-88257B73.000A47D9@us.ibm.com>
Hi Henry,
Henry Story <henry.story@bblfish.net> wrote on 05/21/2013 11:40:01 AM:
> A few minor clarifications...
Thanks but I think you need a few more actually. :-)
>
> On 21 May 2013, at 20:00, Henry Story <henry.story@bblfish.net> wrote:
>
> > (resending to get w3c into issue tracker)
> > Let me take Nandana's first bug tracking example and show how one can
do
> > without membershipPredicate as set out by ISSUE-71.
> >
> > On 21 May 2013, at 18:30, Nandana Mihindukulasooriya
> <nmihindu@fi.upm.es> wrote
> > in the email at http://lists.w3.org/Archives/Public/public-ldp-wg/
> 2013May/0169.html
> >
> >> ----------------------- Model 1
--------------------------------------
> >>
> >> <http://example.org/app/BugTracker> a ldp:Container, bt:BugTracker ;
> >> ldp:membershipPredicate bt:tracksProduct ;
> >> bt:tracksProduct <http://example.org/app/BugTracker/ProductA> .
> >> ------
> >> <http://example.org/app/BugTracker/ProductA> a ldp:Container,
bt:Product;
> >> ldp:membershipPredicate bt:hasBug ;
> >> bt:hasBug <http://example.org/app/BugTracker/ProductA/Bug1> .
> >> ------
> >> <http://example.org/app/BugTracker/ProductA/Bug1> a bt:Bug;
> >> dcterms:title "Product A crashes when shutting down.";
> >> dcterms:creator <http://example.org/users/johndoe>;
> >> dcterms:created "2013-05-05T10:00"^^xsd:dateTime
> >> bt:isInState "New" .
> >
> > So a few remarks on this modelling, which I think is worth opening
> a new issue
> > for by itself on. Your model is confusing a thing - a bug - and
> an information resource
> > that describes it.
> > This means that it is not going to be possible later to identify
> two bugs with owl:sameAs
> > without coming to the conclusion that it was created at different
> times, by potentially two
> > people. It also means you cannot distinguish copyrights on the
> information content -
> > a creative commons licence - from the bug itself, which is not
> something that can be
> > licenced.
> > 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.
The modeling chosen in Nandana's example might not be correct but the
point you're making is orthogonal to the question at hand.
> >
> > So let me here try to bypass this problem and see how far I can go.
> > Let us say </bugs/> is our container with the following content:
> >
> > ~~~~~~~~~~
> > <> a ldp:Container, bt:BugReport;
>
> This should be named something like bt:BugReportContainer rather
> that bt:BugReport.
Indeed. I guess your proposal isn't immune to confusion either, is it? ;-)
> One could perhams even use owl Restrictions to define a class like that.
>
> > val:primaryTopicRestriction [ onProperty bt:product
> > hasValue <http://example.org/app/
> BugTracker/ProductA> ];
>
> So again this is a restriction of the primaryTopic of the members of
> the container.
> another name could be val:memberPrimaryTopicRestriction .
>
I have to admit not to understand what this has to do with the question at
hand. And if we can't defined LDP without OWL we've failed.
> > bt:member <bug1>, <bug2>, <bug3> .
How does a client know that bt:member is the predicate used in your
container to list the member resources?
Given your criticism of Nandana's modeling shouldn't you list bug reports
in your container rather than bugs here?
> >
> > # note that we add metadata on the information resource
> > # note also that the creator is the creator of the bug report, not
> the creator of the bug
> >
> > <bug1> dcterms:title "Product A crashes crashes when starting up.";
> > dcterms:creator <http://example.org/jack#me>;
> > dcterms:created "2013-04-05T10:00"^^xsd:dateTime .
> >
> > <bug2> dcterms:title "Product A crashes when shutting down.";
> > dcterms:creator <http://example.org/users/johndoe#i>;
> > dcterms:created "2013-05-05T10:00"^^xsd:dateTime .
> >
> > <bug3> dcterms:title "My pictures looks funny when I click the red
buton";
> > dcterms:creator <http://facebook.com/users/grannySmith#>;
> > dcterms:created "2013-05-06T11:23"^^xsd:dateTime .
> > ~~~~~~~~~~~
> >
> > So we assume we have some validation description that will be
> > arrived at by the rdf-validation group:
> > https://www.w3.org/2012/12/rdf-val/Overview.php
> > and that allows us to restrict the primary topics of posted content to
> > be about ProductA .
Why are you talking about validation here? How validation is performed has
nothing to do with the question at hand.
> >
> > From this a client would know that all members of the container are
> > bug reports, and that the bugs
>
> ... these bug reports describe ...
>
> > must be about about a specific topic.
> >
> > We publish metadata about <bug1> and <bug2> which are bug REPORTS, not
> > bugs. The Bug reports may themselves be buggy.
> > These bug reports would then say something simple like
> >
> > <bug1> log:semantics {
> >
> > <bug1> dcterms:title "Product A crashes crashes when starting up.";
> > dcterms:creator <http://example.org/jack#me>;
> > dcterms:created "2013-04-05T10:00"^^xsd:dateTime ;
> > foaf:primaryTopic <bug1#y> .
> >
> > <bug1#y> a bt:Bug;
> > bt:product <http://example.org/app/BugTracker/ProductA> ;
> > bt:isInState "closed";
> > bt:cause <http://other.project.org/bugs/bug100#y> .
> > }
Same point as earlier: you're calling "bug1" what is actually a bug
report, aren't you?
>
> ( I of course mean that the bug reports contain what is inside the
> parenthesis ie, after " <bug1> log:semantics { " )
Yeah, I don't think it helps to introduce such a syntax which isn't Turtle
here.
>
> >
> > And now the bug report <bug2>
> >
> > <bug2> log:semantics {
> >
> > <bug2> dcterms:title "Product A crashes when shutting down.";
> > dcterms:creator <http://example.org/users/johndoe#i>;
> > dcterms:created "2013-05-05T10:00"^^xsd:dateTime ;
> > foaf:primaryTopic <bug2#y> .
> >
> > <bug2#y> a bt:Bug;
> > bt:product <http://example.org/app/BugTracker/ProductA> ;
> > bt:isInState "open";
> > owl:sameAs <bug3#y> .
> > }
> >
> > Here an engineer determined that <bug2#y> was the same as <bug3#y>
though
> > he has two different bug reports
>
> which clearly are not owl:sameAs each other
>
> >
> > So now we have a case where it is clear how
> > 1. a client knows what to POST
>
> by looking at the restrictions on what the members are.
>
> > 2. the LDPC never uses anything else other than ldp:member
>
> I meant he never uses anything other than rdf:member
I take it you meant to use that rather than bt:member in your example?
>
> > 3. we correctly make the distinction between information resource
> and thing talked about
> (the bug report and the bug)
Not quite, as I pointed out, but that's again orthogonal anyway. You could
easily fix Nandana's example in that regard without throwing out
membershipPredicate.
I don't understand why you're tying the two - membershipPredicate and the
bug vs the bug report.
>
> > 4. and we don't need membershipPredicate
>
> which makes it easier to find the members since all members can be
> found simply
> by searching
> SELECT ?m WHERE { <> rdf:member ?m }
>
I really think there is a misunderstanding here. There is no question that
we could define a container model without membershipPredicate. The whole
point of having that predicate is to allow a container to be defined over
a resource that uses a different predicate from the one we would impose so
that people can define containers without having to abandon the vocabulary
they are already using.
I would also point out that people have expressed the need and we have
agreed to add membershipPredicateInverse for the same reason.
It also allows to define several containers over the same resource, as
example 3 in the spec demonstrates:
https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-ex-membership-full
We would lose all of this with what you are proposing and I'm still not
sure why.
For what it's worth we also have a mechanism that allows specifying which
predicates are used for ordering. The motivation behind it is the same. We
don't want to force people to use a specific predicate to specify the
order and instead allow people to specify which one(s) they use. It would
certainly simplify the spec if we removed that functionality but we'd also
be crippling the spec.
> >
> > It is true we need a vocabulary for restrictions on contents, but
> that we needed
> > anyway and that is something that clearly can be done by a group such
as the
> > RDF-Validation group https://www.w3.org/2012/12/rdf-val/Overview.php
> >
Again this isn't why we need membershipPredicate and for what it's worth
we cannot possibly depend on what "the RDF-Validation group" might do.
There is no such group at this point. There is merely a workshop to find
out whether there is anything the W3C should do in that space.
> > Hope this helps,
> >
> > Henry
> >
> > Social Web Architect
> > http://bblfish.net/
>
>
I thank you for taking the time to write this down but I think we need to
reconcile our objectives. you seem to be wanting to get rid of a lot of
functionality for the sake of simplicity. I don't think that's reasonable.
I like simplicity too but not at the cost of losing functionality people
want.
Regards.
--
Arnaud Le Hors - Software Standards Architect - IBM Software Group
Received on Wednesday, 22 May 2013 01:52:56 UTC