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

[Lars Marius Garshol]

I think it's probably better to start from scratch here and try to
explain without trying to reply exactly to each paragraph of what you
write. We'll see whether it works or not. :)


The SAM describes the concept of a topic map processor, which performs
work on behalf of another software entity, the topic map application.
What the SAM does is to define the workings of the topic map processor
in minute detail, but it places no constraints on what the topic map
application may or may not do. (It expects the processor to maintain
the TM on behalf of the application, so anything the processor will
not do the application cannot do either.)

Now, the first thing I should say is that I'm beginning to think that
we should remove the conformance section altogether, and just say that
the SAM is a tool to be used by other specifications, and that it is
those documents that define what conformance actually means. This
would mean that you could conform to XTM, HyTM, TMCL, and TMQL, but
that your internal book-keeping is your own business. I don't think we
would lose anything by doing this.

I think you would still have the same issue, however, since your
concern seemed to be as much interchange of XTM documents as anything
else. 

So, let's assume I get an XTM document from you, which uses the SBL
Magic Ontology (hereafter known as SMO), which has peculiar merging
rules of its own.

At this point I must decide what to do with the document. My first
instinct would be to load it in the Omnigator to see what kind of
beast this might be. The Omnigator implements the behaviour of a topic
map processor, but has no application-specific rules whatsoever. So I
get a topic map where the special SMO merging rules have been ignored.

Why should anyone be surprised by that? The Omnigator doesn't follow
the particular SMO display rules, either. Nor can it do the same
simple, easy searches that the SBL application that displays SMO TMs
knows how to do. This requires knowledge of the SMO vocabulary to be
encoded in the software, and the Omnigator, being
ontology-independent, has no such knowledge.

This is the same as loading an XTM document in MSIE, in a sense. MSIE
understands XML, but not the vocabulary used in XTM. The result is
rather sorry-looking, but that's life. XML software only understands
so much of XML independent of particular XML applications.

However, if I sat down to write, on top of the OKS, a Java application
that implemented the special SMO merging and display rules, and also
gave me an efficient search interface, then I could load the topic map
into that (SMO application + TM processor) and get the same results
you get.

It seems that you would like, somehow, the merging rules of SMO (but
for some reason not all the other rules and semantics included in SMO)
to travel with the XTM document. I think it would be a good thing if
we could do that, but unfortunately the SMO merging rules are relative
to the phase of the moon as seen from the country where the XTM
document is read, and so the mechanisms provided by TMCL (ISO
19756:2005) for declaring merging rules don't quite suffice. So
there's no way to put those merging rules into the XTM using existing
standards.

Is that really a problem? If you think it is, what would you have us
do about it? I can't think of any reasonable solution to this. If you
can, I'd be happy to hear it. (I'd be even happier to hear that I
completely misunderstood what you wanted. :-)

* Patrick Durusau
|
| 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.

I agree. The trick is to be able to draw the line between what can and
should be standardized in the right place.
 
| Except that an XML document instance should result in the same
| output from any XML parser.

As should the same XTM document produce the same representation in any
SAM-compliant TM processor. It's *only* when an application reaches
into that representation to apply additional merging, delete topics of
certain types, add occurrences with specific values, transform subject
identifiers according to a regular expression, or what have you, that
the result will be different. That's no different to how what the XML
Recommendation calls an application can change an XML document in any
way it chooses.

| What? In order to use topic maps each end user will need a custom
| application? 

No, but each *ontology* probably will. We've seen some very few
customers who want to deploy the Omnigator, but that's about it. Of
course, you could create a GenealogyXTM and have lots of people use
the same TM-based genealogy program, but that's still custom software
(from the point of view of the SAM).

| Forgive my ignorance of software marketing but that does not look
| like a mass audience sort of approach.

Well, if you can create software that is smart enough to avoid that
I'm happy to say you have a mass market waiting for you. Looks like
you'll have it all to yourself, too.
 
* Lars Marius Garshol
|
| 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.
 
* Patrick Durusau
|
| Sorry, that went by a little quick. Why is declaring merger rules
| outside the scope of 13250? 

The task we gave ourselves was to restate ISO 13250:2002 and to not
add anything new. ISO 13250:2002 basically defines two interchange
syntaxes for topic maps with some very minimal published subjects for
crucial things like the superclass-subclass relationship. Creating an
elaborate machinery for declaring merging rules does not to me seem to
fit into a standard that defines just the basics of what topic maps
are.

I think declaring constraints on topic map vocabularies is what TMCL
is for, and therefore I think the capability to declare merging rules,
together with other types of constraints, should go into TMCL.

| 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? 

The basics of merging, yes. The final and complete solution to the
issue of merging, no.

| OK, so in the SAM, *topic map application* means something that is
| wholly contained in the application (software sense). 

Yes. (It used to say software explicitly, until Robert Barta protested
that that discriminated against TM implementations done in hardware.)

| 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?

Exactly.
 
| 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?

It is. It's called TMCL.

| 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.

I agree completely. That one of the reasons why we see it as urgent to
finish the SAM so that we can move on to work on TMCL.
 
| 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.

I think it is important that we don't turn topic maps into a giant
monolith where you have to implement (and understand) everything to be
able to use it. I think it's very important to do like XML and layer
the specifications on top of one another so that you can use the bits
you want and disregard the bits you don't want. *And* so that if you
don't like TMCL you can use OSL or AsTMa! instead but still know that
you are using topic maps. (Obviously, it's also important that we
don't mess up the relationships between the layers the way XML has
done.)
 
| The "out of scope" argument, I must confess I don't understand and
| need for you to say a bit more about it.

That was basically what I wrote about "restatement" above.

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