Topic: Representing Attribute types, Attribute Values, and
AttributeInstances (qualities in DOLCE) (01)
*********************************************
NOTE: This note is being sent to the newly created COSMO-dev list,
where technical issues related to the structure of the COSMO ontology
should be discussed. Those who expressed an interest in the topic of
attributes, and a few others who are likely to be interested were
automatically subscribed.
First posting, February 3, 2006
********************************************* (02)
My recommendation for representing Attributes is that we distinguish
three disjoint Types which are involved in the representation. They
are, in plain language: Attribute Types, Attribute Values, and
Attribute Instances (03)
In the current TopLevel07 (updated today from TopLevel06) they are
labeled, respectively:
AttributeType
AttributeValue
Quality (04)
In addition there will be the instance-level relations:
hasAttributeValue
isaSubattributeOf (05)
The meaning and rationale for this suggestion are presented below and
(in part) in the comments to those Types in the OWL version of the
ontology: (06)
http://colab.cim3.net/file/work/SICoP/ontac/reference/ProtegeOntologies
/TopLevel07.owl
The meanings of the ontology elements in each of the three ontologies
are probably not precisely the same, but close enough that this
representation should be translatable into any one of the original
three. (07)
This is just the framework for attribute representation. More detail
can be filled in later if we agree on some basic representation such as
that suggested here. (08)
------------------------------------------
Rationale For Representation of Attribute Values: (09)
The representation of attributes varies among the different upper
ontologies, and we need to select some representation. (010)
However, there is a useful common feature of OpenCyc 0.7, SUMO, and
DOLCE, and I believe that the commonality captures important properties
of attributes, even though the details of the representations differ. (011)
The three types required to properly represent attributes and their
values are: (012)
1. AttributeType
The general kind of attribute being represented - color, length,
mass, shape, and mental attributes , e.g. intelligence,
apprehensiveness.
This is not explicitly represented in the 397 version of DOLCE,
though the documentation mentions quality types.
This also differs from the use of these specific terms ("Mass" ,
"Density"), which in OpenCyc 0.7 are types whose instances are the
measures (4 grams, 45 g/cc). (013)
In OpenCyc 0.7 and SUMO an DOLCE we have, in the terminology above, (014)
2. AttributeValue
The actual value of those attribute types (called regions or quales
in DOLCE) associated with particular entities, e.g. BrightRed37, 34
feet, 25 pounds, genius level, terrified. (015)
2.1 in SUMO, more specific AttributeValues (e.g. SalsaRedPearl) are
related to the more general attributes (e.g. Red) by the relation
'subattribute'. (016)
2,2 In OpenCyc 0.7 the similar relation 'genlAttributes' was used (this
was discontinued in 0.9). (017)
2.3 in DOLCE, quality regions (e.g. deep red) can be part of other
quality regions (e.g. red). This also permits subsumption of more
specific attribute values by less specific ones. In DOLCE, a 'quale'
is an "atomic part" of a region and appears to be used to represent a
region that does not have any distinguishable subregions.
------------- (018)
The basic intuition from all 3 ontologies that we should preserve is
that there are attribute values (i.e. instances of the type
"AttributeValue") that are similar to but narrower than other attribute
values, and possessing the narrower attribute implies possession of the
broader attribute. (019)
The narrower-than relation between AttributeValues can be used also
for quantitative attributes (e.g. length, mass), and this
representation can be used as one means of including uncertainty and
approximation in quantitative attribute values. (020)
In COSMO, this suggested Type includes as instances quantitative
attribute values such as "3 feet", which could be returned by a
Cyc-like measure function "feet", so that the function term "(feet 3)"
would be an instance of AttributeValue (more specifically, an instance
of "DistanceMeasure"). In SUMO such measures are returned by a binary
function that uses a number and unit of measure, e.g.
(MeasureFn 3 foot). (021)
3. Quality
This is explicitly represented in DOLCE, but not in OpenCyc or SUMO.
It will likely be used much less frequently than AttributeValue.
Examples are: the redness of my 2005 automobile today; my height today;
my weight today; my shape today ; Barry's intelligence today ; my
apprehensiveness today . Each of these individual instances of Quality
can be given a label if there is a reason to mention them explicitly. (022)
4. relations:
4.1 The basic relation involving AttributeValues would be:
4.1.1 hasAttributeValue
domain (domain 1) - any instance of Entity
range (domain 2) - an instance of AttributeValue (023)
4.1.2 isaSubattributeOf -
relates one AttributeValue to another AttributeValue of broader
coverage. This is essentially identical to the intended meaning of the
SUMO 'subattribute' and the OpenCyc 0.7 'genlAttributes'. (024)
4.2 Having a narrower AttributeValue implies having the broader value: (025)
(=>
(and
(hasAttributeValue ?ENT ?ATT1)
(isaSubattributeOf ?ATT1 ?ATT2))
(hasAttributeValue ?ENT ?ATT2)) (026)
The 'hasAttributeValue' relation can be specialized (e.g. hasColor)
and other relations will also be needed, but are not proposed at this
point. The question I would like to resolve first is whether this
arrangement of attribute-related Types can serve as the basis for more
detailed representation in the COSMO. (027)
4.3 The relation 'hasAttributeValue' is not explicit in DOLCE; DOLCE
uses two relations, including the Quality itself:
has-quality relates an entity to the individual quality
has-quale relates the quality to its quale (AttributeValue) (028)
The use of hasAttributeValue in COSMO will be similar to comparable
relations in OpenCyc 0.7 and SUMO, which do not represent Qualities as
particulars. The DOLCE relations can be accommodated without
contradiction. (029)
The hasAttributeValue relation might be convertible to the DOLCE
relation by the axiom:
(<=>
(hasAttributeValue ?Ent ?Att)
(exists (?Qual)
(and
(has-quality ?Ent ?Qual)
(has-quale ?Qual ?Att)))) (030)
But that axiom might best be used only in the reverse direction, so
that the hasAttributeValue relation can be used by itself with no
implications about Qualities, when the Qualities do not need to be
explicitly represented. In the case where they are represented, the
AttributeValue can be derived if the has-quale relation is also
instantiated. (031)
The exact intention of the 'atomic' nature of a Quale is not clear from
the DOLCE documents I have examined, and probably should be elaborated. (032)
5. AttributeValues and Events
In a 3-D ontology, the AttributeValues are often the things that
will change during an Event or Process. These are what has sometimes
been called "fluents" (no need to debate the use of that term, we will
not need it). Other 'fluents' may also change during an Event (e.g.
relations that are not Attributes). (033)
============================================== (034)
6. More details on how these types are described - from the comments
to the OWL file: (035)
(1) AttributeType (036)
Not directly represented in DOLCE; represented differently in OpenCyc. (037)
COSMO note: AttributeType differs from AttributeValue. The subclasses
of AttributeType are broad categories of attributes such as color,
length, mass. The individual values that those attributes may take for
particular entities are instances of AtributeValue. (038)
At this point the precise relation between AttributeType and
AttributeValue is not specified in the OWL version, as it could involve
a ternary relation such as:
(has Boat123 Length (meters 55)) (039)
. . . which could substitute for individualized relations such as: (040)
(hasLength Boat123 (meters 55)) (041)
. . . and could involve an axiomatization that differs for different
categories in the second argument position. (042)
The simplest 'attribute' relation would be hasAttributeValue,
discussed elsewhere. (043)
-------------------- (044)
(2) AttributeValue
COSMO: AttributeValue differs from AttributeType (which see).
AttributeValues are the values that attributes may take, but they are
not particulars, as there may be many instance of 'Qualities'
(particular attributes adhering to particular entities) which are, in
the DOLCE expression, 'located' in the attribute region that an
AttributeValue may represent. (045)
AttributeValues may subsume many subattributes: "RedColor" may subsume
"MaroonColor" or "BrilliantRed2357" in some categorization of colors. (046)
(In indented list: AttributeValue_Cyc__Attribute_SUMO__region_DOLCE) (047)
DOLCE: 'region' (broadly defined attribute values) and 'quale' - atomic
attribute values
>From DOLCE: We distinguish between a quality (e.g., the color of a
specific rose), and its value (e.g., a particular shade of red). The
latter is called quale, and describes the position of an individual
quality within a certain conceptual space (called here quality space)
Gardenfors (2000). So when we say that two roses have (exactly) the
same color, we mean that their color qualities, which are distinct,
have the same position in the color space, that is they have the same
color quale. (048)
SUMO: Attribute - Qualities which we cannot or choose not to
reify into subclasses of &%Object.
COSMO note: Attribute in SUMO is the range for the 'property
relation: the documentation of 'property' says: property -- This
&%Predicate holds between an instance of &%Entity and an instance of
&%Attribute. (&%property ?ENTITY ?ATTR) means that ?ENTITY has the
&%Attribute ?ATTR.
OpenCyc AttributeValue: (ver. 0.7, 2002; not in ver. 0.9) :A
specialization of #$IntangibleIndividual. Each instance of
#$AttributeValue is a property (in a broad sense of 'property') of some
instance of #$Thing. #$AttributeValue includes as instances quantities,
such as 5 inches (i.e., (#$Inch 5)) or 1000 dollars per year (i.e.,
(#$DollarsPerYear 1000)), as well as qualities like #$Hilly, #$Rough,
#$DeviceOn, etc., which can be used to make assertions about the state
of some tangible object. (049)
AttributeVales are some of the "fluents" which change during an Event
or Process, in certain Process representations. There may be other
kinds of fluents.
------------------------ (050)
(3) Quality (from DOLCE)
DOLCE: Quality: Qualities can be seen as the basic entities we can
perceive or measure: shapes, colors, sizes, sounds, smells, as well as
weights, lengths, electrical charges... 'Quality' is often used as a
synonymous of 'property', but this is not the case in this upper
ontology: qualities are particulars, properties are universals.
Qualities inhere to entities: every entity (including qualities
themselves) comes with certain qualities, which exist as long as the
entity exists. (051)
In DOLCE, qualities are tropes that are considered to inhere in the
objects that possess the quality; they are individuals and therefore
cannot have subclasses; therefore each instance of 'quality' is a
spatio-temporal-particular. Each quality is located in some quality
region by the relation 'has-quale'. A 'quale' may be the location for
many qualities. DOLCE definition of quale: 'An atomic region', (052)
The DOLCE 'qualities' will seldom need be used in reasoning, as they
are peculiarly inherent in other things and have few relations with
other entities. The interesting entities will be the quales, or
AttributeValues. (053)
COSMO note: Examples of qualities would be the redness of a particular
rose, or the shape of a particular ball. (054)
================================= (055)
7 -9: The differences are: (056)
In DOLCE, there are two important Types related to Attributes: Region
and Quality. (057)
7.1 quality
7.1.1 the DOLCE relation has-quality relates a particular to a
quality
domain: particular
range: quality (058)
But in DOLCE, a 'Quality' is a particular which is a kind of Trope,
and is located in a "Quality Region" (in DOLCE, just 'region'). The
ontology elements that are of greatest concern in SUMO, OpenCyc 0.7,
and COSMO are the regions, called AttributeValue in Opencyc 0.7 and
COSMO, and 'Attribute' in SUMO. (059)
7.1.2 the particular qualities are related in DOLCE to their atomic
quality regions (quales) by the relation: has-quale (060)
quale is a subtype of 'region', which includes 'quality region',
and measurements, as well as spatial and temporal regions. What might
be called an attribute can be represented in DOLCE as a
'quality-region' (in the COSMO ontology, an "AttribueValue"). (061)
7.1.3 These concepts (especially the notion of a quality 'region'),
are somewhat similar to the notions of 'quality spaces' described by
Peter Gardenfors in his book "Conceptual Spaces" (MIT press, 2000).
But the ontological representations are not those of Gardenfors. What
I believe is important is that there is a commonality among DOLCE,
SUMO, and OpenCyc 0.7, of the notion that attributes form a dimension
or a space, and that our perceptions of attributes actually pick out
some region of that attribute space or dimension - and that each region
may have subregions that represent more specific attributes. An
'atomic region' is called a "quale". (062)
In DOLCE, but not in SUMO or OpenCyc, this notion is related to the
notion of a 'quality' (a kind of 'Trope') as being an instance - in
DOLCE a particular - of a class of entities that are indissociably
associated with other particulars, e.g. physical objects, and therefore
located in space - along with the object. Guarino explains that
qualities are tropes, but not all tropes are qualities. So we are
concerned with what DOLCE calls "qualities", not directly with tropes.
In the discussion, Barry Smith referred to "the color of Rudolf's nose"
as an example, though I think that is not a good example, since Rudolf
is not a real physical object. More about that below. These
'qualities' are not instances of some 'quale' region, but are
"located-in' a quality region. (063)
The documentation of 'quality' in DOLCE reads; (064)
"Qualities can be seen as the basic entities we can perceive or
measure: shapes, colors, sizes, sounds, smells, as well as weights,
lengths, electrical charges... 'Quality' is often used as a synonymous
of 'property', but this is not the case in this upper ontology:
qualities are particulars, properties are universals. Qualities inhere
to entities: every entity (including qualities themselves) comes with
certain qualities, which exist as long as the entity exists." (065)
This is further discussed in "Sweetening WordNet with DOLCE' by
Gangemi, Guarino, Masolo, and Oltramari:
http://www.w3.org/2001/sw/BestPractices/WNET/SweeteningWN.pdf (066)
"Each quality is an instance of a quality type" and "We distinguish
between a quality (for example, the color of a specific rose) and its
value. The value is called 'quale' . . ." (067)
7.1.4 So we can conclude that (to be more real and physical,
"TheRedNessOfPatCassidys2005ToyotaOnSeptember012005" would be a point
located in the 'Red' subregion of the Color region (to be more
specific, in Toyota's terminology, it would be in the "Salsa Red Pearl"
subregion of the Red subregion of the Color region). We need to
specify the time because the color of physical objects can change as
sun and time work their effects. It is problematic to use an example
like Rudolf, since the color of his nose may differ in different
depictions, and is in fact unknowable, as he is fictional. (068)
7.2 Region
7.2.1 Roughly equivalent to the proposed AttributeValue
The boundaries of any particular quality region may not be precisely
definable any more than the boundaries of Mount Everest or of a
particular atom. (069)
7.2.2 quale, a particular atomic portion of the quality region. Each
quality is a point located in a quale (sub region). Quales are related
to regions by the 'q-location' relation. I have not determined what
makes a region in DOLCE "atomic". (070)
7.3 Quality type, e.g. 'Color' -- for some reason, quality types like
"color" are not described explicitly in the OWL DLP-397 version of
DOLCE. In DOLCElite the documentation states: (071)
" The only class of abstract entities we consider in the present
version of the upper ontology is that of quality regions (or simply
regions). Quality spaces are special kinds of quality regions, being
mereological sums of all the regions related to a certain quality
type.." (072)
8. SUMO
In SUMO, an Entity may be related by the relation "property" to an
Attribute, and more specifically, an Object may be related to an
Attribute by the "attribute" subrelation of "property". What makes
this similar to the DOLCE treatment is that in SUMO there is a relation
defined, "subAttribute", which can be used to specify that, for
example, "SalsaRedPearl" is a subAttribute of "Red". subAttribute is
transitive, and the net effect is that any given Attribute could form a
region like a DOLCE quality-space, with subregions being more
specialized parts of the broader region. In DOLCE, a 'quale' is an
atomic attribute, being the region where a particular Quality is
located. (073)
But SUMO does not explicitly represent the Tropes (in DOLCE,
"quality"). (074)
9. OpenCyc 0.7.
In a manner very similar to SUMO, OpenCyc 0.7 has entities related to
AttributeValues (Attribute in SUMO, region or quale in DOLCE). And also
similarly, each AttributeValue could be related to a more general
AttributeValue by the "genlAttributes" relation (subAttribute in SUMO).
This also has the effect of specifying AttributeValues as regions with
more specific subregions, just as in SUMO and DOLCE. OpenCyc, like
SUMO, did not explicitly represent Tropes, or particular instances of
attributes associated with specific instances of the host entities. (075)
For a reason I don't know, OpenCyc 0.9 changed that representation. It
appears as though having an attribute like a color is now represented
as being an instance of a class of entities having that color. I don't
understand this, since it appears to be a circular definition, but
perhaps some Cyclist can explain the rationale, and this interpretation
may not be correct. The OpenCyc 0.7 usage is closer to that of SUMO
and DOLCE, and I believe some similar usage is the one we should adopt. (076)
10. Conclusion (077)
To retain the maximum common features of DOLCE, SUMO, and OpenCyc 0.7,
it appears that we could represent attributes in this manner: (078)
We could have three disjoint Types in the COSMO, AttributeType,
AttributeValue, and Quality: (079)
10.1 AttributeType - like "Color", "Length". "Mass",
"Apprehensiveness", "Beauty". this would serve as the unrepresented
'quality type' referred to in some DOLCE documentation. But
AttributeValues need not be instances of this type, they can be related
by another relation. Thus these Types need not be metatypes. (080)
10.2 AttributeValue
Instances of AttributeValue would be the values of the relation
"hasAttributeValue": RedColor, SalsaRedPearl, 100Pounds, 20Feet,
Terrified, StunninglyBeautiful, etc. (081)
These AttributeValues could form regions as in DOLCE, SUMO, and
OpenCyc 0.7, related by the relation "isaSubAttributeOf" (in SUMO,
'subattribute' and in OpenCyc 0.7 'genlAttributes', which points from a
more specialized AttributeValue to a broader one. Thus we could have:
(isaSubattributeOf SalsaRedPearl RedColor) (082)
The quantitative AttributeValues, such as 100grams (or, using a
Cyc-like function, "(gram 100)" ), would also form regions (a variance
around the nominal value, representing measurement error) the size of
which could vary by default with context or be explicitly represented
in the quantifier portion of the measurement, e.g. (gram 99-101). (083)
10.3 Quality
Taken from DOLCE: Instances of Quality would be individual qualities
associated with specific objects, such as:
"TheRedNessOfPatCassidys2005ToyotaOnSeptember012005" (084)
It would probably seldom be useful to define the actual instances of
Qualities, since the more interesting things we tend to talk about are
the AttributeValues, as in
(hasAttributeValue PatCassidys2005Toyota SalsaRedPearl)
or, using a more specific subrelation,
(hasColor PatCassidys2005Toyota SalsaRedPearl) (085)
============================== (086)
11. We will, of course want to define other relations concerning
attributes, and there are some interesting and useful possibilities
that arise from using a representation like the above. (087)
12. 4-Dimensional things.
I am still not familiar enough with representation of attributes in
ISO15926 to know how to relate these ontological representations to
that idiom. One difference is the use there of templates to express
certain relations:
http://www.infowebml.ws/introduction/introduction.htm (088)
In figure 1 of the page:
C:\pc\SICoP\ONTACC\COSMO\ISO15926\Hans\ontology foR TEMPLATES.htm (089)
. . . the template ST-3401P appears to function as a reified quintary
relation that has as arguments not only the object and its (numerical)
attribute, but the generic types of the attribute. This might be
translatable by an axiom with several consequents. (090)
I hope that Matthew will be able to provide the detailed analysis. (091)
But at this point I will want to stop and learn what others may think
is appropriate. (092)
===============================================
===============================================
13. Bottom line question: (093)
For the 3-D part of the COSMO, does anyone object to using the three
disjoint types:
AttributeType
AttributeValue
Quality (094)
. . . and the general attribute-assignment relation:
hasAttributeValue (095)
. . . and the subsumption relation:
isaSubattributeOf (096)
. . . to represent attribute values and their relations to entities and
to each other?
===================================================
=================================================== (097)
Pat (098)
Patrick Cassidy
MITRE Corporation
260 Industrial Way
Eatontown, NJ 07724
Mail Stop: MNJE
Phone: 732-578-6340
Cell: 908-565-4053
Fax: 732-578-6012
Email: pcassidy@xxxxxxxxx (099)
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/cosmo-dev/
Community Portal: http://colab.cim3.net/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/COSMO/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?CosmoWG (0100)
|