RE: [xtm-wg] Mapping of XTM syntax to the Conceptual Model

["Kal Ahmed" <kal@ontopia.net>]

First a general comment: It cannot be underestimated how important it is
that the mapping between the CM and XTM is well understood and complete and
how equally important it is that the mapping between the CM and ISO 13250
is. Without such a mapping, be prepared for applications which support ISO
13250 at the expense of true XTM support and vice-versa. So I must start
with a thank you to Daniel for this document.

I do have some queries and comments regarding this document.

Quotes from Daniel's mapping document are preceeded with a > at the start of
the line.


> <!-- association: Topic Association -->
> <!ELEMENT association (associationSpec? , instanceOf* , scope? , (member+
| role+ )*)>
> <!ATTLIST association id ID #REQUIRED >
and later:
> 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.
>
> Note: 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.

I would be in favour of dropping <member> from the content model of
<association> and from the DTD. <role> performs the job admirably.

However I do have a question about the content model of role:

> <!ELEMENT role (roleSpec? , (topicRef | resourceRef |
subjectIndicatorRef ) , player* )>

What is the (topicRef | resourceRef | subjectIndicatorRef ) part of the
content model refering to ? Is it a shorthand to prevent having to write a
nested <player> element ? If so, I would ask for it to be dropped from the
content model of <role>.

Finally, I would like to note that I have made some additional comments with
regards to the element definitions presented at this point in the proposal
in response to Holger's comments (email subject: RE: [xtm-wg] Comments on
XTM Spec 1.0

Next, with respect to the <topicRef> sub element Daniel says:

>Note: 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.
>
>It has been argued that the <subjectIndicatorRef> element can be used
instead of the <topicRef>
>element for this purpose, since the Subject indicated by an XTM element is
always the Subject
>of the topic represented by 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.

I agree with Daniel's assertion that <associationSpec> and <roleSpec> need
something more tightly defined than <subjectIndicatorRef> to locate their
respective template objects or at the very least require that the reftype of
the <subjectIndicatorRef> be suitably constrained for those elements. The
current XTM specification requires that a conformant application chase down
every subjectIndicatorRef to determine whether or not it is a <topic> - a
considerable overhead in a web-based environment. The <topicRef> element
already provides the semantics that are covered by this 'special case' of
subjectIndicatorRef and it seems to me that if I use a <topicRef> I want the
resource indicated by that element to be located and treated as a topic (and
perhaps merged with the topic which references it). If I use a
<subjectIndicatorRef> I *do not* want the resource I point to to ever be
merged with the topic from which it is referenced regardless of whether or
not it is a <topic> element.
Where I have some reservations however is in the 'overloading' of <topicRef>
to point to <association> and <role> elements. I understand the rationale
from the CM perspective, but from a syntax perspective I would much rather
that roleSpec and associationSpec elements by simple XLinks in their own
right with their own specific reftypes. i.e.

<!ATTLIST roleSpec
  id ID #IMPLIED
  xlink:type NMTOKEN  #FIXED 'simple'
  xlink:href CDATA    #REQUIRED>

I feel that this is less verbose and computationally cleaner than
overloading <topicRef>.

With respect to resourceRef, Daniel writes:

> 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.
>
> Note: 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.

I had assumed that <resourceRef> in a <scope> meant more or less exactly as
described - and that the 'implicit' topic generated as a result of
processing the resourceRef may or may not merge with an existing topic by
the subject-based merging rule. My understanding is that the reason that
<resourceRef> is not a child of other 'topic identifying' elements such as
<instanceOf> is that it makes no sense to use a topic who's subject is a
resource for the purposes of specifying a class of topic map constructs.
However, this raises the question of whether or not it should be a
reportable error for <instanceOf> to refer to a topic (e.g. via <topicRef>)
which has a subject constituting resource.

Cheers,

Kal

> -----Original Message-----
> From: Daniel Rivers-Moore [mailto:daniel.rivers-moore@rivcom.com]
> Sent: 08 January 2001 19:42
> To: 'xtm-wg@egroups.com'
> Subject: [xtm-wg] Mapping of XTM syntax to the Conceptual Model
>
>
> I have now prepared a first draft of the mapping from XTM syntax to the
> Conceptual Model.
>
> It is attached as an htm file.
>
>  <<20010108.drm.ConceptualModelToSyntaxMapping.htm>>
>
> The mapping raises a number of issues, some of which I had
> already raised in
> previous messages to this list. They can easily be identified within the
> document when it is displayed by the browser, as they will appear in red
> type.
>
> After review of this draft, and any amendments to it and/or the DTD that
> result from that review, it would be important to incorporate into it a
> statement of the topic merging rules, expressed simply in terms
> of what sets
> of elements map to a single Topic, rather than in terms of processing - in
> other words a declarative rather than a procedural statement of
> the merging
> rules.
>
> Comments please.
>
> Daniel
>
>
>
> To Post a message, send it to:   xtm-wg@eGroups.com
>
> To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
>


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

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