W3C home > Mailing lists > Public > public-swbp-wg@w3.org > May 2004

RE: [OEP] Draft of a note on n-ary relations

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.

Received on Tuesday, 11 May 2004 04:30:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:38 UTC