ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Endurantism and Perdurantism - Re: Some Comments on

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>, Chris Mungall <cjmungall@xxxxxxx>
From: Pat Hayes <phayes@xxxxxxx>
Date: Sat, 21 Mar 2015 11:48:30 -0500
Message-id: <AD5E6B22-A623-4A4A-9D6C-FCA7746B9640@xxxxxxx>
Chris, I doubt if there is much point in continuing this discussion. You are 
clearly extremely comfortable living within the constraints of what you find to 
be an intuitive and useful distinction, and see no need to change. Which is 
fine, of course, and I have no desire to try to convince you otherwise, 
especially if any such change would be highly disruptive. I myself, and I know 
many others, do not find it intuitive, and find the contraints that you embrace 
as useful to be meaningless, constrictive, artificial and at least in my case 
philosophically infuriating. So let us agree to disagree, and I will continue 
to ignore OBO while you continue to use it.     (01)

I have inserted a few comments in-line below in order to at least try to 
clarify what I was saying, and maybe make the points clearer.    (02)

On Mar 20, 2015, at 2:20 PM, Chris Mungall <cjmungall@xxxxxxx> wrote:    (03)

> 
> 
> On 20 Mar 2015, at 0:42, Pat Hayes wrote:
> 
>> On Mar 19, 2015, at 5:52 PM, Chris Mungall <cjmungall@xxxxxxx> wrote:
>> 
>>> 
>>> 
>>> On 19 Mar 2015, at 7:34, Pat Hayes wrote:
>>> 
>>>> On Mar 19, 2015, at 2:40 AM, Matthew West 
>>>> <dr.matthew.west@xxxxxxxxx>
>>>> wrote:
>>>> 
>>>>> Dear Chris,
>>>>> 
>>>>> <snip>
>>>>> 
>>>>> ...
>>>>> [MW>] This argument is not really about a distinction, no one (well
>>>>> at least
>>>>> not me) is arguing that you cannot have both physical objects and
>>>>> activities
>>>>> in your ontology, the question is whether they are mutually 
>>>>> exclusive
>>>>> or
>>>>> not. That is a constraint. Endurantism has the belief/insistence 
>>>>> that
>>>>> this
>>>>> constraint is always true. If you find that it is not always true,
>>>>> then it
>>>>> is unhelpful to insist on it, because when it is untrue you will 
>>>>> have
>>>>> extra
>>>>> work to do to work round on it.
>>>> 
>>>> Exactly. But let me suggest that the real constraint here is that 
>>>> when
>>>> something is considered to be an object or a process, then each way 
>>>> of
>>>> thinking of it has to come with a particular way of formalizing it.
>>>> This        is completely unnecessary, and if this purely syntactic
>>>> constraint is lifted, then the philosophical disagreements become 
>>>> just
>>>> that, purely philosophical matters, irrelevant to the actual 
>>>> practice
>>>> of ontology building. Ontological frameworks like OBO require 
>>>> writing
>>>> things like (Relation x T) when x is a continuant and (Relation 
>>>> (stage
>>>> x T)) when x is an occurrent, so they must keep a rigid separation
>>>> between the two categories.
>>> 
>>> Can we translate this to a concrete example? I feel you keep pointing
>>> out imaginary problems in what your conception of the OBO framework 
>>> is.
>> 
>> My conception is based on working, some years ago, with Barry Smith on 
>> formalizing the basic high-level ontologies of the OBO foundry. I 
>> found that virtually every axiom had to be written out twice, in 
>> appropriately modified forms, once for continuants and once for 
>> occurrents. Exactly the same facts were obliged to be re-stated with 
>> different quantifier patterns because of the 'rules' about where the 
>> time parameter had to be located.
> 
> Yes, I hate mindless repetition of this sort. I'd seek to at least infer 
> the 2nd set of facts rather than restate them    (04)

No, you miss the point. There are not two sets of facts in the first place. 
They are the SAME FACTS, stated in different language, and they have to be 
stated differently because of a COMPLETELY ARTIFICIAL distinction which is 
wired into the ontology at the topmost level. I do not refer here to the 
object/process distinction, but rather to the distinction between two ways of 
describing how an entity relates to time, and how that relationship must be 
described, what Barry refers to as the SNAP/SPAN distinction.    (05)

