[sc34wg3] Re: TMDM comments

[Lars Marius Garshol]

* Lars Heuer
>
> Foreword
> --------
> """
> ISO/IEC 13250 consists of the following parts, under the general title
> Topic Maps:
>     [...]
> """
>
> IMO these references add no value to TMDM.

I agree, but ISO regulations say they must be there.

> 4.1 The metamodel - Introduction
> --------------------------------
> Figure 1 - The class hierarchy
> According to the UML diagramm a Topic may be reified by another
> Topic.
> That is simply not true.
>
> Additionally the note states "[...] and because the value of the
> [reifier] property of topic items can be any topic map construct."
>
> This is also not true.
>
> I know, the UML diagramms are not normative and there is a note that
> says "prose rules" but I wonder why the UML diagramm and its
> note is intentional wrong.

Good point. We discussed this a bit today and decided to add an extra  
abstract class in the UML to make this come out right. Should have a  
new draft tomorrow (I hope).

> 5.3.2 Identifying subjects
> --------------------------
> The note for subject locators states "[...] This of course raises the
> question of when two information resources can be considered to be the
> same. This part of ISO/IEC13250 makes no attempt to clarify this and
> leaves it for individual locator notations to define."
>
> Do the "locator notations" define in which cases the information
> resource should be considered the same?

In practice, no. The HyTime notation did, but that's no longer in  
there. What we're effectively saying is that we are punting on this,  
since it belongs to a layer of the technology stack over which we  
have absolutely no control. So, we go with the "theory of identity"  
that the locator notation we use gives us.

> What about
> "http://beatles.com/" and "http://www.beatles.com/"? Both refer to the
> same information resource and that has nothing to do with the locator
> notation.

Well, if the locator notation were HyTime we would actually be able  
to find this out, so it is actually the choice of locator notation  
(well, locator infrastructure, if you want to be very precise) that  
determines this.

> 5.3.3 Scope
> -----------
> Example 2:
> Not a failure but I'd like to suggest to find a more pleasant example
> than Word War II.

I tried, but it was hard to find another example for which I could  
identify specific authorities and numbers with discrepancies. I could  
probably do it with coastline length measurements (CIA and a  
Norwegian encyclopedia have different numbers for Norway, I know),  
but this requires two external references. This has the benefit that  
we only need one, since the traditional date is known to everyone.

> Additionally this example seems to suggest that dates should be
> modelled with occurrences ("This corresponds to creating [...]").

Certainly that they *could* be.

> It is also possible to create a topic that represents that date and
> connect it via a 'true' association with the WWII topic. ('true' since
> occurrence is a special kind of association).
> I suggest to change it to something like "This may be modelled ..."

"May" sounds fine. Applied.

> Example 3:
> IMO it would be nice to find an example that 99% (or more) of the
> readers understand instead of that cryptic one.

Alternative suggestions are certainly welcome. (I mean that.)

> 5.3.5 Properties
> ----------------
> Equality rule
>
> Wouldn't a ", or" behind each list item make it more clear that only
> one of these items has to be fulfilled to state that particular
> topics are equal?

It might, but it looks funny to me. Other opinions welcome on this,  
though.

> BTW: The equality rules are not addressable (they do not occurr in the
> TOC). I suggest to make the equality rule of each topic map construct
> addressable.

Why?

> """
> NOTE:
>
> Topics may in addition to the properties defined above also have
> types, instances, supertypes, and subtypes, represented by means of
> associations using the subject identifiers defined in 7.2 and 7.3.
> """
>
> Why "may have types"? Hasn't each topic at least one type
> ("http://psi.topicmaps..../subject")?

Not any more. (See reply to Robert.)

> 6.2 Merging topic items
> -----------------------
> "The procedure for merging two topic items A and B (whose [parent]
> properties shall contain the same topic map item) [...]"
>
> Why is the [parent] property mentioned here? The merging procedure
> describes merging of topic items in the _same_ topic map instance. The
> [parent] propety _is_ the same.

Well, before we did this it wasn't 100% clear that it had to be the  
same topic map. Now it is clear. I think it's better this way.

> The merging procedures 6.3 - 6.7 do not state that the [parent]
> property shall contain the the same value.

No, but the equality rules do. :)

--
Lars Marius Garshol, Ontopian                     http://www.ontopia.net
+47 98 21 55 50                                   http:// 
www.garshol.priv.no