[sc34wg3] Removing added scope from <mergeMap>

[Graham Moore]

Hi all, 

>> Both Jim and I have already answered this issue -- mergemap is not solely
an authoring feature, it is very much a distribution feature, a necessary
one for modular Topic Maps.
And in my experience, nonmodular Topic Maps would be pretty useless.

>> That's an impossible distinction. Interchange is never strictly
representational. Modularity requires the ability to request a merge, and
every instance of an internal reference being traversed is "active" (no
longer declarative). And all of these are interpretable contextually, where
the context alters depending on both the place in the document lifecycle
(which itself is not necessarily linear) and the intended use of the
document (which varies as per the user).

I'll address the two together as I believe they can be, and I finish with a
proposal that *might* please everyone.

1. A representation of a state of a model at any given time is just that, a
snapshot. It has no semantics. Part of that model may be the result of some
processing and other parts could be intepreted in order to understand some
process but at a given point in time it has a representation and that can be
serialised and deserialised with no loss and no additonal processing. I can
think of several other things like this, UML XMI for example, generic
serialisation of a dataset.

2. You seem to think I dont want mergeMap for users. This is not the case.
Processing, i.e. Merging topic maps, defining dependencies is an author
convenience, distributed policy and processing instruction. These things are
often called units of work. Units of work can be seen as a transaction that
moves a given model from one state to another. These units of work also have
a data model and they could also be serialised. 

So as Kal positioned to the Editors this dependency, merging, packaging
information could be a seperate standardised portion of the topic map
standard.

Lets hack some XML

Dependency Language:

<deplang>
	<dep tm1="some_url" tm2="som_url" />
</deplang>

Merge Language

<mergelan>
	<merging tm1="some_url" tm2="some_url" />
</mergelan>

TM1
<topicMap>
...
</topicMap>

TM2
<topicMap>
...
</topicMap>

So, this to me looks like we've kept seperate the representation of the
model from a 'description' of the processing. 

Let me say this again. I am not against mergeMap or added themes as a
mechanism, but I would like it in a seperate part of the standard and not
clutter the representation syntax. The reason for me for keeping things as
they are is not becuase we cant seperate data models from processing models
but becuase people are already using the feature.

One suggestion where we can have our cake and eat it, is to layer the
Schemas. i.e. We have a base schema for just the representation, and then a
schema that extends that to basically contain processing instructions. Thus
those who want to indicate that their representation is that of a tmdm model
can do so, while those who want to emded merging instructions can do so
within the same document. This would require less of a shift to the Ahmed
model of seperate packing lang as illustrated again above, but would allow a
clean identifiable syntax that was purely for the representaion of a TMDM
instance.

Cheers, 

Graham


-----Original Message-----
From: sc34wg3-admin@isotopicmaps.org [mailto:sc34wg3-admin@isotopicmaps.org]
On Behalf Of M.Altheim
Sent: 16 January 2006 16:17
To: sc34wg3
Subject: RE: [sc34wg3] Removing added scope from <mergeMap>


Graham Moore writes:
>  
> I dont think that Lars Marius and I disagree with the value of being 
> able to attribute accountability or Scope when merging topic maps.
> 
> The decision for removing it from the syntax was two fold:
> 
> 1. we really were aiming for an interchange syntax and not an 
> authoring syntax and to this end were looking to remove constructs 
> that 'did stuff'. We wanted to remove mergemap altogether.

Both Jim and I have already answered this issue -- mergemap is not solely an
authoring feature, it is very much a distribution feature, a necessary one
for modular Topic Maps.
And in my experience, nonmodular Topic Maps would be pretty useless.
 
> 2. In general we wanted all processing and semantics to be external of 
> the representation syntax, i.e. Applications or external declaration 
> language.
> We were thinking about a family of syntaxes where interchange was 
> strickly representation.

That's an impossible distinction. Interchange is never strictly
representational. Modularity requires the ability to request a merge, and
every instance of an internal reference being traversed is "active" (no
longer declarative). And all of these are interpretable contextually, where
the context alters depending on both the place in the document lifecycle
(which itself is not necessarily linear) and the intended use of the
document (which varies as per the user).
 
> I want clean lines of distinction, modularisation, of the models and 
> syntaxes in the ISO Topic Maps family of standards. MergeMap is not 
> something I dont want, it is something that doesn't belong in the 
> representation syntax.

You won't get those clean lines in any model of any representation language
I know of, and removing necessary functionality from Topic Maps doesn't seem
to do anything except cripple them from being useful at the expense of some
notion of design elegance. I could give a rat's patootie about design
elegance if the damned thing doesn't work. 

Murray

......................................................................
Murray Altheim                          http://www.altheim.com/murray/
Strategic Services Development Manager
The Open University Library and Learning Resources Centre
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

     Short of taking the current president of the United States
     by the scruff of the neck and dunking his head deep into the
     rapidly melting Arctic ice cap, what more did the Earth need
     to do to make someone listen to its cry for help?
                                -- Simon Schama, The Story So Far
     http://www.guardian.co.uk/g2/story/0,3604,1675173,00.html
_______________________________________________
sc34wg3 mailing list
sc34wg3@isotopicmaps.org
http://www.isotopicmaps.org/mailman/listinfo/sc34wg3