DataBinding

From W3C Wiki
Jump to: navigation, search

Data Binding

This is the idea of making it easy to transform back and forth between a program-native data format, and RDF.

 RDF <---> (your programs data format)

For example, imagine you have a simple program:


#!python

web_pages = { "Lion Kimbro": "http://www.speakeasy.org/~lion/",
              "Christophe Ducamp": "http://wiki.crao.net/index.php/ChristopheDucamp/",
              "Alex Schroeder": "http://www.emacswiki.org/alex/",
              "Mattis Manzel": "http://www.mattismanzel.net.tc/", }

for name in web_pages.keys():
  print web_pages[ name ]


We're doing everything in terms of a dictionary.

I don't know about you, but when I program Python, my data is rarely in the form of a graph.

It tends to be in the form of:

  • lists, dictionaries,
  • strings, numbers,
  • composites of the above,
  • and objects

But rarely in the form of a graph.

So this idea is to make it so you can express data bindings between your particular programs arrangement, and RDF graphs.

This is related to query languages (please link this up!), but it is different, (or perhaps "additional,") in that it links straight to a form that your program likes.

See Also

  • XML Data Bindings - this is the same sort of idea, but for XML documents, rather than RDF

Discussion

The example models/contains some domain-specific information, but the relationship is hard-coded in the dictionary. So a question is - why use data bindings to a generic structure such as a dictionary? Might it not make sense to model the domain directly as RDF:

foaf:Person[ foaf:name "Lion Kimbro" foaf:homepage "http://www.speakeasy.org/~lion/" ]

btw, I'm not unsympathetic to the aim - a while ago I put together some Java code to store application config data as RDF/XML effectively as dictionary, it went something like:

Property[ key "foo" value "bar" ]

--DannyAyers

It seems like you are asking: "Why not just use graphs internally?"

I don't know. I think that's a good question.

By "good question," I mean:

Either we can use graphs in our programs, and we just aren't in the habit of doing it- We should ask ourselves "how can we program in a way that uses graphs internally?"

Or: We can't use graphs internally (or, it's hard to use graphs internally), and so we aren't. In that case, we should ask ourselves: "What is it about using native data structures that is easier, what is it about working with graphs that is harder, and what can we do to bridge between the two?"

I heard of some talk where someone was saying that graphs should be a basic Python datatype, and that we should have built-in tools for dealing with graphs in Python.

I don't know if it's a good idea, or if it would just be too weird to handle.

-- LionKimbro DateTime(2004-07-05T21:07:40)