- 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>
On 2002-06-12 12:41, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com> wrote: > > 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, right? 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. Thus: <rdf:Description rdf:about="urn:foo:1234"> <dc:creator> <rdf:Description> <ex:name>John Doe</ex:name> </rdf:Description> </dc:creator> </rdf:Description> gives us <urn:foo:1234> dc:creator _:x . _:x ex:name "John Doe" . whereas <rdf:Notation rdf:about="urn:foo:1234"> <dc:creator> <rdf:Notation> <ex:name>John Doe</ex:name> </rdf:Notation> </dc:creator> </rdf:Notation> 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 resource. 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 -- 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