RE: Why ontology-based product modeling

Dear Henson,
can we logically add a third reason that is application functionalities (optionally) on top of reasoning on top of well-defined meaning (I am thinking about our product configuration/optimisation functionalities...)?
 
ch/Michel
 
ps
Ian, maybe you want to be on the public mailllist?
 
 
tno.nl <blocked::blocked::http://www.tno.nl/> 

Dr H.M. (Michel) Böhms MSc
Consultant Building Innovation 

 

Van Mourik Broekmanweg 6, P.O. Box 49, NL-2600 AA Delft, The Netherlands

T +31 15 2763107

F +31 15 2763024

M +31 6 30381220
E  michel.bohms@tno.nl <blocked::blocked::mailto:michel.bohms@tno.nl>  

Disclaimer <http://www.tno.nl/content.cfm?&context=overtno&content=overtnosub&laag1=282&item_id=72&Taal=2>  

 

 
 
 
 
 

________________________________

From: public-xg-w3pm-request@w3.org [mailto:public-xg-w3pm-request@w3.org] On Behalf Of Graves, Henson
Sent: 04 June 2008 22:04
To: public-xg-w3pm@w3.org
Cc: Ian Horrocks
Subject: Why ontology-based product modeling




In my opinion, there are two primary product development needs that are to the point regarding what one wants to *do* in and the role of an Ontology-Based product modeling tools. I am using Product Modeling in a broad sense that includes product development system engineering, etc.   

The first need is to have consistent terminology with well-defined meaning that is stated independently of (the interpretation by) subject matter experts.  Terminology with semantics is needed to facilitate and reuse information across specific applications within a broad community of interest.  This is a primary use of OWL in life sciences etc.  

The second need is for consistency checking and verification tasks.  Such tasks can be stated in terms of relationships between product modeling classes and properties of individuals in these classes. For example, one may want to check that a collection of requirements are consistent.  This task can be expressed in terms of a class being consistent which means that it has models.  This kind of reasoning can be performed in an appropriate framework.  In my current job is concerned with, for example, verification that product versions that have been built according to a specific design also satisfy specific requirements such as weight restrictions.  Reasoning is intrinsic to these kinds of tasks, as are observation and measurement.    

Current system engineering and product development language standards and the tools that operate on the KBs in the languages of standards do not address semantics and reasoning.  The languages may be sufficiently expressive but there is no formal semantics.  OWL 1.1 has been used to satisfy the first need for life sciences as it has such as semantics and so that is why it is a natural candidate for product modeling.  

Ian and I have attempted to articulate these two needs for reasoning capability in the OWLED paper, and we have been trying to work through some specific reasoning examples for problems expressed in OWL 1.1. I hope that we will have these examples completed for the fall OWLED.  What we are doing is only a first step.  There needs to be a lot of work like this kind of exploration to really figure out what one really needs and how it should be done. Conrad and I have been having a lot of discussion about this kind of thing.  The results of that conversation are in the document that we submitted to this XG.  

I completely agree that "we really should gather use cases & requirements, not simply about expressivity in common PM modeling tasks, but also about what those models are intended to support, w/r/t reasoning services."

- Henson 




This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html