RE: ACTION: elaborate on 4.4

-------- Original Message --------
> From: Kendall Clark <>
> Date: 7 June 2004 18:20
> 
> On Mon, Jun 07, 2004 at 12:01:40PM -0500, Dan Connolly wrote:
> 
> > -- 4.4 User-specifiable Serialization
> > 
> > ACTION: KendellC to elaborate on 4.4
> 
> -sigh-... I'll know DAWG is finished when Dan spells my name correctly
>  two times in a row. :>
> 
> Okay, to discharge this action item...
> 
> I proposed 4.4 because there are now, by my count, several
> exchange serializations of RDF graphs, with varying statuses: de jure
> standards, de facto standards, dead-end proposals, v. promising
> proposals, wild-ass ideas:
> 
> 1. canonical RDF-XML (with a couple of well-known variants)
> 2. Notation3
> 3. NTriples
> 4. TRiX
> 5. Turtle
> 6. RXR
> 7. YAML (I'm working on this one; it has some nice features)
> 
> And probably a few others I'v forgotten or never heard of.

Re: 1, 3, 5, 

There is one, defined recommendation for serializing RDF graphs - its
RDF/XML [1].  The one point of having a recommendation is so everyone can
implement one thing, and not many.

Alternative serialization that encode more information (TriX for the named
graphs, some way of using N3 with formulae) is one thing: promoting
alternative serialises of RDF just negates the value to clients (samll and
large) of having one serialization to deal with.

	Andy

[1] OK - it can't serialize every RDF graph [2]

[2] Example in case you were wondering:
    <x> <http://example.org/pred/> "string" .

And "yes" it can cause problems.  I have had a bug report from this - the
RDF is created programmatically, it is extracted and serialized.  And once
unhelpful predicates are in the DB they are hard to remove.


> 
> These all have different properties, different advantages and
> disadvantages; some are more widely implemented, some are good for
> resource-constrained use cases, and so on. But what seems clear to me
> is that no one of these is going to crowd out the others. Thus, I
> think we should recognize that fact -- if it is a fact -- and act
> accordingly.
> 
> So I want to be able to request or negotiate for -- and I'm *today*
> agnostic as to where, in the protocol or in the QL -- my preferred
> exchange serialization. That was the point of my proposal.
> 
> Open design issues (many of which I expect can be analogized to
> content negotiation in HTTP) include:
> 
>    - how to request one's preferred exchange serialization;
>    - whether it's a request or a negotiation;
>    - whether to identify exchange serializations by Internet Media
>      Type, by URI, or by canonical short name;
>    - which format should be the default? (Ok, that one is easy!)
> 
> Also, is this requirement totally parasitic on 3.4? In other
> words, if 3.4 is rejected, should we still be able to specify which
> kind of exchange serialization one prefers for variable binding
> results? I don't see why not, and, in fact, I think that this design
> objective is applicable to both 3.2 and 3.4 is an indication of its
> utility.
> 
> I hope this discharges my action item to expand on my reasons for 4.4.
> 
> Best,
> Kendall Clark

Received on Friday, 11 June 2004 07:10:22 UTC