- From: Tim Berners-Lee <timbl@w3.org>
- Date: Wed, 3 Apr 2002 23:48:42 -0500
- 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
invalid.
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
general.
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
Eg:
          this log:forAll   :a; :b; :c  :d; :e; :f
ouch.
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
key/predicate.
hmmmm
Tim
Received on Wednesday, 3 April 2002 23:48:38 UTC