Re: issue-13 amended proposal

Steve,

Thanks for the example.

This adds a lot of complexity to containers. Does a container need to delete the prove triples if the member is deleted? How is this supposed to work for paged containers?

I don't understand the problem with putting the prov triples into the representation of <a1>.

If you wanted, you could also put it into the representation of <nw1>.

It is true that the data/metadata split is an application choice. But ldp:Container is not an application construct, it's an LDP construct. So I don't see why we shouldn't place reasonable constraints on the functionality of ldp:Containers to make container logic simpler.

Best,
Richard


On 20 Mar 2013, at 12:45, Steve Battle <steve.battle@sysemia.co.uk> wrote:

> Sure, here's a simple example, based on the NetWorth example from the
> spec, that should illustrate the difference.
> 
> RDF within the LDPC <http://example.org/netWorth/> is as follows. For this
> example I've included additional Provenance metadata within the container;
> this is representative of the kind of 'metadata' one may have about a
> resource that may not be regarded as belonging to the resource 'data' -
> the data/metadadata split is an application choice, and nothing to do with
> LDP:
> 
> @prefix dcterms: <http://purl.org/dc/terms/>.
> @prefix ldp: <http://www.w3.org/ns/ldp#>.
> @prefix o: <http://example.org/ontology/>.
> @prefix prov: <http://www.w3.org/ns/prov#> .
> 
> <> a ldp:Container;
>   dcterms:title "The assets of JohnZSmith";
>   ldp:membershipSubject <http://example.org/netWorth/nw1>;
>   ldp:membershipPredicate o:asset.
> 
> <http://example.org/netWorth/nw1>
>   a o:NetWorth;
>   o:asset <a1> .
> 
> <a1> a prov:Entity; prov:wasAttributedTo
> <http://www.stevebattle.me/foaf.ttl#me> .
> 
> RDF within the LDPR <http://example.org/netWorth/a1>:
> 
> <> a o:Stock, ldp:Resource;
>   o:value 100.00.
> 
> So in this example, I want to be able to distinguish between the RDF
> represented by <http://example.org/netWorth/a1> and statements made about
> this resource within <http://example.org/netWorth/>.
> 
> If I do a GET on the container, I may receive an RDF representation
> containing triples inlined from <http://example.org/netWorth/a1>:
> 
> <> a ldp:Container;
>   dcterms:title "The assets of JohnZSmith";
>   ldp:membershipSubject <http://example.org/netWorth/nw1>;
>   ldp:membershipPredicate o:asset.
> 
> <http://example.org/netWorth/nw1>
>   a o:NetWorth;
>   o:asset <a1> .
> 
> <a1> a prov:Entity, o:Stock, ldp:Resource;
>   prov:wasAttributedTo <http://www.stevebattle.me/foaf.ttl#me>;
>   o:value 100.00.
> 
> Now, even though <a1> has been inlined in the representation above, I
> should still be able to use PATCH on the container to update statements
> (in the container) _about_ it. I should NOT be able to use a PATCH on the
> _container_ to update statements _within_
> <http://example.org/netWorth/a1>, for this I could PATCH the LDPR
> directly.  So, for example, I should be able to PATCH the container to
> update the prov attribution of <a1>, even though <a1> was an 'inlined
> member'.
> 
> Steve.
> 
>> -----Original Message-----
>> From: Richard Cyganiak [mailto:richard@cyganiak.de]
>> Sent: 19 March 2013 21:59
>> To: Steve Battle
>> Cc: public-ldp-wg@w3.org
>> Subject: Re: issue-13 amended proposal
>> 
>> On 19 Mar 2013, at 17:32, Steve Battle <steve.battle@sysemia.co.uk>
> wrote:
>>> As it was me who vetoed closing issue-13 at the F2F, I think the onus
> is on
>> me to come up with a revised proposal.
>>> 
>>> The last (vetoed) proposal was as follows:
>>> "Close the remainder of ISSUE-13 by saying that servers may refuse to
>> update inlined members through PUT/PATCH to a container."
>>> 
>>> My objection is that by referring to 'inlined members' this may be
>> misinterpreted as applying to triplesfrom the container with subject, s,
>> where the LDPR  identified by s is inlined in the response to GET. In
> other
>> words, It doesn't make a clear enough distinction between updating s,
> and
>> updating statements about s.
>> 
>> To be honest, I don't understand the distinction you are making here
>> between "s" and "statements about s". Can you give an example?
>> 
>> Thanks,
>> Richard
>> 
>> 
>> 
>>> The possibility of such triples are, I think, required by section
> 5.2.1 "A
>> Linked Data Platform Container MUST also be a conformant Linked Data
>> Platform Resource." Rightly so - I would like to have user-managed
> metadata
>> in my containers. I should be allowed to use PUT/PATCH to update
>> statements about inlined members, within the container.
>>> 
>>> A simple amendment to the above proposal clarifies this by clarifying
> that
>> we really are talking only  about the content of these inlined LDPRs,
> rather
>> than any statement about them.
>>> "Close the remainder of ISSUE-13 by saying that servers may refuse to
>> update the content of an inlined LDPR through PUT/PATCH to a container."
>>> 
>>> Steve.
>>> 
>>> --
>>> Steve Battle
>>> Semantic Engineer
>>> 
>>> Mobile: +44 (0)7503 624 613
>>> 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 Wednesday, 20 March 2013 15:48:30 UTC