RE: issue-13 amended proposal

See my comments inline.

And a reminder of my amended proposal:
"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."

And for comparison, the earlier proposal:
"Close the remainder of ISSUE-13 by saying that servers may refuse to
update inlined members through PUT/PATCH to a container."

Regards, Steve.

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

Section 5.2.6 describes exactly the case I describe and provided an
example for. The case a) where the "LDPC may include an arbitrary number
of additional triples whose subjects are the members of the container",
and case b) triples that are " from the representations of the members".
The prov:wasAttributedTo property is an example of (a) and the o:asset
property an example of (b).

" 5.2.6 The representation of a LDPC may include an arbitrary number of
additional triples whose subjects are the members of the container, or
that are from the representations of the members (if they have RDF
representations). This allows a LDPC server to provide clients with
information about the members without the client having to do a GET on
each member individually. See section 5.1.1 Container Member Information
for additional details."

I agree that the spec doesn't say what happens if you PUT/PATCH inlined
member triples, I just want to ensure that clarification of this point is
consistent not only with case (b) above, but also with case (a). The
wording of the issue-13 proposal should be consistent with 5.2.6. That is
the point of my amended proposal.

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

In my opinion, the original proposal fails to distinguish between cases
(a) and (b).
My amended proposal also provides the same clarification regarding inlined
member triples, saying that the server may refuse such a request in case
(b) but not in case (a).

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

I meant that issue-13 is merely seeking clarification around these issues,
it is not proposing  a change to 5.2.6. We clearly have different
intuitions about containers and this is worth discussing, though  I think
a change to 5.2.6 (ie. such as explicitly removing the case where the
"LDPC may include an arbitrary number of additional triples whose subjects
are the members of the container") would require raising a separate issue.

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

OK - I still think that's an application level decision. Given the current
spec I would keep the provenance metadata in the container. If clause (a)
were removed from 5.2.6, then - yes - I'd be forced to move them into
either <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 Thursday, 21 March 2013 11:08:56 UTC