TMRA2009 Key Note
- 1. NetworkedPlanet TMRA 2009 Opportunities For Topic Maps
- 2. Linked Data
- 3. Open Data
- 4. Schema Free Data ... and the languages that use it
Editor's Notes
- #3: Linked data – all about getting from one set of data to another related set of data using web protocols and RDF as the interchange syntax. Many topic map applications are out there running, but relatively few are exposing their topic map data. Notable topic map data sets include ??? TMDM -> RDF is a down-translation. Therefore TMDM should be the preferred storage format, RDF is just an interchange syntax. SPARQL is another key element of the Linked Data web, we need to create Topic Map stores that can answer SPARQL queries. Identifiers – everything else is mechanics. Identifiers are the crux of the issue. The Topic Map model of identity is the only one that really works on the Web, the RDF model is fundamentally broken and they know it. Identifiers require a resolution service that is in the layer above DNS. The service should be able to: Provide a list of representations of a subject given its identifier Provide a list of identifier equivalences where multiple identifiers all refer to the same subject Provide a list of identifiers of the subjects that consider a resource to be a representation
- #4: Information wants to be free. It also wants to be a topic map. Take free data and transform it to XTM fragments. Create new repositories of free topic map data. Create the client tools that help developers and real people use this open data. Not just point-to-point mash-ups and pretty maps but real client-side tools that retrieve and merge data from remote sources, using subject identifier resolution services to locate additional relevant data and dynamically typed and/or functional programming languages to make it easier for coders to manipulate, filter and present to end-users.
- #5: An explosion of data-bases for the duck-typed generation. “We don’t need no schemas, just give us key-value pairs.” When they realise how underpowered their key-value pair data model is for representing complex relationships between things, we should be waiting with the TMDM solution. This solution could be a topic map layer on CouchDB or Tokyo Cabinet, or it could be a RESTful topic map API that allows applications to GET, PUT and DELETE topic and association representations from a store. Whatever the back-end store solution turns out to be, it is also important that this store is tightly integrated in to dynamically typed languages like Ruby or functional languages such as F# or Erlang. These are the languages that best reduce the impedence mismatch between a flexible, ever-changing topic map ontology and a static “recompile if it needs changing” class hierarchy.