PSIs for Component Types

Published Subject Indicators for Component Types

PSI Metadata

Description	The assignment of an Aspect-Descriptor pair to an entity is designated by CG's author John Sowa as prehension in his paper on Roles and Relations. This PSI-set re-expresses these same concepts within the XTM 1.0 paradigm by adding CTM-specific constraints. As an ontology, CTM defines types of XTM topics and associations required to model Conceptual Graphs. It seeks to let CGs be used freely in portable Topic Maps, but also to let CGs in their standard ASCII notations be recovered from XTM equivalents. This requires clarity on what the equivalents are, which the constraints below seek to provide. Collisions in terminology do arise, especially in paradigmatic meanings for role and characteristic. To limit the confusion, I employ these terms here ONLY in their XTM sense, and re-label the colliding CG concepts with the terms "Aspect" and "CHRC".
Publisher	Lexikos Corporation
Creator	Dan Corwin
Language	http://www.topicmaps.org/xtm/1.0/language.xtm#en
Version	2004/08/10
Status	Pre-release CTM 1.0 draft for comment
Date Published	2004/07/11

Index Of Subjects

HAS	http://www.lexikos.com/psi/ctm/component/#0
*...Composite	http://www.lexikos.com/psi/ctm/component/#01
*...Component	http://www.lexikos.com/psi/ctm/component/#02
*...Correlative	http://www.lexikos.com/psi/ctm/component/#03
CHRC	http://www.lexikos.com/psi/ctm/component/#1
*...Role	http://www.lexikos.com/psi/ctm/component/#10
*...Occurrence	http://www.lexikos.com/psi/ctm/component/#11
*...Name	http://www.lexikos.com/psi/ctm/component/#12
*...Scope	http://www.lexikos.com/psi/ctm/component/#13
PART	http://www.lexikos.com/psi/ctm/component/#2
*...Piece	http://www.lexikos.com/psi/ctm/component/#20
*...Participant	http://www.lexikos.com/psi/ctm/component/#21
*...Stage	http://www.lexikos.com/psi/ctm/component/#22
Property	http://www.lexikos.com/psi/ctm/component/#3
*...ATTR	http://www.lexikos.com/psi/ctm/component/#30
*...MEAS	http://www.lexikos.com/psi/ctm/component/#31
*...AMT	http://www.lexikos.com/psi/ctm/component/#32
*...MANR	http://www.lexikos.com/psi/ctm/component/#33

HAS

Published Subject Identifier: http://www.lexikos.com/psi/ctm/component/#0

The HAS idiom is often used to speak of entity-Aspect-Descriptor triples. Here we focus on its intrinsic sense, in which only the first two of these CTM role types may be used. We address the third type separately:

Composite = 1: an Entity which HAS the Component Aspects indicated
Component = N: a PART or Property of the indicated Composite
Correlative = N: Aspects of HAS relations deemed Extrinsic

Under CTM, the Entity and Aspect are both a typed XTM topic. They are usually identified by a common English noun so they fit linguistically into the English HAS idiom syntax. It can also use IS and OF, as in these equivalents:

{Entity} HAS {Aspect} Descriptor
[{Entity} {Aspect} Descriptor]
{Aspect} OF {Entity} IS Descriptor
{Aspect} OF {Entity} Descriptor
{Entity} IS Descriptor (Descriptor implies which Aspect)

CTM defines two broad options for an intrinsic Descriptor, both more constrained than in XTM:

If the Descriptor is an XTM topic, the Aspect must be a subtype of PART. XTM allows any COMPONENT, but CTM 1.0 does not support XTM Properties modeled by topics.
If the Descriptor is a String, its Aspect type specs its legal (name or occurrence) values. XTM allows many such types, but CGs specially define only the Property: an optionally quantified modifier. CTM allows any well constrained Occurrence subtype - a major extension.

CHRC

Published Subject Identifier: http://www.lexikos.com/psi/ctm/component/#1

Every entity in CTM is modeled by an XTM topic, which IS itself a formal model of a Composite known as its subject. Under the XTM paradigm, every topic is a binding point for properties, names, and associations that characterize it, and each modeled subject is expected to have only one topic representing it.

CGs formalize HAS using binary relations for various Aspects, one of which is CHRC - a noun-like term in CTM for modeling Property types that is basically what XTM would call a constrained occurrence type.

