RE: OWL and LOD

Tim Berners-Lee wrote:

>I agree adding more OWN by degrees is a good idea.
>
>But what, John, would you mean by "mandate".
>
>Do you mean "When  I have said something about a class in OWL I'm
>happy for your to hold me to it",
>or "When  I have said something about a class in OWL, anyone calling
>themselves a Link Data client would be required to make the inferences
>from it."?

Having OWL in a triple store, and optionally below a SPARQL endpoint, can be useful independent of server-side inference:

* OWL-aware RDF browsers can exploit the OWL data to present additional "schema"-kind information to users, let them browse the class and property hierarchies, show what known instances a class has, which classes or properties are mutually disjoint, which properties are inverse to each other, etc. The OWL data can also be used to /reduce/ the presented information: for example, if there are two triples "x p y" and "y p x", where p is a symmetric property, then the browser can decide to only show one of the triples and tag the predicate as "symmetric".
 
* People can build their SPARQL queries by referring to the existing OWL data, and by this do a form of "poor man's reasoning" based on the given OWL. For example, one can exploit "owl:sameAs" triples to query for additional properties of a given resource by writing something like:

  CONSTRUCT { ex:foo ?p ?o . }
  WHERE { ex:foo owl:sameAs ?s . ?s ?p ?o }

* One can download (parts of) the data and do reasoning locally. No need to have the burden on the server. Maybe even some lightweight reasoning within the RDF browser by means of a Javascript reasoner. In any case, the used inference regime is then completely in one's own responsibility, so no one can complain about a wrong result set.

* The server still keeps the /option/ to do /some/ inferencing now or even more in the future, based on the existing OWL data. For many data services, the rule will be: "The more inferred data, the better.", without any requirement for completeness. And the server does not need to do the inferencing at query time, but can decide to do it nightly, or fill the inference graph incrementally by a low-priority thread.

Cheers,
Michael

--
Dipl.-Inform. Michael Schneider
Research Scientist, Dept. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schneider@fzi.de
WWW  : http://www.fzi.de/michael.schneider
=======================================================================
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
=======================================================================