- From: Frank Manola <fmanola@acm.org>
- Date: Thu, 05 Jan 2006 11:42:29 -0500
- To: Tim Berners-Lee <timbl@w3.org>
- CC: Richard Cyganiak <richard@cyganiak.de>, Jan Algermissen <jalgermissen@topicmapping.com>, Timothy Falconer <timothy@immuexa.com>, semantic-web@w3.org
Tim Berners-Lee wrote: > > On Jan 4, 2006, at 14:23, Richard Cyganiak wrote: > >> >> On 4 Jan 2006, at 20:03, Tim Berners-Lee wrote: >> >>> One answer is: don't! The SemWeb is about conecting the data to >>> what it means. >>> Keep the data in the place where it works and runs fast. >>> Find/Write ontologies about what the data is about. >>> Run a virtual RDF server (supporting SPARQL if a large DB) on top of >>> the data. >>> publish the connection between the database columns and the ontolgies. >>> >> >> I don't get this last bit. Why would someone know what database >> column a bit of data comes from? Isn't this an implementation detail >> that should better be hidden from consumers of the RDF? > > > Sorry. I meant define it. Don't publish it widely. But internally, > this mapping is > what your code then uses to make it virtually part of the semantic web. > A few nits (which don't take away from Tim's basic point): 1. If you're going to provide a virtual RDF server for the data, then it's true that the mapping between the database columns and the ontologies is kind of "internal". But if you're going to provide some other kind of interface to the data, then it would be important to have the mapping from whatever is available at the interface (including the base columns, if that's the interface) to the ontologies, so that others could generate the RDF. 2. What you'd really like to have is as complete documentation of the data in the underlying database as possible, not just the mappings to ontologies. Lots of databases involve constraints and assumptions that are not necessarily expressed in available ontologies, or expressible in, say, OWL (having a rule language available could change that, depending on the capabilties of the language). Understanding those constraints and assumptions could be important in properly interpreting the data, whether it's generated as RDF or not. If you're providing an RDF interface, then by all means express those constraints and assumptions with respect to the RDF (and the ontologies you use). 3. The general principles here are "any Web access is better than no Web access", and "any metadata is better than no metadata". --Frank
Received on Thursday, 5 January 2006 16:40:52 UTC