Re: how to know that something was DELETEd

hello kingsley.

On 2013-03-27 15:35 , "Kingsley Idehen" <kidehen@openlinksw.com> wrote:
>On 3/27/13 4:27 PM, Wilde, Erik wrote:
>>we just build interactions for LDP, and that includes
>> interaction affordances with what unfortunately so far has been called
>> "binary resources", even though it just refers to any kind of payload
>>(as
>> opposed tp LDP stuff we care about). if they POST PROV data as
>> text/turtle, that's fine.
>Okay, but why is the "scenario" any different for any other RDF payload
>since RDF is driven by vocabularies? Basically, as Henry articulated
>earlier on: it's all about relations and their semantics -- the
>semantics in question are delivered by vocabularies.

an LDP server has no knowledge of or interest in PROV, out of the box. one
of our specific design goals is that you don't need to be a native RDF
component to implement LDP as a service. so when i implement LDP on my SQL
storage, all i care about is LDP. that's all i know, that's all i need to
know. whether somebody sends me RDF that might be meaningful for a more
generic RDF implementation, or an image, really doesn't make any
difference.

>>if they POST it as text/prov+turtle, that's
>> fine, too. as long as the LPD server accepts these media types, it
>>simply
>> accepts the data as content, and echoes it when a GET request is
>>received.
>> from the LDP point of view, it's no different from somebody doing things
>> with image/jpeg.
>Fine re. all the media types you mentioned (including text/turtle). I am
>just unclear about the special treatment (or clarity) that applies to
>PROV data. Remember, every statement in an RDF graph is a claim (or
>proposition). Provenance data, metadata, or any other kind RDF model
>based data is just a graph based (or structured) collection of
>propositions.

clients have to POST data that makes sense based on the LDP vocabulary.
but i can also POST "binary resources", which the server doesn't even look
it. if i do that, they are simply not processed at all. the LDP processing
model says: must be stored at POST, replaced at PUT, retrieved at GET, and
removed at DELETE. that's all the processing model says, and that's all an
LDP server must implement. it can do more (such as callimachus) and start
doing smarter things for certain "binary resources", but that entirely
optional from the LDP point of view.

>>i think this was very nicely echoed in james comments regarding
>> callimachus: they just decided to treat POSTed RDF a little different
>>than
>> POSTed JPEGs by storing it in a named graph (to maybe run queries on
>>that
>> graph, i suppose, or maybe support other services they may provide), but
>> in the end this simply means they store this resource as it is, so that
>> they can return it as it was POSTed.
>Yes, but how is that inconsistent with anything Henry, myself, or anyone
>else has been trying to articulate re., RDF content handling?

the difference is in the interactions: callimachus allows you to POST
text/turtle to two URIs. at one, it has protocol semantics (for LDP, that
means you have to use the LDP vocabulary in the way the processing model
prescribes), at the other one, it doesn't (you can POST whatever you like,
and it doesn't have protocol semantics). so even though you can POST the
exact same representation with the same media type in both cases, it has
different protocol semantics. it's the interactions that drive everything,
including the interpretation of requests. that's what HATEOAS is all
about: drive applications by guiding them through interactions.

>>   if they hadn't any requirements for
>> additional services for RDF resources, they could also just store it as
>> CLOB/BLOB.
>Yes they could, but it doesn't help me understand your fundamental
>concerns with the points made by Henry or myself in the past re. RDF
>model semantics and LDP.
>If PROV Data isn't problematic to your world view then nothing else
>should be re., RDF which is always driven by a vocabulary (that defines
>entity types and relation semantics). The treatment you espoused for
>PROV Data applies safely to all RDF based data since there's always a
>vocabulary in play.

almost. unless we also want to be able to treat LDP data as content. which
i guess most people have no immediate interest in, and i haven't seen
mentioned it in any use case.

cheers,

dret.

Received on Wednesday, 27 March 2013 23:08:09 UTC