- 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