W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > May 2007

Re: Advancing translational research with the Semantic Web

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 21 May 2007 11:07:45 -0700
Message-Id: <p0623093fc277897cb93a@[192.168.1.4]>
To: Alan Rector <rector@cs.man.ac.uk>
Cc: Phillip Lord <phillip.lord@newcastle.ac.uk>, Marijke Keet <keet@inf.unibz.it>, public-semweb-lifesci@w3.org

>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.

And for the record, it has long and very respectable history. It was 
first noticed by CS Peirce in the late 1800s, and he himself regarded 
it as one of his important contributions to logic: it has been 
re-invented since then by several notable logicians, including WVO 
Quine, and it has been widely used in formal linguistics and KR work 
under the terminology of 'roles'. In many ways it corresponds to the 
tendency in natural language to treat predications as verbs denoting 
an 'event' or 'fact' to which the relational participants have named 
binary semantic relations (properties in OWLspeak) corresponding to 
grammatical cases like subject, object, manner, time, place, etc.. In 
that latter context, it has the notable advantage of allowing any 
number of arguments to be used, and for some of them to remain 
unspecified, as indeed they often are in normal NL usage. So for 
example if time is an argument, then omitting time information is a 
syntactic error; but using the property encoding, one can simply omit 
the time property assertion.

>
>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.
>
>where n,m are date-time expressions, for simplicity let us assume 
>integers representing milliseconds since some reference point.
>
>Inn OWL 1.1 we can do quite a bit better - although again there is a 
>need for improved tools to make it easier.
>
>*	An organism has a given temperature at some point in an interval
>
>anOrganism -->
>	has_feature SOME (Temperature_feature THAT
>		has_time_point  SOME (has_coordinate SOME int[>=n, <m])
>		has_state...

Don't you also need that the temperature is a functional value of the 
time-point? BTW, this 'manchester syntax' is quite unreadable :-)

>
>*	An organism has a given temperature throughout an interval. 
>(This has to be expressed as "Any temperature feature of the 
>individual anOrganism in the time interval has the given state"
>
>Temperature_feature THAT
>	is_had_by VALUE anOrganism AND
>         has_time_point (Some has_coordinate SOME int[>=n, <m]) -->
>             has_state...
>
>where	is_time_point_of: inverse has_time_point
>		has_time_point: functional
>		Axiom:	(Feature THAT has_time_point SOME Time_point) 
>has_value Max 1 State.
>		has_coordinate is used here with int since I am 
>assuming it is measured in "ticks since basepoint", but could 
>equally well be a float
>
>
>>Nevertheless the results are clunky and will need special tool 
>>support[**] to avoid going insane. In general I am wary of design 
>>pattern type things - they are usually a sign that the language 
>>lacks the constructs required to express things unambiguously and 
>>concisely.
>
>Separate "unambiguously" and "concisely".  Whether or not there is 
>something ambiguous about a design pattern depends on the case.  In 
>this case I think there is no ambiguity.  "Concisely" is a matter 
>for tools and layered "higher level languages".
>
>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.  No one would argue against layoring 
>more convenient languages on top of OWL ( or its successors).  The 
>patterns are a first step towards this end, just as they were in the 
>early days of programming languages.  Neither would anyone argue 
>against more expressive languages.

While I agree with the general sentiments here, that last sentence is 
rather misleading. In fact, people have argued against more 
expressive languages, in fact have argued with great force and 
vehemence, which is why we are saddled with such a baroque DL-based 
standard as OWL. There is no shortage of thoroughly understood and 
semantically coherent more expressive languages.

>But I would argue that building on known, tested, and proven 
>semantics and computational methods is preferable to inventing new 
>ones.

Again, I agree: but there are other known, proven semantics than the 
OWL-DL design. That represents one choice in a spectrum of 
possibilities. It is not necessary to invent new formalisms (which I 
agree is not something to be done lightly or carelessly) in order to 
find something well-understood, standardized and supported by a 
community. ISO Common Logic qualifies on all these counts, for 
example, and is vastly more expressive than OWL (which it contains as 
a subset). N-ary relations are trivial in CL: one simply writes 
relations with as many arguments as one wishes. It need not be the 
same in every case, as variadic relations are possible.

I am not meaning to suggest that OWL be abandoned; there is no doubt 
that it is the de facto Web standard at present, and receives a lot 
of attention and support. But to presume that it represents the only 
possibility, or that more expressive, semantically coherent, 
well-understood, notations are an open research problem, is to 
mis-state the case.

Pat Hayes


-- 
---------------------------------------------------------------------
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 Monday, 21 May 2007 18:07:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:20:26 UTC