Re: Issue 3.4 - daml:UnambiguousProperty (fwd)

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