RE: grove plans (off-topic; was: Re: [xtm-wg] Does processing a TM yield one graph, or several?)

["Daniel Rivers-Moore" <daniel.rivers-moore@rivcom.com>]

One possible role for a TopicMap Query language would be to say "Give me
those parts of that topic map that I am interested in" together with a
specification of the criteria that define my interest. This would serve as a
filter of the kind I think Sam wants. But defining XTMQ is certainly going
to be beyond the scope of Dallas.

A couple of other observations:

Regarding <xtm> ... NewsML has the NewsML element as its root. A NewsML
document must contain a <NewsEnvelope> and may contain one or more
<NewsItem> elements. If <NewsItem> maps to <topicMap., then NewsEnvelope
probably maps to <xtm>


Regarding merging, and whether it has to actually take place when the topic
map is read, I'd like to quote the relevant passage from the NewsML DTD,
which addresses this very issue. You will see that NewsML adopts the
position that systems are not required to actually perform the merge.

"
<!--
================================= TopicSetRef
==================================
A pointer to a TopicSet that is to be merged with the current one. The
TopicSet
attribute is a pointer to the relevant TopicSet. Its value can be an http
URL,
or a NewsML URN as described in the comment to PublicIdentifier, or a
fragment
identifier consisting of a # character followed by the Duid of a TopicSet in
the
current document. The presence of a TopicSetRef child in a TopicSet has the
effect that all the Topics in the referenced TopicSet are included by
reference
within the current TopicSet. When this merging results in there exising two
FormalName grandchildren of the same TopicSet that have the same content and
the same Scheme attribute value, then the Topics that are the parents of
these FormalName elements are in fact the same topic, and are deemed to be
merged.
The merging of Topics need not be performed physically by the system, but
the meaning of the data is exactly the same as if the merging were actually
performed. Merging two Topcis consists of creating a single Topic that
contains
all the children of both, and eliminating duplicates.
============================================================================
====
-->
<!ELEMENT TopicSetRef  (Comment* )>
<!ATTLIST TopicSetRef  %localid;
                       TopicSet CDATA  #IMPLIED >
"

For what it's worth

Daniel

-----Original Message-----
From: Steven R. Newcomb [mailto:srn@coolheads.com]
Sent: 08 November 2000 19:57
To: xtm-wg@egroups.com
Subject: grove plans (off-topic; was: Re: [xtm-wg] Does processing a TM
yield one graph, or several?)


[Steve Newcomb:]
> > (I hope and believe that grove plans have nothing to do with this
> > issue, either conceptually or literally.  I'm curious to understand
> > why you think they might -- seems like I'm missing something, here.)

> Groves, being, like "graphs", graphs, can be humongous; so one wants to
> "filter" the grove to make it usable for a particular purpose. I
> thought that was what grove plans did. [WARNING: If that's wrong, if
> possible just tell me No, and cite the HyTime clause, in the interests
> of time, and space.]

You're not wrong, but the filtration provided by grove plans can only
"filter out" (as it were) specific whole properties (and their values)
of all the nodes of the particular classes that have those properties.
I'm gathering that the kind of filtration you seem to be proposing
would be based on the *values* of properties.  A grove plan can't be
used for such a purpose; it's just the wrong kind of tool altogether.

> An alternative, to be discussed in Dallas, is to forget about <xtm>.
> Then the <topicMap> would become the one and only starting point for
> the graph construction process.

One and only one <topicMap> is *always* the one and only starting
point for the graph construction process, regardless of how many
<topicMap>s may appear in a containing <xtm>.  That's not
controversial, as far as I know.

We can all see this "Do we need the <xtm> container element?"
discussion coming.  There is a perception of a real requirements
conflict here.  To my way of thinking, however, the advantages of
having the <xtm> container element far outweigh the disadvantage
(which seems to me to amount, in toto, to a really insignificant
amount of extra complexity).  But that's just my opinion, and I have
just one vote.

-Steve

--
Steven R. Newcomb, Consultant
srn@coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

405 Flagler Court
Allen, Texas 75013-2821 USA


To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com


-------------------------- eGroups Sponsor -------------------------~-~>
eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9699/1/_/337252/_/973783895/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com