- 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