W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > June 2002

Re: new semantics initiative

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 12 Jun 2002 14:42:51 +0300
To: ext Graham Klyne <Graham.Klyne@mimesweeper.com>, Jan Grant <Jan.Grant@bristol.ac.uk>
CC: RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <B92D0E6B.16919%patrick.stickler@nokia.com>

On 2002-06-12 12:41, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>

> At 09:52 AM 6/12/02 +0100, Jan Grant wrote:
>> Agreed; I'd rather see some syntactic mechanism for darkening (or more
>> generally, colouring*) triples that doesn't rely on URI inspection. In
>> particular, URI inspection doesn't need to be written into the MT
>> documents - it should just appeal to darkness (or otherwise) that's
>> determined through a mechanism external to the document.
> Speaking personally, me too.  But that does seem to require a syntax
> extension, which may be difficult at this stage.

Well, it depends on which 'syntax' you mean. But either way I don't
think it's all that big a change.

First we need mechanisms for representing that bit in the graph syntax.

Now, in NTriples, we can just use the ';' terminator instead of '.'
as has already be suggested. Or if that isn't visually distinct
enough, we could e.g. proceed dark triples with '# ' (which
humorously seems to reflect their role insofar as RDF semantics
is concerned ;-)  

For node-arc diagrams, employ dotted lines for arcs denoting dark
triples. Clear and intuitive enough, I think.

The MT already has mechanisms in place to address dark triples,

That takes care of the graph, right?


Then we have the RDF/XML syntax. There are several options, including the
namespace prefix trick.

I would prefer something independent of namespaces, that's generic, such
as an analog to rdf:Description, called e.g. rdf:Notation within
which all triples would be dark. This would preclude the contracted
form of using class names as element names, but no great loss I
think, in practice.


<rdf:Description rdf:about="urn:foo:1234">
         <ex:name>John Doe</ex:name>

gives us

<urn:foo:1234> dc:creator _:x .
_:x ex:name "John Doe" .


<rdf:Notation rdf:about="urn:foo:1234">
         <ex:name>John Doe</ex:name>

gives us

# <urn:foo:1234> dc:creator _:x .
# _:x ex:name "John Doe" .

An RDF parser produces asserted triples until/unless
it encounters an rdf:Notation element, and then
for that sub-branch of the XML tree, it generates
unasserted triples, until/unless it encounters an
rdf:Description sub-element, then it switches back
to generating assertions, etc. That's easy enough to
implement. Just flicking a switch each time
rdf:Description or rdf:Notation is encountered
and checking the switch to know whether a triple
is asserted or unasserted.

Thus, one either asserts "descriptions about" a
resource or expresses unasserted "notations about" a

This approach has the benefit that one may use the same
vocabulary for both asserted and unasserted triples in the
same RDF/XML instance, should that ever be useful.

It also doesn't require vocabulary-term specific
definitions about what is or is not dark, but provides
a generic syntactic mechanism for setting the dark
bit on generated triples.


Thus, statements that
belong at a higher layer above RDF are just
unasserted notation at the RDF level, but following
the same syntax as asserted statements. And there
is just one bit that differentiates the two.

So that seems to cover it. Eh?


Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Wednesday, 12 June 2002 07:38:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:58 UTC