[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xtm-wg] RE: Mapping document
Luis I don't know why you had trouble opening the attached HTML file. Here it is inline. I've edited the TITLE element to match the full title more closely, and added missing end tags for the BODY and HTML elements (maybe that was why you had a problem). Daniel <HTML> <HEAD> <TITLE>XTM Conceptual Model to Sytax Mapping</TITLE> </HEAD> <BODY> <h1><a name="introduction"/>Mappings between the XTM Conceptual Model and the XTM Interchange Syntax</h2> <h2>Nature of the Mappings</h3> <p>The XTM Conceptual Model and its Interchange Syntax do not map to one another directly, for a number of reasons. First, the Conceptual Model describes certain objects that are not represented directly in the syntax at all. Second, there are certain objects in the Conceptual Model that may be represented in more than one way in the syntax. Third, the syntax contains some constructs that map to specific association templates that conform to the Conceptual Model but do not form part of it.</p> <p>We begin by looking at each item in the Conceptual Model and show which parts of the syntax it corresponds to, if any, and in what way. The syntactic items thus identified will consititue a minimal syntax, which is complete in itself, and could be used to represent any topic map at all, though it would not be optimally concise or readable.</p> <p>Then we identify syntactic constructs that represent extensions to the minimal syntax through the use of association templates. For each of these, we shall provide equivalent syntactic representations of them using the minimal syntax.</p> <p>Finally, we identify syntactic constructs that represent shorter and more readable forms for certain structures, but add no additional semantics in their own right. For these too, we shall provide equivalent syntactic representations using the minimal syntax.</p> <p>Based on these mappings, it will be possible to map any topic map expressed in XTM syntax can back to the Conceptual Model, though this may be a two-stage process, passing through the minimal syntax as a first stage, then using the mapping from the minimal syntax to the Conceptual Model. The mapping may also involve the invocation of one or more of public association temptes included within the XTM specification.</p> <h3>Mapping the Conceptual Model to the Minimal Syntax</h3> <p>There are several ways in which objects described by the Conceptual Model may relate to constructs in the XTM Interchange Syntax:<ul> <li>In some cases, a syntactic construct <i>IS</i> the object described by the model.</li> <li>In some cases, a syntactic construct <i>REFERENCES</i> the object described by the model through the conventions of URI syntax.</li> <li>In some cases, a syntactic construct <i>REPRESENTS</i> the object described by the model.</li> <li>In some cases, the object described has no direct correspondence in the syntax at all, but instead is <i>INDICATED</i> to a human mind by a Resource.</li> </ul></p> <p>We shall go through the constructs of the Conceptual Model in the order in which they are presented in the XTM specification, and will state for each one whether it has a corresponding syntactic construct, and what the nature of the correspondence is.</p> <h3>Resource</h4> <p>There are two kinds of mapping from XTM syntax to the Resource object in the Conceptual Model: <ol><li>The value of the xlink:href attribute of a <resourceRef>, <subjectIndicatorRef> or <topicRef> element <i>REFERENCES</i> a Resource.</li> <li>a <resourceData> element <i>IS</i> a Resource.</li> </ol> The differences between these three contexts for the xlink:href attribute correspond to different ways the Resource my relate to other aspects of the model, as we shall see in the sections that follow.</p> <h4>Subject</h4> <p>The Subject may be an Addressable Subject or a Non-addressable Subject. These two cases are dealt with below.</p> <h4>Addressable Subject</h4> <p>If the Subject is an Addressable Subject, it <i>IS</i> is the Resource that is <i>REFERENCED</i> by the xlink:href attribute of the <resourceRef> subelement of a <subjectIdentity> element</p> <h4>Non-addressable Subject</h4> <p>If the Subject is a Non-addressable Subject, it is <i>INDICATED</i> by the Resource that is <i>REFERENCED</i> by the xlink:href attribute of the <subjectIndicatorRef> subelement of a <subjectIdentity> element</p> <h4>Topic</h4> <p>A <topic> element <i>REPRESENTS</i> a Topic.</p> <p>Note that the Conceptual Model describes the following subtypes of Topic: <ul><li>Association</li><li>Role</li></ul></p> <p>An <association> element <i>REPRESENTS</i> a Topic that is an Association.</p> <p>An <role> element <i>REPRESENTS</i> a Topic that is a Role.</p> <p><font color="#ff0000"><b>Note:</b> The <role> element is not present in the syntax presented in Washington DC. The <member> construct included in that DTD is inadequate to cover the structure of the Conceptual Model, which requires a Topic that is the Role, zero or more Topics that are the players of the Role, and optionally a topic that is a Role in an Association Template, which provides constraints on the players of the Role. The content model for <member> has only two places for references to one or more Topics, and so cannot capture the Role, the players of the Role and the Role constraints. Also, the <association> element requires an optional <associationSpec> element to reference an association template, and the <instanceOf> subelement of <association> should be repeatable. The discussion here is therefore based on the following declarations, proposed as replacements for the <association> and <member> declarations of the 4 December 2000 DTD. Note that these declarations do preserve backward compatibility with that DTD. <font face="Courier" size="-1"><br><br> <!-- association: Topic Association --><br> <!ELEMENT association (associationSpec? , instanceOf* , scope? , (member+ | role+ )*)><br> <!ATTLIST association id ID #REQUIRED ><br><br> <!-- associationSpec: Points to a Topic Serving as an Association Template --><br> <!ELEMENT associationSpec (topicRef | subjectIndicatorRef )><br> <!ATTLIST associationSpec id ID #IMPLIED ><br><br> <!-- member: Member in Topic Association --><br> <!ELEMENT member (roleSpec? , (topicRef | resourceRef | subjectIndicatorRef )+ )><br> <!ATTLIST member id ID #IMPLIED ><br><br> <!-- role: Role in Topic Association --><br> <!ELEMENT role (roleSpec? , (topicRef | resourceRef | subjectIndicatorRef ) , player* )><br> <!ATTLIST role id ID #IMPLIED ><br><br> <!-- player: Player of Role in Topic Association --><br> <!ELEMENT player (topicRef | resourceRef | subjectIndicatorRef )><br> <!ATTLIST player id ID #IMPLIED ></font> </font></p> <h4>Subject Descriptor</h4> <p>The xlink:href attribute of a <subjectIndicator> element <i>REFERENCES</i> a Resource that <i>IS</i> a Subject Descriptor that <i>INDICATES</i> the Subject of the Topic that is <i>REPRESENTED</i> by the parent of the <subjectIndicator> element.</p> <h4>Topic Map</h4> <p>A <topicMap> element <i>REPRESENTS</i> a Topic Map.</p> <h4>Topic Set</h4> <p>The <scope> subelement of an <association> or <baseName> element <i>REPRESENTS</i> the Topic Set that <i>IS</i> the Scope of the Asssociation or Base Name <i>REPRESENTED</i> by the parent element</p> <p>In general, a Topic Set <i>IS</i> the set of Topics that are <i>REPRESENTED</i> by any set of <topic>, <association> and/or <role> elements, and/or <i>REFERENCED</i> by any set of xlink:href attributes on <topicRef> and/or <subjectIndicatorRef> elements.</p> <h4>Scope</h4> <p>A <scope> element <i>REPRESENTS</i> a Scope.</p> <h4>Base Name</h4> <p>A <baseName> element <i>REPRESENTS</i> a Base Name.</p> <h4>String</h4> <p>The content of the <baseNameString> subelement of a <baseName> element <i>IS</i> the String assigned within the Base Name relationship <i>REPRESENTED</i> by that <baseName> element to the Topic <i>REPRESENTED</i> by its parent element within the Scope <i>REPRESENTED</i> by the <scope> element that is the <baseNameString> element's previous sibling.</p> <h4>Association</h4> <p>An <association> element <i>REPRESENTS</i> an Association (and, has already been said, the Topic that <i>IS</i> that Association).</p> <h4>Role</h4> <p>A <role> element <i>REPRESENTS</i> a Role (and, has already been said, the Topic that <i>IS</i> that Role).</p> <h4>Player of Role</h4> <p>A <player> element <i>REPRESENTS</i> a Topic that plays the Role <i>REPRESENTED</i> by the <role> element that is its parent.</p> <h4>Association Template</h4> <p>The xml:link attribute of the <topicRef> subelement of an <associationSpec> element <i>REFERENCES</i> an <association> element that <i>REPRESENTS</i> an Association that is the template for the Association <i>REPRESENTED</i> by the <association> element that is the parent of the <associationSpec> element.</p> <font color="#ff0000"><p><b>Note:</b> To allow this to work, the restriction stated in the DTD of 4 December 2000 that a <topicRef> element can only reference a <topic> element, needs to be relaxed. It also needs to be allowed to reference an element whose element type is represents a subtype of Topic.</p></font> <h4>Role Constraints</h4> <p>The xml:link attribute of the <topicRef> subelement of a <roleSpec> element <i>REFERENCES</i> a <role> element that <i>REPRESENTS</i> a Role in a template Association that provides the role constraints for the Role <i>REPRESENTED</i> by the <role> element that is the parent of the <roleSpec> element.</p> <font color="#ff0000"><p><b>Note:</b> To allow this to work, the restriction stated in the DTD of 4 December 2000 that a <topicRef> element can only reference a <topic> element, needs to be relaxed. It also needs to be allowed to reference an element whose element type is represents a subtype of Topic.</p> <p>It has been argued that the <subjectIndicatorRef> element can be used instead of the <topicRef> element for this purpose, since the Subject <i>indicated by</i> an XTM element is always the Subject of the topic <i>represented by</i> that element, and therefore the Topics themselves are the same. The problem with this approach is that it requires the system to resolve the xlink:href to find a Resource, then ascertain whether that Resource is or is not an element in an XTM document, in order to know how to process it. It would be far more efficient, and consistent with the previous decision that things that are different in kind should be expressed through different syntax, to state that the <topicRef> element should always be used to reference an XTM element that directly represents the relevant Topic, and to use the <subjectIndicatorRef> element when the Topic is being referenced indirectly, by identifying its Subject through a Subject Descriptor.</p> <p>If this reasoning is sound, there are two consequences:<ul> <li>the restriction on the element type of the referent of <topicRef> should be relaxed to allow any element to be referenced whose element type represents a subtype of Topic</li> <li><subjectIndicatorRef should be removed from the content models of <roleSpec> and <associationSpec>.</li></ul></p> </font> <h3>Syntactic Constructs that are shorthand for Associations derived from specific Association Templates</h3> <p><b>Note:</b> The following parts of this document are in note form. They need to be expanded to show specific syntax examples.</p> <h4>instanceOf</h4> <p>The <instanceOf> element is shorthand for an <association> element whose <associationSpec> subelement references the public <b>Class Instance Association Template</b>, containing a <role> element whose <roleSpec> subelement references the public <b>Class Role</b> topic and whose <player> subelement references the topic identified by the <instanceOf> element itself, and a second <role> element whose <roleSpec> subelement references the public <b>Instance Role</b> topic and whose <player> subelement references the parent of the <instanceOf> element.</p> <font color="#ff0000"><p>Example needed here</p></font> <h4>occurrence</h4> <p>The <occurrence> element is shorthand for an <association> element whose <associationSpec> subelement references the public <b>Topic Occurrence Association Template</b>, containing a <role> element whose <roleSpec> subelement references the public <b>Occurrence Role</b> topic and whose <player> subelement references the topic identified by the <occurrence> element itself, and a second <role> element whose <roleSpec> subelement references the public <b>Topic Role</b> topic and whose <player> subelement references the parent of the <occurrence> element.</p> <font color="#ff0000"><p>Example needed here</p></font> <h4>variant, variantName and parameters</h4> <font color="#ff0000"><p>The exact structures for which <variant>, <variantName> and <parameters> are syntactic shorthand needs to be specified.</p></font> <h3>Syntactic Constructs that are shorthand for other XTM Constructs</h3> <p><b>Note:</b> The following parts of this document are in note form. They need to be expanded to show specific syntax examples.</p> <h4>subjectIndicatorRef</h4> <p>The <subjectIndicatorRef> subelement of any element other than a <topic> element is syntactic shorthand for a <topicRef> element pointing to a <topic> element that itself has that <subjectIndicatorRef> as a subelement of its <subjectIdentity> subelement.</p> <h4>resourceRef</h4> <p>The <resourceRef> subelement of any element other than a <topic> element is syntactic shorthand for a <topicRef> element pointing to a <topic> element that itself has that <resourceRef> as a subelement of its <subjectIdentity> subelement.</p> <font color="#ff0000"><p><b>Note:</b> It is difficult to see how what a <resourceRef> subelement on <scope> would mean. What does it mean to be in the scope of a resource? Ditto for a <resourceRef> subelement on <mergeMap>, since if a <resourceRef> makes no sense on a <scope>, it makes no sense to add it to a <scope> when merging.</p></font> <h4>member</h4> <p>The <member> element is syntactic shorthand for a <role> element and its <player> subelement. It can only be used when there is no need to specify the Topic that is the Role itself.</p> <font color="#ff0000"><p><b>Note:</b> This is only included to ensure backward compatibility with topic maps that were created on the basis of the Core Deliverables presented on 4 December 2000 in Washington. If the requirement for such compatibility is dropped, then the <member> element can be droped also.</p></font> <h4>mergeMap</h4> <p>The <mergeMap> elemente is syntactic shorthand for the explicit inclusion of all the subelements of the <topicMap> element referenced by its xlink:href attribute, with the addition to every <scope> element of the all the subelements of the <mergeMap> element.</p> </BODY> </HTML> -----Original Message----- From: Luis J. Martinez [mailto:luisjm@luisjm.com] Sent: 10 January 2001 01:56 To: Daniel Rivers-Moore Subject: Mapping document Daniel, I am not sure if just me, but I can not read the document you attached to your message in egroups about mapping from syntax to model. Could you email me the document when you get a chance? If is not just me, then you might need to re-post the message. I don't know what is going on in there with egroups. Luis 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