[sc34wg3] TMDM doesn't specify what is reified?

[Steven R. Newcomb]

Lars Marius Garshol <larsga@ontopia.net> writes:

> SRN mentioned this criticism of the TMDM to me at the end of the
> Extreme conference: "TMDM doesn't specify what is reified and what is
> not". I don't understand that at all, but he said it was the key
> problem he saw with it, so I'd really like to get to the bottom of
> this. Unfortunately, I don't understand what this means.
> 
> SRN, please let me try to ask you some questions, to see if we can
> clarify what problem you are perceiving:
> 
>   - what does it mean for something to be reified? what is the "acid
>     test," as it were?
> 
>   - how can TMDM specify or fail to specify this? again, is there a
>     kind of "acid test" that can be applied?
> 
>   - is there something else you could say to help me understand this?
> 
> What I'm looking for with this discussion is to get us to a point
> where we all agree the TMDM meets this requirement. The two ways of
> doing that are either demonstrating that the TMDM does meet it
> already, or fixing it so that it does. Either way, the first step is
> to understand what it means. :)

Before I attempt to answer Lars Marius's question, I want to assure
everyone that this exchange is friendly and constructive.  For some
(possibly astrological) reason, we have developed more rapport lately.
I'm convinced that we are listening to each other with genuine mutual
interest in working together to progress the standard.

****

What I'm missing, in the TMDM, are clear, explicit answers to the
question:

  "What are the *subjects* that are being reified?"

By "reify" I mean "represent via a surrogate", and "provide with a
proxy".  The TMDM's definition of "reify" is apparently a bit narrower
than that, but even if we use the TMDM's definition, thus narrowing
the above question, it is still a valid question, and it, too, is not
answered clearly by the draft TMDM (we'll look at this much more
closely in a moment).

Here are some related questions:

* Is every information item a representation of a subject?  Or do only
  topic information items represent subjects?  Or is the nature of
  TMDM such that there are no fixed relationships between subjects and
  information items?  Or what?  I don't think TMDM answers this
  question clearly -- for whatever reasons -- but I think it can, and
  I think it should.

* When an information item has been reified (by creating a topic
  information item that says it reifies the information item), does
  the information item *then* represent a subject, or is the subject
  represented exclusively by the reifying topic information item?  Or
  do the two information items *collectively* represent the subject?
  Or what?

* When an information item has been reified by a topic information
  item, what is the subject of the topic?

Lars, I suspect you believe TMDM answers this last question, at least,
quite clearly.  But I don't think it does.  I'm not exaggerating at
all when I say I find the current draft of TMDM confusing.  Let's look
more closely, to see why I say this:

> 3.8 information item
> abstract representations of topic map constructs

>From the above definition, I understand that "topic map constructs"
are not the same things as "information items", and "information
items" are representatives of "topic map constructs".  

Unfortunately, I'm not able to tell, for sure, what "topic map
construct" means; this term is not formally defined in the TMDM.
However, TMDM does say, about the source locators property of
information items,

  > ...source locators are created that point back to the syntactical
  > constructs that gave rise to the information items in the data
  > model instance.

(I found this by searching for "construct".  N.B. This doesn't say
"topic map construct", but I'm hoping "construct" implies "topic map
construct".  I'll take any help I can get.)

So, is a "topic map construct" an element, or part of an element, or a
group of elements, in an XTM instance?  In other words, is the subject
that is being represented by an information item always a piece of
information (as opposed to an idea, tangible thing, etc.)?

If a "topic map construct" is a syntactic phenomenon, then the
definition of "merging" is very confusing:

  > 3.13 Merging

  > a process applied to topic maps in order to reduce the number of
  > redundant topic map constructs

Maybe this definition is intended to mean, "...redundant topic map
information items" (?)  I don't see how it could mean that the purpose
of merging is to edit an XTM instance in such a way as to reduce the
number of syntactic phenomena that are found in it.  Or maybe I don't
understand what a topic map construct is, because it's something other
than a syntactic construct.

  > 3.19 reification

  > making a topic represent a subject that is a topic map construct

I don't understand what's being reified, when we're reifying "topic
map constructs", because, as already noted, TMDM doesn't define "topic
map construct", and what TMDM does say about "topic map construct"
leads me to draw conflicting conclusions about what this term means.
Let's look a little farther:

  > 3.21 source locator

  > a locator assigned to a topic map construct in order to allow it to
  > be referred to

and later:

  > A source locator is a locator assigned to a topic map construct in
  > order to allow it to be referred to. It is not specified how and
  > when source locators are assigned to information items, and source
  > locators may be freely assigned to information items.

I don't know how to understand this.  Are we assigning identifiers to
topic map constructs, or to their representations?  In the first
sentence of the above paragraph, we're assigning identifiers to topic
map constructs.  In the second sentence, we're avoiding saying when or
how these (same?) identifiers are assigned to information items.

Now, if you tell me that source locator items are proxies of subjects
that are syntactic constructs in, for example, the XTM source from
which the TMDM instance was constructed, then I'm happy, because then
I know what's going on -- I know what subjects certain parts of a TMDM
instance are representing.  But the TMDM draft doesn't say this.  If
it's really true that source locator information items are the
surrogates of certain subjects, then the TMDM should say exactly what
those subjects are.  If it's not the case that source locator
information items are the surrogates of subjects, then TMDM should
reveal what are the subjects of which source locator information items
(and/or the properties of source locator information items) are
properties.

> NOTE: In a sense source locators are identifiers for topic map
> constructs devoid of any specified semantics, and these may be
> automatically assigned to information items to provide them with an
> identifier or to identify the origin of the item.

Once again, it sounds like topic map constructs are syntactic
phenomena, and that information items are the surrogates for them.
But, if that's true, and if information items only represent topic map
constructs, then how can a "topic information item" represent any
subject other than some instance of a syntactic phenomenon?

Or maybe "topic information items" aren't surrogates for the subjects
that syntactic <topic> elements "have as their invisible hearts", and
I *completely* misunderstand the TMDM even at this most basic level.
(But I just don't believe that.  I don't believe that TMDM is designed
only for subjects that happen to be syntactic constructs in instances
of interchangeable topic map documents.  I'm sure it's intended to
work for many other kinds of subjects, too.)

We really need for TMDM to be extremely explicit and clear about how
TMDM instances invoke, represent, surrogate, proxify, reify,
correspond to, or whatever, SUBJECTS.  For every bit of data that a
TMDM instance contains, we need to know what subject(s) that bit of
data is about.  The current draft of TMDM doesn't reveal that
information, but a future draft certainly could.  I'm convinced that
this information exists, if only in the minds of TMDM's editors, and
I'm willing to bet that, at least very arguably, it makes sense, too.


-- Steve

Steven R. Newcomb, Consultant
Coolheads Consulting

Co-editor, Topic Maps International Standard (ISO 13250)
Co-drafter, Topic Maps Reference Model 
  (http://www.coolheads.com/SRNPUBS/ontolog040610)

srn@coolheads.com
http://www.coolheads.com

direct: +1 540 951 9773
main:   +1 540 951 9774
fax:    +1 540 951 9775

208 Highview Drive
Blacksburg, Virginia 24060 USA