RE: adding inline graphs to TriG

On Wednesday, July 24, 2013 6:57 AM, Sandro Hawke wrote
> >> My concerns about it:
> >>
> >>     - it sounds like some more work, and I'm not sure who's going to
> do that.   I don't think I can commit to it.   Are we talking two
> languages, each with their own test suite?  We're quite short on time
> for getting to REC before the end of the WG.
> >  From a BNF perspective, it's really not too much work; I implemented
> the updates, including graphs as subjects, in about 10 minutes (much
> more time to update tests). Obviously, spec work will require more
> explanations and examples.
> 
> It's tracking public comments that worries me most.

Marking the new features as "at risk" would give us some flexibility in that
regard. If too many people complain/don't implement the features we can take
them out again.


> >>     - it puts more pressure on getting it right.  I think if we just
> Recommend TriG 1.1, with flaws (like no inline-graph-subjects), there's
> room for something better to come along.   If we produce something
> *somewhat* better than TriG 1.1, it makes it harder to migrate to
> something a even better than that.    This is very hard to judge.
>
> > I'd say we probably don't need to release a TriG 1.1, and just go
> strait to the better syntax; why muddy the waters even further?

I agree with Gregg. I have been worried about the plethora of syntaxes (and
flavors) we are producing for quite some time now.


> TriG
> 1.0 is reasonably stable and broadly implemented as it is). For that
> matter, there's really not a need to release Turtle 1.1 either, as it's
> completely subsumed in the newer language, except as a publishing
> profile.

That would be my preferred choice as well but I think that ship has sailed.


> Theory vs Practice.     The "Turtle" brand is important.

Yes


> >> Some of the things that might also be included in a better-than-TriG
> (some of which have nothing to do with named graphs), that I doubt
> we're ready to put in a REC yet:
> >>   - particular dataset semantics
> >>   - literal times & dates
> >>   - a syntax to help with repeated objects (either an inverse-
> predicate operator or allowing comma between subjects)
> >>   - things to make turtle usable for people who dont want to handle
> lots of namespaces (cf json-ld and RDFa)
> >>   - a syntax for variables (far-fetched, I know)
> > I'm a bit more wary about the potential problems that untested syntax
> might add. I'd say we may go so far as to borrow patterns already
> established in Notation3 but leave it at that this time around. An
> initial context, based on RDFa's might be interesting, though.
> 
> My point here is that the idea of the "next time around" is
> problematic.   I don't believe the market can handle minor changes in a
> widely deployed data language.    For any change, once it's widely
> deployed, we need to change the mime type.  And people will only bother
> doing that if the new type offers significant improvements.     I can
> see the market handling TriG and one other graph language in the next
> few years, so if we do both of them now, there wont be a "next time
> around" for quite a long time.      Of course, if we only do TriG, it'll
> still be hard for any second language to make it -- but it'll be a bit
> easier.

I'm not sure I buy this argument. Look at HTML. It's much more problematic
to create heaps of different competing syntaxes for essentially the same
thing than to gradually improve a syntax and to keep implementations up to
date with those minor changes. It's very costly to support a wide variety of
syntaxes at the same time and greatly reduces interoperability because the
chance that two systems find a syntax they both understand goes down with
every new syntax we produce. Thus, my preferred set of syntaxes would be
RDFa, Turtle+ (datasets), JSON-LD, RDF/XML (for historic reasons).


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 24 July 2013 07:46:17 UTC