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] Equivalence between TM,RDF,Conceptual Graphs?



<- I don't really have any pointers.  Maybe someone else on the list?  I do
<- have a few (fairly obvious) thoughts.  A rdbms returns sets of
<- rows.  Taking
<- C. J. Date's

(a search on this name was very productive indeed!)


viewpoint, a row's type is a "relation" - a good
<- candidate for
<- a TM association.  The type of a row is the union of each of its column
<- types.

I don't quite understand... you'd have a type something like
"INT+VARCHAR(10)" ???

Each actual row is an instance of that type.   Each role
<- in the TM
<- association would be one of the column types (or labels) of the returned
<- data.  The whole association would be an instance of some
<- association topic.

hmm - I'm wondering where the line is between generating/showing metadata
and merely transforming the data itself into different views


<- The main issue to deal with,as I see it, is that the XTM dtd
<- doesn't allow a
<- member of an association to have just string data, it is supposed to be a
<- hyper-reference.  Specifically, it is supposed to be a simple
<- xlink element.
<- I think this makes it unduly clumsy when you only want to supply
<- strings, as
<- you might want to in your case.

Thanks for this - just the kind of info I need

<- I doubt that you would want to create a separate topic for the
<- value of each
<- cell in each row, for example.  With a computer generated topic map, you
<- certainly could, but it seems like a lot of overhead for very
<- little return.
<- It would also make the xml serialization extremely hard for a person to
<- comprehend, since data values that should be seen together would
<- be spread
<- out.
<-
<- The approach I have favored to get around this issue is to make
<- the data for
<- each cell a uri using the "data:" scheme.  Of course, all
<- processors may not
<- understand this scheme.  Maybe others on the list can provide a better
<- approach (hint, hint!).

this sounds very promising - though the cell uri would be the extreme case

<- (Parenthetically, I'd appreciate hearing from those who really
<- know (Steve
<- Pepper, perhaps?) why an association member can't contain PCDATA for its
<- value.  It has never made sense to me)
<-
<- Another thing to think about is that you could supply different
<- scopes for
<- different groups of results from the database.  This could turn
<- out to be a
<- very nice feature.

could you expand? I'm not sure I understand what you mean

<- Finally, you might want to look at whether you can transform
<- your rdf into a
<- TM or vice-versa, maybe even with xslt.  Given the regularity of the data
<- from a rdbms, this is likely to be feasible.

that's not a bad idea at all - I've got a big red XSLT book with a bearded
bloke on the cover somewhere around... ;-)

<- Hope this is helpful, and let's have others pitch in here, if you would.

Most helpful, thanks a million.

Cheers,
Danny.


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