On 20 Mar 2015, at 0:42, Pat Hayes wrote: (01)
> 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. (02)
Yes, I hate mindless repetition of this sort. I'd seek to at least infer
the 2nd set of facts rather than restate them, 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. 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. (03)
>
>> 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. (04)
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. (05)
> (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.) (06)
I'm not quite seeing the analogy, rdf:type is an essential construct for
doing any traditional kind of reasoning (07)
>>> 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. (08)
OK, we're going round in circles here, I'm contending that the SMEs at
least in my domain 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. (09)
> 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. (010)
I don't either. (011)
>> 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. (012)
I'm wondering how much we actually disagree. You're fine with a
heuristic distinction. I'd rather axiomatize it so that we get the
benefits of automated checking 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. 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. (013)
>>> : 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. (014)
OK, I guess I see the O/C distinction as manifesting in terms of
domain/range constraints etc rather than syntax (015)
>> 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. (016)
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. (017)
>> 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?) (018)
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. 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". (019)
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. (020)
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. 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. 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. (021)
> 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. (022)
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. (023)
> (A judgement, I would add, which has no scientific basis.) (024)
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. (025)
>> 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. (026)
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. (027)
>
> 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 (028)
_________________________________________________________________
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 (029)
|