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

Re: RE: Evidence

From: <samwald@gmx.at>
Date: Thu, 21 Jun 2007 16:44:09 +0200
Cc: public-semweb-lifesci@w3.org
Message-ID: <20070621144409.54530@gmx.net>
To: "Kashyap, Vipul" <VKASHYAP1@PARTNERS.ORG>, alanruttenberg@gmail.com

Hello Vipul,

> I do lack knowledge of the nuances of BFO, but from a 10,000 ft level
> it is not clear to me the value of modeling a process as an occurrent.
[...]
> it fails your acceptance test: understandability..
[...]
> It also fails another acceptance test, doesn't help me to represent the
> notion
> of a computational process easily....

I have to disagree with you here. The distinction BFO (and also DOLCE) makes between continuants and occurents, and especially the distinction between processes and objects, is relatively easy to understand, you just need to look at the documentation and the examples for each a bit more. I also think that the distinction between processes and objects is quite practical. The main point in this discussion so far was that the domains and ranges of some relations might be perceived to be unnecessarily restricted to one or the other. Again, this might be true in some occasions, but I don't see too many problems here at the moment.

I also think that you put too much emphasis on the definitions of terms like 'process' in computer science. I have the impression that many people with a strong background in computer science easily mix up such terms from computer science with the general meaning of these terms. Sometimes it appears that it would be better if they would temporarily forget their education in computer science while creating ontologies, because it does more harm than good.

'Process' in the context of software systems has a very special meaning that does not have much to do with what people in general are thinking of as a process. The 'processes' in BFO are much closer to the intuitive understanding of most people. In other words, it is more likely that the diction of software developers fails the acceptance test of understandability, and *not* BFO!

By the way, this discussion was triggered by my statement that things like 'binding assay result' are not subclasses of something called 'evidence', but instead 'evidence' is more of a role they play in certain contexts. My emphasis actually was that we should NOT make a bogus subclass statement. I don't think we have to deal with 'evidence roles' at the moment, so we can just omit them. Of course, the discussion we are having right now is still valuable, but I did not intend to trigger this discussion when I made that statement.

cheers,
Matthias Samwald

----------

Yale Center for Medical Informatics, New Haven /
Section on Medical Expert and Knowledge-Based Systems, Vienna /
http://neuroscientific.net

cheers,
Ma

> 
> And I suspect similar utility issues will arise with the others as well,
> DOLCE,
> OpenCyc, ...
>  
> > I totally with you on us all agreeing, durably. This has worked for
> > BFO in OBI so far. 
> 
> [VK] Yes, it may have, but then the clinical types in HCLS would view it
> ss a
> siloized approach and issues start coming up when we try to use BFO.
> 
> > This one I find harder to evaluate, for some reason. As I've said, my
> > bias is that I think distinctions are usually good and we need more
> > rather than less of them. I'm worried that absent having them it's
> > too easy to say things that don't have a consequence, or for which
> > the consequence is not clear. I'd say this is an area that I need to
> > learn more about.
> 
> [VK] I guess then the acceptance test would be: Are the entailments that
> are
> inferred as a result of having these distinctions useful? Hope that makes
> it
> clearer ... :)
> 
> > > Acceptance Test 2: Ability to express my information needs without
> > > jumping
> > > through hoops>?
> > don't know what this means
> 
> [VK] I had the use case of "computational process" in mind.... Had to go
> through
> some gyrations there. I guess the issue there was a lack of clear
> methodology to apply these constructs.
> 
> > > Acceptance Test 3: Ability to align with other "standards"
> > not necessarily interesting. Depends on what you think of the other
> > standards.
> 
> [VK] What I meant here is that there are existing standards within
> Healthcare,
> e.g., HL7 - RIM, Snomed, LOINC, etc. So alignment would be good.
> Also, mis-alignment would be good if it exposes gaps and weaknesses in
> these
> existing standards, in that they do not support some use cases.
> 
> > Ideally you evaluate these by having some problem to solve, then
> > trying to use the system to solve the problem and then seeing how
> > well it did. This is hard work and I don't know of any shortcut.
> 
> [VK] Alan you have been the driving force of the HCLS demo and in some
> sense you
> are best positioned to come up with an interesting use case from the
> biological
> world, probably related to evidence. And then we can work it through.
> 
> I can put forward a use case from the clinical world. It is centered
> around the
> aspect of judgements/assessments a nurse makes in the process of nursing
> care
> and the pieces of evidence he/she requires to make that assessment.
> 
> > Maybe we can bring this back to the main subject: What problems are
> > we trying to solve by recording evidence? What are the ways we would
> > know that we've made a mistake?
> 
> [VK] IMHO, the key issue is that the process of assessment/judgement be
> predictable, i.e., given the same set of evidence and the same context,
> one
> should be able to reproduce the same conclusions.
> 
> The other requirement would be the ability to explain why a particular
> ssessment
> was made. Most statistical reasoning systems are weak in this regards....
> 
> Some others may come up with other requirements.
> 
> ---Vipul
> 
> 
> 
> 
> 
> The information transmitted in this electronic communication is intended
> only for the person or entity to whom it is addressed and may contain
> confidential and/or privileged material. Any review, retransmission,
> dissemination or other use of or taking of any action in reliance upon this information
> by persons or entities other than the intended recipient is prohibited. If
> you received this information in error, please contact the Compliance
> HelpLine at 800-856-1983 and properly dispose of this information.
> 

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
Received on Thursday, 21 June 2007 14:44:31 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:48 GMT