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

hello richard.

On 2013-03-26 12:46 , Richard Cyganiak wrote:
> On 26 Mar 2013, at 16:52, Erik Wilde <dret@berkeley.edu> wrote:
>> turtle is not a hypermedia type, it's a data model representation.
> That's not quite accurate.
> The data model represented in Turtle is a model that was originally intended to serve as a hypermedia model by at least *some* of its designers, and that was *always* capable of serving as a hypermedia model, and *has* been used to build (read-only) hypermedia applications for many years. FOAF and its rdfs:seeAlso links were old news when Tim wrote his Linked Data piece.
> The data model has also been used for lots of non-hypermedia applications. But that doesn't change the fact that is fundamentally suited for hypermedia apps.

no disagreement here. but saying "it's suited for" is different than it 
actually being explicit about how hypermedia (and beyond read-only) is 
actually working with it. and if we're talking about turtle-only now 
(which i am unsure about): how does that fit with the idea that syntax 
shouldn't matter and any RDF-based application can be interacted with 
using any RCF syntax? i am really curious here because it does seem that 
there are subtle differences between the syntaxes.

> What if you want to use LDP semantics, but would prefer the RDF/XML serialization because that is better supported in your toolchain? Or you want to use LDP semantics, but want to use the newfangled JSON-LD syntax that seems to be the new hot thing right now? Do you want to define a new RDF/XML+LDP media type and a new JSON-LD+LDP media type as well?

yes, if you want to build interactions based on new ways how to 
represent things, this needs new media types.

> RDF and LDP are syntax-agnostic. It's the model that counts. Media types are a blunt instrument. They just have a single dimension. But in LDP we have two dimensions that we need to represent. First, the choice of surface syntax. Second, the choice of interaction semantics. We already use media types for the first, but this means we can't use them for the second without inventing a whole new orthogonal range of new media types.

the fact that things are layered have been noticed in a variety of 
scenarios. historic examples are XML, and now it's JSON. 
http://tools.ietf.org/html/draft-hansen-media-type-suffix-regs is where 
all of this is going, and afaict, this is where all RDF syntaxes should 
end up. at least this is the intention of this draft.

"Each of the Structured Syntax Suffixes defined in this document are
appropriate for use when the media type identifies the semantics of
the protocol payload.  That is, knowing the semantics of the specific
media type provides for more specific processing of the content than
that afforded by generic processing of the underlying representation."

> I understand the content negotiation scenario that you present above, and sure it would be nice if we could use content negotiation with such precision, but the example seems a bit hypothetical to me, and ultimately we should value backwards compatibility with existing read-only Turtle clients and servers over concerns of theoretical purity. (Also, can't this already be solved with ;profile=...?)

i fully agree that my example is a bit artificial. i was just trying to 
show how, ideally, services could make themselves visible in the web's 
uniform interface, and not just in RDF payload.

we could use profiles for this, but then every RDF syntax would need to 
define a profile media type parameter. one of the goals of profiles 
would be to provide at least this level of visibility on the web, but 
unfortunately it only works for media types that support such a parameter.

cheers,

dret.

Received on Tuesday, 26 March 2013 21:07:18 UTC