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

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

Lars Marius Garshol wrote:

> | Let me be clear: the processing model is the data model of what an
> | API for operating on topic maps exposes. No more no less.
> 
> Agreed.

I also agree with your list of requirements for the static model part of
the processing model.
 
> | Therefore it will by necessity have things like dictionaries because
> | most of the operations on topic maps will be to LOOK THINGS UP.
> 
> Not agreed. A data model doesn't have operations.

Here is our point of disagreement: Lars and I appear to agree that we
must have a static data model that describes the structures that some
API would expose--that is, the data that any XTM processor must act as
though it has in its head (regardless of how it actually manages the XTM
data).

But Lars does not want an API. I think I understand and appreciate Lars'
concerns, but I also feel very strongly that without at least some sort
of minimal standard API in the spirit of the DOM, that the world at
large and our marketing effort in particular will not be well served.

If the DOM has taught us anything it is that, to implementors, an API
with no underlying data model is better than a data model with no API.
Given an API, you can at least have the appearance of client software
plugability, even if, without a data model, you can't prove correctness
of the API (because it has no formal definition of the data it exposes).

If there is no standard API, then I either must completely rework every
integration of every topic map tool I may want to use or I must define
my own topic map API and then wrap every tool I integrate into it, at
the cost of effort and efficiency that would have been avoided had there
been a standard API in the first place.

Note that I am not suggesting we define the full API that a complete
topic map system would expose (and where, for example, you might have
issues of concurrency). I'm only talking about the basic get/set methods
for the classes in the data model, factory methods for creating new
classes, and the minimum set of useful convenience functions needed to
make operating on topic maps relatively easy (e.g., functions to deal
with the complexities of scope, the complexities of association
membership, etc.).

I think that this level of API pretty much falls out of any static data
model and should not pose any great difficulty of specification--if we
agree on the data model, the API should pretty much be an exercise in
typing.
 
> * Lars Marius Garshol
> |
> | I don't think they would have to be. Resources should IMHO just be
> | represented as URIs, that is, strings. In any case, the prose could
> | override undesirable features of groves.
> 
> * W. Eliot Kimber
> |
> | This is fuzzy thinking. What do you get when you dereference the
> | URI?
> 
> That is for the IETF to define. TopicMaps.Org can't start specifying
> what happens when you dereference URIs. That's just way way out of
> scope.

I guess this is true. I'm just reminding people that addressing in the
W3C/IETF domain that is not addressing of XML or CGM is completely
unstandardized and therefore not open to reliable interchange at any
level. That is, if you want to do anything sophisticated, like point to
paragraphs of Word documents, you're F-----. But I don't think it's
sufficient to say that resources are strings, you must say "resources
are whatever you get when you resolve the string, whatever that might
be." To say otherwise is to perpetuate the madness.

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/4cW4jC/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/