- From: Dan Brickley <danbri@w3.org>
- Date: Thu, 6 Jun 2002 20:46:37 -0400 (EDT)
- To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
- cc: <www-webont-wg@w3.org>
On Thu, 6 Jun 2002, Peter F. Patel-Schneider wrote: > From: Dan Brickley <danbri@w3.org> > Subject: Re: Issue 3.4 - daml:UnambiguousProperty (fwd) > Date: Thu, 6 Jun 2002 08:53:20 -0400 (EDT) > > > On Thu, 6 Jun 2002, Peter F. Patel-Schneider wrote: > > [...] > > > > I am totally confused as to why you would think that WebOnt is concerned > > > with time. Could you please let me know why you think that WebOnt should > > > be concerned with the time-varying behaviour of properties? > > > > > > Because the properties of things vary over time, and we're supposed to be > > deploying this language in the World Wide Web. Hence the name. > > I understand that giving OWL a proper notion of time/change would be > > way too much for v1.0, perhaps ever. Nevertheless, if W3C are to RECommend that > > the Web community use OWL vocabs in real life to describe real things in > > the World Wide Web, it won't take long before practical use of OWL runs > > into situations where the truth about property values change of time. > > Agreed. And OWL will have nothing to say about that. Its model theory > will describe information as of a particular instant in time (or, if you > prefer, information that it timeless). That was the DAML+OIL and RDF approach, so seems reasonable for OWL 1.0 too. (Was this formally decided anywhere, or implicit in the 'based on DAML+OIL' charter?) > > Maybe this is tutorial/primer material for OWL 1.0 rather than language > > fodder. > > I would say that it should go in a > Living with OWL > document, not in any normative material or material intended for neophytes. It's hard to know where the right home for this sort of guidance is... Neophytes, and those upgrading their vocabulary descriptions from RDFS to make use of OWL features, are amongst those most in need of guidance. They'll probably 'get' the basic class/property model, and RDF's data model for their instance data. But they might not be sure how they could _tell_ whether the properties they'd created were 'really' owl:UnambiguousProperty. Example: I invent a property "orgchart:roomNumber" that one ascribes to an Employee and that has room numbers as values. For simplicity, assume a world where employees get a room each. For complexity, assume that room assignments change, over time. At each point in time, there is at most one employee with any given orgchart:roomNumber. Our instance data is simple: <orgchart:Employee eg:name="Fred" orgchart:roomNumber="1066" /> In RDFS, there isn't much to add at the schema/ontology level. We get to say that orgchart:roomNumber is an rdfs:Property, and not much more. Maybe domain and range. Dull stuff. In OWL, we *could* declare that orgchart:roomNumber is an owl:UnambiguousProperty. But should we? How would we know whether that'd be a true claim? Some part of the spec or tutorial needs some careful words that'll help ontology designers do the right thing. We don't want people to omit this typing information for properties if it _is_ applicable, nor to mistakenly ascribe it. I'm unfortunately at a loss as to what the 'right thing' is. I have hunches, but can't justify them easily by pointing to the spec, since the spec is couched in timeless terms. If we're happy on monday saying: <orgchart:Employee eg:name="Fred" orgchart:roomNumber="1066" /> and on tuesday claiming instead that: <orgchart:Employee eg:name="John" orgchart:roomNumber="1066" /> (where these employees are different individuals) ...but we're not happy with different individuals having the same roomNumber simultaneously, is it ok to say that orgchart:roomNumber is an owl:UnambiguousProperty? If so, some kind of worked example to this effect in the tutorial/primer would be invaluable. Is there any reason why owl couldn't give a distinct class / name to those owl:UnambiguousPropertys whose values don't vary thru time/context? (One reason I guess is that accounting carefully for the semantics in the Model Theory would be, er, non-trivial.) > > I know my apps that use daml:UnambiguousProperty need to make > > stronger assumptions than those licenced by the DAML formal spec; but > > maybe that's my problem... > > It is a problem. You have several choices, none very palatable. Yup :( Don't suppose you care to enumerate the choices as you see them...? What I do at the moment is flag those properties with a class of my own, basically util:StaticUnambiguousProperty. I have software with hard-coded knowledge of this, and no expectation that anything in the wider Web will know what this means. A bit of a hack... Maybe we'll find a bunch of folk using such hacks, in which case documenting them at w3.org might make sense...? Dan > > > Dan > > peter >
Received on Thursday, 6 June 2002 20:46:40 UTC