ISSUE-78: inferencing levels

inferencing

inferencing levels

State:

CLOSED

Product:

Linked Data Platform Spec

Raised by:

Henry Story

Opened on:

2013-05-31

Description:

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: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 }

Related Actions Items:

• ACTION-86 on John Arwe to [EDITOR] Update spec to reflect resolution of ISSUE-78 with normative text like "separating the payload into an LDP-specified part and an application part, the LDP-specific part of LDP messages MUST NOT require inference." - due 2013-06-27, closed

Related emails:

1. LDP Rec (from eric@w3.org on 2015-02-20)
2. updated ISSUE-71: membershipX description (from henry.story@bblfish.net on 2013-06-03)
3. Re: ldp-ISSUE-78 (inferencing): inferencing levels [Linked Data Platform Spec] (from johnarwe@us.ibm.com on 2013-05-31)
4. Re: ldp-ISSUE-73 (rdf:member): LDPCs to list all their rdf:member [Linked Data Platform core] (from henry.story@bblfish.net on 2013-05-31)
5. Re: ldp-ISSUE-78 (inferencing): inferencing levels [Linked Data Platform Spec] (from henry.story@bblfish.net on 2013-05-31)
6. Re: ldp-ISSUE-78 (inferencing): inferencing levels [Linked Data Platform Spec] (from henry.story@bblfish.net on 2013-05-31)
7. Re: ldp-ISSUE-78 (inferencing): inferencing levels [Linked Data Platform Spec] (from roger.menday@uk.fujitsu.com on 2013-05-31)
8. Re: ldp-ISSUE-77 (types of LDPR ): why MUST a LDPR declare it's type ... ? [Linked Data Platform core] (from henry.story@bblfish.net on 2013-05-31)
9. ldp-ISSUE-78 (inferencing): inferencing levels [Linked Data Platform Spec] (from sysbot+tracker@w3.org on 2013-05-31)

Related notes:

Display change log