W3C home > Mailing lists > Public > public-rdf-wg@w3.org > July 2013

Re: adding inline graphs to TriG

From: Sandro Hawke <sandro@w3.org>
Date: Wed, 24 Jul 2013 00:57:00 -0400
Message-ID: <51EF5E9C.2000106@w3.org>
To: Gregg Kellogg <gregg@greggkellogg.net>
CC: Markus Lanthaler <markus.lanthaler@gmx.net>, public-rdf-wg@w3.org
On 07/23/2013 10:22 PM, Gregg Kellogg wrote:
> On Jul 23, 2013, at 6:26 PM, Sandro Hawke <sandro@w3.org> wrote:
>
>> On 07/23/2013 01:49 PM, Markus Lanthaler wrote:
>>> On Tuesday, July 23, 2013 3:28 PM, Eric Prud'hommeaux wrote:
>>>> * Andy Seaborne <andy@apache.org> [2013-07-23 13:52+0100]
>>>>> I think that IF we do this, we do it properly - {} in the subject
>>>>> position is important and the the new syntax is already some way
>>>>> away from traditional TriG + it is no longer trying to be
>>>>> SPARQL-compatible.
>>>>>
>>>>> Hence: proposal:
>>>>>
>>>>> 1/ Give it a new name and content type.
>>>>>
>>>>> This would be better and probably smooth the process of getting a
>>>>> REC because a new name does not bring old assumptions with it.  No
>>>>> issues with existing use.
>>>>>
>>>>> 2/ Do not have {} for the default graph.
>>>>>
>>>>> Do have {}-graphs in the subject as well as object positions.
>>>>>
>>>>> 3/ Publish TriG as a NOTE.  It is useful to give it some kind of
>>>>> status with the changes for Turtle token alignment etc.
>>>> I think we should seriously consider this proposal. It may be the best
>>>> path for us to engage potential RDF users with an attractive and
>>>> practical language.
>>> +1
>> Would the TriG Note in this scenario document TriG as this WG imagines in today (with the Turtle changes, no "=", allowing repeated graph names, and the SPARQL stuff like PREFIX, BASE, and GRAPH) or would it just be what most/all TriG parses in the world are actually parsing today (or last year)?  Maybe call those TriG 1.1 and Trig 1.0 respectively.
>>
>> Either way, I'm +0 to this, but that might change as I think about it more.   I certainly think there's room for a language that's better than TriG 1.1, I'm just not sure about doing it Rec-Track within this WG.
>>
>> 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.

>>     - we have to come up with a good name for it.    fun, but hard.    (I remember some ideas like "superturtle", "quartle", "turtle 2", "turtle with graph", "mugl", "triq", )
> Hot about Tint? (Tint is not TriG/Turtle) :)
>
>>     - 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? 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.

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

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

          -- Sandro

> Gregg
>
>> Lots of ways to proceed here, but a lot of uncertainty making it hard to pick a path.
>>
>>         -- Sandro
>>
>>> --
>>> Markus Lanthaler
>>> @markuslanthaler
>>>
>>>
>>>
>>
>
Received on Wednesday, 24 July 2013 04:57:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:30 UTC