- From: David Allsopp <dallsopp@signal.dera.gov.uk>
- Date: Mon, 02 Apr 2001 16:14:19 +0100
- CC: www-rdf-logic@w3.org
"Peter F. Patel-Schneider" wrote: > > This is not a naive question at all. > > DAML+OIL does not require that you have the actual father, just that you > know that you have one. This is very different from the situation in > databases. To see why it is a good thing to be able to talk about your > father without knowing who he is, all you have to do is remember the > problems with (and endless debate about) null values. I think I understand that; my question was from the point of view of dealing with actual data representing specific instances of a class. In such a scenario, I would perhaps be using the DAML+OIL ontology to validate my data (and probably make inferences about the data). My question is, how could this process work? Let's say I have data for a person 'A', but not for their father. Does this mean my data do not conform to the ontology/schema (since A can't point to a father instance in my small model of the world)? Alternatively, if it is OK for A to not point to a specific father, then the cardinality restriction isn't doing anything; it isn't restricting anything! As far as one can tell from the data, A does _not_ have a father. I'm hoping that there is a third possibility. If I go to the data directly, I find that A does not have a father. Perhaps I'm not meant to do that; I should check first in the ontology, finding that A _must_ have a father, then deduce from the absence in the data that the father is unknown? If I carry out this process via an ontology-aware query engine, and ask "Who is A's father?", what would it return: - an error? - null? - An new instance of Person (person-who-is-the-father-of-A)? [Assuming here that the query returns 'objects' - if I'd asked for the URI resource of A's father, I guess this wouldn't make sense?] - something else? ...0r is the behaviour application-dependent? Generalising my question, I think what I'm asking is: to what extent can DAML+OIL be used to validate data, checking that the expected properties of an instance have defined values of the correct type (in the way that one can check the range and domain of RDF properties). It seems from the example above that some restrictions may perhaps not be 'checkable' in this sense? Regards, David Allsopp. > DAML+OIL does not have a finite model restriction. It is entirely possible > to have DAML+OIL models with an infinite number of objects that are not > datatype values. > > [Yes, there are many world views where everyone having a father (even an > unknown one) is contrary to fact, but I don't think that this is the > question.] > > I hope you'll forgive a (probably very naive) question: In the DAML+OIL > > walkthrough, we have the following example of a cardinality restriction > > (plus another minCardinality restriction). > > > > <rdfs:subClassOf> > > <daml:Restriction daml:cardinality="1"> > > <daml:onProperty rdf:resource="#hasFather"/> > > </daml:Restriction> > > </rdfs:subClassOf> > > <rdfs:subClassOf> > > <daml:Restriction> > > <daml:onProperty rdf:resource="#shoesize"/> > > <daml:minCardinality>1</daml:minCardinality> > > </daml:Restriction> > > </rdfs:subClassOf> > > My question is: how can such a restriction (cardinality=1) be enforced > > in practice, since we always deal with finite datasets - at some point > > our family tree will run out and we shall have an instance of Person > > without a corresponding Father instance. Can one specify a > > 'placeholder' of some kind or is there some other solution? Or will such > > data always cause a warning when validated against the ontology/schema? -- /d{def}def/u{dup}d[0 -185 u 0 300 u]concat/q 5e-3 d/m{mul}d/z{A u m B u m}d/r{rlineto}d/X -2 q 1{d/Y -2 q 2{d/A 0 d/B 0 d 64 -1 1{/f exch d/B A/A z sub X add d B 2 m m Y add d z add 4 gt{exit}if/f 64 d}for f 64 div setgray X Y moveto 0 q neg u 0 0 q u 0 r r r r fill/Y}for/X}for showpage
Received on Monday, 2 April 2001 11:18:19 UTC