RE: syntax evolution, was Re: adding inline graphs to TriG

On Wednesday, July 24, 2013 3:34 PM, Sandro Hawke wrote:
> I'm not suggesting creating heaps of different competing systems.  I
> agree that's bad (which is why I proposed making our quad-testing
> language be a subset of our dataset syntax).  But I think we need a
> few, like maybe two or three in the Turtle family.   That will be a
> pain, but it will allow innovation and improvement.

Why do you think we need two or three (at the same time)?


> You say HTML manages with one media type (more or less), but it has
> some advantages here, including the ignore-what-you-don't-recognize
> rule of HTML and JavaScript shim functions.   And it's still rather
> painful.   How much do people use <section>?

Code on demand is actually a pretty interesting concept and I could imagine
that in a future version of JSON-LD it might make sense to consider allowing
some form of it.

 
> Lets imagine we wanted to extend Turtle to include a shorthand for ISO
> dates.   Instead of writing "2013-07-24T13:57:01Z"^xsd:dateTimeStamp
> we want to let people just write 2013-07-24T13:57:01Z.  That seems to
> me like it would be nice.

I would say that the fundamental difference is that HTML evolved while
keeping the parsing (more or less) stable. The tokens still look the same.
This is very problematic in languages like Turtle. JSON-LD or RDFa in
contrast don't suffer under that problem. It may look like a limitation (in
JSON-LD we need to use special keys to work around those limitations) but it
drastically improves evolvability if you don't need to change an
implementation at the lowest layer, i.e., the tokenizer.


> How could we do this without changing the media type?

I agree, for a language like Turtle that's impossible for the reasons stated
above. The question however remains whether we need to recommend them at the
same time or whether introducing new versions (Turtle 2.0) over time is
better.


> Basically, the only way you can change a format without changing the
> media type is to have the vast majority of the market on board and
> willing and able to get the extended parsers out there before people
> lose interest.    That's another thing HTML has going for it - there
> is a small number of players who control the market and are able to
> update nearly everyone's systems without convincing end-users of the
> merit of doing so.   (Of course, saying "IE6" to them is like saying
> "httpRange-14" to us.)

I'm quite sure a ten year old browser would still parse most documents and
display something more or less useful. Of course you would lose a lot of the
features available in newer browsers.


> Even if we had that level of participation and agreement among the
> parser writers -- which I think we MIGHT be able to get -- we still
> rely on other people to install upgrades.  I think people are not
> likely to deploy the new software unless it does something for them,
> and it wont do something for them until everyone has already deployed
> the new software.   (Otherwise you're in the people-mad-at-Dave
> scenario.)  Yes, you can try to convince them to upgrade for other
> reasons, bug fixes and other features, but it can take a very, very
> long time, and until pretty much everyone has upgraded, and somehow
> everyone knows this has happened, no one can use the feature in the
> open.

The RDF ecosystem is still tiny compared to HTML's. Most of the stuff has
been working without being standardized at all. I believe the community
should focus much more on building tools for the existing syntaxes than to
invent new ones. Sure, it may be nice to add some additional syntactic sugar
but how often do you really write RDF by hand? If you really need to do so,
write a little pre-processor that converts your own dialect to a
standardized syntax (think of all the "languages" that compile to JavaScript
like CoffeeScript)


> Media types and content negotiation give us a solution to this
> problem.   With them, people can deploy the new software (with the
> TurtleD parser using text/turtleD or something) and get the benefits
> immediately.  And those benefits grow as other people upgrade.  You
> don't have to wait for everyone to upgrade before using the new
> features among everyone who happens to have implemented them.

It looks like this becomes a discussion about media types. I'm a big fan of
media types. Nevertheless I'm not a big fan of having heaps of competing
solutions - especially if they are produced by a single entity.


> Even with the media types, it's important to get everyone on board, so
> there is a very small number of media types.   I wonder if we need an
> ongoing Turtle Working Group to handle that.

The question is whether the underlying data model will/can be changed or
not. If it won't/can't, you can't do much more than adding syntactic sugar -
which is not very interesting IMO. That energy can be spend better
elsewhere.



--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 25 July 2013 20:11:35 UTC