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: [email protected]
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
=======================================================================
smime.p7s
Description: S/MIME cryptographic signature
