A minimalist proposal for issue-50

It seems to me that issue-50 is related to the earlier issue-25 closed at the previous F2F. 

Specifically, I proposed that a resource is only (strictly) composed under a container if its URI can be hierarchically relativized to the URI of the container (and without using '..' in the relativized path). Intuitively, the URI of the subordinate resource begins with that of the container. 

I recall that the major factor for this being rejected was the need to accommodate linked data spread across a number of (federated) servers that differ in the host-name. I believe the above definition of subordinate resources could be modified, so that we focus on relativization relative to a defined root; a container could potentially specify multiple roots if required.

I'd still prefer the spec to state that container members are relativized to the container such that all the forms raised in issue-50 work properly. ie.

<.> to refer to the creating container
<sibling> to refer to a sibling of the content created
<../other> to refer to a child of the parent of this container 
<sister/child> to refer to a child of a sister content created in this container


In the spirit of producing a minimalist LDP model as demanded by cygri, here's a proposal for resolving issue-50:

This proposal aligns containment with hierarchical URIs, such that if I post RDF to a resource, a new resource is created at a new URI immediately below that resource. (You may be experiencing deja-vous at this point in time).

a) creation: If I POST R to C, this creates a new child X with hierarchical URI C/X. Metadata MAY be appended to C (eg. any triples in R that refer to C).
b) access:   FoIlowing a) above, if I GET C/X I get R.
c) update:   PUT or PATCH may be used as currently defined.
c) deletion: If I DELETE C then any resource hierarchically 'below' it, such as C/X, are also deleted along with C.

The LDP does not need to distinguish between resources and containers.
The LDP does not support weak aggregation.
The LDP does not need membership predicates. If required, the client can add their own membership triples to the representation R (this info isn't required for deletion).

Steve.

-- 
Steve Battle
Semantic Engineer

E-mail: steve.battle@sysemia.co.uk
Web: www.sysemia.com

Sysemia Limited
The Innovation Centre, Bristol&  Bath Science Park, Dirac Crescent, Emerson's Green, Bristol BS16 7FR
Registered in England and Wales. Company Number: 7555456

DISCLAIMER

Information contained in this e-mail is intended for the use of the addressee only, and is confidential and may also be privileged. If you receive this message in error, please advise us immediately. If you are not the intended recipient(s), please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Attachments to this e-mail may contain software viruses which may damage your systems. Sysemia Ltd have taken reasonable steps to minimise this risk, but we advise that any attachments are virus checked before they are opened.

Received on Thursday, 14 March 2013 22:13:11 UTC