Re: Section 4: LDPR/non-LDPR formal definitions

On 3/25/13 4:52 PM, Martynas Jusevičius wrote:
> Kingsley,
>
> RDF based Linked Data != RDF, you're right. Instead, RDF based Linked
> Data = RDF wrapped in REST. I can prove this to you by showing source
> code that takes Jena RDF API objects, wraps them with JAX-RS REST
> code, and serves Linked Data.

Not disputing that. I don't need any additional proof :-)

RDF wrapped in REST or anything else != RDF. It's (as you state) RDF + 
something that's actually not in the RDF spec.

>
> That code has no problems working with generic RDF media types like
> text/turtle, and I don't see why other Linked Data systems should have
> a problem with that. Why invent new media types if the existing ones
> just work?

Because it won't cost you anything. At the same time, you build a bridge 
to other communities and profiles that are resistant to RDF because they 
find its comprehension eternally mercurial.

Will it cost you anything to support another media type in your 
application?

> Media types are largely orthogonal to the LDP spec, which
> should specify RDF state change over HTTP.

No, it's a practical comprise to clarify what RDF based Linked Data is 
all about via a specific media type.

Kingsley

>
> Martynas
>
> On Mon, Mar 25, 2013 at 10:01 PM, Kingsley Idehen
> <kidehen@openlinksw.com> wrote:
>> On 3/25/13 3:50 PM, Erik Wilde wrote:
>>> hello kingsley.
>>>
>>> On 2013-03-25 12:43 , Kingsley Idehen wrote:
>>>> On 3/25/13 2:41 PM, Erik Wilde wrote:
>>>>> sort of. but type is not a registered media type parameter of turtle,
>>>>> so you cannot actually to that. also, my suggestion would be to use
>>>>> profile instead
>>>>> (http://dret.typepad.com/dretblog/2013/03/on-profiles.html), but that
>>>>> one isn't a registered media type parameter either. but yes, what
>>>>> you're proposing is probably what we will have to do, given that it's
>>>>> unlikely that we will actually expose the LDP-ness of LDP resources at
>>>>> the media type level.
>>>> Why not?
>>>> What's wrong with media type: application/ld+turtle,
>>>> application/ldp+turtle or whatever else to end this most recursive line
>>>> of discussion and debate?
>>>
>>> absolutely nothing is wrong with that in my mind; it's actually the
>>> opposite: i think that's what we should be doing from the REST perspective.
>>> however, it seemed to me that whenever i suggested that it would be good to
>>> expose LDP semantics on the media type level, the majority opinion in the WG
>>> was that this is not what you normally do for RDF-based designs, and that
>>> instead we should be exposing generic RDF media types.
>>>
>>> cheers,
>>>
>>> dret.
>>>
>>>
>> Okay, for the record, I support exposing RDF based Linked Data semantics via
>> a specific media type. If I've been on the other side in the past, here is
>> my official position retraction :-)
>>
>> Generic RDF media types are problematic because they perpetuate a
>> problematic misconception about RDF and Linked Data. To denote something
>> with a URI != denoting something with a URI that resolves to the description
>> of said URI's referent.
>>
>> Conflating RDF simply undermines RDF's tangible virtues. IMHO., if LDP truly
>> wants to deliver something that's useful it should seize the moment by
>> killing off this eternal RDF & Linked Data conflation problem via a Linked
>> Data or Linked Data Profile (LDP) media type.
>>
>> RDF based Linked Data != RDF.
>> RDF based Linked Data is something that RDF enables you produce, most
>> effectively.
>>
>>
>> --
>>
>> 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
>>
>>
>>
>>
>>


-- 

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