RE: [xtm-wg] Equivalence between TM,RDF,Conceptual Graphs?

["Danny Ayers" <danny@panlanka.net>]

<- > I don't quite understand... you'd have a type something like
<- > "INT+VARCHAR(10)" ???
<- >
<- Think of a row as being like a struct in C or a record in Pascal
<- - there are
<- a number of slots, each slot may have a different type.  The
<- struct itself
<- can be thought of as a type.  A row instance would be like an
<- instance of a
<- record or struct.

Got it now, thanks.

<- As I re-read your original post, I see you are more thinking of
<- the metadata
<- rather than the data, so I may have been adding confusion in my
<- response.  I
<- was thinking more of capturing actual row data in the TM.
<- Still, metadata
<- queries are likely to return row data, too, so the principles may be the
<- same.

Yep, the more I think about this the more self-similar it seems at different
levels

<- By metadata, do you mean basically the database schema?

That's certainly where I'm starting.

 I'd at least as
<- interested in the view and query definitions, since they are how
<- you can get
<- data into or out of a database.

Good point.

 In a proper database application, all
<- access to the data is through predefined queries.

Extremely good point - I keep forgetting that.

 So the right metadata
<- would seem to be the returned data types for each query, or the data type
<- you need to feed to an update query (I'm using "type" in my
<- previous sense
<- as the type of a row).

That makes sense.

<- It seems to me that if you put such a row type definition into a TM
<- association, and each member of the association refered to a topic that
<- described its data type, perhaps using xml-schema data types,
<- you'd be in a
<- good position to define classes or whatever from the TM.

Time to get the TM notes out...

<- To be complete, you'd really want to figure out how to capture
<- the integrity
<- constraints.  That may be impossible in general, since there can
<- be stored
<- procedures that get triggered by inserts, deletes, etc, and you probably
<- can't get and understand those in an automated way.  But at least the
<- standard relational integrity constraints (from the foreign key
<- definitions)
<- would be important.

Yep - the constraints strike me as being very important, though it might
well be hard work (everything so far has been considerably harder than I
expected!). I'm not even going to think about dealing with stored procedures
& triggers...

Thanks again. I've now got plenty to keep me going ;-)

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/