Re: [OEP] Draft of a note on n-ary relations

>>2. Strictly, this way of describing it is wrong: the thing that 
>>gets, er, reified is not the relation, but an instance of the 
>>relation (A tuple rather than set of tuples: sometimes called a 
>>trope or a situation or a holding, or more prosaically a fact or 
>>even an event). If you aren't clear about this the account gets 
>>kind of murky: for example, in your example, the relation is a 
>>3-argument thing, but the orange node has role-style links only to 
>>two arguments: so if it is a relation is is binary or trinary? But 
>>if it was binary, why did you need to do anything about it in the 
>>first place? And what is the relationship between the relation 
>>Diagnosis_Relation and the property link labelled has_diagnosis? 
>>Shouldnt there be some kind of actual (not reified) property to 
>>which the reified property is somehow related? How?? And so on.
>>
>>I'd suggest that it would  be better to say something like his:
>>
>>"If we need to...., we can do it by creating individuals which 
>>stand for an instance of the relation, and relate them to the 
>>things that are involved in that instance of the relation. The 
>>original relation can be thought of then as the class of all these 
>>relation-instances. This is sometimes described as a 'role-value' 
>>style of description, where the various arguments are seen as 
>>playing a 'role' in the fact or event indicated by the instance of 
>>the relation."
>
>Pat, thanks for the constructive suggestion. We'll try to weave in 
>something like this and get rid of the word "reify" to avoid 
>religious wars. That said, perhaps we can put a note saying that 
>doing so is often called "reifying a relation" to ground it for 
>those who actually do know the KR meaning of the word.

Well, let me suggest more strongly that you do not do this.

First, I don't think that this is what is widely meant by that phrase 
in KR, in fact; and in any case reification isnt widely discussed at 
all in KR. (Try giving "reifying a relation" to Google and see what 
you get: not exactly overwhelming.).  With the usual pre-W3C meaning 
of 'reify', a reification of a relation would be the whole relation, 
not an instance of it (as here). Now, Im all for reifying relations 
in that sense, myself, but there are a lot of folk who emphatically 
are not, and consider that to be an illicit move to a higher-order 
logic; and some of them are in the WG, so why stir up unnecessary mud?

Second, on one view of the matter (again, not one I subscribe to, but 
many do) the things that would be denoted by these 'extra' nodes, ie 
are being 'reified', are in fact best not thought of as being in the 
domain of discourse at all, so are NOT being reified; and in fact the 
whole design of OWL DL (as described in the normative abstract 
syntax) is based on this view, and things like the blank nodes in the 
OWL/RDF collections used in the RDF encoding are not seen as being on 
a par with 'real' denoting names at all, and are prohibited from 
being treated as first-class names intended to denote first-class 
individuals. All of which forms a perfectly coherent point of view, 
according to which only a subset of the 'RDF universe' actually 
comprises real OWL things, and the rest is just a kind of scaffolding 
or maybe more like a junkheap, a side-effect of what you need to do 
in order to encode OWL into RDF, a sort of RDF connective tissue 
between the real OWL muscle.  Its not really part of the *logic* at 
all, viewed from the true-logic abstract-syntax perspective.  On this 
view, then, it would be *seriously* misleading to use a word like 
'reify' to refer to the act of, say, encoding a relational instance 
using the collection vocabulary.  In many ways this is quite an 
elegant point of view, and it certainly keeps one's conceptual model 
clear.

And third, I don't think this remark, even if it were true, is 
helpful, particularly to a beginning user.

>>3. Most importantly, I don't like the note saying that this is 'THE 
>>general solution' . It is one of several options, and not clearly 
>>always the best one. OWL for example frequently uses a different 
>>option, where the second argument of the relation is made into a 
>>list of the remaining arguments: this has many practical 
>>advantages, the most important being that the property stays a 
>>genuine property.
>
>Yes, someone pointed out  this solution privately and we'll try to 
>include it as one of the options. Do you have a good example of when 
>such a solution would be preferable?

