Rather than "OWL vs. RDF", how about both? We used RDF for our
"instances" of measurement data and OWL as the semantic types for those
instances much like Bill suggests in the "OWL vs RDF" thread:

William Bug wrote:
For much of the semantic representation we need to do in large scale
biological data repositories, RDF alone will clearly be a sufficient
first step, so long as we continue to develop effective means of
expressing the triplets in the context of the ontologies and extending
the ontologies via analysis (as automatic as is feasible) of the
triplet repositories.

We expressed our triplets in the context of an ontology by linking our
RDF to OWL classes with RDFS. That way, we get the best of both worlds:
Whoever wants to query the data can use SPARQL or their favorite RDF
query language. Whoever wants to reason about our model (or the data)
can use an OWL reasoner. A hidden benefit is that, if the OWL model is changed, the data can simply be re-linked to the proper semantic types by changing relevant RDFS statements without needing to 'migrate' all affected datasets (such as would be necessary if OWL types were explicitly inserted in the RDF). See [1] for details (presented at the Knowledge Systems in Bioinformatics Workshop[2]). See also [3].

The type of data that we have been exploring is measurement data (> 11M
triples). It didn't seem like a good use of OWL to make an 'individual' for every measurement. Nor did it seem practical to require OWL reasoning to perform the simple type of (RDFS) reasoning that was necessary to link our data to its semantics (as Phillip Lord mentioned).

Having said that, we are a little curious about what OWL stores and
query engines such as Instance Store 2 can do with our data/query. Our
query/data combination seemed to find a bottleneck in RDF query engines
 -- something that we intend to follow up on.

-scott

[1]http://integrativebioinformatics.nl/docs/MarshallKSinBIT.pdf
[2]http://www.cs.rmit.edu.au/fedconf/index.html?page=ksinbit2006cfp
[3]http://integrativebioinformatics.nl/semanticdataintegration.html









Reply via email to