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

[Steven R. Newcomb]

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

> I think we can identify one source of confusion here immediately.  ISO
> 13250:2000 and XTM 1.0 both use the term "reify" in a different sense
> from the one it was coined for by the artificial intelligence
> community, and I think you continue to use and understand it in that
> sense. 

"Reification" is an idea and a term that is considerably older than
AI.  I'm persuaded that my usage of the term is completely
appropriate, except, perhaps, if the audience thinks the term was
coined by or for the AI community.

I just went to Google and typed "reification".  The top-scoring web
page (http://pespmc1.vub.ac.be/ASC/REIFICATION.htm) was a definition
in "Principia Cybernetica Web".  I reproduce its two definitions here:

[1] treatment of an analytic or abstract relationship as though it
    were a concrete entity. (Young, p. l09)

[2] The process of regarding something abstract as a material entity,
    Whitehead's "fallacy of misplaced concreteness," e.g., the mistake
    of confusing a system, which is a construct, with the physical
    entity described in its terms (see general systems theory). In
    social systems reification is encouraged by the use of language
    and underlies many processes of constructing social
    reality. (Krippendorff)

I suspect your definition is similar to the one numbered [1], above.
Mine is extremely similar to [2].  It seems reasonable, in an online
dictionary devoted to the terminology of cyberspace, to list the AI
audience's understanding of the term as the #1 definition.  However,
definition #1 is not normally the primary definition of this term:

* The Free On-line Dictionary of Computing, ((C) 1993-2004 Denis
  Howe), gives the definition of "reify" as "To regard (something
  abstract) as a material thing."

* WordNet ((C) 2003 Princeton University), gives as the definition of
  "reify": "consider an abstract concept to be real".

* The American Heritage Dictionary of the English Language, Fourth
  Edition ((C) 2000 Houghton Mifflin Company), says "reify" means "To
  regard or treat (an abstraction) as if it had concrete or material
  existence."

Of our two definitions, I think the much-narrower definition that you
prefer is the more "private" one.

Perhaps we should agree to allow each other to use the terms we think
we should use, with the proviso that each of us can always press the
other for a deeper explanation of what we mean when we use our terms.

> There are three problems with this usage of the term:
> 
>   a) it confuses people who know the original meaning of the term,

!

>   b) it scares people, because "reify" and "reification" are
>      difficult-sounding terms, and so most people go blank whenever
>      these words are uttered, and

Agreed.  It's unfortunate, but all my experience supports your remark.

>   c) it leaves us without a term for distinguishing "reification" (in
>      the original sense of the word) from "reification" (in the ISO
>      13250:2000 sense of the word), and we do need such a term.

