W3C home > Mailing lists > Public > www-webont-wg@w3.org > September 2002

LANG: An approach to issue 5.1 (was Re: LANG: issue 5.1 - Uniform treatment of literal/data values)

From: Jim Hendler <hendler@cs.umd.edu>
Date: Thu, 19 Sep 2002 08:03:50 -0400
Message-Id: <p05111736b9af6abeb238@[]>
To: Ian Horrocks <horrocks@cs.man.ac.uk>
Cc: www-webont-wg@w3.org

At 12:53 PM +0100 9/19/02, Ian Horrocks wrote:
>This is *NOT* a proposal, half baked or otherwise. It is just a report
>on (possibly) relevant ongoing research (my reluctance to provide such
>a report was exactly because I was worried that it might be
>interpreted as a proposal).

I never interpreted what you said as a proposal.  I made the proposal 
below and only had it attached to your mail because it followed in 
the thread - I should have given it a new title -- something like "An 
approach to issue 5.1" instead of making it look like it was a 
continuation on your previous mail. I apologize for the confusion.

I take it from the message I'm responding to that you don't approve 
of the below - but please argue it on its own merits -- that is, 
given there are members of the group who cannot live with the 
daml+oil situation, and given the D+O group expliciely said this was 
an issue that should be revisited, I think it is incumbent on the 
working group to consider new proposals.  Dan C sent the "States" use 
case which he believes important, and I heard a number of people 
agree.  Dan's proposal is to drop the distinction all together.

  I think the below addresses his issue in a way I hope he could live 
with, and it provides a syntactic hook by which you could say clearly 
in your documents that if an ontology uses this specific syntactic 
feature then they lose completeness/decidability (or whatever the 
specific consequence is) - meaning you could do a syntactic check to 
see if an ontology contained it (and give appropriate warning), 
rather than having to reason about whether things are data or objects.

Again, I do offer this as a strawman, I'd like to see the group 
converge on something which everyone can live with (even if no one 
prefers it) and I hope this is a starting place for discussion  - if 
anyone has a better compromise solution, please put it forth.


>  >
>>  I think some sort of compromise is needed, here is a half-baked
>>  proposal that might be useful in continuing the discussion
>>  Suppose we continue to have data and object properties distinguished,
>>  but with some sort of syntactic construct that would let one do an
>>  association that allows keys- as follows:
>>  :SSnum a owl:dataTypeProperty.
>>  :Individual a owl:class.
>>  :Individual a owl:ObjectTypeProperty.
>>  :SSnum owl:dataDesignatesUniqueObject :Individual.   (needs a better name)
>>  which would be a syntactically special way to say inverseFunctional
>>  on a datatype.  (This would allow keys and some other similar uses).
>>  The advantage is that there would be a syntactic flag to know this is
>>  occuring so that Fact and other reasoners could say "If you use this
>>  property, you may not get completeness" -- in short, this is a
>>  variant on Jeremy's "here be dragons" approach -- but since, at least
>>  I think, the inverseFunctional on datatypes would mostly be used by
>>  people doing things to instances (rather than class reasoning) this
>>  wouldn't be a major problem.
>>    Dan's states examples seem to be satisfied by this (details left as
>>  exercise to reader) and it also allows distinguished data and type
>>  classes for tools like RIC that can profit from knowing which is
>>  which.
>>    -JH
>>  p.s. Please note this message doesn't say "chair neutrality off" -
>>  I'm not putting forth my personal preference here, but trying to get
>  discussion restarted.

Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
Received on Thursday, 19 September 2002 08:04:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:56:47 UTC