Dear John, (01)
Actually, AND OR and NOT functions can be
calculated, and usually are done so, with inverted
files inside SQL interpreters. That time is very
nearly linear rather than polynomial. The main
performance limitations in most SQL interpreters
is the time required to go through the disk access
at this time in technology. Calculation time is
so fast for this kind of query that RAID drives
are the preferred solution to performance problems
in large databases. (02)
-Rich (03)
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On
Behalf Of John F Sowa
Sent: Thursday, October 11, 2012 1:54 PM
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: Re: [ontolog-forum] [SMW-devel] [News]
Google, Microsoft, Facebook And Others Launch SMW
site (04)
Kingsley and Michael, (05)
JFS
>> People understand AND, OR, NOT, and EXISTS --
and their combinations.
>> They can be evaluated in polynomial time in all
SQL implementations.
>> But nobody, not even the SPARQL developers,
understand FILTER, OPT,
>> and UNION. (06)
KI
> As per my comments above, we do, and we always
opt to demonstrate
> our understanding via live instances of
Virtuoso. (07)
Yes. If they are specified precisely, they can be
implemented.
But note Michael's comments: (08)
MB
> It is my impression from working with SPARQL and
SQL that constructing
> and optimizing SPARQL queries is more difficult
than SQL. (09)
There are two kinds of translations required: (010)
1. For constructing queries, it's necessary to
translate questions
from humans (typically NLs or something
easily mapped from NLs)
to the query notation. (011)
2. For high-speed processing, the logical form
derived from point #1
has to be reorganized to reduce the number of
accesses to external
devices (disks or hardware). (012)
Since nearly all NLs support AND, OR, NOT, and
EXISTS, point #1 can be
supported fairly well by a language that uses
those operators. And
SQL implementers have 40 years of experience in
optimizing point #2. (013)
But FILTER, OPT, and UNION and their combinations
don't have a simple
mapping to or from any NL. And there are
publications that say that
many combinations of those three operators can be
NP complete. (014)
MB
> We all know that nary relations can be modeled
with binary relations
> so what reasons could there be for nary
relations ? (015)
There are two separate issues here: (016)
1. Teaching people how to state their problems
(assertions, queries,
programs) clearly and precisely. (017)
2. Teaching them to formulate their statements
in a way that a computer
can process them efficiently. (018)
Point #1 itself is hard, but it's possible. But
if we have to teach
them how to state their problems precisely (#1)
*and* optimize them
for the computer to process efficiently (#2), that
makes a difficult
problem nearly impossible. (019)
MB
> I see those potential reasons:
>
> 1) Simplicity of notation
> 2) Efficiency of computation (lookup, store)
> 3) Efficiency of reasoning
> ...
> But how important is reason 1 ? (020)
If you can't keep it simple, nobody will use your
system. (021)
John (022)
__________________________________________________
_______________
Message Archives:
http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr:
http://ontolog.cim3.net/mailman/listinfo/ontolog-f
orum/
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?WikiHomePa
ge#nid1J (023)
_________________________________________________________________
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 (024)
|