Re: A minimalist proposal for issue-50

Steven,

That is obviously a reasonable naming scheme, but I'm not in favour of
imposing it in all cases.

FIRST, on the server side, I can think of other valid naming scheme.

For example, I can think of cases where the contained resources' URIs are
not *directly* under the LDPC's URI. Taking the netWorth example from the
spec, if /assets/ is an LDPC, contained resources could be
/networth/bond/123 and /networth/stock/456.

I can also imagine a case where the contained resources' URIs are at the
same level of the LDPC's URI. In another implementation of the netWorth
example, /assets/ could be the subjectMembership of two LDPCs /assets/bonds
and /assets/stocks, but all members of those containers could have URIs of
the form /assets/b123 or /assets/s456.

Of course, *if* the server uses the naming scheme you suggest, it can use
it internally to recognize that a resource is contained in a container. But
that is an implementation detail, and the choice should be left to
implementers.


SECOND, on the client side, I share Erik's concern with putting too much
information in the URIs themeselves.

Consider this: in pure RDF semantics, URIs are opaque. If you are able to
infer a relation between two URIs, you should be able to infer it even if
you replace those URIs with blank nodes having the same properties.

I'm not saying that we can not decide to specify inferences that go beyond
RDF semantics -- only that if we do that, it should be an informed well
discussed decision.

 best

  pa


Le 14 mars 2013 23:13, "Steven Battle" <steve.battle@sysemia.co.uk> a
écrit :

> 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.
>
>
>
>
>
>
>
>