Re: issue-13 amended proposal

On 20 Mar 2013, at 17:20, Steve Battle <steve.battle@sysemia.co.uk> wrote:
> However, I'm not adding complexity to Containers, I'm describing
> complexity that's already there.

That's not quite true. You're describing an issue that the spec as written doesn't answer. The spec doesn't say what happens if you PUT/PATCH inlined member triples.

> I think you're arguing to take that
> complexity (or is that flexibility) out - but I don't think issue-13 is
> the vehicle for doing that.

ISSUE-13 [1] asks for clarification how PUT/PATCH on a container interacts with inlined member descriptions.

The proposal which you vetoed provides that clarification, by saying that the server may refuse such a request.

So I'm not sure how you come to the conclusion that ISSUE-13 would be the wrong place to answer this question.

You also didn't address my question about putting the triples into <a1> or <nw1>.

Best,
Richard


[1] http://www.w3.org/2012/ldp/track/issues/13


> 
> Steve.
> 
>> -----Original Message-----
>> From: Richard Cyganiak [mailto:richard@cyganiak.de]
>> Sent: 20 March 2013 15:48
>> To: Steve Battle
>> Cc: public-ldp-wg@w3.org
>> Subject: 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 17:43:04 UTC