Warning:
This wiki has been archived and is now read-only.
ContainerHierarchy
We look here at the container hierarchy. Starting form a minimal consensual position that the LDP group should be agreeing on ( please mail the list if there is something wrong there) we will then show what types of positions are not actually possible, in order to then arrive at a conclusion as to what the actual class hierarchy has to be.
Contents
1 The minimal consensus position
The following is ( Henry Story believes ) the consensus and relatively uncontroversial position. We here only have a number of classes and properties. We have some minimal type hierarchy between the containers. It will then be easier to argue from this what other things are possible or not.
Perhaps it is important to start from the following uncontroversial ontology
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
ldp:Resource a rdfs:Class;
rdfs:label "ldp Resource";
rdfs:comment """
A HTTP resource whose state is represented in any way that conforms to the simple
lifecycle patterns and conventions in section 5. Linked Data Platform Resources.
""" .
ldp:Source a rdfs:Class;
rdfs:label "ldp Resource";
rdfs:subClassOf ldp:Resource;
rdfs:comment """
an ldp:Resource that is also an rdf source: ie that is an RDF graph.
""" .
ldp:Container a rdfs:Class, owl:Class;
rdfs:label "ldp Container";
rdfs:subClassOf ldp:Source;
rdfs:comment """
An LDPR representing a collection of member resources and/or contained documents
(RDF Document [rdf11-concepts] or information resources [WEBARCH]) that responds
to client requests for creation, modification, and/or enumeration
of its members and documents, and that conforms to the simple lifecycle patterns
and conventions in section6. Linked Data Platform Containers.
""";
skos:editorialNote """
As the outermost class of the container hierarchy it may be that the ldp:Container could
be made to be the same as the ldp:IndirectContainer. But leaving space could allow for further
extensions.
""" .
ldp:IndirectContainer a rdfs:Class, owl:Class;
rdfs:subClassOf ldp:Container;
rdfs:comment """
A LDPC that has the flexibility of choosing what form its membership triples take,
and allows members to be any resources [WEBARCH], defined in the posted document.
""" .
ldp:DirectContainer a rdfs:Class, owl:Class;
rdfs:subClassOf ldp:Container;
rdfs:comment """
A LDPC that has the flexibility of choosing what form its membership triples take,
and allows members to be any resources [WEBARCH], not only documents.
""" .
ldp:BasicContainer a rdfs:Class, owl:Class;
rdfs:label "BasicContainer";
rdfs:subClassOf ldp:Container;
rdfs:comment """
A LDPC that uses a single pre-defined predicate to link to both its contained and
member documents (information resources). Posting to an ldp:BasicContainer has
no extra consequences other than creating an ldp:contains relation from the container to
the newly created resource.
""" .
ldp:contains a rdf:Property, owl:ObjectProperty;
rdfs:label "contains";
rdfs:domain ldp:Container;
rdfs:range ldp:Resource;
rdfs:comment """
the ldp:contains relation relates an ldp:Container to a ldp:Resource ( ie a document of some form )
""" .
ldp:membershipResource a rdf:Property, owl:ObjectProperty, owl:FunctionalProperty;
rdfs:label "membershipResource";
rdfs:domain ldp:IndirectContainer;
rdfs:range rdf:Resource .
ldp:hasMemberRelation a rdf:Property, owl:FunctionalProperty, owl:ObjectProperty;
rdfs:label "hasMemberRelation";
rdfs:domain ldp:IndirectContainer;
rdfs:range rdf:Property .
ldp:isMemberOfRelation a rdf:Property, owl:FunctionalProperty, owl:ObjectProperty;
rdfs:label "isMemberOfRelation";
owl:equivalentProperty [ owl:propertyChainAxiom ( ldp:hasMemberRelation owl:inverseOf ) ];
skos:editorialNote """
the ldp:isMemberOfRelation is the equivalent to the hasMemberRelation followed by the owl:inverseOf property
""";
rdfs:domain ldp:IndirectContainer;
rdfs:range rdf:Property.
ldp:insertedContentRelation a rdf:Property, owl:FunctionalProperty, owl:ObjectProperty;
rdfs:label "insertedContentRelation";
rdfs:domain ldp:IndirectContainer;
rdfs:range rdf:Property .
2 Implications of the consensus position
The consensus position described above allows us to draw the following Venn Diagram:
We have a number of overlapping positions. We can now consider for each of the overlapping positions if there is anything that can be contained in that space.
2.1 B & F: DirectContainers that are not Indirect
Every DirectContainer contains the following relations
?dc ldp:DirectContainer;
ldp:hasMemberRelation ?rel;
ldp:membershipResource ?dc .
And those imply the following relations
?dc ldp:IndirectContainer;
ldp:hasMemberRelation ?rel;
ldp:membershipResource ?dc ;
ldp:insertedContentRelation ldp:MemberSubject .
This follow from section 6.4.1.5 from the 2 March 2014 LDP spec
6.4.1.5 LDP Direct Containers must behave as if they have a ( LDPC URI, ldp:insertedContentRelation , ldp:MemberSubject ) triple, but LDP imposes no requirement to materialize such a triple in the LDP-DC representation. The value ldp:MemberSubject means that the member-derived-URI is the URI assigned by the server to a document it creates; for example, if the client POSTs content to a container that causes the container to create a new LDPR, ldp:MemberSubject says that the member-derived-URI is the URI assigned to the newly created LDPR.
It follows therefore that all ldp:DirectContainers are ldp:IndirectContainers. And so the space in B & F is empty. There is nothing in B.
Section 6.4.1.5 can be rewritten in owl as
ldp:DirectContainer
owl:equivalentClass [ a owl:Restriction;
owl:onProperty ldp:insertedContentRelation;
owl:hasValue ldp:MemberSubject
].
but since the domain of ldp:insertedContentRelation is ldp:IndirectContainer, it follows that ldp:DirectContainer must be an ldp:IndirectContainer .
2.2 C&D: BasicContainers that are not Direct Containers
Every BasicContainer can be written as
?dc a ldp:IndirectContainer;
ldp:hasMemberRelation ldp:contains;
ldp:membershipResource ?dc ;
ldp:insertedContentRelation ldp:MemberSubject . # note this triple is missing from spec
from the ldp:insertedContentRelation triple one can conclude that ?dc is an ldp:BasicContainer and the above could then be simplified to
?dc a ldp:DirectContainer;
ldp:hasMemberRelation ldp:contains;
ldp:membershipResource ?dc
This follow from section 6.3.1.2 and 6.3.1.3 from the 2 March 2014 LDP spec
6.3.1.2 LDP Basic Containers must behave as if their state contains the triple whose subject is the LDPC URI, whose predicate is ldp:membershipResource, and whose object is the LDPC URI (subject and object are the same URI), but there is no requirement to materialize this triple in LDP-BC representations.
6.3.1.3 LDP Basic Containers must behave as if their state contains the triple whose subject is the LDPC URI, whose predicate is ldp:hasMemberRelation, and whose object is ldp:contains, but there is no requirement to materialize this triple in LDP-BC representations.
Those sections could be rewritten in owl as
ldp:BasicContainer
owl:equivalentClass [ owl:intersectionOf ( [ a owl:Restriction;
owl:onProperty ldp:membershipResource;
owl:hasSelf "true"^^xsd:boolean ]
[ a owl:Restriction;
owl:onProperty ldp:hasMemberRelation;
owl:hasValue ldp:contains ]
[ a owl:Restriction; # this restriction seems to be missing from the spec!
owl:onProperty ldp:insertedContentRelation;
owl:hasValue ldp:MemberSubject
])].
There seems to be text missing in the spec in section 6.3.1. for the restriction on the ldp:MemberSubject.
With that last restriction one knows that a BasicContainer is a DirectContainer. So there cannot be anything that is a BasicContainer and not a DirectContainer. C & D are empty.
2.3 Conclusion
We only proven that B&F and C&D in the Venn diagramm above are empty and so that only A, G, E and Z have members
3 LDP-BC <: LDP-DC <: LDP-IC <: LDPC
The above allows one to redraw the venn diagrams as follows
from which we can deduce the following UML diagram
ie. Basic Containers are a subclass of Direct Containers and Direct Containers are a subclass of Indirect Containers.
3.1 OWL Ontology
We found the following extra restrictions to be found in the ldp specification
ldp:DirectContainer
rdfs:subClassOf [ a owl:Restriction;
owl:onProperty ldp:membershipResource;
owl:hasSelf "true"^^xsd:boolean ],
[ a owl:Restriction;
owl:onProperty ldp:insertedContentRelation;
owl:hasValue ldp:MemberSubject
].
ldp:BasicContainer
rdfs:subClassOf [ a owl:Restriction;
owl:onProperty ldp:membershipResource;
owl:hasSelf "true"^^xsd:boolean ],
[ a owl:Restriction;
owl:onProperty ldp:hasMemberRelation;
owl:hasValue ldp:contains ],
[ a owl:Restriction;
owl:onProperty ldp:insertedContentRelation;
owl:hasValue ldp:MemberSubject
].
If we add those to the main ontology we then get as further conclusions that:
ldp:DirectContainer owl:subClassOf ldp:IndirectContainer . ldp:BasicContainer owl:subClassOf ldp:DirectContainer
You can download the ldp ontology on which this is based here File:Ldp.ttl
3.2 Mechanical Verification
Using the File:Ldp.ttl one can then run a few tests to see if the reasoning is correct. Pellet gives the following
(1) The ontology is consistent
$ sh pellet.sh consistency --input-format Turtle ../ldp.ttl Consistent: Yes
(2) We get the desired class hierarchy
$ sh pellet.sh classify --input-format Turtle ../ldp.ttl
Classifying 10 elements
Classifying: 100% complete in 00:00
Classifying finished in 00:00
owl:Thing
rdf:Property
rdf:Resource
ldp:BasicContainer
ldp:Resource
ldp:Source
ldp:Container
ldp:IndirectContainer
ldp:DirectContainer
ldp:BasicContainer
With Protégé we can see the explanation for the class hierarchy on the DirectContainer