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

[Patrick Durusau]

Lars,

Lars Marius Garshol wrote:

>* 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?
>
Well, that is what I would term "interoperability." Much of the benefit 
of ISO 8879 and the XML standards (to the extent they have had 
conforming applications) is that I can take a document prepared with one 
application and get the expected result with another. Not always by any 
means, I may be using an application that has "extensions" (like 
Micosoft's version of XML) but for the most part. If there are no 
constraints on applications (software sense), then what is being 
standardized?

It may be in part my understanding of that a standard means at some 
level, conformance. If there is no conformance or it is so loose as to 
be difficult to imagine something that does not conform, it isn't much 
of a standard.

> 
>| 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.
>
Except that an XML document instance should result in the same output 
from any XML parser. The XML application may treat it differently from 
application to application (software sense) but that is different from 
saying I get result A from parser X and result B from parser Y, using 
the same XML document.

>
>| 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.
>  
>
What? In order to use topic maps each end user will need a custom 
application? Forgive my ignorance of software marketing but that does 
not look like a mass audience sort of approach.

>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.
>  
>
Sorry, that went by a little quick. Why is declaring merger rules 
outside the scope of 13250? If merger is the way we get to a single 
location representing all the information about a subject (What SteveP 
calls collocation, what I would call something a little different but I 
think the ideas are close) then doesn't that have to be within the scope 
of 13250? If we don't talk about merger, I am not sure how we can still 
be talking about topic maps. (If I have seriously mis-read your remarks, 
just ignore. Just struck me as odd that merger rules are out of scope, 
if that is what you meant.)

>| (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.
> 
>
OK, so in the SAM, *topic map application* means something that is 
wholly contained in the application (software sense). I guess that also 
means that the rules in that *topic map application* are also unknown 
unless the application designer chooses to make them known? Well, would 
have to be in the absence of a standard way to make them known won't it?

>| 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. 
>  
>
How so? (serious question, see my comments earlier on 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.
>  
>
Let me try to illustrate why I differ on this point. Content models, as 
in SGML/XML DTDs are enforced by software, implemented if you will, but 
they are not inherent in the parser or application, if you want to make 
that distinction. I guess I am wondering why a similar mechanism is not 
being considered for topic maps? Would seem to me to make the software 
more generic and open up the market for topic map applications (software 
sense), authoring tools, consulting, education and the like.

>| 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. 
>  
>
But the argument that declaring merging rules "do not belong in 13250" 
is a different argument than that it is "out of scope." Not trying to 
quibble over words but the criteria for one is different than the other. 
Given all the spats that have arisen over words I want to make sure 
which one (or both if you like) of these arguments you are making on 
merging rules.

The "don't belong" argument hinges on expected patterns of usage and 
current practices. If there is no loss to current practices by allowing 
declaration of merging rules, then I don't see the downside to such a 
mechanism as it meets the current practice for custom applications and 
leaves the market open to grow to more generic applications.

The "out of scope" argument, I must confess I don't understand and need 
for you to say a bit more about it. Since I think merging and the rules 
for merging are central to what topic maps are trying to achieve, I 
don't see any way it could be out of scope. You may convince me 
otherwise but that is how I see it at the moment.

Patrick

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
Co-Editor, ISO Reference Model for Topic Maps