

RE: Why isn't FunctionalProperty a subClassOf owl:ObjectProperty?

From: Jim Hendler <hendler@cs.umd.edu>
Date: Wed, 5 Mar 2003 08:25:27 -0500
Message-Id: <p05200f1aba8ba8c2cc3e@[]>
To: "Peter Crowther" <Peter.Crowther@networkinference.com>

At 8:27 +0000 3/5/03, Peter Crowther wrote:
>  > From: Jim Hendler [mailto:hendler@cs.umd.edu]
>>  transitive datatype property is easy - zipcode in the same state
>>  i.e.
>>  if zipcode is a datatype property
>>  and SameStateAs is a property with range:zipcode, domain:zipcode
>>    then saying
>>  SameStateAs is transitive is useful
>Mmm.  Good point - and that answers the symmetric one, too, as
>sameStateAs should be symmetric.  Thanks, Jim.
>Just to muse on this a bit as a real-world application, however, I guess
>I'd naturally have modelled it that SameStateAs applies between
>addresses, not zipcodes, i.e. an address that has zipcode 20852 is in
>the same state as one that has address 20740... etc.  This would better
>match my own notion of an address, and would also allow for addresses
>with the same code that are in different states --- which may not be
>true in the US but is certainly true with UK postcodes as they keep
>screwing with boundaries!
>Given that there is this more-or-less-equivalent form in this case, what
>cases do we know where that transformation *cannot* apply?  I'll respond
>to Bob MacGregor's point separately.
>		- Peter

Peter - there sometimes are logical equivalents if you're allowed to 
define things in advance, but suppose all you have is a database 
which tracks purchases based on zipcodes (which many stores now 
collect) and you have a cross list of some people and the states and 
zipcodes they live at (perhaps even the addresses).  For example, 
several catalog companies maintain these sorts of databases -- so if 
I wanted to use a logic-based engine to deduce the states where the 
people making the purchases lived, coming up with a mapping of 
zipcodes to states, and then a "sameStateAs" sort of relation would 
be a possible way to do it.  The point being that for many 
applications the logic must be based on the real instance data that 
is available, and it may be partial, noisy, incomplete, inconsistent 
(for example, mail to my office comes with 20740, 20742 and 20853 zip 
codes from different mailing lists - which is the "right" one).  Or 
for a more semantic-webby sort of example, we build a number of our 
instance bases by scraping web sites and the like, but our scrapers 
aren't 100% correct, and we can only get some information reliably, 
so we would consider using various kinds of reasoning to clean up the 
data, fill in missing components, etc.   In all these cases, we have 
to deal with what we get, and it is often instances full of  strings 
and numbers.  Where we can massage these into DL, it is great, but in 
those cases, we have to sometimes do odd seeming things like the 
hypothetical "sameStateAs" instead of what we would do if we could 
have designed the logic/semantic schemas from scratch.
p.s. As I understand the current state of the datatyping stuff in OWL 
(details still being finalized) the notion of reasoning about 
"addresses" in DL may be tricky if we want them to have components 
that are partially objectTypes (like the 50 US states) and parts 
which are datatypes (like the zipcodes).  I suspect the implemented 
solution will often be to massage one into the other using some 
"extralogical" or procedural coding, but only time will tell...
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Received on Wednesday, 5 March 2003 08:25:36 GMT