I'm persuaded that 13250 uses the term in its *original* original
sense.  13250 uses the term only once:

       NOTE 4 The invisible heart of every topic link is the subject
              that its author had in mind when it was created.  In
              some sense, a topic link reifies a subject.  The
              identity attribute of a topic link is provided to allow
              the author of the topic link to indicate, as
              unambiguously as possible, the subject he had in mind as
              the organizing principle of the topic.  See the
              definition of `subject descriptor'.

In Topic Maps, to reify something is to put a handle on it -- a handle
that has material existence in the universe of human expressions.  The
reason we reify subjects as topics is so that we can use our various
symbol-manipulation tools (maths, rhetoric, etc.) on their reifiers;
we can't use these tools on the subjects themselves.  Everything that
happens in topic maps is intimately bound up with the idea that we're
regarding something abstract (a subject) as if it were something
manipulable (a topic).  In some limited, hopefully well-defined
senses, we treat the topics as if they were their subjects.  Topics
have features that make them useful, in some limited way(s), as models
of the subjects that they reify.

> So for all these reasons, and also because there appears to be no
> reason to change the meaning of the term when the term
> "representation" will do what we want,TMDM changes the meaning of the
> term. This has been discussed at ISO meetings, and the current draft
> uses and defines the terms carefully, but I suppose if you have gotten
> used to your own meaning of the term for many years that isn't
> necessarily enough to clear things up.

Your words seem to accuse me of creating confusion, and of not using
words carefully.  I regret any confusion caused, and any words poorly
chosen.  I do try to clear up confusion, and to choose my words
carefully.

> So, here's an attempt to do that.
> 
>   A topic REPRESENTS its subject. The topic is an electronic symbol
>   which stands in for, represents, the real-world thing that is the
>   subject.

>   If the subject REPRESENTED by a topic is part of the topic map we
>   have what the term reification was originally introduced to mean;
>   REIFICATION is a special case of REPRESENTATION, where the thing
>   represented is a construct in the same model that isn't a fully
>   privileged proxy (to use TMRM terminology).

> I think you smelled this, to judge from your comment:

> | The TMDM's definition of "reify" is apparently a bit narrower
> | than that, [...]

> And that's precisely it. Reification, as used in TMDM and generally in
> computer science, is a special case of representation, and the TMDM
> defines this carefully as:
> 
>   The act of reification is the act of making a topic represent a
>   subject that is a topic map construct. For example, creating a topic
>   that represents an association is reification.

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

> Actually, I think you are subtly wrong here. I think you need to
> rephrase your original question in TMDM terms in order to be able to
> find the answer in TMDM. I also think TMRM should start using the
> normal meaning of the term "reification" and instead start calling it
> "representation".

You would not be the first person to advise me to drop the word
"reification" from my vocabulary.  It loses friends and alienates
people.  (That doesn't change the fact that, sometimes, it's exactly
the right word, given an audience to whom the name "Whitehead" means
something other than "a kind of skin blemish".  (;^))

> So your question becomes: 
> 
>   "What are the subjects that are being represented?"
> 
> which sounds a bit odd, so we should perhaps amend it to
> 
>   "What are the subjects that are being represented by explicit
>   proxies?"

OK.

> which IMHO is enormously much clearer than the original question,
> since it does not depend on a private definition of "reified".

(It's pretty clear that my definition is significantly less private
than yours.)

> | Here are some related questions:
> | 
> | * Is every information item a representation of a subject? 
> 
> Notice how you fell back to "representation" here, when to be
> consistent you should really have written "reification".

I was asking a broader question than the one you seem to think I
should have intended to ask.  I wanted to give you plenty of room
to say whatever needed to be said.

> Anyway, I believe the answer is yes. Notice how for every information
> item type the type is introduced by a sentence of the form
> 
>   "<typename> items represent <formal term>s."
> 
> as in
> 
>   "Locator items represent locators."
>   "The topic map item represents the topic map."
>   "Topic items represent topics."
> 
> Notice how TMDM explains things in terms of a trichotomy:
> 
>   subject world | topic world | TMDM world

Now we're getting somewhere!  I think maybe you just gave me
the biggest missing piece of the puzzle.

> where subjects in the real world are represented by abstract topics,
> which again are represented by topic items.

OK, so do I understand correctly that the "abstract topics" are the
*real* reifiers of the subjects -- reifiers that don't really exist
anywhere -- and that the information items reify those abstract topics?

> |   Or do only topic information items represent subjects? 
> 
> TMDM keeps the original definition for "subject" word for word, since
> it cannot be improved upon,

thank you

> and so in TMDM "subject" is explicitly
> defined as "anything whatsoever". So any item that represents
> something represents a subject, and they all represent something, so
> they all represent subjects.

Wait, just checking.  The subjects they represent: are they the
"abstract topics", or are they the *subjects* of the "abstract
topics"?

> |   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.
> 
> Here I am not sure what to say. I guess my answer is above; if that
> needs further elaboration, let me know, and I will try.

I appreciate your effort.  Hang in there.  This is truly the question
that's on my mind.  

I now gather, from your answer, that the relationship between an
information item and a subject is embodied in a thing called a "topic
map construct", or perhaps just called a "topic".  The information
item reifies a subject that is a topic map construct (or maybe a
"topic"), and that topic map construct's subject is the subject that
is the whole reason for the existence of both the topic map construct
and the information item.  Am I getting closer, or farther away?

> | * 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?
> 
> Here I think we are back to the different meanings of "reify". An
> information item is reified if a topic item has been created that
> reifies it. An information item always *represents* something, which
> is a completely different thing.

What, for you, is the difference between "reify" (in the general
philosophical sense) and "represent"?  I think it's worth talking about.

For me, as for you, there's a big difference.  A thing can "represent"
something without being usable as a model or expression of it.  For
example, the Indian flag represents India, but one can't learn much
about India from it, and there's almost no sense in which one can
treat an Indian flag as if it were a model of India.  By contrast, a
topic that reifies India can have, in addition to any information
inherent in the topic, a context in a graph of topics.  This context
can be a model of India's actual relationships with other subjects,
and it can make the topic that reifies India useful, in some limited
way, as a model of India.  It can be treated, for certain limited
purposes, as if it *were* India.

The idea that, in Topic Maps, topics go beyond mere *representation*
of their subjects, and that they in fact *reify* their subjects, is
closely related to the idea that topic maps strive to reflect the fact
that, in any given universe, each subject is unique.  If we represent
a universe of subjects as a topic map, and we do it in such a way that
each subject's reifier is the *only* reifier of its subject, and
everything known about each subject is either inherent in it or
connected to it, then there are very real senses in which each reifier
is a model of the subject, within a model of a universe.

> | * 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 think you may be right here. We say that the topic represents the
> topic map construct (topic name, occurrence, association, whatever),
> but we don't say the last bit, which is that the topic then represents
> the same thing that the topic map construct represents.

OK.  But why not?  It seems to me that if TMDM doesn't make
ontological commitments about exactly how it serves as a model of
actual subjects, TMDM is vulnerable to the (potentially devastating!)
criticism that it doesn't have anything to do with the representation
of any subjects other than topic map constructs.  Why would anybody
bother with a representation that can only represent a few kinds of
extremely specialized subjects (the idea of a topic, the idea of an
association, the idea of an occurrence, etc.), if they can choose a
representation (such as RDF, for example) that can *directly*
represent multiple broad spectra of subjects?  What advantages are
gained by using a representation of a representation of a subject, as
opposed to a representation of a subject?  I think it will be
important for TMDM to articulate a compelling answer to this question.

> This is kind of unfortunate, because there is a difference between
> representing the relationship between me and Ontopia, and representing
> the association between the two.

Exactly my worry!  An association is already a representation of a
relationship, so an information item that represents an association is
two removes from the relationship.  It seems to me that most users of
Topic Maps, and of TMDM, are more interested in the relationship than
in a representation of a relationship.  And, they are more interested
in a representation of the relationship than in a representation of a
representation of the relationship.

> I think reification (TMDM sense!) must be taken to mean the former,
> since otherwise it is not of any use whatsoever.

Agreed.

> (There has been quite
> a bit of discussion on this, but I'm not sure how many people have
> been in on it. I'll expand if anyone's curious.)

I have the feeling that we're discussing it again.  Please feel free
to expand if you have time.  Maybe we can fly over familiar territory,
instead of slogging through it again.

> | > 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.
> 
> That's a very good point. I believe Graham and I discussed whether or
> not to define this term, and decided against it. I guess we were
> wrong.
> 
> The definition would read something like this
> 
>   3.x topic map construct
>   topic maps, topics, associations, topic names, variant names,
>   occurrences, and association roles are topic map constructs
> 
> which implies that nothing else is, of course.
> 
> Does that help? Does anyone think we should add this definition to the
> text?

Maybe it will turn out to be helpful, but, right now, all it does is
to beg the questions, "What is a topic map?"  "What is a topic?",
"What is an association?"  These questions are legitimate and
necessary because the only formal definitions of these terms -- the
definitions that appear in 13250 -- actually define syntactic
constructs, but, in what follows below, you say that "topic map
constructs" (as you use this term) are not syntactic constructs.

> | 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.)
> 
> Actually, it doesn't. I suppose this could be clearer, too. Any
> proposals for replacements for "syntactic constructs" that would
> retain the original meaning of "syntactic element of intuitively or
> formally apparent extent" without using the loaded term "construct"?
> "Element" leads one in the direction of XML, which isn't good.
>  
> | So, is a "topic map construct" an element, or part of an element, or
> | a group of elements, in an XTM instance?  
> 
> No. It is abstract. Those are all "syntactic constructs", which is
> something else.

Fair enough.  Thank you for answering my question!  This is helpful.

> | 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.)?
> 
> No, the other way around.

You're saying that the subject of an information item is an idea, and
that idea is a topic map construct.  Right?

> | If a "topic map construct" is a syntactic phenomenon, then the
> | definition of "merging" is very confusing: [...]
> 
> True. Thankfully, it isn't a syntactic phenomenon. :-)

Good.

> |   > 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.
> 
> Yep. I hope I cleared this up above.

I've been trying to "play back" my understanding.  I'll appreciate
it if you'll tell me where I seem to be going astray.

> | [source locators]
> |
> | I don't know how to understand this.  Are we assigning identifiers
> | to topic map constructs, or to their representations?
> 
> Topic map constructs are already representations, are they not? A
> topic is a representation of a subject, right?

Sounds both good and familiar to me.

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

> Correct. It's outside the scope of the TMDM. XTM handles assignment of
> source locators when reading XTM files. LTM does the same for LTM
> files, and so on.

You seem to be saying that the XTM specification will specify the
interpretation of its instances as TMDM instances.  Is that right?

If so, will that specification implicitly or explicitly specify the
interpretation of XTM instances as sets of topic map constructs?

What will specify how the subjects represented by the topic map
constructs will be determined to be the same as each other?

> | 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,
> | [...]
> 
> Well, first of all, there are no source locator items, only locator
> items. These represent URIs, or HyTime locators, or some so far
> undefined locator syntax.

Are the locators constrained by the definitions of the interchange
syntaxes, or can any sufficiently powerful locator expression be used
as a source locator for any syntax?  (This question sounds awfully
academic, but, like the three preceding questions, it has a practical
purpose.  I'm trying to understand your vision regarding what is
supposed to be defining what.)

> The other item types all represent some topic map construct.
> 
> The [source locators] property is used to say that the locator refers
> to the syntactic construct that the topic map construct represents.

Do you really mean to say that a topic map construct represents a
syntactic construct?  Until I read the above sentence, I was just
getting comfortable with the idea that a topic map construct
represents a real subject, in sequence of layers of representation:

  real subject (is represented by)
  topic map construct (is represented by)
  TMDM information item

Now you seem to be saying that there's an additional layer in this
cake:

  real subject (is represented by)
  syntactic construct (is represented by)
  topic map construct (is represented by)
  TMDM information item

Is either of the above layer cakes accurate?

> | because then I know what's going on -- I know what subjects certain
> | parts of a TMDM instance are representing.  
> 
> Hopefully you do now. :-)

You tell me.  Am I getting it, or not?

> | 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?
> 
> I can see how the TMDM prose led you to this conclusion, but hopefully
> you'll now see that this is not the case.

I hope I see.  Maybe I see.  Let me know.

> | 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.
> 
> We do. I fully agree with this. I'm hoping that with your help we can
> make sure that this is the case. I think we're pretty close and that
> the causes of this are tiny pieces of missing text in the TMDM draft,
> as well as confusion over the meaning of the term "reification".
> 
> I hope this brought us at least another step forward.

I sense progress, 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