[topicmapmail] Choosing between association and reification

[Kal Ahmed]

On Sat, 2003-04-05 at 18:47, G. Ken Holman wrote:
> 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?
> 
Not exactly, in A, all three topics are tied together in a single
aggregation - I read that as a single statement. In B, there is one
statement (the association), and then there is a statement about that
statement (the topic that reifies the association). In B, the notion
that the Joinery scenario uses the ubl-despadv doctype is a statement in
its own right.


> >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"?
> 

When I originally endorsed the reification approach, it was with the
assumption that the formatting specification was the relationship
between the scenario and the doctype, but I think I was wrong in that
assumption.

OK, so this just goes to show how hard it is to do modelling when you
don't have the full facts about the domain ;-)

Here is how I now think you might now model the domain: 

1) The Joinery scenario uses the ubl-despadv doctype

2) The resource UBL_FS_0p70_DespatchAdvice.html is (or defines) the
formatting specification for the ubl-despadv doctype in the context of
the Joinery scenario. (Note, I presume that there are different
formatting specifications for the same doctype in the other scenarios)

If this is the case, then (1) is a straight-forward binary relationship.
It could be inferred from (2), but I think it should be considered
important enough to be worth making explicit.

(2) could be modelled as the tripartite association that you originally
suggested. (2) could also be modelled as a binary association between
the doctype and the formatting specification scoped by the scenario - I
like this a bit more because I see the scenario as providing a context
for the use of a formatting specification for a specific doctype...is
that correct ?

> >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".
> 

I think that my original concern was that in the tripartite
relationship, there was no notion that doctype and scenario are the two
parameters that govern the use of a specific formatting specification -
the association is an aggregate with no grouping of the roles. Now I can
see that this might actually be what you are trying to communicate.

> >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>
> 

I'm not sure what the theme in the scope is, but other than that, yes.

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

CXTM is only intended to be generated by topic map processors for the
purpose of validation of their processing models. You should use XTM
syntax for the topic maps you create.

The SAM model does not have a [types] property on a topic information
item, but I don't think that there is a proposal on the table to remove
the <instanceOf> element from the <topic> element in the interchange
syntax - though I'll have to go back to the docs to check on that.
Basically the <instanceOf> element is a short-cut for expressing the
class-instance relationship.

Perhaps the SAM editors could comment on why topic information items
have no [types] property when association information items have a
[type] property.

> 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"?
> 

Not yet... :-(

But thinking about these kinds of questions are a great start to such a
document...watch this space! 

> >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>
> 

Yep, except you could make the topic in the UBL FS topic map a "stub"
with minimal characteristics and move all the meta data to the Meta data
topic map. Also, resourceRef is an empty element - the reference goes in
an xlink:href attribute. So in the UBL FS topic map, you could get away
with:

<topic id="fsdesadvhtml">
  <subjectIdentity>
    <resourceRef xlink:href="UBL_FS_0p70_DespatchAdvice.html"/>
  </subjectIdentity>
</topic>

Eliminating the redundant "date" occurrence makes maintenance a whole
lot easier.

> Even though the ids are different, the subjects would indicate the same 
> file.  (I think!).
> 

Yep.

Cheers,

Kal