Dear Adrian,
You wrote:
Actually, one can sometimes, inside the black box,
code around previously implemented subsystems to get a clean semantics for a
clean author-programmer user interface. For example, SQL from vendor A has
different semantics from that of vendor B (Yes, really), but the black box can
know this and act appropriately. Similarly, the black box can assign simple
datalog semantics to RDF as in [1].
Not a beautiful approach, but it gets the job done.
Cheers, -- Adrian
Yes, that is true; it’s a result of
the skimpiness of the SQL standards, which all each vendor to mess with the
implementation in unforeseen ways. The vendors do it to keep their customers
from switching to other vendors.
But there are numerous add-ons to various
SQLs which have to be tailored to the particular SQL involved. Mostly, Oracle
and SQL Server have the largest library of add-ons, but even the low end stuff
like Firebird has the ability to add on embedded functionality.
The people who write the add-ons have to
deal with all that messiness and inelegance, but the SQL programmers can use
the add-ons with SQL, in most cases, with rather acceptable interface
consistency.
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Adrian Walker
Sent: Sunday, August 12, 2012
11:42 AM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Ontologies, knowledge model,
knowledge base
Hi Rich,
The following is hopefully relevant. It's from John's new topic
"Evolution of the Semantic Web" also on this forum.
------------------------------//---------------------
AW:
Actually, one can sometimes, inside the black box, code around previously
implemented subsystems to get a clean semantics for a clean author-programmer
user interface. For example, SQL from vendor A has different semantics
from that of vendor B (Yes, really), but the black box can know this and act
appropriately. Similarly, the black box can assign simple datalog
semantics to RDF as in [1].
Not a beautiful approach, but it gets the job done.
Cheers, -- Adrian
[1] www.reengineeringllc.com/demo_agents/RDFQueryLangComparison1.agent
Internet Business Logic
A Wiki and SOA Endpoint for Executable Open Vocabulary English Q/A over SQL and
RDF
Online at www.reengineeringllc.com
Shared use is free, and there are no advertisements
On Sun, Aug 12, 2012 at 1:58 PM, Rich Cooper <rich@xxxxxxxxxxxxxxxxxxxxxx>
wrote:
Dear Adrian and John,
My comments are below,
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
Hi John & All,
There's another dimension to the discussion about storing rules, triggers etc
in an SQL database.
As John has described, the result is a Rube Goldberg combination of different
semantics of different components, reminiscent of the OWL/RDF/SPARQL
"stack".
True, using domains as I suggested is by no means
an elegant solution, but it works.
Exposing these different components provides many job
opportunities for programmers, but un-maintainability comes much sooner than it
should as such a system scales up in complexity.
Also very true, but there is presently no
economical alternative that works well in products that are economic and
available and well supported.
Bottom line -- there should be a single clean
programmer interface with well defined semantics. The interface can be
implemented with different subsystems, but they should be completely hidden in
a black box.
Agreed also, but such an approach remains a
customization of existing products, mostly using domains as I suggested in the
previous email. There are other ways to do the same thing, but like you
say, they are all kludges in one way or another.
Just my 2 cents.
Thanks! Well worth the price!
-- Adrian
Internet Business Logic
A Wiki and SOA Endpoint for Executable Open Vocabulary English Q/A over SQL and
RDF
Online at www.reengineeringllc.com
Shared use is free, and there are no advertisements
Adrian Walker
Reengineering
On
Sat, Aug 11, 2012 at 8:41 AM, John F Sowa <sowa@xxxxxxxxxxx> wrote:
On 8/10/2012 4:51 PM, Rich Cooper wrote:
> The reason it is important to store rules as well as facts in the
> database is that such architecture makes it very easy to store a table
> of context IDs and relate them to which rules and facts apply to each
> context ID. Searching for contexts becomes very manageable with that
> method.
But
you need to do much more than storing and finding rules in order
to make a DB into a deductive DB. The critical task is to make the
deductive component a natural extension of the query component.
In SQL, for example, a view V uses a WHERE-clause to define
a *virtual* relation that accesses some logical combination of
other relations (which may be stored and/or virtual relations).
To an SQL user, V looks like an ordinary relation. But any use of V
will trigger a backward-chaining deduction that is similar to what
happens in a rule-based language like Prolog.
SQL implementations use a method of storing and indexing their
relations, either stored or virtual. But that method is separate
from the methods for storing data. If you store a view as data
in the DB, it will never get used as a view.
_________________________________________________________________
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
|
_________________________________________________________________
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)
|