Re: ldp-ISSUE-78 (inferencing): inferencing levels [Linked Data Platform Spec]

On 31 May 2013, at 12:11, Henry Story <henry.story@bblfish.net> wrote:

> 
> 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.

Argh that conclusion was not quite right either.

<> ldp:membershipPredicate ex:attachment;
   ldp:membershipSubject <subject> .
<subject> ex:attachment <member1>, <member2> .

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 }


> 
>> 
>> 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:14:41 UTC