- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 21 May 2007 21:34:15 -0700
- To: Chris Mungall <cjm@fruitfly.org>
- Cc: Phillip Lord <phillip.lord@newcastle.ac.uk>, Marijke Keet <keet@inf.unibz.it>, public-semweb-lifesci@w3.org
>On May 20, 2007, at 11:49 PM, Alan Rector wrote: > >> >>Chris >> >> >>On 18 May 2007, at 18:10, Chris Mungall wrote: >> >>> >>>I'm afraid I'm unclear how to state the OWL n-ary relation >>>pattern(http://www.w3.org/TR/swbp-n-aryRelations) where I really >>>need it. In all the examples given, the "lifted"[*] n-ary relation >>>was never truly a relation in the first place and always better >>>modeled as a class. It's kind of cheating. What if my n-ary >>>relation is transitive or if the 3rd argument is a temporal >>>interval over which the relation holds? >>> >>>I think the former is doable with property role chains. Updating >>>the n-ary relations note with this - and all the other omitted >>>details, such as how to re-represent domain/range, functional >>>properties, n-ary relations in restrictions etc - would take a lot >>>of work and would make it utterly terrifying to the naive user. >>> >>>Nevertheless the results are clunky and will need special tool >>>support[**] to avoid going insane. >> >>I'd love to see DLR or similar means worked into future versions of >>OWL or other standards, although I am not the one to comment on the >>logical/complexity issues. I certainly agree that re-expresssing >>relations as properties carries a modest penalty by being more >>verbose, but it is manageable. >> >>To take the example in question for some relation R, let's take >>temperature as an example. I shall use the subrelations >>"has_feature" / "has_state" to minimise arguments over what is, and >>is not a "quality" - an issue not germane to this discussion. Also >>I will use "has_state" as the property name so we don't have both a >>property "has_value" and a keyword VALUE. >> >>In the binary relation form in manchester simplfied syntax in OWL >>1.0 we have: >> >>Organism has_feature SOME (Temperature_Feature THAT >> has_temporal_extent VALUE temporal_extent_1 AND >> has_state SOME (has_magnitude VALUE 37 AND has_units VALUE >>degrees_C)) >> >>where temporal_extent_1 is an individual which has facts >> has_start_time VALUE n AND has_end_time VALUE m. >> has_magnitude is a functional datatype property and has_units >>is a functional property. > >Here Temperature_Feature is a "history" (sensu Hayes) or a >time-slice. Do I have this correct? I think it is more like a fluent, i.e. a time-relative relation. Here Organism is the entity, a slice of which would be a history; but Organism isn't time-sliced: rather, Temperature_Feature, i.e. one of its predicates, is. To get this into OWL-DL, the predicate has been reified into a property value of a generic 'attaching' property called has_feature; this makes it possible for this predicate (which has now been OWLized into an individual) to itself have properties, in this case the time-interval during which it is stated to hold of the Organism. >This sort of thing can always be made to work if the relevant >concessions are made in the upper ontology. For example, in the >above I never talk of qualities-as-continuants, but only through >their histories. But if a *quality* is itself a continuant, then it cannot change, so there would be no need to go to all this trouble. One could model that simply as an OWL property. I really don't think it is necessary to mess with the upper ontology. All the awkwardness of the above arises from the fact that OWL cannot go beyond binary relations, and there is something intrinsically trinary about a time(1)-sensitive property(2) of a thing(3). So to map into OWL one is forced to objectify some part of this irreducible triangle, so as to make an individual entity which can be given a temporal property. But this really is just an artifact of the OWL embedding, and IMO should not have any deep significance attached to it. In particular, you really don't need to get into the full 4-d way of thinking here. If you start with a 4-d histories ontology and try to embed it into OWL the same artifacts will show up, for the same reason. >To my mind this complicates things a lot - unless you fully embrace >the 4D view of the world. > >What about for relations such as part of and location? For example, >a protein that is in the cytoplasm at a certain time: > >Protein that has_feature SOME (Location_Feature THAT > has_temporal_extent VALUE temporal_extent_1 AND > has_location SOME cytoplasm) > >Would this be a fair extrapolation? > >Would the following be accurate for a 4D representation of the same thing? > >Protein that has_history SOME (History THAT > has_temporal_extent VALUE temporal_extent_1 AND > has_location(4d) SOME (History THAT history_of SOME cytoplasm) No. The history framework would only talk of history-pieces of the protein, and the 4d 'location' is indistinguishable from the history itself. Im not very familiar with this Manchester syntax, but I think it would be more like Protein that is-stuff-of SOME (History THAT has_temporal_extent VALUE temporal_extent_1 AND isSubHistoryOf SOME ( History THAT contains-stuff SOME cytoplasm) This assumes that 'Protein' and 'cytoplasm' are classes of kinds of stuff, ie biological material. <snip> >> >>The history of computing is the history of "design patterns" at one >>level that eventually get built into "higher level languages" at >>the next level of abstraction up. > >I think I have a less optimistic view of progress in computer >science. For example, many of the paradigmatic GoF design patterns >are there to make up for deficiencies in the OO languages that >*succeeded* more expressive and abstract functional languages. Amen to that. And we are living through an exactly similar transition in representational languages, where DLs are re-inventing axioms of classical logic. Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 cell phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Tuesday, 22 May 2007 04:34:24 UTC