On 9/25/13 12:32 PM, Barkmeyer, Edward J wrote:
>
> Kingsley Idehen wrote:
>
>> 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.
> 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". (01)
In my attempt to not mention RDFS and OWL (sensing they can be trigger
words for John) I ended up with a quite superfluous statement :-( (02)
Of course, the semantics facilitated by TBox and RBox statements don't
come into play, automagically . RDFS and OWL are crucial. (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. (04)
Yes, as per my *mea culpa* acknowledgement above. (05)
> 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. (06)
Yes, of course! (07)
>
>> SPARQL enables you query RDF model based structured data.
> 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.)
>
> 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. (08)
Yes. (09)
>
> 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. (010)
Yes, and that's what I demonstrate in my examples. Basically, how
reasoning and inference can scale while being applied to practical
problems. In the early days of RDF SPARQL didn't exist. When SPARQL came
a long it was challenged by performance and scalability. Today, as least
as far as we are concerned, the performance and scalability challenges
are history since we do have live instances of Virtuoso with 51 Billion+
triples against which anyone can perform ad-hoc queries that include
reasoning and inference. (011)
I am yet to find (modulo ours) a live SQL endpoint on the Web let alone
one that could be marginally exercised in comparative tests against
SPARQL where the challenge is all about demonstrable utility applied to
contemporary data access and integration challenges. I know
(wholeheartedly) that SQL will fail woefully !! (012)
> 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). (013)
Yes. (014)
>
> 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. (015)
Yes, and this difference is compounded by the nature of contemporary
data access, integration, and management challenges i.e., data being
disparately located, heterogeneously shaped (relational tables and
relation property graphs), voluminous, and volatile.
>
> -Ed
>
> 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. (016)
Hopefully, I fixed my careless statement about RDF, next time I won't
over-anticipate responses :-) (017)
Thanks! (018)
Kingsley
>
>
> --
> 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
>
> "The opinions expressed above do not reflect consensus of NIST,
> and have not been reviewed by any Government authority."
>
>
>
>
>
> _________________________________________________________________
> 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
>
>
> (019)
-- (020)
Regards, (021)
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen (022)
smime.p7s
Description: S/MIME Cryptographic Signature
_________________________________________________________________
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 (01)
|