1 Ontological Modelling

A powerful way to model a problem is to do it logically, using an ontology. This allow one to look at the relationship between different elements of the spec by looking at the consequences of adding a new relation to the ontology. By using well defined and well known relations one can much more objectively and clearly discuss the consequences of a modeling suggestion. Certain types of questions appear that would not previously have been clearly asked such as whether one class is a subclass, overlaps, or has no members in common with another class, what the identity criteria for being an object of that class are, etc,....

( When discussing comments statements on the ontology we using the N3 syntax a superset of Turtle, which makes it easy to speak about other statements ).

Below is the stable ontology of which a simplification has been proposed as part of ISSUE-47

@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .


ldp:Container a rdf:Class;
    rdfs:note """
     An HTTP GET on an ldp:Container returns a graph listing all the members of the container, as described in the spec.
     Deleting a Container with an HTTP DELETE method call MUST delete all its members.
       More precisely: for a container with URI Uc, let the set of its contents S, be all 
        the results given by the query

           SELECT ?c 
           WHERE {  ?container a ldp:Container; 
                              rdfs:member ?c . }     

      where ?container is bound to Uc. Then deleting the resource named by Uc should delete all 
      the resources named in the set S . 
      Furthermore for any resource ?r in a container ?c, such that 
          ASK { ?c rdfs:member ?r } .
      is true
      If the resource bound to ?r is deleted ( after for example sending to ?r an HTTP DELETE request that is accepted), 
      then ?r must MUST be removed  from the container C, ie:
          ASK { ?c rdfs:member ?r } .
      must is false. 
    """;
    vs:term_status "unstable";
    rdfs:subClassOf ldp:Collection .


ldp:Resource a rdf:Class;
   vs:term_status "unstable";
   rdfs:note "HTTP resource that conforms to the simple lifecycle patterns and conventions in the LDPRs section.".

From the above it follows as described in the pdf "LDPRs, LDPCs and the mysterious LDPX" that there is a class of things that are LDPRs but not LDPCs.

1.1 Ontology Extensions

Below are some ontology extensions that were used in discussions on specific topics. They may or may not be valuable outside those topics.

1.1.1 Aggregation & Collection

To help in the debate on Aggregation and containership relations ( see Issue-34 Simple Proposal for example )and following a suggestion by Arnaud, we created the following somewhat vague distinctions

ldp:Aggregation a rdf:Class;
    rdfs:note """
       Creating,  Updating or Deleting an Aggregation does not have any necessary implication as to 
       the state of its rdfs:member object.   This is very different to an ldp:Container.  
       Similarly deleting updating or altering resources that are members of an ldp:Aggregtion
       does not have any required implication on an ldp:Aggregation. 
       See: http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal for examples
    """ ;
    vs:term_status "unstable";
    rdfs:subClassOf ldp:Collection.

ldp:Collection a rdf:Class;
   vs:term_status "unstable";
   rdfs:note """
   Information Resources ( things that one can interact with HTTP verbs on the Web ) that can have sets 
   of rdfs:member and that are defined by the LDP Spec.
    """ .

1.1.1.1 Lemma: Container is disjoint with Aggregation

The following seems to follow from the definitions above: ( feedback welcome )

{ 
   ldp:Container owl:disjointWith ldp:Aggregation  .
}  defendedBy [ = g1; foaf:member Arnaud, <http://bblfish.net/people/henry/card#me> ];
   = <#lemma1>;
   rdfs:note """
Reasons:
POST semantics are different:
1. when you POST content on an ldp:Container you 
   a) will create a new GETable resource whose name is added to the ldp:Container 
      via the rdfs:member relation
   b) and relative uris in the posted document are interpreted relative to 
      the created resource
2. when you POST a graph onto an LDPR ( or an LDPA ) then
  a) the contents of the graph are appended to the LDPR  (if 
    ISSUE-45 passes ( http://www.w3.org/2012/ldp/track/issues/45 )
  b) the relative URIs are resolved relative to the LDPR
  c) no new resource MUST be created.
DELETE semantics are different:
1.LDPC 
  a. Deleting an LDPC will delete all its members
  b. Deleting a LDPC member directly, removes it from the LDPC
2.LDPA
   a. Removing a resource membership relation from an LDPA does not delete the resource itself.
   b. Deleting a resource that is a member of an LDPA does not delete the rdf:member relation from the LDPA 
""" .

1.1.2 Atom Entry and Feed relation to LDP

As argued on 31 January 2010 Feeds and Entries, with detailed links to atom history and ontology, the following would probably make most sense for modelling Atom:

awol:Feed rdfs:subClassOf ldp:Container .

awol:Entry rdfs:subClassOf [ 
          a rdfs:Class;
          rdfs:label "LDP_:X";
          owl:intersectionOf ( [ owl:complementOf ldp:Container ] ldp:Resource ) 
  ] .

1.2 Open Issues

1.2.1 Are LDPCs subclasses of LDPRs?

Arnaud in teleconference of 21 January 2013 seemed to suggest so.

{
   ldp:Container rdfs:subClassOf ldp:Resource .
 }  defendedBy [ = <#g2>; foaf:member Arnaud ];
    = <#proposal1> .

But the spec says that they are "HTTP resource that conforms to the simple lifecycle patterns and conventions in the LDPRs section.", which seems to suggest that they are not, since POSTing a Graph on an LDPR is very different from POSTing on an LDPC, and since RDF is a logical vocabulary that does not work with the concept of method overloading.

{
   ldp:Container owl:differentFrom ldp:Resource .
 }  defendedBy [ = <#g3>; foaf:member <http://bblfish.net/people/henry/card#me> ];
    = <#proposal1a> .

BUT: From the ontology it follows as described in the pdf "LDPRs, LDPCs and the mysterious LDPX" that there is a class of things that are LDPRs but not LDPCs. Those things would be the things to which that POST applies. And so it is ok that ldp:Containers are subclass of ldp:Resource.

1.2.2 can LDPAs be LDPRs?

It seems very reasonable to have LDPRs be LDPAs.

{
  [] owl:intersectionOf ( ldpx:Resource ldpx:Aggregation ) 
      owl:differentFrom owl:Nothing .
 }  defendedBy [ = <#g4>; foaf:member <http://bblfish.net/people/henry/card#me> ];
    = <#proposal2> .

That is compatible with my example. It is just that in the example I tried not to take the special case. Essentally it would allow

<http://localhost:9000/2013/aggReg> to contain 

{ <> a ldpx:Aggregation . }

1.2.3 Must LDPAs be LDPRs ?

Others may want to claim that

{
   ldp:Aggregation rdfs:subClassOf ldp:Resource .
 }  defendedBy <#g5>;
    = :proposal3 .

1.2.4 Create ldp:Content class

It was argued on 24 January 2013 that the name Resource is usually understood to cover very general things. It would be better to have a subClass for Content, like this:

{
ldp:Content rdfs:subClassOf ldp:Resource;
    owl:disjointWith ldp:Container .

 ldp:contains rdfs:subPropertyOf rdfs:member ;
       rdfs:domain ldp:Container .
} defendedBy [ foaf:member <http://bblfish.net/people/henry/card#me ];
  = :proposal4

One could then argue that a POST of a graph on a resource c that is an ldp:Content can append those triples to the resource, as argued by Issue-45.

This is going a bit beyond what is described in the pdf "LDPRs, LDPCs and the mysterious LDPX" that there is a class of things that are LDPRs but not LDPCs. It is going beyond insofar as it is deciding to call these LDPXs ldp:Content. But that might not be a good name, since Containers can contain Containers too. Something like "File" would be better perhaps.