RE: less-restrictive range and domain terms

I have recently had a similar (although not precisely the same) problem with
the UI of Protege.

I particular, if you:

(a) Choose not to use global domain and range constraints (for, among other
reasons, the "open world" assumption), and

(b) Have lots of optional and/or datatype properties which do not make sense
to include in DLs for defined classes,

then these properties will not show up at the (intended) classes in
individuals forms.  One must explicitly modify the forms for classes and the
resultant data is stored in a separate file from the OWL ontology.

If someone is looking at the ontology for the first time (or is otherwise
not an expert in the domain of discourse) it is not immediately clear which
classes are intended to be used with these types of properties.

It would almost make sense to introduce a couple of annotation properties to
say, for example, "this property is intended to be used with the following
class (or classes), or "this property is intended to take as values the
following class (or classes).  This information would then be stored in the
OWL file and could be directly exploited by ontology editors to offer up
reasonable options to users.

Just a thought.

--- Stephen


Phil Dawes wrote:

Hi All,

I've recently found myself wanting a less-restrictive version of
rdfs:range (or owl:allValuesFrom) and rdfs:domain. I want to say
'property *can* have range of class foo' rather than 'property *must*
have range of class foo'.

I first came across this requirement with my veudas RDF browser when
consuming RDF without schema information. Hints like 'can have range'
help when rendering the editing UI. They can also be inferred easily
from the RDF.

The second example was attempting to implement a cross-store querying
mechanism - I want to make statements like 'in the context of store A,
property canHaveRange class' This works as a useful hint for the query
chopper-upper to decide which patterns to run against which stores.

Does such a term exist anywhere or shall i make one up?

(or is there a better way? :-)

Many thanks,

Phil


Note:  The information contained in this message may be privileged and
confidential and protected from disclosure.  If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify us immediately by replying to the message and deleting it from
your computer. Thank you.  ThruPoint, Inc.