- From: Henry Story <henry.story@bblfish.net>
- Date: Fri, 31 May 2013 12:11:28 +0200
- To: Roger Menday <roger.menday@uk.fujitsu.com>
- Cc: Linked Data Platform Working Group <public-ldp-wg@w3.org>
On 31 May 2013, at 12:06, Roger Menday <roger.menday@uk.fujitsu.com> wrote: > >> ldp-ISSUE-78 (inferencing): inferencing levels [Linked Data Platform Spec] >> >> http://www.w3.org/2012/ldp/track/issues/78 >> >> Raised by: Henry Story >> On product: Linked Data Platform Spec >> >> The spec should clearly set up out front what the inferencing level is for a client to be able to interact with the resources. >> >> Currently it is not clear, there are two views one can have of this: >> >> Inferencing level 0 >> ---------------- >> >> One can deduce from various passages in the spec that no inferencing level is the desired requirement. >> >> "4.1.6 LDPR representations should have at least one rdf:type set explicitly. This makes the representations much more useful to client applications that don’t support inferencing. " >> >> In the Editor's TODO it is written: >> >> "Deployment guide (was: 4.8 Common Properties) talks about rdfs:Range which implies inferencing. 4.1.7 spec says want to avoid putting that reqt on >> clients." >> >> The spec should make clear up front that no inferencing is required of clients to work with this version of the specification. ( I.e. to interact with the LDPCs and LDPRs as far as HTTP goes ). Publishers may use vocabularies that go beyond this of course. >> >> Higher inferencing levels >> --------------------- >> >> The spec also seems to require inferencing of the client in various other parts: >> >> 1. In order to know that >> <> rdf:member <member> >> implies that <member> was created by <>, one needs to know that >> <> a ldp:Container . >> This can be made clear by considering that if one had an explicit relation ldp:contains then one would not need this inferencing step. >> >> 2. The ldp:membershipXXX properties require inferencing to go from an initial >> >> <> ldp:membershipPredicate ex:attachment; >> ldp:membershipPredicate <other> . >> <other> ex:attachment <member1>, <member2> . >> > > Henry, > > Is there something wrong with the above turtle ? > i.e. is there a typo on the two membershipPredicates ? Ah yes, thanks. I improved it to <> ldp:membershipPredicate ex:attachment; ldp:membershipSubject <subject> . <subject> ex:attachment <member1>, <member2> . to <subject> rdf:member <member1>, <member2> . that should be easier to read. I also fixed the issue report. > > thanks, > Roger > > >> to >> >> <> rdf:member <member1>, <member2> . >> >> which would let one know what the <member>s of a container were. >> >> The inferencing required would be a rule expressed in N3 of the form: >> >> { ?ldpc a ldp:Container; >> ldp:membershipPredicate ?p; >> ldp:membershipSubject ?s . >> ?s ?p ?o . } => { ?ldpc rdf:member ?o } >> >> >> >> > Social Web Architect http://bblfish.net/
Received on Friday, 31 May 2013 10:12:00 UTC