Whats the criterion of preference? IMO, this just IS the preferable 
one, if you have to choose one, since it allows you to use a single 
strategy/implementation for any such case, and everyone knows its 
properties. (Like, use LISP??) When we were designing DAML, we 
considered all these options and plumped for this one. I think it was 
considered the one least likely to lead to misunderstandings, and 
also familiar to many programmers. The downside (for some) is that it 
puts lists into the domain of discourse.

>>Other options still are a systematic role-value style of expressing 
>>things (which your example could be, in fact: its not quite clear) 
>>and other 'container' style solutions, and its even possible, 
>>though clunky, to use things like binary subProperties to play the 
>>role of the component links.
>
>hmm... I am losing you there. If you think it's worth mentioning as 
>one of the alternatives, perhaps you could give some 
>examples/descriptions? Or does it get too clunky to recommend it to 
>people?

Yes. I mentioned it only to emphasize that there are many options. I 
was thinking of something like the rdf container vocabulary but using 
special named subproperties of the original property as the container 
membership functions, rather than relating the container itself to 
the property, so the overall pattern for three arguments would be

x P1 a
x P2 b
x P3 c
P1 subProp P
P2 subProp P
p3 subProp P

rather than

a P x
x _:1 b
x _:2 c

or

a P _:l
_:l first b
_:l rest _:m
_:m first c
_:m rest nil
.

>>4. I think that the discussion of the two cases distinguished by 
>>whether there is an 'originator' is best omitted. It is potentially 
>>misleading and has no connection whatever with the OWL semantics, 
>>and in any case isnt needed for the point being made.
>>
>
>Well, as an ontology designer, if I am reading a note like this, I 
>would like to have some indication of which approach to choose.

<aside>
I wish we didn't feel that we had to give advice like this. ANY 
advice we give is going to be wrong, whatever we say. If a 
programming manual told you what programs to write, would that make 
it a better manual? Sigh.
</aside>

>Perhaps the indication that we've given is not the best one (in 
>fact, it most probably isn't), but if you could suggest an 
>alternative simple rule-of-thumb-type explanation, that would be 
>great.

Er... .explanation of what, exactly? I thought I was suggesting that 
you just shouldnt go into this distinction because there isn't any 
distinction there worth making.

This ought to be very simple, seems to me. The issue here is that OWL 
properties have two ends, but some relations have more than two ends, 
and so you have to do some hacking to encode them somehow into 
collections of two-ended things. (Forget about what any of this 
MEANS, what it MEANS is perfectly clear: its an n-ary relation, we 
know that already. The issue is that our users have to do some 
hacking because we got stuck with a binary notation in Year One. So 
lets be honest about it and not pretend that this craziness is good 
for them)
And then the two basic hacking patterns, both having a venerable 
ancestry and intuitive justifications, are a chain or a starburst:

a1 P x1
x1 N x2
...
x1 F a2
x2 F a3
....

or

a1 P x
x S1 a2
x S2 a3
....

or maybe (logically/linguistically more correct but less RDF-ish)

x type P
x S1 a
x S2 b
x S3 c
....

You could mix these in various ways, obviously, and run variations on 
them (see above) but there is usually no need to and its usually 
clearer if you stick to one.  The chains use more triples than the 
starbursts, but n vs. n+1 vs. 2n+1, what the hell.  If you want to 
use 'standard' names, use the rdf collection vocabulary for the chain 
and the rdf container vocabulary for the starbursts.  Oh, and BTW, 
OWL itself uses the chains a lot and never uses the starburst, for 
what that's worth.

OK, done, end of story.  If only they were all this easy.  Next question....

Pat

PS. If you really, really, want an intuitive 'explanation' of what 
the chains and stars actually "mean" (sound of crazed laughter), then 
you could say that the star (the x in the example) is the actual fact 
or event (proposition, holding, situation (-Barwise, not -McCarthy), 
eventuality, whatever) which is being stated here, and that the chain 
(the list) was the list of things involved in the event or fact, like 
a kind of cast-list for a scene in a play. Or some such. But I think 
it would be better to just say: look, at some level it doesn't really 
mean anything, its just something you have to go through because we 
don't have n-ary relations, sorry.



-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Thursday, 13 May 2004 18:20:22 UTC