- From: Jim Hendler <hendler@cs.umd.edu>
- Date: Wed, 5 Mar 2003 08:25:27 -0500
- To: "Peter Crowther" <Peter.Crowther@networkinference.com>
- Cc: <www-rdf-logic@w3.org>
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. -JH 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 Maryland Information and Network Dynamics Lab. 301-405-6707 (Fax) Univ of Maryland, College Park, MD 20742 240-731-3822 (Cell) http://www.cs.umd.edu/users/hendler
Received on Wednesday, 5 March 2003 08:25:36 UTC