> , but even this can be a an 
> axiomatic kludge or dongle as you put it, and it's simply cleaner to 
> avoid the separation in the first place. I have seen this kind of thing 
> with other upper level categories. For example, I've seen ontologies 
> where a 'disposition' hierarchy mirrors a process hierarchy. I can see 
> how it would be very possible to do the same kind of thing with an 
> object vs process distinction. For example, I could take any existing 
> anatomy ontology and make a process ontology with "life of " prefixed to 
> every class. But I would argue if you look closely at the widely used 
> OBO ontologies, this is *not* what is happening. Different aspects are 
> being described in each hierarchy.    (06)

Can you give an example of an aspect which can only be described by one way of 
placing the temporal parameter but not by the other?     (07)

> You may dislike this separation 
> philosophically, but it serves a purpose. We're quite simple minded at 
> the end of the day, and prohibiting someone attaching a "mass" or 
> "width" property to a fruit ripening process appeals to us, and the 
> benefits of abandoning this aren't clear.    (08)

Why would a PROHIBITION appeal to you? What possible advantage is gained by 
prohibiting a useful form of expression? It is one thing to say that you prefer 
not to use it, but to prohibit it is much stronger. It is surely obvious what 
this would mean, even in your segregated world-view: it means that the 
continuant substrate of the ripening process has a mass or a width during the 
lifetime of the process. Such 'transcriptions' from a 4-d descriptive framework 
to the CO/OC framework are quite uniform and I would suggest, intuitively 
clear.     (09)

>>> Let's say we have a relation 'has substrate', and it has a domain
>>> constraint of process, and a range constraint of molecule 
>>> (continuant),
>>> and it connects the process to a molecule that is changed somehow by 
>>> the
>>> process. You're saying the framework here is a problem because you're
>>> unable to say
>>> 
>>>     molecule1 has-substrate molecule2
>>>     process1 has-substrate process2
>>> 
>>> I suppose I'm so indoctrinated that I see this as a feature, not a 
>>> bug.
>> 
>> I guess I am wondering why this distinction, between process of a 
>> change in something, and the thing undergoing the change, was ever 
>> made in the first place, necessitating the introduction of this 
>> 'substrate' relation. Every day I grow olderr. Is a process of my 
>> aging using me a substrate? Or am I simply getting older? I strongly 
>> suspect that this relation has-substrate is what I have elsewhere 
>> called an axiomatic dongle: a piece of sytnax whose only purpose is to 
>> connect things that should never have been separated in the first 
>> place.
> 
> Right, an example of such a dongle would be a relation like 'life of'. 
> But I don't think 'has substrate' would be an example of this kind of 
> dongle. It's doing useful work.    (010)

Can you sketch what its utility is?     (011)

> 
>> (Other examples of dongles, by the way, include rdf:type and the 
>> ancient "is-a" construct, both of which are a relation used to express 
>> a predication.)
> 
> I'm not quite seeing the analogy, rdf:type is an essential construct for 
> doing any traditional kind of reasoning    (012)

A rdf_type B is an awkward way to say B(A). "rdf:type" is simply an artifact of 
the necessity to render one syntax into another (in this case, into RDF 
triples.) In a less barbaric notation than RDF it would never appear as a 
binary relation.     (013)

>>>> Until one knows which category a new concept is in, one is quite
>>>> literally unable to write even the simplest axioms about it, so the
>>>> ontology engineering process cannot even begin.
>>> 
>>> I can see how this might be a problem if you were sitting down to 
>>> make
>>> an ontology of chemical structures and just couldn't decide if 
>>> chemical
>>> structures were processes or structures. Or if you were making an
>>> ontology of biological processes and couldn't decide if the 
>>> biological
>>> processes were processes or physical entities.
>> 
>> I know that such debates do in fact take place, and are often found 
>> puzzling by subject-matter experts.
> 
> OK, we're going round in circles here, I'm contending that the SMEs at 
> least in my domain    (014)

My evidence comes from reading the discussions on the OBO email archives, which 
have many examples of OBO users finding it hard to decide whether some thing is 
a continuant or not, and some quite extended debates on this question. I also 
notice that these are often resolved by what amounts to an appeal to 
philosophical authority, so that something is a continuant because someone at 
U. Buffalo says it is, and that ends the matter.     (015)

