Re: Aggregation: simple proposal

hello nandana.

thanks for the feedback!

On 2013-01-17 23:18 , "Nandana Mihindukulasooriya" <nmihindu@fi.upm.es>
wrote:
>So if we put that idea into an example in the context of LDP, do you mean
>something like this where ldp:contains indicates aggregation
>
>@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
>@prefix ldp: <http://www.w3.org/ns/ldp#>.
>@prefix o: <http://example.org/ontology/>.
>
><http://localhost/cnt1>
>    a ldp:Container;
>    rdfs:member  <http://localhost/cnt1/a1>;
>    ldp:contains <http://external/resource> .
>
><http://localhost/cnt1/a1>
>   a ldp:Stock;
>   o:value 10000.
>
>I have several questions in mind but as I am quite positive that what you
>meant is not exactly like this so I will keep them for later.

that's different in a variety of ways from what i would suggest. following
the model i was describing earlier, this is what needs to happen (for what
we call "aggregation"):

- the entry that's managed by the server contains those metadata fields
that are under the control of the server and thus part of the LDP
protocol. in atompub, these are a handful of fields such as title,
creation and modification data, and author. also, clients can add any
other number of client-specific metadata fields that the server won't
understand, but will happily manage. all of this will become part of the
entry managed by the server, but it's only entry metadata.

- the actual entry content is not part of the data POSTed to the server,
it is only linked in the data POSTed to the server. one way to look at
this would be to say that there is yet another metadata field "content",
which when used means that the content of an entry is "external" to the
server ("aggregated" in current LDP speak). this link will be managed by
the server like all other data that has been submitted.

- a client GETting such an entry will GET all the metadata that's governed
by LDP, plus all the metadata that the creator of the entry has decided to
put into that entry's metadata. the client will also GET the link to the
"external" content. given that this link is defined by LDP, the client
will know that in order to GET the full entry, it needs to follow this
link to GET the actual entry content.

- if a client DELETEs this entry, nothing special needs to be done. the
server will simply delete everything it controls, which means it will
delete all the metadata that had been submitted, including the link to the
content. the content itself (what the content link was linking to) will of
course remain unaffected, since it can live anywhere on the web.

what i like about this is that there's no need to define different
behavior or protocols or management strategies for the server. you simply
say "the server manages whatever you submit to it, and nothing else", and
you have to make sure you can submit embedded content or a link to
content, and then you're done.

that being said, keep in mind that while this is useful and simple, this
does not cover the case of "media entries" where we actually want the
server to manage both a media entry, and a media link entry. in that case,
the interactions actually go through the media entry, as clients submit
the media entry to the server, and the server then creates a corresponding
media link entry that represents the media entry and contains the LDP
metadata for it. since in this case the server manages both resources, a
DELETE on one of them could effectively delete both (atompub makes that a
SHOULD, though, just to be careful i guess).

cheers,

dret.

Received on Friday, 18 January 2013 09:27:05 UTC