- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 22 May 2013 01:04:09 +0200
- To: Roger Menday <Roger.Menday@uk.fujitsu.com>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-Id: <10BDF141-2E89-43E5-B10C-4C28DB5950F6@bblfish.net>
On 22 May 2013, at 00:01, Roger Menday <Roger.Menday@uk.fujitsu.com> 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. >>> >>> 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. That's one way of looking at it. But then this gap may be a lot more difficult to fill in than you think, and that is perhaps why it is not in the spec. And there may be other complexities hiding behind such a relation once it is in place. > But, I think it can be resolved without throwing everything out. e.g. my proposal at the end of [1] addresses it I think. And the other way of looking at it is that there is no gap. That was the point of my two e-mails. You can do what you need without those relations. You just need to think about the problem differently. And since you don't loose anything you need from the UC&R we might as well throw these out. They just clutter the visiblity to the simple underlying answer that was there all along. > > 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/ >> > Social Web Architect http://bblfish.net/
Received on Tuesday, 21 May 2013 23:04:45 UTC