Re: how to know that something was DELETEd

On 3/27/13 7:07 PM, Wilde, Erik wrote:
> 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.

Okay.

> one
> of our specific design goals is that you don't need to be a native RDF
> component to implement LDP as a service.

But PROV Data treatment doesn't correlate with that point. The PROV Data 
is RDF.

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

The LDP vocabulary will allow you do whatever it is you seek with your 
SQL DBMS based storage.


>   whether somebody sends me RDF that might be meaningful for a more
> generic RDF implementation, or an image, really doesn't make any
> difference.

Here's where things really stand, IMHO.

You see LDP as Linked Data Platform specification effort.

You adon't see Linked Data and RDF as being the same thing.

Henry for instance, sees Linked Data and RDF as the same thing.

I am in the middle because I think the middle is where RDF based Linked 
Data sits.

At some point, this group needs to take a vote as to what it believes 
its actually working with re., one of the following:

1. Generic Linked Data
2. RDF Model based Linked Data
3. RDF on the assumption that it also implies Linked Data.

If RDF is part of the narrative, then you can't negate the fact that 
vocabularies are a critical part of the deal. There's no such thing as 
RDF modulo vocabularies.

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

Yes!

> but i can also POST "binary resources", which the server doesn't even look
> it.

That's an LDP implementation decision i.e., some may understand binary 
formats.

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

> that's all the processing model says, and that's all an
> LDP server must implement.

Fine.

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

Fine. Thus, far their isn't an iota of novelty.

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

Hmm.

So is Callimachus uncontroversial to you? I ask because I just don't see 
how what is does is controversial to me or anyone else that's trying to 
understand your RDF concerns. As I've stated before, I see value in 
being clearer about RDF based Linked Data which isn't basic RDF data, 
but that's really a very small thing that can be resolved amongst RDF 
folks without disrupting or breaking LDP.

> 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).
A vocabulary can define data and how its processed. The entire HTTP 
protocol is describable in RDF. HTML can be described in RDF (Henry 
pretty much gave some examples in an earlier post). The same applies to 
Atom, but as you embark on doing that for Atom you also discover why it 
isn't good enough. Again, Henry covered that a while back to .

Remember, I once told you we (OpenLink Software) were very early 
implementers of AtomPub. That functionality still exists in Virtuoso as 
I type.


> so even though you can POST the
> exact same representation with the same media type in both cases, it has
> different protocol semantics.

LDP can define its protocol semantics using an RDF vocabulary.

>   it's the interactions that drive everything,
> including the interpretation of requests.

Yes, and neither Henry nor I expect or seek anything different. Links 
can drive everything if they denote entity types, *relations*, and 
instances. We just don't understand how the combination of RDF and 
Linked Data remain problematic as the basis for defining a Linked Data 
Platform.

> that's what HATEOAS is all
> about: drive applications by guiding them through interactions.

HATEOS isn't in anyway novel to me. I'll take a puff for social reasons, 
but it doesn't excite me one bit. It's chronic RDF based Linked Data 
that really gets me going :-)

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

If LDP is in anyway based on RDF based Linked Data then it has to be 
safe to assume the following about Data and Content:

Content is fine-grained Webby structured data endowed with 
machine-readable (and comprehensible) entity relationship semantics via 
the RDF data model. The LDP vocabulary should be able to clearly define 
everything required for deductive interactions between clients and 
servers that's totally driven by de-referencable URI (links). There's 
never been a time when logic, pointers, data structures, design time 
functions & parameters, runtime functions & arguments, haven't been the 
key components that drive programming. It just so happens that the 
Internet (network) is rapidly becoming the dominant computer and the Web 
is its dominant Unix-inspired operating system.

"Link:" relations enable the surfacing of relevant aspects of the LDP 
vocabulary up to the HTTP level, as and where its required. Denotation 
via links has never been solely confined to document content re. RDF 
based Linked Data.

Data is like parts of a tree trunk i.e., comprised of many rings. This 
analogy is applicable to data boundaries between HTTP level metadata and 
text/turtle based content. The RDF data model isn't confined to 
text/turtle, hence the reference to "Link:" relations above (again: 
Henry has also offered examples in the past).

BTW -- we've used "Link:" relations for eons as exemplified by DBpedia, 
to facilitate deductive interactions with user agents that grok RDF 
based Linked Data. Just curl an entity URI or its description document URL.


> which
> i guess most people have no immediate interest in, and i haven't seen
> mentioned it in any use case.
>
> cheers,
>
> dret.
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen