[topicmapmail] Choosing between association and reification
G. Ken Holman
gkholman@CraneSoftwrights.com
Sat, 05 Apr 2003 12:47:17 -0500
At 2003-04-05 16:43 +0100, Kal Ahmed wrote:
>My understanding of the different approaches you have used are that (A)
>says "There is some sort of relationship between joinery, ubl-despadv
>and a the UBL Despatch Advice formatting specification, where joinery
>plays the role of the scenario, ubl-despadv plays the role of the
>document type and the formatting specification UBL Despatch Advice plays
>the role of the formatting specification."
Right ... there are three scenarios, and in the Joinery (a cabinetmaker's
shop) scenario four of the seven UBL document types are used. In another
scenario a different set of four document types is used. In the third
scenario all seven document types are used. A formatting specification for
each document type for each scenario describes how instances of that
document type are rendered in that scenario.
>(B) says that joinery and ubl-despadv are related by a "formatting
>specification" relationship, and that the relationship itself is a thing
>in its own right with a date and a related document.
Ummmmmmm ... isn't that the same thing?
>My feeling is that (A) is somewhat confused as there is no sense that
>the formatting specification is the "lead" role in the association -
>this is based on my assumption that the formatting specification is a
>document which says something about the relationship between a scenario
>and a document type.
Not about "the relationship", but that "in the Joinery scenario, for the
Despatch Advice document type, the formatting specification describes how
instances are to be rendered". Or am I missing that that is, indeed, "a
relationship"?
>If it is the case that the formatting specification defines the
>relationship between the scenario "joinery" and the doctype
>"ubl-despadv", then reification would be a better approach,
Perhaps what I'm missing is the nuance expressed between "(x) defines the
relationship between (y) and (z)" versus "for a given (y) and (z), then (x)
applies".
>and I would
>make the document UBL_FS_0p70_DespatchAdvice.html an occurrence of the
>reified association as you have done. The date, however is really meta
>data about the HTML document.
Fine .....
>To model that in the topic map, I would
>add another topic that reifies the HTML document itself and put the meta
>data there.
Would the meta data occurrence then read as follows?
<topic id="fs-jda-t">
<instanceOf>
<topicRef xlink:href="#formspec"/>
</instanceOf>
<occurrence>
<instanceOf>
<topicRef xlink:href="#filename"/>
</instanceOf>
<scope>
<topicRef xlink:href="#ubl-0p70"/>
</scope>
<resourceRef xlink:href="#fsdesadvhtml"/>
</occurrence>
</topic>
<topic id="fsdesadvhtml">
<subjectIdentity>
<resourceRef>UBL_FS_0p70_DespatchAdvice.html</resourceRef>
</subjectIdentity>
<occurrence>
<instanceOf>
<topicRef xlink:href="#date"/>
</instanceOf>
<resourceData>2003-01-27</resourceData>
</occurrence>
</topic>
>So this would mean that you end up with a bunch of associations between
>scenarios and their related document type(s); each of which may have
>(assuming it is reified) an associated resource which is the formatting
>specification. Each formatting specification is itself reified to
>specify the date on which it was last modified.
This brings up a question in my mind of "reification" versus
"inheritance". I note in both SAM-20030309 and CXTM-20030404 that topics
don't have types any more ... there is no instanceOf child of topic.
I think I recall instanceOf was a syntactic variant of a class/instance
association ... are we expected in CXTM and SAM to only represent
class/instance as an association and no longer use instanceOf? If so, why
was it removed from topic but not removed from association? I guess it
could also be removed from base name and occurrence by giving each of base
name and occurrence an ID attribute, reifying the construct through the ID
attribute, and then creating the association with the reifying topic. It
seems asymmetrical to me that the instanceOf "short cut" isn't available on
topics.
In my reification above I indicate the reification topic "is a formatting
specification" through the <instanceOf> ... but I wouldn't be allowed to do
that in CXTM ... I think would need to create another association to
indicate the reified topic is a formatting specification.
I guess I'll wait to see some CXTM examples. I'm finding that I'm quite
daunted approaching writing a topic map from scratch just from reading the
specifications. Are there any Topic Map cookbooks around saying "to do
this, model it this way"?
>By doing this, you can separate the maintenance of meta data from the
>maintenance of the associations between scenario and doctype. In fact,
>you could even make these two separate topic maps - perhaps using XSLT
>or connection to the document repository to provide up-to-date meta data
>about the documents.
Interesting! Would that be instantiated as follows?
UBL FS Topic Map:
<topic id="fs-jda-t">
<instanceOf>
<topicRef xlink:href="#formspec"/>
</instanceOf>
<occurrence>
<instanceOf>
<topicRef xlink:href="#filename"/>
</instanceOf>
<scope>
<topicRef xlink:href="#ubl-0p70"/>
</scope>
<resourceRef xlink:href="#fsdesadvhtml"/>
</occurrence>
</topic>
<topic id="fsdesadvhtml">
<subjectIdentity>
<resourceRef>UBL_FS_0p70_DespatchAdvice.html</resourceRef>
</subjectIdentity>
<occurrence>
<instanceOf>
<topicRef xlink:href="#date"/>
</instanceOf>
<resourceData>2003-01-27</resourceData>
</occurrence>
</topic>
Meta data Topic Map:
<topic id="desadv70file">
<subjectIdentity>
<resourceRef>UBL_FS_0p70_DespatchAdvice.html</resourceRef>
</subjectIdentity>
<occurrence>
<instanceOf>
<topicRef xlink:href="#date"/>
</instanceOf>
<resourceData>2003-01-27</resourceData>
</occurrence>
</topic>
Even though the ids are different, the subjects would indicate the same
file. (I think!).
Thanks again for your patience with my questions.
................. Ken
--
Upcoming hands-on courses: Europe (XSLT/XPath): May 5, 2003
- Europe (XSL-FO): May 16, 2003
- (XSLT/XPath and/or XSL-FO) North America: June 16-20, 2003
G. Ken Holman mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
ISBN 0-13-065196-6 Definitive XSLT and XPath
ISBN 0-13-140374-5 Definitive XSL-FO
ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath
ISBN 1-894049-10-1 Practical Formatting Using XSL-FO
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/o/bc