[topicmapmail] Topicmaps and LINQ ??

Fri May 18 08:46:47 EDT 2007

Miles,

Thompson, Miles wrote:

>Hello all,
>
>No answers here, just questions.
>
>  
>
Well, no answers in response but some random musings. ;-)

>I wonder if anyone out there in TopicMap world has been thinking about
>whether TopicMaps is a fit (or not!) for the LINQ
><http://msdn2.microsoft.com/en-us/netframework/aa904594> style syntax
>that seems to be the latest trendy thing in programming.
>
>Just to give an idea what I'm talking about consider that...
>--
>..the following code snippet is NOT SQL this is pure C# (3) code.
>
>var productGroups = 
>   from p in products 
>    group p by p.Category into g 
>    where g.Group.Any(p => p.UnitsInStock == 0) 
>    select new {Category = g.Key, Products = g.Group}; 
>
>--
>And here's a sample from JavaFX Script, Sun's new scripting language..
>
>var titleTracks =
>  select indexof track + 1 from album in albums,
>    track in album.tracks where track == album.title;
>
>--
>
>I'm not really smart enough to see whether it would be possible to write
>a converter to would link up LINQ to TopicMaps, but I bet some of you
>out there must've been thinking about it. If so, what are your thoughts.
>
>--
>
>Apparently C# "LINQ" syntax can made to interact with data stored in all
>sorts of data formats simply by writing the relevant mapping/conversion
>layer - with the first implementations being for SQL databases (DLinq),
>XML documents (XLink) and in memory datasets.
>
>  
>
Hmmm, well I did look at one of the promotional pieces on the webpage 
and found:

> "If we're going to attack the dreaded so-called impedance mismatch 
> between program-type systems and back-end database systems and now add 
> XML to the mix, I don't think there are many people walking the planet 
> that have the expertise he has to pull this off," O'Kelly says.

(Under the section "The Hejlsberg Factor" at: 
http://reddevnews.com/features/article.aspx?editorialsid=707)

I am not real sure what "dreaded so-called impedance mismatch" the 
author is describing.

It really looks like they are embedding a query language in a language 
and then writing converters to make that work with arbitrary back-end 
database systems and XML.

Perhaps that reduces the amount of work for programmers and makes it 
easier to integrate querying in programs since the programmers will have 
only one interface to learn.

But, and it is a significant *but,* that does not begin to answer the 
more significant issue which is semantic impedance between systems.

While I can see how you could use topic maps to do the mapping that is 
ascribed to converters, query terms are after all subjects, I think 
there is a lot more that could be done with topic maps in such a 
context. Such as solving the semantic impedance problem.

Certainly being able to learn only one interface for querying multiple 
systems will be attractive to programmers but if the systems you are 
querying exhibit semantic impedance for their content, I don't know that 
you have really gained that much.

>I think it involves setting up lamda expressions or "expression trees"
>or something... 
>
>But even though I (clearly) have no idea what I'm talking about I can't
>help but imagine how neat it would to interact with TopicMaps in this
>kind of way - especially so if you had a totally dynamically typed
>language. Maybe you could do some kind of thing so that the TopicType
>names automagically map to the things that look like 'table' names in
>expressions like the above??
>
>  
>
Sure, see above.

>As Anders Hejlsberg says "of course, you could do this previously... but
>its very clunky and indirect... and by the time you are done it, it no
>longer looks like a query - right, I mean you may have abstractly in
>your head imagined a query but certainly looking at the code you don't
>see it any longer... but if you remove all the housekeeping and fluff,
>then out of the fog emerges .. this illusion of a query language -
>constructed as an API.."
>
>  
>
Well, that really depends upon how you expose the topic map doesn't it? 
In a programming environment, imagine for the moment that you use 
whatever query terms are standard in that language. Unbeknowst to you, 
when you select data sources, there is a topic map that has the mappings 
of the query terms you used to the appropriate query terms for that data 
source. That would depend upon there being such a mapping but there is 
no such thing as a free lunch. ;-) Someone has to do the grunt work of 
doing the mapping.

The advantage of a topic map in such a situation is that the maintainer 
of the mapping, probably some sysadmin or lesser familiar, would be able 
to debug the mapping on the basis of a unified view of all the mappings 
for a particular query term in the local language.

>--
>
>So what do you say out there?
>
>Even if you don't have any definitive answers, I for one would love to
>hear any initial reactions or speculations.
>
>
>  
>
Beyond the simplier problem of the query terms, it would be possible to 
have other mappings that bridge the semantic impedance between data 
sources, again without the programmer or any user even being aware that 
such a process was occurring in the background. After all, if I am 
searching for a particular individual, I don't really care how various 
data sources (for the most part) have decided to organize their data. 
What I do care about is getting a result that is expressed in some 
terminology that I understand and is about the individual (or other 
subject) that I am looking for.

While the "how" is vitally important to us as architects of such 
systems, we have to be mindful that users are going to be more impressed 
by useful results than systems that are "in your face" with our 
cleverness. I think the very best systems perform a task well and 
completely opaquely to the average user. When was the last time you were 
really curious about a bank ATM? It works (mostly) and functions as 
expected. How that is done is really not important to the average user.

>I found the following great interview with Anders Hejlsberg (from
>somewhere north of Poland! ;-) to be very informative on this subject
>(and in this he does talk about deferred execution and ways to make it
>not so horrendously inefficient as it looks like it would be at first)
>
>http://blogs.msdn.com/charlie/archive/2007/01/26/anders-hejlsberg-on-lin
>q-and-functional-programming.aspx
>
>As he says "its not like we invented all this, we just came up with a
>new way to put it together.."
>
>  
>
Thanks for the link!

Anyone who finds that interesting may also enjoy:

The Functional Approach to Data Management: Modeling, Analyzing and 
Integrating Heterogeneous Data by Peter M.D. Gray, Larry Kerschberg, 
J.H. King, Alexandra Poulovassillis (Eds.) ISBN 3-540-00375-4, 
Springer-Verlag.

Pricey but I think worth a visit to your local university library.

Hope you are looking forward to a great weekend!

Patrick

>--
>
>Thanks for your thoughts (if any)
>
>Miles Thompson
>Sentient Sentient
>CreditSights Inc
>
> 
>_______________________________________________
>topicmapmail mailing list
>topicmapmail at infoloom.com
>http://www.infoloom.com/mailman/listinfo/topicmapmail
>
>
>
>  
>

-- 
Patrick Durusau
Patrick at Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work! 