N3Alternatives
43.5 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content=
"HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 13), see www.w3.org" />
<title>
Alternatives in the design of Notation3
</title>
<style type="text/css">
/*<![CDATA[*/
.not {background-color: #BEBEBE}
/*]]>*/
</style>
<link rel="Stylesheet" href="di.css" type="text/css" />
<meta http-equiv="Content-Type" content=
"text/html; charset=us-ascii" />
<link href="di.css" rel="stylesheet" type="text/css" />
</head>
<body bgcolor="#DDFFDD" lang="en" text="#000000" xml:lang="en">
<address>
Tim Berners-Lee<br />
Date: 2002/03/14, last change: $Id: Notation3.html,v 1.49
2001/11/27 23:59:33 timbl Exp $<br />
Status: personal view only. Editing status: draft.
</address>
<p>
<a href="./">Up to Design Issues</a>
</p>
<h3>
Ideas about Web Architecture
</h3>
<p>
<em>This is simply a footnote historical record about some
rather arbitrary choices, to save me going over the reasons
again and again. It is not part of the main thread.</em>
</p>
<hr />
<h1>
Alternative design choices in <a href=
"Notation3.html">Notation3</a>
</h1>
<p>
In this article:
</p>
<ol>
<li>
<a href="#Syntax">Syntax for Graph traversal</a> ("paths")
</li>
<li>
<a href="#Infix">Infix operators</a>
</li>
<li>
<a href="#Sets">Syntax for sets</a>
</li>
<li>
<a href="#Considered">Other issues</a>
</li>
</ol>
<h2>
<a name="Syntax" id="Syntax">Syntax for graph traversal</a>
</h2>
<p>
There is a strong need for a neat syntax for converting an
expression for x into an expression for something removed one
step along the graph from x by an arc of type (rdf:Property)
p. For example, if x is a person then we want an expression
for x's email address. <em>(I am dropping the prefixes in
this discussion to reduce clutter)</em>
</p>
<p>
"Neat"? Compact, powerful, simple, naturally understandable
because of metaphors with existing use of similar syntax.
</p>
<p>
Strictly, we are talking about <em>some y, such that
p(x,y)</em>, or in n3, [is p of x]. There is no implication
in this syntax at the moment (but could be later) that there
is only one such y. The information that there can be only
one such y, when it is so, is conventionally in stored by
noting that p is a daml:uniqueProperty property. This can be
stated in any document, though current colloquial use puts it
into the schema for p.
</p>
<p>
I will call moving from x to [ is p of x] forward traversal,
and moving from x to [p x] backward traversal. My instinct is
that forward traversal, which is the only thing you can do
naturally in many systems of linked objects, is more common
need in the language than backward traversal.
</p>
<p>
Backward traversal can also be expressed as forward traversal
through the inverse of a property, so a compact expression
for the inverse of a property would be an alternative, so
long it was clear when this was syntactic device for making a
backward link, and when(if ever) it was actually used to make
</p>
<p>
We need both to chose punctuation and also the grammar, as to
the precedence of the operator if any. To be able to write
"the person whose wife's uncle is driving my bother's car" .
Mostly here I am looking at traversal expressions going left
to right with no precedence, but "of" as used in english is
an exception in that it is right to left.
</p>
<h3>
Use case examples
</h3>
<p>
Forward traversal: The phone number of the home of the chair
of the conference x,
</p>
<table border="1">
<caption>
Example scenarios
</caption>
<tbody>
<tr>
<td></td>
<th>
English
</th>
<th>
Existing Notation3 (2002/02)
</th>
</tr>
<tr>
<td>
<p>
Forward traversal
</p>
</td>
<td>
The phone number of the home of the boss of x. X's
boss' home's phone number.
</td>
<td>
[ is :phone of [is :home of [is :boss of :x]]]
</td>
</tr>
<tr>
<td>
Mixed traversal
</td>
<td>
The phone number of the home of someone whose boss is
the uncle of x.
</td>
<td>
[is :phone of [is home of [ boss [is uncle of :x]]]]
</td>
</tr>
<tr>
<td>
Units
</td>
<td>
100 dollars.
</td>
<td>
[dollars "100"]
</td>
</tr>
<tr>
<td>
Units
</td>
<td>
the price in dollars
</td>
<td>
[ is dollars of price]
</td>
</tr>
<tr>
<td>
Language
</td>
<td>
The french phrase "chat"
</td>
<td>
[ lang:fr "chat"]
</td>
</tr>
<tr>
<td>
Language
</td>
<td>
The title in french
</td>
<td>
[ is lang:fr of :label]
</td>
</tr>
<tr>
<td>
Mixed
</td>
<td>
The author of the book whose title in english is "The
Little Prince"
</td>
<td>
[is author of [ has title [lang:en "The Little
Prince"]]]
</td>
</tr>
<tr>
<td>
Unary function
</td>
<td>
The sine of x.
</td>
<td>
[is sine of x]
</td>
</tr>
<tr>
<td>
Nary function
</td>
<td>
The maximum of 12, 23 and 20
</td>
<td>
[is math:max of ("12" "23" "20")]
</td>
</tr>
<tr class="not">
<td>
Nary function (named args) <strong>Not</strong> a
traversal case
</td>
<td>
The the result of spellchecking foo.html with
dictionary eng.dict.
</td>
<td>
[we:spellcheck <foo.html>; we:dictionary
<eng.dict>.]
</td>
</tr>
<tr>
<td>
Labeled traversal
</td>
<td>
an sculture whith a price of x dollars and creator y
domiciled in italy.
</td>
<td>
[a Sculpture; cost [ dollars x]; creator [=y; domicile
cc:it]] <em>This use of "=" is not real N3 syntax</em>
</td>
</tr>
</tbody>
</table>
<p>
The last case, labelled traversal, is in fact much more than
graph traversal - by embedding variables into the graph in
search template (rule antecedent), one make a reference which
can be used in a rule conclusion. One can also, by reusing a
variable more than once, make multiply connected (right
phrase?) graph in place of a tree.
</p>
<h3>
Dot
</h3>
<p>
This problem has strong analogy with moving from an object to
a slot in an object. Python, c++, etc: x.email, so that
metaphor is a natural one to pick up.
</p>
<p>
Pro: For programmers, this is a natural.
</p>
<p>
Con: Dot as the end of an n3 sentence would have to be
protected by following space or punctuation. The language is
made more complex in that either some tricky tokenizing with
some form of look-ahead becomes necessary.
</p>
<p>
There is no equivalent convention as far as I know for
backward traversal, so let's pick something random and
inverse to "." -- say "^". (Metaphor: back up rather than
down forwards?). Think of "^" as a combination of "." and an
operator to generate the inverse property. (Or maybe "^"
should be that property, which would make foo.^bar a
back-traversal except that it would actually be represented
using an extra triple.)
</p>
<h3>
Bang
</h3>
<p>
There is a form of path familiar to those who knew email and
net news in the days of source routing: when one had to
specify a series of machine names through which the mail had
to be forwarded, as in
<code>mcvax!cernvax!online!timbl</code>. Though few current
users will remember it, it has the advantage over dot of
being unused elsewhere in teh N3 syntax. This leaves the N3
language simpler.
</p>
<table border="1">
<caption>
Example scenarios
</caption>
<tbody>
<tr>
<td></td>
<th>
English
</th>
<th>
Using dot and caret, left to right
</th>
<td>
Right to left parsing with $ and %
</td>
<th>
Keywords, right to left
</th>
</tr>
<tr>
<td>
Forward traversal
</td>
<td>
The phone number of the home of the boss of x. X's
boss' home's phone number.
</td>
<td>
x.boss.home.email
</td>
<td></td>
<td>
email of home of boss of x
</td>
</tr>
<tr>
<td>
Mixed traversal
</td>
<td>
The phone number of the home of someone whose boss is
the uncle of x.
</td>
<td>
x.uncle^boss.home.email
</td>
<td></td>
<td>
email of home of thatwhich boss uncle of x
</td>
</tr>
<tr>
<td></td>
<td>
The formula from parsing a document whose URI is the
first command line argument
</td>
<td>
"1".os:argv^log:uri.log:semantics
</td>
<td>
log:semeantics%log:uri$os:argv%"1"
</td>
<td>
log:semantics of [] which has uri [] which is od:argv
of "1"
</td>
</tr>
<tr>
<td>
Units (b)
</td>
<td>
100 dollars.
</td>
<td>
"100"^dollars
</td>
<td>
dollars$"100"
</td>
<td>
thatwhich dollars 100
</td>
</tr>
<tr>
<td>
Units (f)
</td>
<td>
the price in dollars
</td>
<td>
price.dollars
</td>
<td>
dollars%price
</td>
<td>
dollars of price
</td>
</tr>
<tr>
<td>
Language (b)
</td>
<td>
The french phrase "chat"
</td>
<td>
"chat"^lang:fr
</td>
<td>
langfr$"chat"
</td>
<td>
thatwhich lang:fr "chat"
</td>
</tr>
<tr>
<td>
Language (f)
</td>
<td>
The title in french
</td>
<td>
title.lang:fr
</td>
<td>
lan:fr%title
</td>
<td>
lang:fr of title
</td>
</tr>
<tr>
<td>
Mixed
</td>
<td>
The author of (the book) whose title is the french "Le
Petit Prince
</td>
<td>
"Le Petit Prince"^lang:fr^doc:title.author
</td>
<td>
author % doc:title $ lang:fr $"Le Petit Prince"
</td>
<td>
author of thatwhich <em>has</em> title thatwhich
<em>has</em> lang:fr "Le Petit Prince"
</td>
</tr>
<tr>
<td>
Unary function
</td>
<td>
The sine of x. sin(x)
</td>
<td>
x.sin
</td>
<td>
sin%x
</td>
<td>
sin of x
<p>
x's sin
</p>
</td>
</tr>
<tr>
<td>
(its inverse)
</td>
<td>
arcsin(x)
</td>
<td>
y^sin
</td>
<td>
sin$y
</td>
<td>
thatwhich sin y
</td>
</tr>
<tr>
<td>
N-ary function
</td>
<td>
The maximum of 12, 23 and 20
</td>
<td>
("12" "23" "20").max
</td>
<td>
max$("12" "23" "20")
</td>
<td>
max of ("12" "23" "20")
</td>
</tr>
<tr>
<td>
Labeled traversal
</td>
<td>
A sculpture with a price of x dollars and creator y
domiciled in italy.
</td>
<td>
[a Sculpture; cost :x^dollars; creator [is y; domicile
cc:it]]
<p>
<em>This use is not real N3 syntax unless we change
"is'</em>
</p>
</td>
<td>
domicile$
</td>
<td>
[] a Sculpture; cost [] dollars 100; creator :y which
:domicile cc:it. <em>Note that a consistent grammar is
not obvious</em>
</td>
</tr>
</tbody>
</table>
<h3>
<a name="L7286" id="L7286">Multiply, Divide</a>
</h3>
<p>
Metaphor: Units of measure
</p>
<p>
A snappy syntax is useful in the leaves of an expression
tree,. Examples come up frequently when the logical way to
express data types, units of measure, and so on is with a
graph traversal. With units of measure, people use use
multiplication and division, and these actually make sense
mathematically.
</p>
<p>
Cost = 100*dollars or even Cost/dollars = 100 and
Cost/day=100*dollars.
</p>
<p>
Pro: / and * are indeed inverse, when you have unique and
unambiguous functions: x/y*y =x.
</p>
<p>
Con: This is not always the case! Also, "*" and "/" in math,
and in units of measure, have properties like commutativity
which you expect of "*" and it doesn't have in this context/.
Also, I had expected that it would be pragmatic to add in
operators directly to the syntax for convenience, and so was
reserving <em>+ - * /</em>.
</p>
<h3>
<a name="Keywords" id="Keywords">Keywords</a> - which, of,
's, the
</h3>
<p>
The english language suggests some keywords.
</p>
<p>
"which" I have considered using in a sentence to turn the
current object into the new subject. There are two forms I
had thought of, I'll call them "which" and "thatwhich" for
now. "Which", as in english, applies to a started object and
allows labelled traversal. "thatWhich" is used for backward
traversal, though the grammar is different.
</p>
<p>
<code>:joe :son :johnny which has :girlfriend :jane.</code>
</p>
<p>
<code>:joe :son thatWhich :girlfriend :jane.</code>
</p>
<p>
<code>thatwhich has :home thatwhich has :email thatwhich
has</code>
</p>
<p>
Pro: <em>which</em> reads very well (unless you insist on
<em>whose</em>!), especially with N3's optional <em>has</em>
before the property.
</p>
<p>
Con: <em>thatwhich</em> is unbeliveably ugly. Even
<em>which</em>, while reading well, is not a very concise
form.
</p>
<p>
A possibility is to just use <em>which</em>, with [] for the
<em>that</em> or <em>something</em> which precedes it in
english grammar. In fact, if someone wants <em>something</em>
as a synonym of [] I wouldn't violently object.
</p>
<p>
<code>:joe :son [] which :girlfriend :jane.</code>
</p>
<p>
A synonym for "which" could be the more mathematical
"suchthat", which suggests a vertical bar.
</p>
<p>
<code>:joe :son [] | :girlfriend :jane.</code>
</p>
<p>
This makes an effective traversal operator []| which is an
eyeful, but the pipe is nice as a connector.
</p>
<p>
<code>joe son :johnny | girlfriend jane | mother [] | email
<audey@example.com>.</code>
</p>
<p>
"Of" is interesting, though could be confusing that it parses
right to left
</p>
<p>
<code>email of home of boss of x</code> means <code>email of
(home of (boss of x))</code>
</p>
<p>
I just noticed that when I write on the blackboard, % and
<em>of</em> look pretty similar, so % to be read as
<em>of</em> would a possibility for forward traversal prefix
operator.
</p>
<p>
The astute will have noticed that "of" is already used as a
keyword in N3. However, all is not lost, in fact much could
be gained. Could one not split "of" and "is" into separate
features of the language, <code>p of y</code> being simply
short for what is currently <code>[ is p of y]</code>, and
<code>is</code> being an operator which at the syntactic
level indicates that two things are the same node.
</p>
<p class="detail">
(This is not the same as N3's =, which is daml:equivalentTo,
which has axioms about properties of similar things being the
same, but is not involved at this level. N3 and RDF treat
different URI-identified nodes separately, whether or not a
daml:equivalentTo arc joins them))
</p>
<p>
This allows things like
</p>
<p>
<code>joe brother [ is fred; wife margy; kids jane,
john]</code>.
</p>
<p>
Contrast "of" with with the english 's, German -es
</p>
<p>
<code>x's boss's home's email</code> meaning (<code>(x's
boss)'s home)'s email</code>
</p>
<p>
which reminds one of Ada's
</p>
<p>
<code>x'boss'home'email</code>
</p>
<p>
of whose etymology I am unaware.
</p>
<p>
Con: I was kinda thinking of keeping all the quotes I can in
hand for use in various forms of quotation! So many languages
needs many forms of quotation and run out of options all to
fast. (XML an Python both use " and ' to mean the same - a
waste if you ask me!)
</p>
<p>
One could go the other way and just use a keyword "s"
</p>
<p>
<code>x s boss s home s email.</code>
</p>
<p>
or use a "$" with a closeness to "'s" and expectation of
being read aloud as such:
</p>
<p>
x$boss$home$email
</p>
<p>
"The" in english signifies the uniqueness of something, and
so could be used to indicate that something is indeed a
function.
</p>
<p>
the email of the home of the boss of x
</p>
<h3>
<a name="Arrows" id="Arrows">Arrows</a>
</h3>
<p>
Access limited logic, and the original N3 design, one of the
conceptual graph serializations, and other languages derived
from a transcription of whiteboard circles-and-arrows
diagrams, use "->" or ">" as a traversal operator.
Multics used (I understand) ">" for descent of a directory
tree and "<" for ascent, so ../../foo/test would be
<<foo>test which is neat even though it frightens
the xml-minded side of one.
</p>
<p>
N3 uses <> to surround URIs, which i suppose could be
changed, but it interferes strongly with this.
</p>
<h3>
<a name="Slashes" id="Slashes">Slashes</a>
</h3>
<p>
Same idea as arrows, but using slash.
</p>
<p>
Pro: The metaphor with directory traversal is useful (even
though the graph being traversed is not always a tree).
</p>
<p>
Pro: A nice simplicity.
</p>
<p>
<code>x.uncle^boss.home.email</code>
</p>
<p>
becomes
</p>
<p>
<code>x/uncle\boss/home/email</code>
</p>
<p>
Con: Unix types could find it strange when finding their
universal escaping character used as anything else. And it
rules our using it for that form.
</p>
<p>
Con: The confusion which Microsoft introduce by using
backslashes for directories has done lasting harm to the
community, leaving many people still unsure which is which.
This sort of
</p>
<h3>
<a name="Parens" id="Parens">Parens</a>
</h3>
<p>
The application of a monadic function is a special case of
the traversal of a graph arc, so syntactic metaphors from
functions would seem appropriate. The most obvious case is
when a function takes a list, to just abut the function
identifier to the list, looking like a regular function call
in more languages than I could name:
</p>
<p>
<code>x = math:max(y z w)</code> for <code>x = [ is math:max
of (y z w)]</code>
</p>
<p>
Pro: Looks great.
</p>
<p>
Con: Doesn't work when the function doesn't take a list.
Also, if you get a space in between, it means something
completely different. Hopefully it will in some cases at
least be a syntax error, but not within in a list.
</p>
<p>
Maybe a separator of some sort as punctuation would work a
left/right reversed from of "."
</p>
<p>
<code>x = math:max$(y z w)</code>
</p>
<h3 id="Summarizin">
Summarizing
</h3>
<table border="1">
<caption>
Categorizing
</caption>
<tbody>
<tr>
<td></td>
<td>
Forward traversal
</td>
<td>
Backward traversal
</td>
</tr>
<tr>
<td>
suffix
</td>
<td>
x.email
<p>
x's email
</p>
</td>
<td>
y^email
</td>
</tr>
<tr>
<td>
prefix
</td>
<td>
email of x
<p>
email(x)
</p>
</td>
<td>
[] which email y
<p>
[] | email y
</p>
</td>
</tr>
</tbody>
</table>
<p>
One thing that becomes evident: it can be really difficult to
read the backward traversal in english. Like many systems,
(including WWW) , english is optimized for forward traversal
</p>
<h3>
Swan
</h3>
<p>
Sandro's swan language used a name immediately followed by
"(" as a function opener as in sum(2 3).
</p>
<p>
He also used "." for path traversal.
</p>
<h2>
<a name="Infix" id="Infix">Infix operators</a>
</h2>
<p>
I had reserved * / + - for infix operators for arithmetic.
The | operator for or and & for and (or union and
intersection of sets) are also reasonable to use in this way.
</p>
<p>
If N3 is to have a to have a path toward becoming a language
in which arithmetic and set operations are easy to write, it
is hard to improve on infix notation. This would, however,
change the form of the language significantly. It isn't clear
that it would still be predictively parsable.
</p>
<h2 id="Sets">
Sets
</h2>
<p>
<a name="following" id="following">The following</a>
considers design alternatives in extending N3 to include a
notation for set literals. 2005/1/1
</p>
<h3>
Background on containers
</h3>
<p>
In the area of containers, RDF started with some "Sequences"
and "Bags" which were in my opinion and with the benefit of
hindsight, sub-optimal (The infinite rdf:_1 series of
predicates was downright weird, and taking it into
consideration made code much mroe complicated. Futher, for
all the arbitrary complexity of the rdf:_nnn predictaes, they
didn't tell you that essential bit of information as to when
the container was finished: what <strong>wasn't</strong> in
the container) .
</p>
<p>
RDF does however have a <strong>collection</strong> which is
an ordered list, and is very useful. N3 has a shorthand
syntax ( 1 2 3 ) for the list of the numbers 1, 2 and 3, and
the RDF/XML syntax has parseType="collection" shorthand.
There is also defined a way of expressing lists in triples
using blank nodes, using <code>rdf:first</code> and
<code>rdf:rest</code>, and <code>rdf:nil</code>. The list 1 2
3 would be expressed as
</p>
<pre>
[ rdf:first 1; rdf:rest [<br /> rdf:first 2; rdf:rest [<br /> rdf:first 3; rdf:rest rdf:nil]]]
</pre>
<p>
This is, if you like, a reification of a list. It described
it totally. Some RDF systems actually store lists in this
way. The RDF and OWL specs together are not (as far as I was
aware) very clear about the axioms of lists. One would expect
clear axioms that all lists exist, that any two lists with
the same first and rest are owl:equivalent, and so on.
</p>
<h3>
Introducing sets
</h3>
<p>
It turns out that in many cases in applications we have seen,
containers are in fact logically unordered sets, not ordered
lists. Whether it is mail addresses on a mailing list, or
rows in a database, or statements in an N3 formula, the order
is immaterial, and something can occur in the set once or not
at all.
</p>
<p>
In these circumstances to use a list to represent the data is
suboptimal in may ways. For example,
</p>
<ul>
<li>It is not clear when two different lists actually have
the same members in a different order that they represent the
same set;
</li>
<li>The information about what is in fact a set end up being
communicated out of band, or just assuemd by those who know
the application;
</li>
<li>Underlying implementations cannot use code library
support which is optimized for sets.
</li>
</ul>
<p>
For these reasons it is useful to have sets in the language
in the same way as lists: to have a reification - a way of
expressing them in triples so as to be able to pass them
though general RDF applications whcih may be unaware of them,
and a shorthand syntax to allow them to be written
effeciently.
</p>
<h3>
Reification
</h3>
<p>
It turns out that OWL provides is with owl:oneOf, a
relationship between a class and a list, such that the class
is the class of things which are members of the list. Unless
for some reason one wants to make sets different from
classes, it seems appropriate to use classes for sets, and
furthermore to use owl:oneOf as the constructor which allows
us to specify a specific set in terms of an arbotrary
ordering of its contents. The set of numbers 1,2 and 3 would
then be written as
</p>
<pre>
[ owl:oneOf (1 2 3)]
</pre>
<p>
or, to elaborate it down to triples:
</p>
<pre>
[ owl:oneOf <br /> [ rdf:first 1; rdf:rest [<br /> rdf:first 2; rdf:rest [<br /> rdf:first 3; rdf:rest rdf:nil]]]]
</pre>
<p>
Of course, any reification of a set whish lists the same
members in a different order describes the same set.
</p>
<h3 id="Syntax1">
Syntax
</h3>
<p>
This is the more difficult choice! Here is a table of
suggested syntax extensions to N3 for sets.
</p>
<table border="1">
<caption>
Syntax extensions suggested for sets in N3
</caption>
<tbody>
<tr>
<td>
Syntax
</td>
<td>
Advantages
</td>
<td>
Disadvantages
</td>
</tr>
<tr>
<td>
(1, 2, 3)
</td>
<td>
Miniumal encroachment on to new punctuation.<br />
Comma becomes a marker for lack or ordering. This is
consistent with an object list.
</td>
<td>
Parser has to look ahead a whole expression to know
which it is dealing with: major change.
</td>
</tr>
<tr>
<td>
($ 1 2 3 $)
</td>
<td>
"S" stands for "set". Otherwise just like lists.
</td>
<td></td>
</tr>
<tr>
<td>
{$ 1 2 3 $}
</td>
<td>
"S" stands for "set". Curly braces are conventional for
sets. Curly braces are used for formulae, which are
also unordered.
</td>
<td>
Curly is used for formulae, which are not normal
collections
</td>
</tr>
<tr style=
"color: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">
<td>
{$ 1, 2, 3 $}
</td>
<td>
"S" stands for "set". Curly braces are conventional for
sets. Curly braces are used for formulae, which are
also unordered.<br />
Comma becomes a marker for lack or ordering. This is
consistent with an object list.
</td>
<td>
Curly is used for formulae, which are not normal
collections.
</td>
</tr>
<tr>
<td>
{* 1, 2, 3 *}
</td>
<td>
"S" stands for "set". Curly braces are conventional for
sets. Curly braces are used for formulae, which are
also unordered.<br />
Comma becomes a marker for lack or ordering. This is
consistent with an object list.
</td>
<td>
Curly is used for formulae, which are not normal
collections. Asterisk could be used as infix operator,
though not with .
</td>
</tr>
<tr>
<td>
{, 1, 2, 3 }
</td>
<td>
Curly braces are conventional for sets. Curly braces
are used for formulae, which are also unordered.
</td>
<td>
Curly is used for formulae, which are not normal
collections. Weird and unconventional to start with a
comma
</td>
</tr>
<tr>
<td>
@Set{1, 2, 3}
</td>
<td>
Just a new keyword, no extra syntax.
</td>
<td>
d.
</td>
</tr>
</tbody>
</table>
<p>
The current choice is {$ 1, 2, 3 $} which is conventional
mathematical set notiation, plus dollar signs to distinguish
a set from a formula.
</p>
<p>
An interetsing possibility pointed out by Sandro Hawke is to
actually make sets and formulas examples of the same thing. A
formula is just a set: a set of statements. This makes
statements first class objects. This is inherently appealing
in its symmetry. However, as there is no statment opener
syntax, only the closer (".", and effectively ";" and ","),
there is no way for the parser to know in advance whether a
statment or set is being parsed. This would not be the end of
the world, but makes life more difficult. Futher, the current
syntax alows an empty property list, so [ a :Deciduous, :Pine
]. is valid N3. This means that { :x } is a valid statment
(with no triples), which would overlap with set syntax.
</p>
<h3>
<a name="Disjoint" id="Disjoint">Disjoint</a> sets?
</h3>
<p>
There is an issue as to whether {$ :a , :b, :c $} imlies that
a, b and c are distinct. There was a <a href=
"http://rdfig.xmlhack.com/2005/01/26/2005-01-26.html#1106763446.326655">
discussion</a> of this in the SWIG.
</p>
<p>
If sets are disjoint:
</p>
<ul>
<li>You can say how many members are in a set.
</li>
<li>You cannot form the union or intersection of two sets
unless all the members involved are known to be disjoint, (or
one knows whcih ones are equivalent), for example if one
knows that they each are members of a larger set.
</li>
<li>In applications where the assumption is that a set is
disjoint, the system can check and trap an errro if two
members turn out to be the same.
</li>
<li>Cwm in smush mode, --mode=e, when it takes into account
equality, would probably remove dupliactes from sets but
there would be no signifince.
</li>
</ul>
<p>
If sets are not disjoint:
</p>
<ul>
<li>You don't know how many members they have, in general.
</li>
<li>You can do set union, but not intersection.
</li>
<li>You can validly handle sets where you don't actually know
how mny distinct (people say) there are.
</li>
<li>Cwm in smush mode, --mode=e, when it takes into account
equality, would on loading a new equality, in some cases
reduce the number of members of a set mentioned in the
knowledge base.
</li>
</ul>
<p>
One possibility is to build into the processor that in a mode
in whcih it is aware of equality it also tracks disjointness,
for example using inverse functional properties and
functional properties with numeric ranges.
</p>
<p>
Of course, where all the members of a set are vlues of a
datatype which provides a binary equality operator, such as
integers, this is not a problem.
</p>
<h2>
<a name="Considered" id="Considered">Considered design
alternatives in other areas</a>
</h2>
<p>
(older)
</p>
<ol>
<li>Using : for >- and -> so that the propertylist
looks like a list of attributes. Advantages: really human
readable. Disadvantage: keep "=" as an operator. Also, I
don't like "=" being used for something which is not
equality. It is ingrained as a binary reflexive operator and
it would be confusing to use it in attribute attribution.
Alternative alternative: use ":" for both "->" and
"-<".
</li>
<li>Use/allow keyword "has" for >- and "is" for <-.
Maybe, if still unambiguous, allow "of" for both "->" and
"-<". And/or use colon instead of "of". These assume that
the english words people pick as properties are noun clauses.
I actually preferred the use of verb clauses for what is in
fact a verb. I used to prefer "wrttenBy" to "author". Now I
have found the role-noun form much better.
</li>
<li>Making the subject of the propertylist, be another
property. (Say, "ref"). This is like Henrik's SOAP-RDF
mapping. Every statement has to become an anonymous node
syntax example: [ >- core:ref -> [ >- x:firstname
-> "Ora" ] ; >- dc:wrote -> [ >- dc:title ->
"Moby Dick" ]]. The thing becomes a binary rather than
ternary syntax so we should use binary syntax. Using -<
and -> only (omitting the >- and <- ) example would
be
<p>
[ core:ref : [ x:firstname : "Ora" ] ;
</p>
<p>
dc:wrote : [ dc:title : "Moby Dick" ]
</p>
<p>
]
</p>
<p>
or equally well
</p>
<p>
[ x:firstname : "Ora" ;
</p>
<p>
dc:wrote : [ dc:title : "Moby Dick" ]
</p>
<p>
]
</p>
<p>
We need better examples, requiring explicit reference to
the subject by URI.
</p>
</li>
<li>Allowing well-formed XML element as object. reserve
<alpha for this? What does XML infoset look like expressed
in RDF in notation3? decide: don't do it. Burdens notation3
compiler with XML parser weight.
</li>
<li>Use <> for URIs instead of ' - DanC. Hmmmm I wanted
to keep <> for other things maybe like string
delimiters. Actually it is cool to use inverse <. for
stings >this is a string< because then you end up being
able to make pages which look like markup and which are
functions in notation3.
</li>
<li>Bind vs @prefix. Bind was a directive which declared a
namespace with an implicit "#" between the namespace and the
local name. This has many advantages: it meant that by
looking at a URIref one could separate it unambiguously into
namespace URI and fragment ID. This in turn meant one could
dereference the namespace URI to get a schema or other
information describing the namespace. However, this is not
standard RDF. Nevertheless, the use of namespaces ending in
"#" is recommended, as then the items in the name space can
be easily described by a single document associated with the
namespace identifier.
</li>
<li>Whitespace: what about unicode NL? This was
included as one of teh few changes which happened in
XML as it changed fro 1.0 to 1.1 . NL is a C1 control
character which was introduced to allow the EBCDIC newline
character to eb encoded. Why should one have a separate
NL from the LF which CCITT defined all those years ago as the
code to be used when newline (CR LF together) was required?
</li>
</ol>
<h2>
Fodder
</h2>
<p>
Connolly points out: "This grammar starts to look a lot like
the formalized english/conceptual grammar stuff. >
http://meganesia.int.gu.edu.au/~phmartin/WebKB/doc/grammars/
>
http://www8.org/w8-papers/3b-web-doc/embedding/embedding.html
</p>
<p>
Philippe Martin says, "Given the similarities of your
Notation 3 with the (currently) more readable and expressive
Frame-CG notation (FCG) that I designed 2 years ago and that
is one of the notations used in my large-scale knowledge
server <a href="http://www.webkb.org/">WebKB-2</a> , you
might want to have a look at some executable <a href=
"http://www.webkb.org/doc/webkb2OntologicalExamples.html">example
files</a> (e.g. ) and at the <a href=
"http://www.webkb.org/doc/F_languages.html#FCG">grammar</a>.
The wide range of "quantifiers" is especially useful. You are
welcome to copy any part of the FCG grammar into your
Notation 3. (email 2001/09/17)
</p>
<h2 id="Footnote">
Footnote
</h2>
<h3 id="Thought">
Thought process behind implicit definition
</h3>
<p>
How does one label a node in notation 3 for incomming
reference? (The quivalent of "rdf:id=")? How about a property
"Thought process behind implicit definition How does one
label a node in notation 3 for incomming reference? (The
quivalent of "rdf:id=")? How about a property "is hereby
defined to be" with a suitable shorthand? One can then refer
to such as thing internally as '#foo' which is a bit messy
but not bad. You can't have keywords and identifiers both
using that precious status of pure alphanumerics unless you
reserve keywords. [ >- n:def -> '#ora' ; >-
x:firstname -> "Ora" ] . [ '#ora' >- dc:wrote-> [
>- dc:title -> "Moby Dick" ] ] . [ >- x:firstname
-> "Laura" ] <- x:hasChild-< '#ora' . or equally
well [ >- n:def -> '#ora' ; >- x:firstname ->
"Ora" ] . [ '#ora' >- dc:wrote-> [ >- dc:title ->
"Moby Dick" ] ] . [ >- x:firstname -> "Laura" ] <-
x:hasChild-< '#ora' . Ah. Now consider what is the
difference betwen reference and definition? I conclude there
is none, as both are the assertion that the resource in
question is identified by a URI. In the statements: [ >-
n:def -> '#ora' ; >- x:firstname -> "Ora" ] . [
'#ora' >- x:lastname -> "Lassila" ] . is there any
significance that the node '#ora' is defined to be one which
has firstname "ora" and lastname "Lassila" whichever way one
looks at it. I would therefore propose that the use of a new
local symbol :foo or '#foo' is taken as introducing it, but
the definition of it by the document is really the whole web
of statements which involve it. In fact, it maybe rather
difficult to talk about the definition of it as distinct from
the document, as as it is always best to avoid extra
concepts, I won't. The above examples should just be,
therefore, [ '#ora' >- x:firstname -> "Ora" ] . [
'#ora' >- x:lastname -> "Lassila" ] isn't that
simpler?.is hereby defined to be" with a suitable shorthand?
</p>
<p>
One can then refer to such as thing internally as '#foo'
which is a bit messy but not bad. You can't have keywords and
identifiers both using that precious status of pure
alphanumerics unless you reserve keywords.
</p>
<p>
[ >- n:def -> '#ora' ; >- x:firstname -> "Ora" ]
.
</p>
<p>
[ '#ora' >- dc:wrote-> [ >- dc:title -> "Moby
Dick" ] ] .
</p>
<p>
[ >- x:firstname -> "Laura" ] <- x:hasChild-<
'#ora' .
</p>
<p>
or equally well
</p>
<p>
[ >- n:def -> '#ora' ; >- x:firstname -> "Ora" ]
.
</p>
<p>
[ '#ora' >- dc:wrote-> [ >- dc:title -> "Moby
Dick" ] ] .
</p>
<p>
[ >- x:firstname -> "Laura" ] <- x:hasChild-<
'#ora' .
</p>
<p>
Ah. Now consider what is the difference betwen reference and
definition? I conclude there is none, as both are the
assertion that the resource in question is identified by a
URI. In the statements:
</p>
<p>
[ >- n:def -> '#ora' ; >- x:firstname -> "Ora" ]
.
</p>
<p>
[ '#ora' >- x:lastname -> "Lassila" ] .
</p>
<p>
is there any significance that the node '#ora' is defined to
be one which has firstname "ora" and lastname "Lassila"
whichever way one looks at it. I would therefore propose that
the use of a new local symbol :foo or '#foo' is taken as
introducing it, but the definition of it by the document is
really the whole web of statements which involve it. In fact,
it maybe rather difficult to talk about the definition of it
as distinct from the document, as as it is always best to
avoid extra concepts, I won't.
</p>
<p>
The above examples should just be, therefore,
</p>
<p>
[ '#ora' >- x:firstname -> "Ora" ] .
</p>
<p>
[ '#ora' >- x:lastname -> "Lassila" ]
</p>
<p>
isn't that simpler?.
</p>
<hr />
<h2 id="References">
References
</h2>
</body>
</html>