- From: Roger Menday <roger.menday@uk.fujitsu.com>
- Date: Fri, 13 Dec 2013 15:58:51 +0000
- To: Henry Story <henry.story@bblfish.net>
- CC: Steve K Speicher <sspeiche@gmail.com>, Arnaud LeHors <lehors@us.ibm.com>, Linked Data Platform WG <public-ldp-wg@w3.org>
- Message-ID: <00672D7F-75D3-4B0C-84BC-5B4A0AC72C73@uk.fujitsu.com>
Henry, Whilst the path between a product and a bug is probably something like: product --hasbug--> bug ... you are saying: product --bugreportcollection--> bugcollection --ldpcontains--> bug I have a number of problems with this. For a start, this becomes more difficult to query. thanks, Roger On 12 Dec 2013, at 22:28, Henry Story wrote: > > On 12 Dec 2013, at 21:26, Steve Speicher <sspeiche@gmail.com> wrote: > >> Hi Henry, >> >> Let me try to reiterate the use case we've discussed. >> >> On Thu, Dec 12, 2013 at 2:01 PM, Henry Story <henry.story@bblfish.net> wrote: >> > >> > >> > On 12 Dec 2013, at 19:20, Arnaud Le Hors <lehors@us.ibm.com> wrote: >> > >> > > While true, it's been pointed out before, several times, that this would fall short of addressing the use case at hand: allowing one to define a container over existing data by leveraging a domain specific vocabulary. >> > >> > I am not sure I understand. The use case is I suppose that one should >> > be able to publish existing data using LDP. It can't be a requirement >> > to publish the data in an LDPC in particular. >> > >> > It seems obvious that one can publish any data in an LDPR ( that is not >> > an LDPC of course ). So the use case is satisfied anyway. >> > >> > Can anyone explain in particular why the data MUST be placed in an >> > LDPC? >> >> Because that how my model structured being part of a container-like structure, prior to LDP spec, and I want to apply LDP to it. I shouldn't need to setup a LDPC to the side of my model but apply to it. Take example 6 from the primer[1], it is an example of this. > > Example 6 from the primer is very badly modelled. It is confusing the LDPContainer with a product. > Unless the product is the container itself, in which case it is a very odd container that has so many bugs. > (I would not use a container that has so many bugs). > > Presumably the product should be something other than the container. It would then need > another LDPG that can describe that product, in order to make it easy for a client to edit > ( using PATCH ) without getting confused about relations that are managed by the container > - such as ldp:xyz, a.k.a. ldp:contains relations - and those that are relations about the product > ( such as its size, its date of creation, its owner, its price, etc, and that may be managed by human > managers ). > > So we could have the following resources > > </app/product1> <- the document about the product > </app/product1#v1> <- the real product > </app/product1/bugs/> <- the bugs about the product > > You don't even need anything more than a ldp:SimpleContainer as > I can show below: > > The product description can be found with the following > > [[ > GET /app/product1 > > <#v1> a > dc:title "Semantic Web For the Working Ontologist"; > shop:price "38"^^currency:dollars; > bt:bugReportCollection <bugs/> . > ]] > > The bugs collection linked from the product can also be found by following > your nose from above: > > [[ > GET /app/product1/bugs/ > > <../product1> bt:bugReportCollection <> . > <> a ldp:SimpleCollection; > ldp:contains <bugReport1>, <bugReport2>, <bugReport3> . > ]] > > > • Looking at that </app/product1/bugs/> collection one can find what product is the subject of the collection. > • POSTing to /app/product1/bugs creates new bug reports > • DELETEing a bug report is the understood way to remove it from the LDPC > • There is no duplication of triples here anywhere > > >> Additional context is that there are a number of data sources that expose similar models (servers emitting Linked Data resources). So basically it has membership predicate bt:hasBug, you can infer ldp:xyz from it. Using the approach Henry outlined below it opposite what I need. I already know the membership triples. > > If I map this to programming languages this seems like what you are saying is that a List or a Set is not enough > to represent a collection, that you need the relations in each list to be a different type of relation. > > But usually in programming languages one models such things by creating an object with an attribute to a collection > of things. Eg: > > { > name: "Semantic Web For the Working Ontologist"; > bugs: [ bug1, bug2, bug3 ]; > } > > where the collection [ bug1, bug2, bug3 ] here is a list, where the relation from one member of the list > to the next is always the same relation ( e.g.: rdf:first, rdf:next ). > > Here for some reason you seem to be requiring that each collection have a different > type of relation, but that the subject of the collection be an LDPC and the object be an LDPR. > There are so many other ways of modelling this that seem to be better, and that would > make the specification simpler, and the work of clients easier. > >> >> We've already cover this use case quite a bit. I believe for DirectContainers, the ldp:xyz could be inferred for those clients that need it. Instead of requiring that burden on all servers to explicitly produce these (c, ldp:xyz, mr) triples that are very simple for those clients that need it to produce it. > > I think I show above that you get what you want without the need for DirectContainers, without the need for duplicationg relations, > and without needing clients to do odd inferencing. > >> >> [1] - https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html > > > >> >> - Steve Speicher >> >> > >> > >> > > It's this new relationship that should be inferred. >> > > -- >> > > Arnaud Le Hors - Software Standards Architect - IBM Software Group >> > > >> > > >> > > Henry Story <henry.story@bblfish.net> wrote on 12/12/2013 09:27:28 AM: >> > > >> > > > From: Henry Story <henry.story@bblfish.net> >> > > > To: Linked Data Platform WG <public-ldp-wg@w3.org>, >> > > > Date: 12/12/2013 09:31 AM >> > > > Subject: Issue-89, proposal 3: Duplication of triples & inferencing >> > > > >> > > > Part 3 of Issue-89 creates a relation ldp:propertiesOnlyResource >> > > > to allow an LDPC to point in its header to the "membership properties". >> > > > The reason for this is to avoid so called duplication of triples. >> > > > >> > > > The duplication of triples is an issue mostly for the >> > > > ldp:DirectContainer as is visible for a container such >> > > > as the following >> > > > >> > > > <> a ldp:DirectContainer; >> > > > ldp:containerResource <>; >> > > > ldp:containsRelation m:manages; >> > > > ldp:xyz <doc1>, <doc2>, <doc3> ; >> > > > m:manages <doc1>, <doc2>, <doc3> . >> > > > >> > > > ( I am using ldp:xyz for what alexander in ISSUE-89 calls >> > > > ldp:contains. You can replace it without loss here and >> > > > throughout this e-mail. ) >> > > > >> > > > But according to the rule such as the one used in the Membership wiki [1] >> > > > it would be very easy to determine the "membership triples" using only >> > > > the ldp:xyz relations >> > > > >> > > > PREFIX ldp: <http://www.w3.org/ns/ldp#> >> > > > >> > > > CONSTRUCT { ?subject ?predicate ?object } >> > > > WHERE { >> > > > ?ldpc a ldp:DirectContainer; >> > > > ldp:containerResource ?subject; >> > > > ldp:containsRelation ?predicate; >> > > > >> > > > ?ldpc ldp:xyz ?document . >> > > > BIND (?document AS ?object) # the >> > > > POSTed resource is the member >> > > > } UNION { >> > > > ?ldpc a ldp:DirectContainer; >> > > > ldp:containerResource ?object; >> > > > ldp:containedByRelation ?predicate. # >> > > > ldp:containedByRelation is used >> > > > >> > > > ?ldpc ldp:xyz ?document . >> > > > BIND (?document AS ?object) >> > > > } >> > > > } >> > > > >> > > > In that case duplication is not a problem at all, >> > > > since a client could just infer the "membership triples" >> > > > from the ldp:xyz ones using that query. >> > > > >> > > > On the other hand if such a rule is not true, and cannot >> > > > be written out, then there is no duplication, since the >> > > > "membership triples" are in fact different triples, and >> > > > have no necessary relation to the ldp:xyz ones. >> > > > >> > > > But then this does give one a good reason for having them in a >> > > > different possibly server managed resource. >> > > > >> > > > >> > > > >> > > > >> > > > [1]in the Membership wiki "Determining the membership triples to be >> > > > added when a new member >> > > > is created" http://www.w3.org/2012/ldp/wiki/ >> > > > Membership#Determining_the_membership_triples_to_be_added_when_a_new_member_is_created >> > > > >> > > > >> > > > Social Web Architect >> > > > http://bblfish.net/ >> > > > >> > > > >> > >> > Social Web Architect >> > http://bblfish.net/ >> > >> > > > Social Web Architect > http://bblfish.net/ >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Friday, 13 December 2013 15:59:27 UTC