Re: [xtm-wg] An XTM test suite

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Graham Moore
|
| I agree with Lars that this a important thing to get done. I also
| strongly agree with Steve that the current processing model is not
| as rigerous as we need it to be.

I guess it is no secret that I also agree strongly with this. :)
 
| I would suggest that the Processing Subgroup (I think it exists
| formally? - eric?) would do well to concentrate its efforts in
| producing the appropriate formalism.
 
Yes!

| So to move on I am proposing that the processing model group builds
| its model based on the work that steve had begun and both Kal and I
| have worked on - and anyone else who has the time and inclination to
| contribute to produce a model of what an internal topic map looks
| like.

I'm hoping that Geir Ove and I will be able to contribute to this
work. Exactly how is not yet clear, but this is our hope.
 
| To avoid the problems of implementation specifics or one mechanism
| over another I would further suggest that we encode our model using
| a number of representations:
| 
| 1. Grove Definition
| 	Nodes and Properties
| 
| 2. Entity Relationship Diagram
| 	Entities with properties and relationships
| 
| 3. RDF triples
| 	subject, propname, object
| 
| 4. Mathematically formal
| 	N E Name = {N1, N2, ...} 		(Object Name)
| 	O E Object = {O1, O2, ... } 		(Object)
| 	ROW E Env = Name ->(func) Object 	(Naming Function)
| 	T E Topic = {N1, N2, ...}		(Topic)
| 
| This will easily map onto each other for the job that we need to
| do. And we will have an unambigous and rigerous model from which to
| clearly define the processing model.

Hmmmm. I'm not happy at the prospect of there being several models in
different formalisms. I agree with SRN that each has its own
mindshare, but this is still the high road to bloat, inconsistency and
furthermore means more work (which probably implies delay).

If groves were better-known I would have argued for using them, but as
it is I am more uncertain what to choose. EXPRESS would also be very
good, but it is not too well known, either, although it seems easier
to learn. RDF and mathematical formalisms have the same problems.

Whatever we choose I think it has to be made clear in the
specification that one of these representations is the normative one,
and that the rest are only informative. And in fact it may be better
to just define one model in the specification, but to put the others
out as separate informative documents.

--Lars M.


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/337252/_/982493127/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com