But beware of terminology, for CTM expands the CHRC-related "characteristic" term into its broader standard XTM sense, which subsumes all of these different topic-modeling elements:

Role = extrinsic or PART; mediating element of an association
Occurrence = typed ResourceData or URI recorded as a string
Name = binds special case typed Strings for topic names
Scope = idiomatic set of topics limiting CHRC visibility

The first - an XTM role type - is used in CTM to say how a PART relates to its WHOLE Composite. Like a CHRC subtype, each PART should have a noun-like name.

The second - an XTM occurrence type - is used in CTM to define the Property data related to a SUBSTRATE Composite. Each occurrence type is a subtype of CHRC.

Names and scope are undefined in CGs, but CTM will define special-case CHRC types corresponding to types of XTM 1.1 names, and will let them be scoped to a locale. Details are TBDL.

PART

Published Subject Identifier: http://www.lexikos.com/psi/ctm/component/#2

CTM distinguishes several kinds of PARTS, as each is important. The sub-type of a PART topic does this, and it also constrains its Descriptor topic to meet various expectations:

Piece = part of a continuant, such as an object
Participant = spatial part of an occurrent (process or situation)
Stage = temporal part of a process; a situation or sub-process

An intrinsic association type specifies role types for both Composite and Composite topics. It lets both these role types be constrained in English by rules in a PSI, or enforced by embedding within its own PROPERTY set Range, Domain and Cardinality constraints - such as these defined in the WORDS language.

The HAS association sub-type being used can impose additional constraints on its instances, by dictating the Composite type, its set of required PARTs, any special PROPERTY set for each, and any implied further associations.

Such richly constrained conceptual graphs make it relatively easy to model any complex real world Entity type in detail. Be it an object, substance, process, or situation, CTM lets each of its PARTS be specified at levels of detail ample for any application, using a vocabulary of English-like associations specific to its needs.

Property

Published Subject Identifier: http://www.lexikos.com/psi/ctm/component/#3

For a PROPERTY, the HAS idiom requires that each CTM 1.0 Descriptor be a String modifier - a constrained type of Occurrence. To handle the needs of CGs, CTM must address these particular relations as CHRC occurrences, sub-typed as needed to properly handle different Entity and Aspect types:

ATTR = Attribute - adjective-like term from a facet spanning a range
MEAS = Measure - numeric quantifier for an ATTR, modeling its extent
AMT = Amount - numeric quantifier for a CHRC, modeling its extent
MANR = Manner - adverb-like ATTR variation that models a process

CTM does not limit PROPERTY String types to just those above, but it does insist that each type and its legal format be defined by a PSI, at a level of detail appropriate for a portable "data type". In XTM, several such types are widely discussed, from URIs to BigNums, but most are validated (pending TMCL) only by application-specific code.

The job of ATTR can be done by denoting one term in an ATTR-specific facet that lists five regions of some scaler range - like "tiny", "small", "normal", "large", and "giant". This works for any ATTR subtype with a scaler MEAS. By CTM convention, the list position "1", "2", "3", "4" and "5" would actually get stored in instances, as numbers are smaller and easier to process and to localize. See PSI tree specs for working examples.

To store MEAS or AMT values, CTM just adds comma-separated extensions to such an ATTR. To manage these properly, each ATTR subtype also needs constraints: PSI declarations for the units and number type (like integer BigNums), plus 6 numbers bounding its 5 scalar regions. With a little computation, a proper linguistic modifier can then be found by a CTM application for any given scalar value of an ATTR subtype. The 2 outermost boundaries provide for its quantitative validation.

The MANR subtypes need similar handling to ATTR, but expect a Descriptor linguistically more like an adverb, whose domain must be a Process or Situation. Some MANR sub-types like "speed", could reuse the same MEAS infrastructure. To handle other MANR subtypes well, such as "sloppily" or "creatively" just require a PSI asking "On a scale of 1 to 5, how much ...?".

The bottom line: each PROPERTY type in CTM can be formalized easily, but in all cases somebody must spec the related rules in a PSI, then expand the type topic itself with PROPERTY values which fully define the Range constraints on its instances. That is all CTM requires. The rest is left to each CTM application, or to utilities within constraint languages such as WORDS or TMCL.