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"



* Lars Marius Garshol
|
| I have to say that I'm not at all happy with this model. Much of the
| intent I agree with, but the form it has taken I find repugnant in
| the extreme.

* Sam Hunting
| 
| Don't be shy Lars! Say what you feel? :-)

I did already! :-)
 
| Can you expand on both parts of your statement? (1) What do you
| perciee that the intent is,

What I meant was that much of the ideas expressed about what an
abstract topic map looks like I agree with.

| and (2) what's repugnant about the form?

That everything is reduced to three kinds of nodes, and that one of
those kinds of nodes (S-nodes) seems *beep*. Turning resources into
topics is just *beep* *beep* *beep*. There is more, but I have no time
right now to really explain this properly.

Also, the whole thing is based on association templates, which I think
has to be considered together with topic map schemas, and I think it
has to be developed a lot further than it has been to date.

| (The notion of nodes connected by typed arcs seems simple and
| elegant to me, but then what do I know?)

Well, it _is_ elegant in its quirky mathematical way; it's just so far
removed from what an implementation would look like that as a basis
for describing requirements for implementations it doesn't work very
well. It also requires considerable mental effort to piece together
what is going on there.

If you think there are only three kinds of things in topic maps, then
why doesn't the syntax reflect that? If the syntax doesn't reflect
that, why should the abstract model? If you've first gone to the
trouble of separating base names from occurrences, why squash the two
concepts back together in the abstract model? 

Also, specifying things like the TNC and the variant tree gets more
awkward when these things are treated the same way as occurrences (and
topics!). 

For the conceptual model to merge these topics is a completely
different thing and makes very good sense: it does so to point out
that these things are semantically related. 

Well, you ended up getting a rant on this anyway. I'm just sending
this off now, as I have no time to organize it properly.
 
* Lars Marius Garshol
|
| I would prefer the abstract data model not to use classes, since that
| would look altogether too much like an implementation and might cause
| problems for us if and when we want to make a standardized topic map
| API. This is also the reason why I'm not so keen on UML.
 
* Sam Hunting
|
| Lars, I am very glad to hear you say this. But property sets define
| classes, does not this objection apply to groves as well?

They use the term class, but those classes have no methods and any
implementor looking at them will immediately recognize these are not
classes in the sense that Java or UML classes are classes.
 
| Also, in some ways "not look like an implementation" is a really
| good general design criterion for PM. I should say, though (hoping I
| do not distort Steve's view) that one reason for typed arcs and
| property-less nodes was precisely so as NOT to look like an
| implementation. If this aspect of the PM is what you find repugnant,
| that's pretty ironic, eh?
  
Well, there can be too much of a good thing. If the goal is to get as
far away from what an implementation would look like at all costs, why
don't we just use a GIF of a hedghehog? :)

* Lars Marius Garshol
|
| That position I can't accept. This is as if I should say: [...]
 
* Sam Hunting
|
| I think this is a language issue of English between two non-native
| speakers. 

It could well be. Certainly I've misunderstood Nikita before.

--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