> are comfortable with the separation, and would find 
> it puzzling if structures and processes were conflated, but I'm not sure 
> either up have empirical evidence at hand so we'll have to leave it at 
> that.
> 
>> And to my ears, this entire discussion has something of a surreal 
>> flavor, since I see no strong or principled difference between things 
>> undergoing change and processes of change in things.
> 
> I don't either.    (016)

?? But that is exactly the distinction you are insisting it would be puzzling 
to fail to prohibit.    (017)

> 
>>> Meanwhile, in the real world of OBO ontologies developed by domain
>>> scientists outside of philosophy land, this hasn't turned out to be a
>>> problem.
>>> 
>>>> But suppose that these two ways of saying that R is true of x at a
>>>> time T are interchangeable, interderivable, and have exactly the 
>>>> same
>>>> meaning, both intuitivel
>>>> y and in the Tarskian model theory, so that the choice between them 
>>>> is
>>>> purely one of axiom-writers taste or convenience, a matter of 
>>>> ontology
>>>> engineering aesthetics, no more. Then work can continue without
>>>> resolving what might be a difficult and lengthy (or even 
>>>> meaningless)
>>>> debate, and indeed can continue and be completed, without ever 
>>>> needing
>>>> to resolve such a dispute. It no longer matters whether x is a
>>>> continuant or an occurrent; and in time, I suspect, this distinction
>>>> would simply wither and die from under-use, as having no bearing on
>>>> the actual practice of ontology construction. Or perhaps Chris M is
>>>> right and the distinction is critically embedded in intuitive human
>>>> thinking
>>> 
>>> I'm not sure I would go so far. But in the OBO world at least the
>>> distinction between objecty things and processy things arose 
>>> naturally
>>> independent of philosophical involvement. (commitment to finer 
>>> grained
>>> or more exotic upper level categories is a different matter entirely, 
>>> I
>>> will grant you)
>> 
>> Fine, as a general heuristic distinction I agree it can be intuitively 
>> useful, and sometimes close to essential, to maintain such a 
>> distinction, for example when processes involve interactions between 
>> multiple objects and one does not want to invent a super-object for 
>> this to be a change of state of. But when a distinction is welded into 
>> the highest ontology of an entire system of ontologies, as the 
>> cont/occur is in OBO, it has much more force than a heuristic 
>> intuitive guide: it is a rigid distinction that *must* be obeyed at 
>> all times and in all instances, and to blur which is to create an 
>> immediate inconsistency.
> 
> I'm wondering how much we actually disagree. You're fine with a 
> heuristic distinction.    (018)

...between objects and process, which are real things. Not between continuants 
and occurrents, which are a strange, occult product of a warped philosophical 
imagination, having their roots in Brentano's confused theology. (Sorry, could 
not resist getting a little florid there.)     (019)

> I'd rather axiomatize it so that we get the 
> benefits of automated checking    (020)

Checking what, exactly? If the point is to check whether something *really is* 
an object or a process, I would suggest that is misguided, because there are so 
many things can be usefully described either way. And there is no practical 
reason to prohibit such descriptions, since they can be consistently used 
together.     (021)

> using reasoners etc. I'd rather push it 
> up to a higher level rather than keep it local so that I get predictable 
> results when combining ontologies together, I can write tools that 
> behave predictably, we can share ontology design patterns.    (022)

We can do all that in either framework.    (023)

> I'm sure 
> there are trade-offs to both approaches, and I'd hate it if were making 
> a bad or inefficient decision here, which is why I'm doggedly pursuing 
> this thread.
> 
>>>> : fine, by all means keep it around, if it suits you. But it need no
>>>> longer have this arbitrary connection to syntactic axiomatic style.
>>> 
>>> Sorry, I don't know what you mean by syntactic axiomatic style. All 
>>> OBO
>>> ontologies used an OWL concrete form as syntax.
>> 
>> I did not mean the choice of surface syntax, which is essentailly 
>> irrelevant (though when you use something a limiting as OWL, it does 
>> cramp your style somewhat :-). I meant decisions such as whether to 
>> treat a concept as a relation or a function or an individual, where to 
>> locate the temporal parameters, whether or not one uses a discipline 
>> to keep differently typed parameters distinct, and if so what it is, 
>> and so on. There are many alternative ways to express a given set of 
>> facts in a given formal language, even one as inexpressive as OWL.
> 
> OK, I guess I see the O/C distinction as manifesting in terms of 
> domain/range constraints etc rather than syntax    (024)

