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

[Daniel Rivers-Moore <daniel.rivers-moore@rivcom.com>]

Thanks for these comments,  Kal.

Responses:

1) Elimination of <member>

I agree that it would be preferable to drop the <member> element, and
replace it with the <role> element as defined in the "Note" in the mapping
document. The inclusion of <member> for backward compatibility purposes
becomes unnecessary if we accept (as I believe we should) that the status of
the "Core Deliverables" is that of a draft rather than approved
specification. This brings us to the question of "process" that Steve Pepper
raised. As Steve Pepper says, this is something that must be resolved at our
forthcoming meeting in Paris. I have my views, which I shall write
separately to the participating members only (hearing the plea from some
members of this list that we try to segregate processs issues from technical
ones).

2) Content model of <role>

Kal asks about the (topicRef | resourceRef | subjectIndicatorRef ) group in
the role element. This is a pointer to the Topic that is the role. I gave an
example in  a response to Holger, using the association "Daniel employed by
RivCom as Director of New Technologies). The Role Topics are distinct from
the Player Topics, as follows:

Role: Daniel's job-function at RivCom - Player: Director of New Technologies
Role: Daniel's employer as Director of New Technologies - Player: RivCom
Role: RivCom's Director of New Technologies - Player: Daniel

A <topicRef> subelement of the <role> element will have an xlink:href
pointer to an element representing the Role Topic as described in the
left-hand list above. A <topicRef> subelement of the <player> element will
point to an element representing the Player Topic as described in the
right-hand list above. The complete structure, including the corresponding
template <association> element, is included in my message "RE: [xtm-wg]
Modified diagram for Association Template" of Tuesday 9 January (the one in
response to Holger, not the one in response to Chris).

In fact, I believe we only need the <topicRef> subelement of <role>, and
that the <resourceRef> and <subjectIndicatorRef> would be better dropped.
This applies to *all* cases where this grouping occurs. I believe it would
be a clarification to have <resourceRef> and <subjectIndicatorRef> *only* on
<topic> elements, and for other elements that represents subtypes of Topic
always to use a <topicRef> element to point to a <topic> element with which
they are identical, and to have that <topic> element contain the
<subjectIndicatorRef> that points to a Subject Descriptor resource. In my
view, the clean options are *either* to allow all element types that
represent subtypes of Topic to have *all* the subelements of <topic>,
including <baseName>, <instanceOf>, <occurrence> etc, *or* for them *only*
to have <topicRef> and the special subelements that are unique to them. The
former option would retain "backward compatibility", but I am coming to the
view that the latter might be clearer and easier to understand and avoid
errors.

3) <subjectIndicatorRef>

In your first paragraph, beginning "I agree with Daniel's assertion", I
think you have understood me well, and I agree with your additional remarks.

In your second paragraph, beginning "Where I have some reservations", you
make an interesting suggestion. I don't think there is necessarily an
overloading of <topicRef>. The <topicRef> element *always* points at another
element that represents the same Topic as the Topic represented by the
element that contains it. Since Association and Role are subtypes of Topic,
<association> elements and <role> elements represent Topics and can be the
targets of <topicRef> pointers without there being an overloading of the
meaning of the <topicRef> element. If we consider that the <rolesSpec>
element itself represents the Topic that is the Role in the association
template to which the <topicRef> pointer points, then we are consistent in
our usage and there is still no overloading. However, if we consider the
<roleSpec> and <associationSpec> elements to be *just* pointers, then yes,
we could make them into xlinks in their own right. I agree that this could
be preferable, as it emphasises the special nature of these two pointers.


4) <resourceRef>

I agree with everything you say here, including the fact that the question
about whether the scenario you describe should constitute a reportable error
is an interesting question. I have not been concerning myself with what
should or should not constitute a reportable error. For me, this is part of
the very large question of what constitutes a conformant application. I have
been concerned more with the meaning of the information, and have left the
very interesting question of conformance to one side, for now.

Best regards

Daniel


-----Original Message-----
From: Kal Ahmed [mailto:kal@ontopia.net]
Sent: 15 January 2001 10:03
To: xtm-wg@egroups.com
Subject: RE: [xtm-wg] Mapping of XTM syntax to the Conceptual Model


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

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

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