- From: Arnaud Le Hors <lehors@us.ibm.com>
- Date: Mon, 24 Feb 2014 21:25:24 -0800
- To: public-ldp-wg@w3.org
- Message-ID: <OF0DCD12F4.A9A27382-ON88257C8A.00161B50-88257C8A.001DCB78@us.ibm.com>
Thanks Henry for taking a crack at this.
However, this doesn't quite match what's in the current draft. The current
draft actually has BasicContainer as a subclass of DirectContainer rather
than Container.
Container (aka IndirectContainer)
|
------- DirectContainer (restricts insertedContentRelation property to
ldp:MemberSubject)
|
------- BasicContainer (restricts membershipResource
property to <> and hasMemberRelation property to ldp:contains)
The whole idea behind this hierarchy being that we just add more
constraints as we go down the hierarchy.
You're missing the isMemberOfRelation property (formerly known as
membershipPredicateInverse). I think it would look something like that in
your model:
ldp:isMemberOfRelation a rdf:Property;
rdfs:domain ldp:Container;
rdfs:range rdf:Property.
Now, the question is whether this makes more sense than if we flipped the
whole tree up-side-down. This requires thinking in terms of expanded
capabilities instead of restrictions. We start from the simplest class and
add to it as we go down. This gives us:
Container (aka BasicContainer)
|
------- DirectContainer (adds membershipResource, hasMemberRelation,
isMemberOfRelation properties)
|
------- IndirectContainer (adds insertedContentRelation
property)
I think you could express it this way in OWL (I'm really no OWL expect so
I apologize if there are mistakes in there):
~~~~~~~~~~~~~~~~~definition of the well known classes and relation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@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#> .
ldp:Resource a rdfs:Class;
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:Container a rdfs:Class;
owl:subClassOf ldp:Resource;
rdfs:comment """
An LDPR representing a collection of contained documents
(RDF Document [rdf11-concepts] or information resources [WEBARCH])
that responds
to client requests for creation, modification, and/or enumeration
of its documents, and that conforms to the simple lifecycle patterns
and conventions in section6. Linked Data Platform Containers.
""";
skos:editorialNote """
This used to be known as the ldp:BasicContainer. A client
successfully posting
to an ldp:Container will create a new resource that is linked to this
container
via an ldp:contains relation.
""" .
ldp:contains a rdf:Property;
rdfs:domain ldp:Container;
rdfs:range ldp:Resource;
rdfs:comment """
the ldp:contains relation relates an ldp:Container to an information
resource.
""" .
ldp:DirectContainer a rdfs:Class;
owl:subClassOf ldp:Container;
rdfs:comment """
A Container that also manages a configurable list of members. A client
successfully posting
to an ldp:DirectContainer will create a new resource that is linked to
this container
via an ldp:contains relation and will also add a membership triple of
either form:
membershipResource hasMemberRelation member
or
member isMemberOfRelation membershipResource.
in which the member is the created resource.
""" .
ldp:membershipResource a rdf:Property;
rdfs:domain ldp:DirectContainer;
rdfs:range rdf:Resource .
ldp:hasMemberRelation a rdf:Property;
rdfs:domain ldp:DirectContainer;
rdfs:range rdf:Property .
ldp:isMemberOfRelation a rdf:Property;
rdfs:domain ldp:DirectContainer;
rdfs:range rdf:Property .
ldp:IndirectContainer a rdfs:Class;
owl:subClassOf ldp:DirectContainer;
rdfs:comment """
A DirectContainer providing the additional flexibility to have non
information resources
[WEBARCH]) as members. A client successfully posting to an
ldp:IndirectContainer will create
a new resource that is linked to this container via an ldp:contains
relation and will also add
a membership triple of either form:
membershipResource hasMemberRelation member
or
member isMemberOfRelation membershipResource.
in which the member is the object of the insertedContentRelation in
the created resource.
""".
ldp:insertedContentRelation a rdf:Property;
rdfs:domain ldp:Container;
rdfs:range rdf:Property .
As I said on the call I've managed to convince myself that both ways make
sense.
I think what's key is that if a client only knows how/wants to deal with
BasicContainers, with this model they would simply ignore the whole
membership stuff and be fine just looking at the containment (container
ldp:contains resource).
I'm not as sure that a client that only knows how/wants to deal with
DirectContainers can deal with IndirectContainers as if they were
DirectContainers. For one thing I would expect them to get confused about
not finding the contained resources in the list of members.
So, maybe the actual hierarchy we need is this:
Now, the question is whether this makes more sense than if we flipped the
whole tree up-side-down. This requires thinking in terms of expanded
capabilities instead of restrictions. We start from the simplest class and
add to it as we go down. This gives us:
Container (aka BasicContainer)
|
------- IndirectContainer (adds membershipResource, hasMemberRelation,
isMemberOfRelation, and insertedContentRelation properties)
|
------- DirectContainer (restricts
insertedContentRelation property to ldp:MemberSubject)
I'd love for someone more fluent in this type of stuff to tell me which
way is right.
Best regards.
--
Arnaud Le Hors - Software Standards Architect - IBM Software Group
From: "henry.story@bblfish.net" <henry.story@bblfish.net>
To: "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>,
Cc: Sandro Hawke <sandro@w3.org>
Date: 02/24/2014 10:52 AM
Subject: class hierarchy of containers
Hi,
in today's call there was a discussion on what the class hierarchy of
the containers
should be. (There was also a discussion of what the names should be, but
I'd better leave that
to another thread.) With the spec as it is currently I'd propose the
following ontology.
~~~~~~~~~~~~~~~~~definition of the well known classes and relation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@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#> .
ldp:Resource a rdfs:Class;
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:Container a rdfs:Class;
owl:subClassOf ldp:Resource;
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 """
This used to be known as the ldp:IndirectContainer. A client
successfully posting
to an ldp:Container will create a new resource that is linked to this
ldp:container
via an ldp:contains relation, but may also create what are currently
known as membership
properties.
""" .
ldp:contains a rdf:Property;
rdfs:domain ldp:Container;
rdfs:range ldp:Resource;
rdfs:comment """
the ldp:contains relation relates an ldp:Container to an information
r
""" .
ldp:membershipResource a rdf:Property;
rdfs:domain ldp:Container;
rdfs:range rdf:Resource .
ldp:hasMemberRelation a rdf:Property;
rdfs:domain ldp:Container;
rdfs:range rdf:Property .
ldp:insertedContentRelation a rdf:Property;
rdfs:domain ldp:Container;
rdfs:range rdf:Resource .
ldp:BasicContainer a rdfs:Class;
owl: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)
""" .
ldp:DirectContainer a rdfs:Class;
owl: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.
""" .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So here is I think why the group has been thinking of ldp:BasicContainer
as a subclass of ldp:Container, and that is that it could be defined
as a a set of constraints on ldp:Container, something like this perhaps
( my owl is not good enough so I am not sure)
ldp:BasicContainer owl:subClassOf
[ a owl:Restriction;
owl:onProperty ldp:membershipResource;
owl:hasValue ?self ],
[ a owl:Restriction;
owl:onProperty ldp:hasMemberRelation;
owl:hasValue ldp:contains ],
[ a owl:Restriction;
owl:onProperty ldp:insertedContentRelation;
owl:hasValue ldp:MemberSubject ] .
I could not find how to express the first restriction in owl, so I put
?self there to represent that one wants the value to be bound to container
itself. ( each membership resource should point back to itself )
At least it makes a good case that ldp:BasicContainer is a subclass of the
ldp:Container .
But this does perhaps reveal something odd. Namely that we are here
adding a restriction on relations such as ldp:membershipResource,
ldp:hasMemberRelation and ldp:insertedContentRelation that have
ldp:Container
in their domain, and that therefore already have ldp:contains set...
Perhaps this can explain Sandro Hawke recent arguments that one feels that
there
are two different classes that are somewhat merged together. [1]
Henry
[1] https://www.w3.org/2012/ldp/wiki/Collection_Types
Social Web Architect
http://bblfish.net/
Received on Tuesday, 25 February 2014 05:25:57 UTC