W3C home > Mailing lists > Public > www-rdf-interest@w3.org > April 2002

Re: n3 suggestion: comma, semi-colon, and period; Versioning

From: Tim Berners-Lee <timbl@w3.org>
Date: Wed, 3 Apr 2002 23:48:42 -0500
Message-ID: <00f401c1db93$ff90ce00$ac01a8c0@CREST>
To: "Sandro Hawke" <sandro@w3.org>
Cc: <www-rdf-interest@w3.org>

----- Original Message -----
From: "Sandro Hawke" <sandro@w3.org>
To: <timbl@w3.org>
Cc: <www-rdf-interest@w3.org>
Sent: Wednesday, April 03, 2002 10:14 AM
Subject: n3 suggestion: comma, semi-colon, and period; Versioning

> My biggest practical hassle in using n3 is changing between period and
> semi-colon when I add or re-order properties.
> It occurs to me that there is no need for period to be used this way:
> one could use semi colon to mark the end of a tuple, and the parser
> would fill in any missing fields in the tuple, on the left, with the
> data from the same field of the previous tuple.

True, I suppose.

(That rules out allowing comma-separated lists in other spaces which
I had considered, a la

:start, :middle, :end   a :node.

:joe  foaf:friend, work:supervisor :fred.)

> The counter argument is probably that redundancy in a language helps
> catch user errors, but when I hit this error, it's always because I've
> used the wrong punctuation, not because I've used the wrong number of
> terms in a tuple.

I find I do all kinds of silly things, and the syntax enerally ends up
The error is often "expecting . or ]"  or words to that effect. So  I would
worry about the error catching.

> Actually, given the format people seem to use for n3, I'd lean towards
> the tuple terminator being either semi-colon or newline.  (This is
> much like the shell, where semi-colon or newline ends a
> space-separated tuple which ends up in argv[].

Hmmm...   more shelllike, python like indeed. Cuts down on punct'n in

So you would lose the ability to use a newline as blank.
The list syntax is maybe a separate thing.

>  The idea of repeating
> fields on the left is quite different though.)

Yes.... those are independent things.

> I've used the word "tuple" instead of "triple" because this algorithm
> generalized to any size tuple.  It means you could have an n3 file
> with only predicate/object pairs (perhaps the default subject is "<>",
> or perhaps it depends on context), or even just objects.  I think
> that's pretty cool -- a file with one term per line would be a
> collection of values for some property of some subject.

Yes, it is cool.    I had wondered about allowing
{ <a>,  <b>, <c> } as a set.  Dan thought it would be confusing,
and lead to syntax error mixups. But there is a niceness to:-

{ <a>; <b>; <c> }  is a set
{ <a>  <b>;  <a2> <b2> } is a dictionary  (set of pred/obj pairs)
{ <a> <b> <c>; <d> <e>; <f> } is a formula.

I have to let this sink in...

> Allowing semi-colon where period and comma are now used would not
> break old data files, it would just give meaning to files which
> currently have invalid syntax.  Allowing newline to work like
> semicolon would break some files, but not many, and most of those
> would caught in a transitional language where comma and period
> retained their current meaning.

Yes.  What do folks think?  I am not sure about the readability,
and I am not sure about error catching.
I have very often missed out a comma in a list,
and doing it in this case would alas just parse fine

          this log:forAll   :a; :b; :c  :d; :e; :f


Another variation is to use whitespace instead of ";" and use puctuation
for the separators in a sentence.

Another ppossibility would be to try to match the the python dictionary

{ height: big; color: grey}

for the 2ple case, extending it to allow multiple values for the same


Received on Wednesday, 3 April 2002 23:48:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:35 UTC