Re: A modest attempt to re-open ISSUE-20

On 3/15/13 6:55 AM, Reto Bachmann-Gmür wrote:
>
>     The WG has not considered either, that there likely is a more formal
>     way to specify a Linked Data Platform. That an LDP instance could
>     consist of an RDF dataset, declarative description (ontology), and a
>     specification of the (state-machine) processor, that produces RDF
>     responses based on those inputs. It is not unlike how XSLT works:
>     given input XML document and a stylesheet, the processor produces a
>     result XML.
>
>
> I think this is an important point. A by the hypertext requirement of 
> REST a REST client should need nothing more than an entry URI and a 
> shared media type to be able to fully use a REST service. No spec 
> reading should be needed except for understanding the media type. Now 
> for Semantic REST service in my opinion the common media type is 
> trivially given and the requirement should be the common ontology. So 
> the specification of a Semantic REST service is nothing but specifying 
> the ontology. And ok, mandating a serialization format the service 
> must support if you insist.

There is a problem of conflation that continues to adversely affect RDF 
and RDF based Linked Data. At this juncture, there isn't a content-type 
formalization for RDF based Linked Data.

Examples of how these problems manifest:

1. RDF (a framework comprised of: model, syntax, syntax notation, and 
serialization formats) isn't the same thing as Linked Data (which is an 
application of RDF for creating graphs where URIs based hyperlinks have 
specific behavioral expectation or functionality)

2. The issue of relative vs absolute URIs when dealing with RDF syntax 
notation which is how one expresses to an RDF processor the graph to be 
serialized -- so an actual RDF graph doesn't contain relative URIs but 
an expression (e.g. in Turtle via "<>" etc.) can indicate to a processor 
how to determine the base URIs for the eventual serialization.

As proposed some time ago, maybe we need a content-type for RDF based 
Linked Data. This would enable RDF heavy and RDF Lite solutions to be 
less confused about payloads exchanged over HTTP (and any other protocol 
in the future).

RDF based Linked Data Lite:

This would have content-types such as:

1. application/ld+turtle
2. application/ld+n-triples.

Note the above is similar to the approach taken re., json-ld [1] which 
has content-type: application/ld+json . It SHOULD also allays the 
concerns of the RESTafari.

RDF based Linked Data Full:

This stays as is with the additional requirement for RDF based Linked 
Data processors to treat the content-types above as a more precise 
indication of Linked Data principles [2] adherence. Note, these 
principles outline specific behavior of HTTP URIs with regards to RDF 
model based graphs.

RDF:

Nothing changes, clients can continue to express RDF model based graphs 
using all existing syntax notations. Same applies to handling of actual 
graph serialization formats. There is no assumption that RDF == Linked 
Data.


Links:

1. http://www.w3.org/TR/2012/WD-json-ld-syntax-20120712/ -- JSON-LD .
2. http://www.w3.org/DesignIssues/LinkedData.html -- TimBL's meme that 
outlines Linked Data principles.


-- 

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