[xtm-wg] [xtm-iss/xtm-cms] suggesting Properties for XTM ( inline facet

Hi All,

I want to propose adding a "property" element to the XTM infoset:

It should be considered "second-class" (or even "third-class")
This is a draft proposal, I did not have enough time thinking it over,
But I do want to submit it to your attention prior to the London meeting.

I hope you will find the proposal interesting.

<!ELEMENT property ( property* | #PCDATA ) >
<!ATTLIST property
   type CDATA #IMPLIED
   scope CDATA #IMPLIED
   proprl CDATA #IMPLIED
>

Property element should be added to the children content of all XTM elements:
topic, assoc, assocrl, occurrl, topname and property itself.

Definitions:

The property is the scope within which the property value is relevant to the containing topic map resource. The set of themes (topics) that constitute the scope is specified via the optional "scope" (scope) attribute.

(The optional proprl attribute can be used to provide a mnemonic name for the occurrence role. If the proprl attribute is not specified, the generic identifier is regarded as the mnemonic name of the occurrence role. ???)

The optional "property type" (type) attribute references a single topic link. The subject of the referenced topic link is a class of properties of which the property expressed by the property element is an instance. The class-instance relationship established between the subject of the referenced topic link and the referencing property element could alternatively be established by making the property element an occurrence of the referenced topic link, within the scope of "property element" whose meaning is that the property is an instance of the subject of the topic link.
If the "property type" (type) attribute is specified, and if the topic referenced by the type attribute has a name characteristic that lies within a scope that is appropriate to the topic map user's context, the referenced topic's name characteristic is used to characterize the property for the user. (Otherwise, the value of the proprl attribute is used to characterize the occurrence role for the user???).

(Question marks ??? are related to the issue of weather we need to add optional proprl attribute)

[Steve Pepper]
> But to use RDF instead of facets would mean to lose the connection between the semantic network layer

> and the metadata, which today is provided for by the fact that facet types and facet value types are topics.

Introduction of "properties" into XTM will provide an alternative to "facets" mechanism for defining metadata on a topic map without loosing connection between the semantic network layer and the metadata. Properties can be considered being an in-line facet.

Proposed XTM properties can be used to define probability weights on association roles, prescription details, max/min constraints in XTM templates, etc. See example bellow.
A standard way for expressing properties of resources in topic maps is obviously beneficial.

In attempt to answer the Shakespearean question:
Should properties be part of XTM specification or should it be a part of some
external standard?
Proposed properties in my view provide an interesting compromise. XTM properties being a second-class (or third-class :-)) objects can not be mistaken with other XTM constructs and yet being they provide pure topic-map ways to define property types and datatypes.
Property sub-classing can be expressed by means of sub-classing supertype-topics referenced by property type attributes.

Property datatype can be expressed by means of scope
So, something can weight 10 in the scope of "kg" and 20 in the scope of "pound".

Example:

Interesting:
if we are allowed to use architectural forms then the above fragment can be simplified to:

Issue:
Can property values be remote resources? I think not. In this case the property should be upgraded to an occurrence role and the resource on which the property is defined should be upgraded to a topic.

Side issue for the scope algebra:
Constraint that a single scope can not contains both "kg" and "pounds" themes can be enforced through inheritance.
For example, the rule can say: no more then one "weight unit" theme per scope. Then topics "kg", "pound", "gram" and "oz" inherit from "weight unit" topic by means of types association.

Thanks,

Nikita Ogievetsky
http://www.cogx.com
nogievet@cogx.com
(917)406-8734
Consultant in XML/XSLT/Xlink/TopicMaps

topicmaps-comment message