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: [xtm-wg] A challenge on "the graph"



* W. Eliot Kimber
| 
| There are a zillion different name spaces in topic map (topics by
| base name, characteristics by scope, etc.). Each of these would be
| naturally modeled as some sort of dictionary or index in the
| processing model

Hmmmm. You would at least need to specify the uniqueness constraints,
and it may be that if you use groves you really ought to do it this
way. It may be a bit of a stretch to say that that makes groves
unsuited for the PM, though.

| But given Lars' other comments, I think that we are not all in
| agreement about what the processing model is.

That seems painfully clear, yes. :)
 
| Let me be clear: the processing model is the data model of what an
| API for operating on topic maps exposes. No more no less.

Agreed.

| Therefore it will by necessity have things like dictionaries because
| most of the operations on topic maps will be to LOOK THINGS UP.
 
Not agreed. A data model doesn't have operations.

| I have no idea what Lars thinks a processing model is, but it
| clearly isn't what I think it is.
  
My proposed requirements list probably expresses this best, but here
goes:

 - it should be an abstract data model suitable as a basis for the
   specification of TMQL

 - the abstract model should also restrict itself to formalizing the
   information structure of a topic map without wandering off into API
   territory (reasons: TMQL suitability, time required to finish,
   keep separate levels separated, create better basis for API spec)

 - it should have a mapping from and to both XTM and ISO 13250 syntax
   (ISO 13250 may be very difficult because of HyTime, but it should
   at least be attempted)

 - there should probably also be a mapping to the conceptual model as
   Nikita proposed


* Lars Marius Garshol
|
| I don't think they would have to be. Resources should IMHO just be
| represented as URIs, that is, strings. In any case, the prose could
| override undesirable features of groves.
 
* W. Eliot Kimber
|
| This is fuzzy thinking. What do you get when you dereference the
| URI? 

That is for the IETF to define. TopicMaps.Org can't start specifying
what happens when you dereference URIs. That's just way way out of
scope. 

| If you want to remain sane and have interchange you get grove nodes.

There's a lot to be said for that point of view, but XTM can't
unilaterally require that. To do so would make XTM unusable in a lot
of contexts where it currently is very very useful.

| That's why we invented groves, so you could talk meaningfully about
| what you get when you resolve an address. The Web punts on this
| issue and chaos results, with every MIME type providing a different
| way to access its content.

I agree wholeheartedly, but I don't think XTM is the correct vehicle
for doing anything about that.
 
| 13250 is an application of HyTime and therefore explicitly addresses
| groves.

Yes. XTM lives in a completely different context, however, as it must,
for political and practical reasons. The PM will have to reflect that.

--Lars M.


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
Do you have 128-bit SSL encryption server security?
Get VeriSign's FREE Guide, "Securing Your
Web Site for Business." Get it now!
http://us.click.yahoo.com/EVNB7A/c.WCAA/bT0EAA/2n6YlB/TM
---------------------------------------------------------------------_->

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

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




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


Powered by eList eXpress LLC