Yes. I tend to think in terms of using a richer expressive notation such as 
ISO-CL, and when this is re-rendered in OWL, what was syntax can become part of 
the ontology (cf rdf:type), so perhaps my terminology here is confusing, sorry.     (025)

>>> I wasn't aware of any
>>> syntactic styles imposed by choosing to differentiate between 
>>> physical
>>> entities and processes.
>> 
>> The cited passage from my email, just below, gives you one.
>>> 
>>>> You can write (R x T) when x is a process (or an object) and you can
>>>> also write (R (Stage xT)) when x is an object (or a process). Work 
>>>> can
>>>> proceed while the philosophical dogs are barking at each other.
>>> 
>>> I'm not sure what these philosophical dogs are
>> 
>> Sorry, this was my barbed witticism, an extended analogy comparing 
>> ontological philosophers to dogs. I enjoy this partly because it 
>> offends philosophers who take their discipline too seriously.
>>> , and what exactly the
>>> perceived problem is with OBO ontologies distinguishing processes 
>>> from
>>> physical entities.
>> 
>> The problem is forcing the distinction in all cases, and enforcing 
>> distinct ways of describing the two categories of entity, and the 
>> axiom-bloat that this creates.
> 
> Right, I'd like to avoid this kind of axiom bloat. I'm contending it 
> happens less than you think in practice, but I may be wrong. I'd love a 
> wider variety experienced ontologists to take a *close* look at the OBO 
> ontologies and give critical feedback.    (026)

I am sure that what I see as axiom-bloat (and concept-bloat) you will see as 
meaningful assertions doing useful work. :-)    (027)

> 
>>> If I'm understanding correctly, you'd like domain/range restrictions 
>>> and
>>> other upper level constraints to be lifted for relations like R? You
>>> object to not being able to say a 'fruit ripening' is part of a 
>>> 'fruit',
>>> and having to use a different relation?
>> 
>> Yes to the second sentence. It seems simply obvious to me that a 
>> fruit's ripening is a temporal part of the fruit. I genuinely do not 
>> understand how anyone can disagree with this. (What else would it be? 
>> *Where* else would it be?)
> 
> This is just disagreement over terminology. If you're using the OBO 
> (specifically PO and GO) representation of fruit and fruit ripening then 
> you would have to use a different relation than part_of to connect these 
> things, if we're to integrate our axioms without a bloaty translation 
> layer.    (028)

I know you do, and that is what I am complaining about. I have to use two 
relations to mean the same thing, because a generation of ontology designers 
swallowed the kool-aid fed to them by philosophical followers of Brentano 
(whose primary interest, ironically, was phenomenology rather than ontology.) 
Now, if you feel happy doing that, then fine. But others do not, and  – my 
point in the post which started this thread – the only reason why your ontology 
*requires* you to do this (as opposed to *allowing* you to) is a byproduct of 
the restricted syntactic rules of conventional logic (and hence of OWL-DL, by 
the way.)     (029)

> Sorry about that. AFAICT none of the SMEs or users have had an 
> issue with this. If it's really a terminological problem for you then 
> I'd be happy with a grouping relation defined via UnionOf (sadly not 
> available for object properties in OWL) and we could even configure your 
> version of Protege so this shows up as "part of".
> 
> It just happens that OBO goes with a certain set of primitives and 
> part_of is used in a more restricted way than you might like, but this 
> shouldn't stop you working with us, any more than if we had chosen 
> "overlaps" as a primitive and defined part_of in terms of overlaps.
> 
> As to the modeling decision to use part_of in a more restricted fashion 
> (namely C->C or O->C), it turns out to be very useful for us.    (030)

Can you sketch how it is useful? I am genuinely interested, as I would like to 
know what I am missing by not having it.     (031)

> I realize 
> this is going in circles but I would wager the users wouldn't want to 
> see 'ripening' as a part of the fruit the way they see the vasculature 
> and layers. Dissecting the fruit in space vs time are both important, 
> but they're separate questions.    (032)

