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

On 3/27/13 6:04 PM, Pierre-Antoine Champin wrote:
> 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!

+1

Richard: over to you re. LDP-WG and RDF-WG :-)


Kingsley
>
> More details below:
>
> On Tue, Mar 26, 2013 at 10:06 PM, Erik Wilde <dret@berkeley.edu 
> <mailto: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.
>
>


-- 

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