Kingsley Idehen wrote: (01)
> I am implying that FOL should be an integral part of the underlying data
> representation. With that in place you can then use a query language to
> exploit expressiveness.
>
> RDF does enable the incorporation of FOL into structured data
> representation. (02)
NO. It doesn't. RDF has a restricted FOL interpretation. That interpretation
allows the use of some FOL reasoning about the information represented in RDF.
The point is that that interpretation is a formal part of the meaning of the
RDF language, which gives RDF statements a well-defined logical interpretation,
unlike XML elements. But every RDF predicate you invent has whatever
interpretation the author gives it, and RDF does not give the author a way to
formally define a predicate. In general, it is extremely difficult to state
axioms in RDF, because the language lacks quantification and implication terms.
Some of that shortcoming is repaired by RDF Schema, and a great deal more
logical expressiveness is provided by OWL. So, RDF statements of fact,
accompanied by an OWL ontology that provides an FOL model of the concept
structure in which the RDF verbs appear, "enables the incorporation of FOL into
structured data representation". (03)
By the same token, if I have an OWL ontology for the concept structure, and a
formal mapping of XML types and structures to concepts in the ontology, then an
XML resource that uses only those types ALSO has an FOL interpretation. The
difference here is that OWL can be used directly to define RDF predicates; it
takes an additional formal language to define the formal foundation for the XML
structures. But in both cases, the real "incorporation of FOL into structured
data" requires the terms to be defined/axiomatized in an ontology written in an
FOL language with sufficient expressiveness, e.g. OWL. Otherwise, all you get
out of RDF is: Name1 gibberishVerbX Name2. (04)
> SPARQL enables you query RDF model based structured data. (05)
Yes, and it is defined to do "natural joins", without the requirement for you
to tell it (as in SQL). That is the extent of the FOL value of the RDF
semantics. (The term "natural join" id RDBMS land, refers to joining two
tables by pasting together one row from table A with one row from table B where
the key value for the A row and the key value for the B row are identical.
That is the mathematical interpretation (a la Codd) that has the obvious FOL
interpretation, supposing, as RDF does, that the key values refer to individual
things, and that the other columns of each table represent functions whose
domain is the things the keys refer to.) (06)
We have never had problems assigning FOL semantics to data that was rigorously
modeled and properly queried. That was the whole point of Codd's work (and for
all that, of Steve Mellor and some of the other O-O apostles, or Sjir Nijssen
and Terry Halpin). The step forward in RDF is that the formal logic
interpretation, however limited, is a part of the definition of the language,
as opposed to a value introduced by a rigorous engineering practice. That
said, the real rigorous engineering practice for RDF was built on it with RDF
Schema and OWL. (07)
In a related way, SPARQL per se does not support anything more interesting than
natural joins, unless it is coupled to some more advanced reasoner with an
ontology for the concept system in its back pocket. And any data system that
supports queries can be made to support FOL interpretation, if you formulate
the queries based on an ontology in your back pocket. What Codd/Mellor/Nijssen
suggested is that good modeling practice is the formulation of that ontology,
but their formal modeling languages were divorced from the implementation tools
(and generally somewhere between RDFS and OWL in expressiveness). RDF, RDFS,
and OWL, by comparison, are implementation languages that can be used directly
in SPARQL engines (and others). (08)
The important breakthrough here is that we now have IMPLEMENTATION languages
for the FOL knowledge models that support structured data representation. RDF
is just the surface language for the data. It is only better than XML or SQL
by allowing the ontology-defined verbs to be used directly, as opposed to
requiring a formal mapping. (09)
-Ed (010)
P.S. I don't doubt for a moment that Kingsley realizes this. I just get
worried about pithy bald statements that are inaccurate to the point of
misleading. I will happily leave the rest of the debate to others. (011)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Systems Integration Division, Engineering Laboratory
100 Bureau Drive, Stop 8260 Work: +1 301-975-3528
Gaithersburg, MD 20899-8260 Mobile: +1 240-672-5800 (012)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (013)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (014)
|