Juan, (01)
I would have said that the question you have to ask yourself is whether
the classification "Ferrari 458 Italia"
(a) is a thing that you need to deal with as an abstract object that has
properties of its own, like a price range or a marketing plan or a
manufacturing program that associates it with factories and resource
allocations; or
(b) is a cluster of properties that apply to each Ferrari 458 Italia
individually and not, in general, to cars of other types; or
(c) neither (a) nor (b); or
(d) both (a) and (b) (02)
If it is (a), then it is imperative that you capture "car model" as a
class that has properties like model name, price range, marketing plan
and manufacturing plan. Then "Ferrari 458 Italia" is an instance of
"car model" and has its particular values for those properties. In
addition, you capture "car has model" as a property, and relate the
individual cars to the "model". The point here is that the 'car model'
is a thing that is managed in its own right in the application domain,
and individual cars are related to that thing. One can if necessary
refer to those cars as a set by creating a class "Ferrari 458 Italia"
defined as "car whose car model is named "Ferrari 458 Italia", but it is
probably not necessary. (03)
If it is (b), then it is imperative that you capture "Ferrari 458
Italia" as a subclass of "sports car". Then you define the specific
properties that apply only to such vehicles and to specify the class
"Ferrari 458 Italia" as the domain (or part of the domain) of these
properties, so that statements assigning such properties to the
individual vehicles will be meaningful. (04)
If it is (c), Sjir Nijssen would say that the model name is just another
information unit attached to the individual 'car' objects -- it has no
properties of its own (that you care about). You can just create the
property 'car has model (name string)'. My vote for best practice would
be to do (a). Assume that in the future, or in lashing up with another
ontology, 'car model' might be a useful kind of thing that has
properties in its own right. Make 'car model' part of the domain of
'thing has name', and stop there. Create the property 'car has car
model', and populate it properly for the individual instances, not only
of Ferraris, but also of Fords and Volkswagens and Hondas. (05)
If it is (d), you must do (a) in order to capture the managed properties
of the car model that are not properties of the individual cars (they
don't have a marketing plan). And you must also do the last sentence of
(a) above, because those cars are more than a set, they are a class that
assigns to its members some unique properties. Then that class "Ferrari
458 Italia", defined to be the cars whose model is named "Ferrari 458
Italia", is the class that has to be defined in (b) and then you do the
rest of (b). (06)
In my experience, most of this taxonomic modeling stuff is situation (a)
or (c). The nominal classification is a "thing of the business domain"
that may have some properties in its own right. The nominal
classification is not a useful classifier of things, because its
instances have no special properties. The meaning of the classification
is that it is a sports car and that it has a Ferrari nameplate with all
the rights and privileges associated therewith, whatever those may be,
but you are not modeling them. (07)
The other concern you may want to consider is properties of the individuals:
- unary or binary properties that only have meaning (or have special
meaning) for the particular car model, and have different values for
different individual vehicles; and
- unary or binary properties of a more general classification (sports
car) that have fixed values for all members of the class. (08)
In the first case, you must define the car model as a class. If 'has
Riviera windows' is a possible property of Ferrari 458s that is
meaningless for other vehicles, you can define it for a more general
class, but it is probably better to define its domain to be Ferrari
458s, and thus there needs to be a class for them. An alternative
approach that you see in data models is to add some completely general
'special attributes' property to 'car', and define 'special attribute'
as a name/value pair. That is an implementation trick for ad hoc schema
extension, and I strongly discourage that kind of thing in ontologies. (09)
In the second case it may be useful to define the car model as a class,
so that you can state the fixed values via a universal quantification,
once. E.g. Every Ferrari 458 Italia has a 4.58 litre engine.
Otherwise, if that is important, you would have to make a similar
statement for each Ferrari 458 Italia you introduce, or run the risk of
the reasoner treating the engine size as unknown. (010)
Bottom line: The choice is not so simple. You need to understand what
properties will be associated with the classifications and how you
intend to use the ontology. The above is merely some considerations
drawn from (sometimes bitter) experience. (011)
Best of luck! (012)
-Ed Barkmeyer (013)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 (014)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (015)
Juan de Nadie wrote:
> Hi David.
> Thanks for the answer.
>
> I agree about the "Ferrari 458 Italia" to be treated as a
> specialization of "sports car". Seems resonable to me too.
> But, i guess that this is a particularity of "artificial domains" (or
> domains whose core objects are "artificial things/artifacts"). The
> taxonomies are open-ended: we can create a new subtype at any time.
> This strategy (a new class for each new "model") seems to result in
> complex ontologies, with a huge number (and growing) of leaf nodes.
>
> I wonder if this strategy is more suitable to deal with this problem.
> Or to consider "model" as an attribute of the root node.
> I guess that the two design choices have differente implications. But
> I still could not identify what the implications are.
>
> Best regards.
>
> 2012/7/10 David Leal <david.leal@xxxxxxxxxxxxxxxxxxx
> <mailto:david.leal@xxxxxxxxxxxxxxxxxxx>>
>
> Dear Juan,
>
> Regarding "Ferrari 458 Italia" as a specialization of sports car
> seems reasonable to me.
>
> However the important information is that this class is a "model" as
> defined by the marketing department. Probably the manufacturing
> department has a different taxonomy, where instances of many
> different classes can be sold as "Ferrari 458 Italia" because they
> look similar on the outside. So perhaps we have in Turtle:
>
> :myCar a ferrari:458Italia .
>
> ferrari:458Italia rdfs:subClassOf :sportsCar ;
> a
> :ClassOfArtifactDefinedByTheMarketingDepartment .
>
> Best regards,
> David
>
> At 19:23 10/07/2012, Juan de Nadie wrote:
> >Hi!
> >
> >Recently I have encoountered a problem in my ontology engineering
> >project. Sometimes we must represent the notion of models in the
> >ontology. Let us consider the domains of cars, robots and aircrafts,
> >for example.
> >
> >In the car domain, we have the concept of car as a root node in a
> >taxonomy of types of cars. Let us suppose that the cars can be
> >"family cars" or "sport cars". What is the suitable way to model
> >different models of "family cars" and "sport cars"? Let us consider
> >the "Ferrari 458 Italia". I consider this model as a concept that
> >specializes the "sport car" concept in my ontology? Or is more
> >suitable consider an attribute of the concept "car" called "model"?
> >
> >There is some ontology design pattern to model these cases?
> >
> >Thanks.
> >
> >_________________________________________________________________
> >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
> <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
> >
>
>
> ============================================================
> David Leal
> CAESAR Systems Limited
> registered office: 29 Somertrees Avenue, Lee, London SE12 0BS
> registered in England no. 2422371
> tel: +44 (0)20 8857 1095 <tel:%2B44%20%280%2920%208857%201095>
> mob: +44 (0)77 0702 6926 <tel:%2B44%20%280%2977%200702%206926>
> e-mail: david.leal@xxxxxxxxxxxxxxxxxxx
> <mailto:david.leal@xxxxxxxxxxxxxxxxxxx>
> web site: http://www.caesarsystems.co.uk
> ============================================================
>
>
>
> _________________________________________________________________
> 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
> <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
>
> (016)
_________________________________________________________________
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 (017)
|