RE: issue-13 amended proposal

However, I'm not adding complexity to Containers, I'm describing
complexity that's already there. 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.

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:21:08 UTC