Urgent decision required? (was Re: Section 4: LDPR/non-LDPR formal definitions)

Hi Erik, Richard, all,

short summary:
* one solution for conveying interaction semantics in RDF media types
*could* be to use the profile= parameter ;
* Erik notices that this is only possible if the respective media-types
allow this parameter;
* as those formats are *currently* being re-defined by the RDF-WG, now
would be the perfect time to do it;
* but Turtle is already CR, so we should not wait too long!

More details below:

On Tue, Mar 26, 2013 at 10:06 PM, Erik Wilde <dret@berkeley.edu> wrote:

> hello richard.
>
> On 2013-03-26 12:46 , Richard Cyganiak wrote:
>
> 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.
>

I totally agree with Richard that we have to many dimensions to be captured
by content-type, here.


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

I think that, with RDF, the problem is even more complex: XML and JSON
basically conflate their data model with a single syntax. So "+xml" in
application/atom+xml means two things:
* the atom conceptual model is encoded in a DOM tree
* that DOM tree can be parsed with an XML parser

With RDF, there are multiple surface syntaxes to encode the data model, so
the media-type would be something like
application/ldp+rdf+turtle ; feasible, but kind of ugly. And it does not
play well with content-negociation...

> 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=...?)
>

+1 to that !


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

... and this is where we might have a chance to seize. As mentionned in my
short summary above, the RDF WG is still active, and shares a number of
members with this WG -- I, for one, would advocate in favour of this
addition :) Besides LDP, I have a few use cases in mind...

I even think that the 'RDF Concepts' document could require that all
current and future surface syntaxes support that parameter, in order to
convey such additional semantics (Richard, what do you think? )

  pa



> cheers,
>
> dret.
>
>