[topicmapmail] This is weird modeling, but is it valid XTM ?

[Murray Altheim]

Lars Marius Garshol wrote:
> * Lars Marius Garshol
> |
> | Actually, pointing to the ID of the <resourceData> element is
> | something you should not expect to be understood by XTM processors.
> | They discard that the ID on that element type when reading in the
> | topic map, so they have no way of knowing what it is you are
> | pointing to.
> 
> * Murray Altheim
> | 
> | Well, perhaps not your topic map processor. 
> 
> I'm talking about the current drafts of the standards, Murray, so
> unless we change it, this is what the standard will say. 
> 
> Which is why I mention it, so that people unhappy about it can
> complain. I strongly recommend careful reading of the next drafts of
> the DM and XTM that will be published in the coming months, precisely
> because they clear up a lot of issues like this one, and *after* the
> next drafts it will be very difficult to make substantive changes.

Well, I understand and to a great degree agree with you, but in our
desire to keep things reification-wise straight, those times when one
wants to talk about a specific XML/DOM Node, whether that's in an XTM
document, an SVG, or an XHTML one, dumping the incoming knowledge about
IDs and other XML-related things may be a bit dangerous.

> | But if you look at one of the very first public topic maps, core.xtm
> | (plus language.xtm and country.xtm, to a much lesser extent),
> | <resourceData> elements are pointed to as descriptions and/or
> | subject identity. 
> 
> I know, and I think that is acceptable, if imperfect. You then put the
> subject indicator one place, and don't duplicate it, and you have a
> real subject identifier. You can't really expect there to be much
> software that resolves the subject identifier correctly, but that's
> really the only problem.

But it's at least relatively simple to resolve it for applications
that want to. I now use Kal's engine for most of my TM processing
(esp. since I'm a committer on the project and have been able to
make minor changes that I needed), but I still keep my own engine
within Ceryle because it does keep track of this kind of thing, i.e.,
it pays attention to XTM syntax and the original XTM document.

> | It's a common practice AFAIK, and something I used to do fairly
> | frequently, [...]
> 
> You did it in those topic maps, and I've seen other people do it,
> citing those topic maps as the precedent, but that's the only examples
> of it I've seen.

I do agree that this is "mucking" at the syntax level, though one must
remember that at the time, under the intense pressure we were under
to deliver on deadline, and because we were in new territory, the
publication of PSIs was something that only in retrospect can we see
(perhaps) how best to approach. And even given a lot of thought about
it, there are still some use cases that seem unsolved.

And there are still some good reasons IMO to do this kind of thing,
it's just that we haven't found them all yet. I imagine that the
application of XTM syntax has yet to be explored in its entirety,
and especially as a foundation of TM/XTM projects continue to emerge
more will be found.

> | though now that I have my own PSI for topic descriptions I don't
> | need to.
> 
> Good.
>  
> | In a nutshell, when an XTM document is used as a source of PSIs,
> | this happens. Given that the OASIS PubSubj TC has published
> | recommendations which suggest using human-readable documentation,
> | this might not happen so often. 
> 
> Agreed.
> 
> | But for some applications people may still end up using XTM
> | documents for that purpose. I know several places in my own
> | application where I want XTM, not XHTML, as my PSI source.
> 
> Well, the question you need to ask then is whether you require the XTM
> processor to be able to understand what your subject identifier URI.
> If it's acceptable for it to simply use it to do merging without
> worrying about what it points to you should be fine.

As I mentioned above, I keep my old engine around because I do need
that kind of "understanding".

I imagine that as time passes a lot of the niggling problems that have
arisen as we investigate application of TM/XTM will shake out.

Murray

...........................................................................
Murray Altheim                         http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK                    .

    "Shhh. Be vewy, vewy quiet. We're hunting wabbits." -- Elmer Fudd

    "I don't know how close we are, closer than we were yesterday,
     I guess. All I know is we're on the hunt." -- George W. Bush
     BBC News: http://news.bbc.co.uk/1/hi/world/americas/3110615.stm