Relationship to RDF
From LDTables Wiki
The Linked Data Tables system has been designed to be 100% compatible with RDF, but it can (hopefully) be used without any knowledge of RDF. If you already know RDF or want to use RDF tools with your Linked Data Tables, this page explains the details of the relationship.
text below is somewhat out of date
As a technology, Linked Data Tables is just another RDF serialization, like RDF/XML, N-Triples, or RDFa. It's a way of constructing and interpreting HTML tables such that all RDF Graphs can be serialized as a collection of these tables, and each (well-formed) table can be parsed to an RDF Graph.
Some principles behind the design of LD Tables:
- The links in RDF become links in HTML, so the resource structure remains the same. In HTML, the link structure is visible to users and can be explored using any Web browser.
- We use only the commonplace, user-visible features of HTML. LD Tables can be constructed in wiki markup languages and using WYSIWYG HTML editors. The only attribute you have to use is a.href. (For some data, you also have to either use the id attribute or use multiple HTML pages.)
- LD tables look natural. Users can usually understand them without explanation. CSS and AJAX can be used to make them look great, be interactive, or be invisible.
- No RDF software, or knowledge of RDF, is necessary for creating or consuming LD Tables. Users only get RDF/XML dumped at them if they click on an RDF button.
The basic approach:
- Each table heading (<th> element) contains a link to a definition of that heading. That definition controls how cells with that heading are mapped to RDF. So, for a machine to read the data out of an LD table, it has to follow the <th> links. If it can understand the heading definitions, then it can turn the table data into an RDF graph.
- In most contexts, we use indirect identifiers, referring to something by using the web address of some content about that thing. While the preferred direct identifier for Tim Berners-Lee is "http://www.w3.org/People/Berners-Lee/card#i" (which just gets raw RDF/XML), for indirect identifiers you can use Web address like http://www.w3.org/People/Berners-Lee/ and http://en.wikipedia.org/wiki/Tim_Berners-Lee . In general we handle this difference gracefully, so RDF tools see direct identifiers and HTML tools see indirect identifiers.
[edit] some text to merge in
Every Linked Data Table maps to an RDF graph. The basics of the mapping are straightforward:
- Each entry in the table maps to an RDF node. (Entries are rows in top-heading tables and columns in side-heading tables.)
- Each heading maps to a predicate.
- Each (non-heading) cell maps to an arc in the graph. The end of the arc depends on the contents of the cell and the format of the associated heading.
Roughly speaking, Example 1 maps to this RDF/XML:
<rdf:Description> <rdfs:label>Paris</rdfs:label> <ns:country>France</ns:country> <ns:population rdf:dataType="&xs;integer">2203817</ns:population> <ns:founded rdf:dataType="&xs;gYear">-4200</founded> ...
There are some complexities, however.
- RDF always uses direct links; it doesn't even have the notion of indirect links. (cf RDF Identifiers) LDT allows both, with a strong preference for indirect links. So, some mapping between the two styles is necessary. Proper mapping from indirect identifiers to direct identifiers require using an on-line service, such as TableGate.
- In all RDF serializations, certain blank nodes need temporary, local-scope names for transmitting certain graphs. In RDF/XML, nodeID is used.
- RDF allows multiple values for one subject/property pair; tables usually do not. In LDT, we use "multi" formats to provide matching functionality.
- RDF does not, in general, constrain the range of properties; in one graph, some values of dc:creator might be strings while others are nodes representing people. In LDT, the same format applies to all table cells with one heading. The RDF functionality can be done either by using multiple smaller tables or by using formats which include a type indicator.
