- From: Chris Mungall <cjm@fruitfly.org>
- Date: Mon, 21 May 2007 12:17:16 -0700
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Phillip Lord <phillip.lord@newcastle.ac.uk>, public-semweb-lifesci@w3.org
On May 21, 2007, at 11:24 AM, Pat Hayes wrote: > >> >>>>> "CM" == Chris Mungall <cjm@fruitfly.org> writes: >> >> >> >> Out of curiosity, can you describe how different or similar this >> >> is to the result that you can achieve in the N-ary relation >> >> design pattern for OWL? >> >> >> >> Obviously, building things into the DL is nice, but it's not >> >> currently representable in OWL, so would require tooling >> support, >> >> while the OWL N-ary relation pattern doesn't. >> >> CM> I'm afraid I'm unclear how to state the OWL n-ary relation >> CM> pattern (http://www.w3.org/TR/swbp-n-aryRelations) where I >> CM> really need it. In all the examples given, the "lifted"[*] n- >> ary >> CM> relation was never truly a relation in the first place and >> CM> always better modeled as a class. It's kind of cheating. >> >> Well, it is kind of cheating, yes, although if it works... > > No, really, its not cheating. This reduction of n-ary relations to > binary+unary relations is quite general and quite sound, and has > been known and thoroughly understood for over a century. It can > always be done, and it often makes perfectly good intuitive sense. > The 'thing' that the arguments all relate to is something like the > event, or fact, or situation, or state of affairs that holds, etc.. > (choose your favorite terminology) Sorry, I shouldn't have used a pejorative term like cheating, I was just pointing out that if I am presented with a template for a solution for problem X and that solution is to transform to representation Y, this doesn't help if my problem was actually X2 and I would have used Y for X in the first place. Or let me be more concrete: using an ontology like BFO (perhaps DOLCE too) as a guiding framework, one would use owl classes and not owl object properties for diagnoses, observations, purchases and flight segments (the examples given in the n-ary note). Applying the same pattern to relations that should be modeled as relation leads to more design decisions and more complex representations. >> >> CM> What if my n-ary relation is transitive or if the 3rd argument >> CM> is a temporal interval over which the relation holds? >> >> The former is hard because it's not clear what do you with n-ary >> relationships. I think that this is true for any >> representation. Fundamentally, if you say "a is part of b" and I say >> "b is part of c", then is "a part of c" and according to whom? > > Right, it simply isn't clear what 'transitive' means for relations > other than binary. Try writing it out as an axiom in logic to see > all the different possibilities. This would have to be done on a case by case basis. I believe someone is working on this for the time-indexed temporal relations in the OBO relation ontology >> >> It is possible to use build on top of the n-ary relationship, for >> example a symmetric property. Perhaps you could do the same for >> transitivity if you could work out exactly what the semantic should >> be. >> >> >> CM> I think the former is doable with property role chains. >> Updating >> CM> the n-ary relations note with this - and all the other omitted >> CM> details, such as how to re-represent domain/range, functional >> CM> properties, n- ary relations in restrictions etc - would take a >> CM> lot of work and would make it utterly terrifying to the naive >> CM> user. > > Well, naive users probably shouldn't be trying to represent > functional relations with more than one argument. This kind of > thing just IS complicated. > > My advice to new users is to forget completely about N-ary > relations. Tell yourself that there are no relations in nature > above binary. If you think you need one, re-think what you are > trying to say so that it all fits into the binary case. Chances are > this will be fairly easy to do, and as a side-effect, you will > probably then be much more clear on what exactly it is that you > want to say about transitivity, functionality, domains and so forth. I'm afraid that one of the core ontologies we are using disagrees with this: http://genomebiology.com/2005/6/5/R46 >> Yep, but I think that this reflects the underlying complexities of >> life. > > Exactly. Although I would prefer to say, the complexities of > awkward modes of describing life. > >> >> CM> Nevertheless the results are clunky and will need special tool >> CM> support [**] to avoid going insane. In general I am wary of >> CM> design pattern type things - they are usually a sign that the >> CM> language lacks the constructs required to express things >> CM> unambiguously and concisely. It sounds like DLR could provide >> CM> this, which would be great. >> >> Well, this I would agree with. Folding design patterns in, would be >> nice. > > Agreed. We made this a central feature of our COE graphic OWL > editor, in that a user can design a 'template' (a chunk of OWL with > gaps in it) and give it a name, then just drag-and-drop one into a > new OWL concept map and fill in the missing parameters. Its a > simple device and not perfect, but it does seem to be useful. > > 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 19:17:43 UTC