RE: [xtm-wg] Comments on XTM Spec 1.0

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

I'm happy with most of what Kal says here in response to Holger.

Just two points:

1) I must respond to. Holger asks (referring to my proposed amendment to the
content model of <association>) why <association> needs both
<associationSpec> and <instanceOf> subelements.

The answer is simple: "backward compatibility with the 'Core Deliverables'
document of 4 December", where the <association> element has an <instanceOf>
subelement.

Kal is right that I have added the * to the <instanceOf> subelement in the
content model because what this means is that the Topic that is the
Association is an instance of a certain class, and it may be an instance of
many classes.

Having said all that, and in line with my view that there *is no
requirement* for backwards compatibility with the Core Deliverables
document, I would be very happy to drop the <instanceOf> subelement on
<association> and rely on the <topicRef> subelement to point to a <topic>
element that has any relevant <instanceOf> subelements in *its* content.

2) I do think we need to say something clear about reification. I hope to
bring to the Paris meeting (or, if things go well, send it out to the list
beforehand) a second draft of the "Mapping of XTM syntax to the Conceptual
Model" in which I attempt a clarification of:
- the meaning of "reification", in the conceptual model and in the syntax
- the respective meanings of  <topicRef>, <resourceRef> and
<subjectIndicatorRef>
- the criteria that determine when multiple elements represent the same
Topic (aka the "merging rules").

Best regards

Daniel


Daniel


-----Original Message-----
From: Kal Ahmed [mailto:kal@ontopia.net]
Sent: 12 January 2001 12:51
To: xtm-wg@egroups.com
Subject: RE: [xtm-wg] Comments on XTM Spec 1.0



Hans Holger Rath wrote:

> =====================
> Wording:
> =====================
>
[snip]
> REMARK 2: If I get the "Notes" right (after five times reading)
> <occurrence> could use <topicRef> to point to an topic as
> occurrence and then some constraints apply. My point is, that
> the content model does not allow <topicRef> as subelement of
> <occurrence>. Is the model from or is the wording wrong?
>

My comment is 'thank goodness there isn't a <topicRef> there' ! Why should
an arbitrary occurrence cause a merge ? Surely at most I would be creating
an implict association between the two topics. But let's not speculate any
further on that - I can use resourceRef to point to a topic and it has no
semantics above and beyond being a resource which provides information
relevant to the containing topic. And that's all I want.

> =====================
> Content Model:
> =====================
>
> 4.6.2 <subjectIdentity> Element
>
> REMARK: If we really do not want to have a mixture
> of resourceRef with topicRef and/or subjectIndicatorRef
> we should make this crystal clear by the content model.
> I do not know what we want. I was just a little bit
> confused by the "Issue: ..." comment.
>

Despite the potential confusion, I want to be able to have topics with both
resourceRef and topicRef and/or subjectIndicatorRef - it enables me to
assert that the resource referenced by the subjectIndicatorRef has been
determined to indicate the subject found at the URL specified by the
resourceRef and can be used to force controlled, subject-based merging.
The processing exception raised if such a merge creates a topic with two
resourceRefs is acceptable as it is a robust way of determinig a mismatch in
the subjects perceived by two entities from the same subjectIndicatorRef.
> ...old...
[snip]

> =====================
> Concept and Content Model:
> =====================
>
> 4.8.1 <association> Element
>
> REMARK 1: A couple of people - and I am one of them - stated
> that association should have a name (<baseName>) and occurrences
> (<occurrence>) as child elements. The answer to that request
> was: reification. The is an appropriate solution but it is
> nowhere described in the XTM spec. There is
> http://www.doctypes.org/xtm/syntax/reification-syntax.html
> but *the* solution is not marked in the document.
> => Please add information about reification to the spec with
> an example that shows how names and occurrences can be "assigned"
> to associations.
>

My feeling is that keeping the description of reification out of the XTM 1.0
spec serves to keep it to a manageable length and that later issuing the
reification solution as a further Topicmaps.Org output would seem reasonable
to me.

> REMARK 3: Daniel Rivers-Moore posted 2001/01/08 a proposal
> for a new association content model which is complient to
> the processing model. I copy it here for easier reference.
>
> <!-- association: Topic Association -->
> <!ELEMENT association (associationSpec? , instanceOf* , scope? ,
> (member+ | role+ )*)>
> <!ATTLIST association id ID #REQUIRED >
>
> <!-- associationSpec: Points to a Topic Serving as an Association
> Template -->
> <!ELEMENT associationSpec (topicRef | subjectIndicatorRef )>
> <!ATTLIST associationSpec id ID #IMPLIED >
>
> <!-- member: Member in Topic Association -->
> <!ELEMENT member (roleSpec? , (topicRef | resourceRef |
> subjectIndicatorRef )+ )>
> <!ATTLIST member id ID #IMPLIED >
>
> <!-- role: Role in Topic Association -->
> <!ELEMENT role (roleSpec? , (topicRef | resourceRef |
> subjectIndicatorRef ) , player* )>
> <!ATTLIST role id ID #IMPLIED >
>
> <!-- player: Player of Role in Topic Association -->
> <!ELEMENT player (topicRef | resourceRef | subjectIndicatorRef )>
> <!ATTLIST player id ID #IMPLIED >
>
>
> First, a syntactical point:
> <!ELEMENT association (associationSpec? , instanceOf* , scope? ,
> (member+ | role+ )*)>
> should be written as
> <!ELEMENT association (associationSpec? , instanceOf* , scope? ,
> (member* | role* ))>
> or as
> <!ELEMENT association (associationSpec? , instanceOf* , scope? ,
> (member | role )*)>
>

I agree

>
> Second, why do we need <member> and <role>?
> Just for backwards compatibility? If yes, I
> recommend to define a clear model instead
> of looking for backwards compatibility and
> ending up with a messy model.
>

I agree with this too.

>
> Third, can someone explain why <association>
> needs both <associationSpec> and <instanceOf>?
> Is this just for backwards compatibility reasons?
> If not, could someone provide an example, please.
> Also if not: Will it make sense that an assoc template
> is an <instanceOf> a class? Especially if the
> derived assoc is also an <instanceOf> a class.
> Do we have to define some constraints that have
> to be fulfilled by the classes (e.g., derived
> has to refer the same class as the template
> or one of its subclasses? Or ???).
>

I would note here that Daniel's content model also has instanceOf* which is
not compatible with XTM's instanceOf? I assume that associationSpec is
allowed to point to the <association> which provides the template for this
<association> and that <instanceOf> refers to the <topic>(s) which define
the class of associations to which this <association> belongs and that these
(template and class of association) are separate. I also assume that Daniel
is using instanceOf* rather than XTM's instanceOf? because the CM defines an
Association as a subclass of Topic and there is no reason to constrain the
type property for the Association subclass. But this raises the question of
the meaning of an association which is an instance of multiple classes.

Cheers,

Kal


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