ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Representing design

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: David Price <dprice@xxxxxxxxxxxxxxx>
Date: Thu, 17 Oct 2013 11:56:54 +0100
Message-id: <D9015274-44B3-4199-A08C-CA8E53413DF3@xxxxxxxxxxxxxxx>
The problem may also be that the idea of "Concept" is under-specified, or perhaps you should have separate ideas rather than just the one.

It doesn't sound like you've teased out what you're trying to do with "Concept" by understanding things like whether Concept has members that are the classes that are the product designs (or other classes), or whether Concept has members that are the real world physical objects that are members of the classes that are the product designs. Nobody on this forum can do that for you.

Suggest keep it as simple as you can though: Product designs are classes that specify membership criteria. Some real-world physical objects are members of those classes, in particular those you manufacture based on those product designs.  When you need to make statements about the classes that are product designs, make those classes members of other classes for that purpose (not subclasses, otherwise you're also making statements about the real-world objects). Understand all this before worrying about how to represent within the limitations of whatever logic language you choose to use. For example in the 4D beyond logic world that is ISO 15926, even having a property like "length = 40 cm" is being a member of a class. However, for practical reasons you might not want to represent it that way so you can make use of the power of specific logic engines.

WRT design models (E.g. 3D CAD models), those are also just classes in a specific language. Your product design class is really the intersection of all those classes (i.e. the complete product design class is the intersection of the things that are member of the 3D CAD model class and are members of the material properties class and are members of the EE design class, etc.). 

Also suggest being more clear about what you're doing - you don't "describe" a class or a concept, you "define" it (or perhaps more accurately, define what it means to be a member). Then it means whatever you've defined it to mean. You can "describe" real world things, but not classes or concepts.

All that said, there are no "right" answers, just answers that work for your specific use case. There are of course approaches or frameworks that are proven to work - just don't get drawn into discussions about the framework being "right", or else you'll spend all your time doing that and none doing useful work:-)

Cheers,
David

UK +44 7788 561308
US +1 336 283 0606




On 17 Oct 2013, at 02:55, henson wrote:

Sandro,
In industrial product development applications that I am familiar with a design concept is more general than a design specification. so
    Ax NewHammerDesign(x) implies NewHammerConcept(x)
 
Also designs are more restrictive than descriptions which are more restrictive than concepts.
    Ax NewHammerDesign(x) implies NewHammerDescription(x) implies NewHammerConcept(x)
 
However, the conceptual hierarchy is different from  physical objects.  That is, a design object and a description object are not physical objects. The FOL statement  “Ax NewHammer(x) -> length(x, 40cm)” could certainly be in either of NewHammerDescription or  NewHammerDesign, but is not a hammer. The conceptual classes and the physical classes are related by a NewHammerModelOF relation
   
    Ax,y NewHammerDesignModelOf(x,y) implies NewHammerDesign(x) and HammerPhysicalObj(y).
 
 
With the above distinction between the conceptual objects and physical objects, the statement that “the description of a design must explicitly reference the ontology” would be replaced by  ”description and the design specification of the physical artifacts must explicitly reference the ontology”.  The description of the design refers to design artifacts. A specific named design instance might have multiple design artifacts with different data types related to it.
 
Henson Graves
 
Sent: Tuesday, October 15, 2013 12:00 PM
Subject: [ontolog-forum] Representing design
 
Dear all,

This list frequently rises the difficulties and ambiguities involved in modeling the notion of design (as in “product design”) and engineering model. We are now developing an ontology that must represent these concepts and we are facing those same issues. We would like to seek some advice from people in this list.

The ontology we are working on must deal with a conceptualization already in use by a specific application. This application deals with automated production lines that produce different types of artifacts (hammers, for example). These artifacts are produced according to their respective specific designs.

However, it is not clear what are these designs and what are their relationship with the respective artifacts. Intuitively, we consider artifacts as subtypes of physical objects. We consider designs to be mental or abstract entities that specify instances of an artifact to be built (but not *how* they are built, in terms of list of actions). For instance, a design of a type of hammer should specify what are its attributes, parts, structure and materials.

That definition of design makes it quite similar to the very notion of concept. The argument going on in our group is whether there is any essential difference at all between then, and if so, what are they relationship. Both seem to “abstract” the properties of a class of individuals. Differences could be the level of detail they are intended to specify. Another point of view emphasizes that there is a fundamental difference between the concept/class of Hammer (for example) and the design of specific hammers. Nevertheless, their main content of a class/concept seems to be very similar, but we are not sure whether this similarity necessarily implies the identity between these notions.

The differences become even more difficult to spot when we consider the design and its description. We distinguish the design from its description as a piece of text or a blueprint. A single design can have many individual descriptions.

One of the requirements of this project is that the description of a design must explicitly refer to entities provided by the ontology. For example, consider a design for a new kind of hammer, which should be 40 cm in length. This design has a description (say, in first order logic) “Ax NewHammer(x) -> length(x, 40cm).” According to our requirements, NewHammer and length must relate to the “Hammer” and the property “length” provided in our ontology. We could, for instance, rewrite that formula to “Ax NewHammer(x) -> Hammer(x) ^ length(x, 40cm)”. However, in this case we start to have the description of a design of Hammer is striking similar to the description of a subconcept of Hammer.

Some people in our group quite understandably have problems with that position, arguing that the content of the description of a design should only reflect an existing concept, but it cannot be the same as the description of a concept (to justify the subsumption relation in the second formula, for instance). Other argue that the description of a design *is* the description of a concept, justified by the lack of differences between them.

The question is: what is the relation between design and concept/class? We considered two possible answers:

1-The  concept/class Hammer’ is its own design. In this sense, it seems that the notion of design is only useful as a modeling tool to group different possible descriptions of the same entity. It seems to be interesting to think about the instances here. In this point of view, both the concept and design of NewHammer collapse in the same entity, abstracting the same class of individuals.

2- The concept/class NewHammer and its design are different things. An instance of NewHammer is different from an instance of Design that specifies the class of NewHammer. In this point of view, it seems that we are proposing a new type of relationship that holds between instances and classes, which is not the instantiation relation. In this relationship (maybe called specifies), a specific instance (of design) specifies a new class of entities in the ontology. That is, this new class comes to existence due to the very existence of an instance of Design that specifies it.

best,
-- 
Sandro Rama Fiorini
Phd Candidate
Institute of Informatics
Federal University of Rio Grande do Sul (UFRGS)
Website: www.inf.ufrgs.br/~srfiorini



_________________________________________________________________
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


_________________________________________________________________
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    (01)

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