- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Tue, 11 May 2004 10:29:13 +0200
- To: "Natasha Noy" <noy@SMI.Stanford.EDU>, "Bernard Vatant" <bernard.vatant@mondeca.com>
- Cc: "Alan Rector" <rector@cs.man.ac.uk>, "swbp" <public-swbp-wg@w3.org>
I've got another comment that I have not managed articulate yet - it is possibly two comments. I'll try and sketch the point here, in the hope that someone else will be able to pick it up and run with it. 1) (more basic one) defaults and nulls This design pattern may well be used by people porting relational data to RDF and OWL. Sometimes that permits null values; the most obvious mapping is null values get mapped to 0 triples. Unfortunately, the semantics of a column might indicate some default semantics when a null is present. This is not appropriate on the semantic web and default values need to be made explicit. (e.g. a language column in a US library might only be used for foreign works, i.e. not in US english) 2) harder point again, in the same use case of porting from a relational database. In porting to RDF you need to break the n-tuples into triples, one per column. RDF semantics imposes a monotonic semantics on these triples. This can result in porting errors where the semantics of an n-tuple depends on the values of its fields in a non-monotonic fashion. These errors can best be avoided by making it clear in any rdfs:comment that a single triple does not have meaning, but the combination forming an n-tuple is given meaning (poorly expressed), see the way that OWL Full discusses the meaning of owl:onProperty. combining the above: An example of where this might fail is where the n-tuple represents a certificate, and one of the fields is called "valid-until" and if the value is null the certificate is understood as always valid. The most obvious mapping to triples is flawed by being non-monotonic. Jeremy
Received on Tuesday, 11 May 2004 04:30:30 UTC