OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [topicmaps-comment] TMs & XTM [Was: skills to create topic maps]



* Lars Marius Garshol
|
| We'll have a model, a specification describing how to process XTM
| documents into instances of that model, and a normative recommendation
| for how to get back to XTM documents. The first step will require
| certain kinds of merging to be performed.
 
* Murray Altheim
|
| Yes, and I mentioned that #1 would require this merging. Check that
| last sentence.

I did check it, but misunderstood it. If #1 requires all that merging
to be performed I have absolutely no problems with it, but then I
don't know what the difference between #1 and #2 is. Could you
explain?

(I'm not replying to the "danger" stuff as it seems pointless to tell
you what I think of a proposal I don't understand.)
 
* Lars Marius Garshol
|
| How will you explain the role of this form of normalized XTM in this
| context? I'm not necessarily against this, but I'm concerned that we
| need to end up with a coherent set of specifications at the end of
| the day. SC34's plans are now quite clear and coherent, and we need
| to make sure that we don't mess that up.
 
* Murray Altheim
|
| I think what you want is #2, below.

Well, no. What I want is a coherent set of specifications. If the ISO
stuff + #1, #2, and #3 is not coherent then me being happy about #2 is
not going to help. Of course, I can't claim that they will damage
overall coherency before I understand the difference between #1 and #2.
  
* Lars Marius Garshol
|
| This sounds like the result of following the XTM import/export
| procedure to be described by ISO, and then sorting the topics by some
| agreed procedure in the exported file. Sounds perfectly fine to me, as
| it would enable topic map work to be done using less powerful tools,
| which in effect makes topic maps easier to work with and easier to get
| started with.
 
* Murray Altheim
|
| Exactly. And a tool that did this I believe would be quite useful. 

I agree.

* Lars Marius Garshol
|
| [graph-normalized]
|
| This one I don't understand. What is it intended to achieve? How is it
| going to do that?
 
* Murray Altheim
|
| This represents a fully-processed XTM document, as according to the
| PMTM4 spec (or whatever is the end product of the ISO committee),
| but exported back to XML. 

I understood that, but I wanted to know what you saw the purpose of
that as being.

It's also worth noting that as currently planned there will be no
difference between documents processed according to the XTM syntax
spec and those processed in terms of the reference model (PMTM4).

If you read document 0278 you'll see that the plan is for the
deserialization specifications to map into the Standard Application
Model (a descendant of the infoset model), which again will have a
mapping to the reference model. So the graph and infoset
representations of an XTM document will be 100% equivalent. In short,
there will be only one "processing model".

(I'm referring to my understanding of the plan agreed on by SC34 in
Orlando here, not my personal opinion. Hopefully others will correct
me if they interpreted the Orlando meeting differently.)
 
* Lars Marius Garshol
|
| What issue, Murray? I see lots of them here, and I'm not sure which
| one it is you're looking to address.
 
* Murray Altheim
|
| By "issue" I mean the whole issue of canonicalization or
| representation of XTM documents in a way that allows checking for
| similarities or differences.

You mean checking using existing syntax-based tools, right? Because
presumably there will be tools based on the data model that do the
same, but these will be a while in coming, and in any case existing
tools will probably remain cheaper.

| In researching use of XTM in a conceptual graph/ontology usage I
| believe this will be necessary, esp. if an inference engine were to
| be desired.

This I don't follow. Why would you build an inference engine on top of
a normalized XTM syntax instead of on top of a topic map engine? If
you have a topic map engine you don't need a normalized syntax. And
doing it on a topic map engine would be an awful lot easier.

--Lars M.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC