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

hello kingsley.

On 2013-03-26 8:00 , Kingsley Idehen wrote:
>>> >We have to solve the problem. We can't will it away:-)
>> 5. keep text/turtle - there is no problem.
> Okay, you might just be right re. #5. I've just revisited the current
> text/turtle media type description [1].
> Erik: what do you think could be missing from the existing media type
> definition re. links and associated interaction models?

turtle is not a hypermedia type, it's a data model representation. so 
for pure technical reasons, we have two options:

- go the XML route and accept that the underlying media type is not a 
hypermedia type, and then define all hypermedia semantics in the model 
we are defining. this means we have to do all the heavy lifting in terms 
of being a RESTful service: we have to document and annotate all links 
we are exposing, so that clients know which of the URIs we are serving 
actually are the ones that are hypermedia affordances. it can be done, 
but it just means we're solving the hypermedia problem just for 
ourselves (the LDP service).

- go the Atom route and build on a more generic model of interlinked 
data which we can utilize. in this case, we depend on a foundation layer 
of hypermedia-enabled RDF, and then build LDP on top of that. in that 
case, you could have generic client support for hypermedia, and then 
build LDP as one application on top of that.

the pragmatic web has mostly centered around the first approach in the 
last years, most often using XML or JSON as the data model foundation, 
and then building hypermedia structures on a per-service basis. that 
works, but has the "precious snowflake" smell to it that has been 
criticized by some.

the REST community has made several attempt to go the second route, some 
propose their own generic hypermedia types (such as HAL), others propose 
to use established ones such as HTML. the advantage of this way is to 
avoid the precious snowflake trap, the disadvantage is that generic 
types always look like it: a little generic, not really tailored to 
specific needs, maybe a little awkward in some scenarios.

my understanding of the RDF universe is that there is great momentum 
behind the idea of being generic. so i would assume that the second 
approach (which i have referred to as "hyperRDF" in some previous posts) 
might have more appeal. on the other hand, solving this problem 
generically is more effort, and is not really within the LDP scope. so 
pragmatically, i think the first approach is more feasible.

in the end, all we want is to support meaningful web interactions. 
assume there are three ways in which i can manage collections. one is 
LDP, which is clearly the best. the second is AtomPub, which i also 
really like, and then there's another one that also is RDF-based, but 
it's not so great and i don't really like it. but i still know how to 
use it. i want to be able to start interacting with a collection by saying:

Accept: application/ldp+turtle, application/atom+xml; q=0.5, 
application/badservice; q=0.1

and of course it's not really the case that servers must be able to work 
exactly like this (provide multi-service support and content negotiation 
between those services), but i think the point i am trying to make is 
that a service should be exposed at this level (i.e., in HTTP 
vocabulary) to be most helpful on the web.

cheers,

dret.

Received on Tuesday, 26 March 2013 16:52:48 UTC