Re: [xtm-wg] A challenge on "the graph"

["W. Eliot Kimber" <eliot@isogen.com>]

Sam Hunting wrote:

> Personally, I'm leaning toward groves, since (a) property sets have
> angle brackets, therefore I understand them, (b) property sets are
> simple and elegant (unlike -- no flames please! -- UML, at least in my
> experience), (c) groves do describe graphs, and (d) groves seem to meet
> the node/property desire voiced by some implementors. (Kal?)

My objection to using a grove property set as the formal definition of
the graph is that it would impose grove-isms that a  more generic formal
model would not have.

In particular, anywhere that you would normally have a dictionary (a
mapping of keys to values), you must represent that in a grove as a
named node list whose members are "artificial" nodes that represent each
item in the mapping.

A grove that is not being used for representing non-grove data ("primary
groves") or direct views of that data (architectural groves, data
tokenization groves) is really an internal implementation view of a more
abstract data model.

I am convinced now that we made a mistake in 10744 in defining the
"HyTime semantic grove" as a grove. It made sense at the time because we
weren't aware of any other modeling formalism. But an EXPRESS or UML
data model would have been much more appropriate. My experience in
building a full-scale hyperlinking system has convinced me that there is
*API* advantage to having the hyperlinking data (the knowledge of what
is linked to what) held as a grove. It only makes what should be
relatively intuitive difficult to use at the API level and difficult to
understand at the documentation level. Using a property set to define
the data model gives you no natural way to define an API over that grove
that provides the appropriate convenience functions, something that a
topic map system will need in spades (for example, imagine dealing with
the complexity of scopes solely in terms of systems of node lists where
every user of the grove has to perform complex navigational queries to
get what they need rather that using API methods that encapsulate the
queries and hide their details from client systems.

While I don't think it would be the end of the world if a property set
was chosen as the definitional mechanism, I think it would be a
seriously suboptimal choice. I would, for example, much prefer an
EXPRESS model over a grove.

Note, however, that the actual data elements accessed through this
API--the occurrences of topics, would still be grove nodes, just as they
are in HyTime. Groves exist to enable reliable and interchangable
addressing of *data*. They were not designed as and do not work well as
a general abstraction definition and management facility.

Cheers,

E.     
-- 
. . . . . . . . . . . . . . . . . . . . . . . .

W. Eliot Kimber | Lead Brain

1016 La Posada Dr. | Suite 240 | Austin TX  78752
    T 512.656.4139 |  F 512.419.1860 | eliot@isogen.com

w w w . d a t a c h a n n e l . c o m

------------------------ Yahoo! Groups Sponsor ---------------------~-~>
Secure your servers with 128-bit SSL encryption!
Grab your copy of VeriSign's FREE Guide,
"Securing Your Web site for Business." Get it now!
http://us.click.yahoo.com/KVNB7A/e.WCAA/bT0EAA/2n6YlB/TM
---------------------------------------------------------------------_->

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

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/