Absolutely agree, time and space are different. But there are not two different 
ways of being in time and space.    (033)

> Of course, are be ways to recapitulate 
> these as distinct queries in the tooling/UI layer, without making a 
> separation in the ontology between objects and processes; but here lies 
> tool bloat and tool dongles.    (034)

To repeat: if you like the object/process distinction, by all means keep it. 
But separate it from the issue of how to express temporal and spatial 
reltionships, the CO/OC distinction. The two topics have nothing to do with one 
another.     (035)

> 
>> But in any case, for sure, I want to be able to apply the language of 
>> ripening to the name denoting the fruit, without receiving error 
>> messages telling me I have violated someone's peculiar ideas about 
>> things not being processes.
> 
> I'm sure if you delve deeper there's a ton of other modeling and 
> terminological decisions you don't like. Most OBO ontologies involve a 
> lot of compromises on all sides. Some decisions could probably be 
> changed easily. But others that would affect a wide range of ontologies 
> (e.g. collapsing object & process) would need some serious justification 
> beyond having a philosophical or terminological objection.    (036)

I agree, it is probably too late to change OBO now. Although the casualness 
with which you meet my decision to flout the CO/OC distinction in our work 
suggests it might be easier than it may first appear.     (037)

> 
>> (A judgement, I would add, which has no scientific basis.)
> 
> I wouldn't disagree here. It's just a modeling decision independent of 
> the science. I guarantee you can say whatever you need to say about 
> fruits and fruit ripening within the (I previously thought) minimal 
> constraints of existing OBO ontologies, so long as it's biologically 
> valid.    (038)

I think that is probably true. But OBO is certainly not minimally constraining.     (039)

Pat    (040)

> 
>>> If there is a problem with OBO ontologies, help me fix things. Give 
>>> me
>>> concrete examples. Otherwise I guess the problems are philosophical.
>> 
>> I do not claim that OBO is broken in the sense that it does not work, 
>> or cannot express reality adequately. But I will claim that I, myself, 
>> would not wish to use it. I don't think about the world in the way 
>> that it presumes I must. In fact, I have on several occassions recused 
>> myself from collaborations that would have required me to work with 
>> OBO, for this very reason. I suspect that others may share my pain, if 
>> not my stubbornness.
> 
> Well that's a shame. I don't doubt that there are reasons to have been 
> put off, and that others have also felt pain. But I wasn't aware that 
> the object vs process distinction was such a barrier for anyone.
> 
>> 
>> Pat Hayes
>> 
>>> 
>>>> Pat Hayes
>>>> ------------------------------------------------------------
>>>> IHMC                                     (850)434 8903 home
>>>> 40 South Alcaniz St.            (850)202 4416   office
>>>> Pensacola                            (850)202 4440   fax
>>>> FL 32502                              (850)291 0667   mobile
>>>> (preferred)
>>>> phayes@xxxxxxx       http://www.ihmc.us/users/phayes
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _________________________________________________________________
>>>> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>>>> Config Subscr: 
>>>> http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>>>> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>>>> Shared Files: http://ontolog.cim3.net/file/
>>>> Community Wiki: http://ontolog.cim3.net/wiki/
>>>> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>>> 
>>> _________________________________________________________________
>>> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>>> Config Subscr: 
>>> http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>>> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>>> Shared Files: http://ontolog.cim3.net/file/
>>> Community Wiki: http://ontolog.cim3.net/wiki/
>>> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>> 
>> ------------------------------------------------------------
>> IHMC                                     (850)434 8903 home
>> 40 South Alcaniz St.            (850)202 4416   office
>> Pensacola                            (850)202 4440   fax
>> FL 32502                              (850)291 0667   mobile 
>> (preferred)
>> phayes@xxxxxxx       http://www.ihmc.us/users/phayes
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _________________________________________________________________
>> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>> Shared Files: http://ontolog.cim3.net/file/
>> Community Wiki: http://ontolog.cim3.net/wiki/
>> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> 
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/ 
> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (041)

------------------------------------------------------------
IHMC                                     (850)434 8903 home
40 South Alcaniz St.            (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile (preferred)
phayes@xxxxxxx       http://www.ihmc.us/users/phayes    (042)







_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (043)

<Prev in Thread] Current Thread [Next in Thread>