1 PROPOSAL 1: define hierarchy of resources
This proposal is about labelling the kind of resources managed by LDP.
LDPRs and LDPCs are defined as disjunctions of other kind of resources:
LDPR ::= # LDP Resource: is either an LDPG, LDPC or LDPB | LDPG # LDP Graph: representation is RDF | LDPC # LDP Container: representation is RDF + ldp:Container as rel="type" Link header | LDPB # LDP Binary: representation is anything but RDF LDPC ::= # ldp:Container is explicitly made the common parent for all Container types | SimpleContainer # members and contained LDPRs are aligned | DirectContainer # membership subject and predicate are application specific | IndirectContainer # membership triples are application specific
A special kind of LDPR (outside of the hierarchy) is the
ldp:ContainerResource, the object of the
ldp:containerResource property for a Container.
- not all Web resources are LDPR
- this doesn't force an LDPR to be contained by some Container eg. root Container
- LDPR becomes LDPG
- non-LDPR becomes LDPB
- LDPC is not a subtype of LDPG
2 PROPOSAL 2: LDP Named Graphs
Any LDPG/LDPG is a Named Graph. This proposal describes to what Named Graph the protocol-related triples belong.
The membership triples belong to the representation of the hashless-ContainerResource.
The containment triples belong to the representation of the LDPC.
The successful creation of an LDPG/LDPC results in a new Named Graph (modulo the interpretation of relative URIs through 5.4.7).
- creation via POST
- URI is the value of the Location header at successful creation
- RDF Graph depends on how the Container interprets the POSTed content (no garanty it's the same as the POSTed one)
- creation via PUT
- URI is the one used for the PUT
- RDF Graph is exactly what was sent
- this proposal does not prevent application data to co-exist with server-managed data in same Named Graph
- if an LDPC is also a ContainerResource, then it contains both the containment triples and the membership, which could be the same triples
Here are some examples, where
- both membership and containment triples are represented
- the LDPR/LDPR interactions are advertised through the rel-Link headers
- the Named Graphs are explicit in the interactions using curl
Revisiting Example 3:
$ curl -i http://example.org/container1/ ... Content-Type: text/turtle; charset=UTF-8 Link: <http://www.w3.org/ns/ldp#Container>; rel="type" ... @prefix dcterms: <http://purl.org/dc/terms/>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. @prefix ldp: <http://www.w3.org/ns/ldp#>. <> a ldp:SimpleContainer; dcterms:title "A very simple container"; ldp:contains <member1>, <member2>, <member3>.
Re-visiting Example 5:
$ curl -i http://example.org/netWorth/nw1/ ... Content-Type: text/turtle; charset=UTF-8 Link: <http://www.w3.org/ns/ldp#Resource>; rel="type" ... <> a o:NetWorth; o:netWorthOf <http://example.org/users/JohnZSmith>; o:asset <assetContainer/a1>, <assetContainer/a2>; o:liability <liabilityContainer/l1>, <liabilityContainer/l2>, <liabilityContainer/l3>. $ curl -i http://example.org/netWorth/nw1/assetContainer/ ... Content-Type: text/turtle; charset=UTF-8 Link: <http://www.w3.org/ns/ldp#Container>; rel="type" ... <> a ldp:Container; dcterms:title "The assets of JohnZSmith"; ldp:containerResource <..>; ldp:containsRelation o:asset; ldp:insertedContentRelation ldp:MemberSubject; ldp:contains <a1>, <a2>. $ curl -i http://example.org/netWorth/nw1/liabilityContainer/ ... Content-Type: text/turtle; charset=UTF-8 Link: <http://www.w3.org/ns/ldp#Container>; rel="type" ... <> a ldp:Container; dcterms:title "The liabilities of JohnZSmith"; ldp:containerResource <..>; ldp:containsRelation o:liability; ldp:insertedContentRelation ldp:MemberSubject; ldp:contains <l1>, <l2>, <l3>.