- From: Roger Menday <Roger.Menday@uk.fujitsu.com>
- Date: Tue, 21 May 2013 23:01:25 +0100
- To: Henry Story <henry.story@bblfish.net>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <4806AFC0-1992-4550-809A-30521C8D28F0@uk.fujitsu.com>
>> >>> (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. >> >> Henry, >> >> Can you be more explicit about the connection between the modelling style and the implication for the general usefulness of membershipPredicate ? > > 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. > > The membershipPredicate way of doing things is proposing a pattern that > will lead developers to think of the problem in the wrong way, and as > Nananda did lead them to make the created resource be some > object in the world other than the GETable PUTable etc document. If I understand your point correctly, I don't think you can blame membershipPredicate for that. It is possible that you could blame the *lack of* membershipObject. Actually, I think that is a gap in the current spec. But, I think it can be resolved without throwing everything out. e.g. my proposal at the end of [1] addresses it I think. Roger [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0120.html > As I showed you can get the same information you need whilst still keeping > the distinction between the container and its members - things the Web > Server deals with - distinct from the logic of the things described by > those documents. > > Furthermore it is close to the Atom way of doing things so it should be > relatively easy to understand, and as Erik Wilde pointed out a few times > it allows clients to keep track of resources on the server by following > ldp:member properties from a root 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. > >> >> Roger >> >> >>> >>> 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; >>> val:primaryTopicRestriction [ onProperty bt:product >>> hasValue <http://example.org/app/BugTracker/ProductA> ]; >>> bt:member <bug1>, <bug2>, <bug3> . >>> >>> # 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 . >>> >>> From this a client would know that all members of the container are >>> bug reports, and that the bugs 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, for example. >>> 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> . >>> } >>> >>> 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. >>> >>> So now we have a case where it is clear how >>> 1. a client knows what to POST >>> 2. the LDPC never uses anything else other than ldp:member >>> 3. we correctly make the distinction between information resource and thing talked about >>> 4. and we don't need membershipPredicate >>> >>> 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 >>> >>> Hope this helps, >>> >>> Henry >>> >>> Social Web Architect >>> http://bblfish.net/ >>> >>> >> > > Social Web Architect > http://bblfish.net/ >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Tuesday, 21 May 2013 22:02:21 UTC