You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1413 lines
44 KiB
1413 lines
44 KiB
<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>
|