What is an *application*? Was Re: [sc34wg3] The Nowegian National Body Positon on ISO 13250

[Lars Marius Garshol]

* Patrick Durusau
| 
| I searched the SAM for some definition of how one declares a *topic
| map application* but did not find one.

There isn't one. The SAM prose just assumes that there will be
something that handles the basic topic map processing (called the
topic map processor) and something that uses the processor to do
something (called the topic map application). The SAM doesn't attempt
to constrain what the application does so long as it respects the
structural rules of the SAM.

I don't see why we should try to restrict or constrain applications in
any way. What's the point of that?
 
| The SBL prepares a topic map using brand X topic map software which
| uses a *topic map application* (SAM sense) that is somehow loaded
| into the software (or is it inherent in the software?) that has only
| the SAM merging rules. 

The relationship is that the application uses the topic map processor
to implement something useful for the end user. This is exactly like
the relationship between an XML application and an XML parser.

| That topic map is distributed to SBL members, who use a variety of
| topic map software from both current vendors and future vendors.
| Those topic maps are returned to the SBL for merger into the SBL
| topic map. Our members will expect that merger will follow the rules
| they have experienced with their topic map software and will be
| quite surprised to find that the results of merger do not.

I see what you mean. I don't see any problem here, really. End users
using topic maps will almost invariably do so through an application
built especially for them and if you want to get something like this
to work you have to basically design an application with an
architecture that does what you want. There's no way around that, and
putting a definition of what an application is into the SAM document
is not going to help.

I think it will be useful to provide a way to declare the merging
rules used in a topic map or topic map vocabulary, but that's outside
the scope of 13250, and in any case won't be enough in the scenario
you suggest.

| (At least if you assume that they can't send the *topic map
| application* (SAM sense) along with their topic map so that human
| intervention could create rules to honor the terms of their topic
| map.)

I think that's a fair assumption. Sending software around rarely
works except in very restricted circumstances.
 
| Part of the goal of the N0393 was to provide a way to disclose the
| rules governing a topic map by what is called a TM Application
| (N0393 sense). If I don't know what the rules of a *topic map
| application* (SAM sense) are, I can't very well prepare merging
| rules for my *application* (software sense) that allow me to make
| sense of the topic map or get the same results.

This is outside the scope of 13250. 

It's also a fact of life that other applications will not understand
the semantics of the vocabulary that you use unless they have prior
knowledge of it. An ontology language allows you to describe a tiny
bit of those semantics, but that's pretty much all you can hope for in
this world.
 
| Not sure that users, not most SBL users at any rate ;-) , are going
| to be able to add merging requirements if they are inherent in the
| *application* (software sense). 

They're inherent in the topic map ontology/vocabulary, but it's the
application (SAM sense and software sense) that has to implement them.
There's no other way for it to happen in ISO 13250:2002, and all we're
doing is restating that in a more formal manner.

| If the *topic map application* (SAM sense) is not defined outside of
| the *application* (software sense), I am not sure how that
| information would accompany the topic map instance. If I don't have
| access to the *topic map application* (SAM sense), how am I to ever
| move from one application (software sense) to another, or for that
| matter, add my merging rules to the *topic map application* (SAM
| sense)? I can imagine low-end topic map software having only the SAM
| merging rules and vendors offering more powerful versions that allow
| the loading of an interchangeable (as in between applications,
| software sense) *topic map applications* (SAM sense). That latter
| case presumes we have some standard (ISO sense) of how to declare a
| *topic map application* (SAM sense). Seems to me that would provide
| a more unified market, not to mention benefits to users and
| information providers.

I think being able to declare your merging rules is useful, but I
don't think it belongs as part of ISO 13250, nor do I think this is as
much of a problem as you seem to think. End-users will depend on
software applications tailored to specific vocabularies to do what
they want to do, anyway, and I don't think we will ever be able to
change that. 

And, as I said, a tight definition of what a SAM application is won't
make the slightest bit of difference.
 
| Apologies for all the parens, just trying to make sure my post is not
| any more confusing than necessary. ;-)

Not sure that was a success, really. :)

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >