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

Natasha, Jeremy, All

I think this raises an important point in translating between databases that have fixed table structures and closed world semantics and OWL which has flexible lists of restrictions/facts and open world semantics.

I think there are at least two different ways in which NULL values are used in databases:

a)   To mean undetermined
b)    To mean negation - since a query will will fail to find anything.

In the specific example of a certificate, my assumption is that it has a "valid until" field which contains a date if the certificate is time limited and NULL otherwise, i.e. that it is case b)

I am not sure if this is in SWBP, but it is certainly a different note, but it is important.  My preferred solution to the problem is that the translation into OWL for the certificate containing a NULL field for "valid until" should be "not (valid until xml:date)" .  It paraphrases better if we rephrase it as

    has_expiration_date value( xml:Date ....      )

for the case where there is an expiration date, and as

    has_expiration_date owl:maxCardinality( 0 )

for the case where there is no expiration date.


This should let us find the class of all unexpired certificates defined roughly as  "The class of all certificates that do not have an expiration date prior to NOW" with the correct open world semantics and without any annotation properties.

There may still be some issues around query and rule languages here for data type properties. I'll leave that to others.

The main point is that I don't think we should not be translating things into OWL that have the sort of implicit semantics annotated when there is an explicit semantics available.

However, this may mean making semantics that are implicit in various programming constructs explicit in our ontology.  I would argue that that is a good thing.

Regards

Alan

PS

(I am not sure if there is a syntax for negating a datatype property with a generic top value analogous to

    complementOf( restriction( has_property someValuesFrom owl:Thing))

because I can't work out if you can use an 'empty' datatype to indicate 'anything of that type'.   If this is legal, then it would be an alternative, but I think the maxCardinality(0) solution  works with either datatype or object properties.)





Natasha Noy wrote:

> Jeremy,
>
> > 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.
>
> I have a vague idea what your point here is, but it's very vague
> indeed. Someone will have to "run  with it", as you say, if it is to be
> more clear.
>
> However, from what I can gather, I think this issue is out of scope for
> the note on how best to represent n-ary relations in RDFS and OWL. You
> may want to write a different note on how best to import data from
> relational database (and it may be a good idea to do so), but I am
> strongly in favor of each of these notes on ontology-design patterns to
> focus on one particular issue, and either sweep other issues that come
> up in examples under the rug, or (better yet!) cross-reference another
> note or pattern.
>
> If I am trying to build an ontology and have to represent an n-ary
> relation, I want to read something that is brief and hopefully answers
> my question rather than sort through many related topics trying to find
> my answer.
>
> The most difficult part would be somehow indexing or bringing all this
> stuff together later, when we have enough notes to try and bring them
> together.
>
> Natasha

--
Alan L Rector
Professor of Medical Informatics
Department of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL: +44-161-275-6188/6149/7183
FAX: +44-161-275-6236/6204
Room: 2.88a, Kilburn Building
email: rector@cs.man.ac.uk
web: www.cs.man.ac.uk/mig
        www.opengalen.org
        www.clinical-escience.org

Received on Friday, 14 May 2004 05:21:35 UTC