OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xtm-wg] [xtm-iss/xtm-cms] suggesting Properties for XTM ( inline facets )


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 meeting.
I hope you will find it 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:

<topic id="weight" types="property weight-unit"/>
<topic id="no" identity="SSN">
   <topname>.</topname>
   <property type="weight" scope="kg">95</property>
   <property type="height" scope="m">1.98</property>
   <property type="BDAY" scope="gregorian">
      <property type="year" >67</property>
      <property type="month" >10</property>
      <property type="day" >26</property>
   </property>
   <occurs>
      <occurrl type="movie" scope="russian" href="***">
         <property type="duration" scope="sec">23</property>
      </occurrl>
      <occurrl type="mentioned" href="***">
         <property type="rating">97</property>
      </occurrl>
   </occurs>
</topic>
<association type=" scope=">
   <property type="from" scope="yyyy">1995</property>
   <property type="to" scope="yyyy">1999</property>
   <assocrl type="consultant" href="no">
      <property type="time-allocation" scope="%">60</property>
   </assocrl>
   <assocrl type=" project" href="XYZ"/>
</association>

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

<topic id="no" identity="SSN">
   <topname>.</topname>
   <weight scope="kg">95</ weight >
   <height scope="m">1.98</height>
   <BDAY scope="gregorian">
      < year >67</year>
      < month >10</month>
      < day >26</day>
   </ BDAY >
   <occurs>
      <occurrl type="movie" scope="russian" href="***">
         <duration scope="sec">23</ duration >
      </occurrl>
      <occurrl type="mentioned" href="***">
         <rating>97</rating>
      </occurrl>
   </occurs>
</topic>
<association type="" scope="">
   < from scope="yyyy">1995</from>
   < to scope="yyyy">1999</to>
   <assocrl type="consultant" href="no">
      < time-allocation scope="%">60</ time-allocation >
   </assocrl>
   <assocrl type=" project" href="XYZ"/>
</association>

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



-------------------------- eGroups Sponsor -------------------------~-~>
Get FREE long-distance phone calls on Tellme!
Dial 1-800-555-TELL, say "Phone Booth"
http://click.egroups.com/1/9532/4/_/337252/_/971369466/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC