Kingsley and Michael, (01)
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. (02)
KI
> As per my comments above, we do, and we always opt to demonstrate
> our understanding via live instances of Virtuoso. (03)
Yes. If they are specified precisely, they can be implemented.
But note Michael's comments: (04)
MB
> It is my impression from working with SPARQL and SQL that constructing
> and optimizing SPARQL queries is more difficult than SQL. (05)
There are two kinds of translations required: (06)
1. For constructing queries, it's necessary to translate questions
from humans (typically NLs or something easily mapped from NLs)
to the query notation. (07)
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). (08)
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. (09)
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. (010)
MB
> We all know that nary relations can be modeled with binary relations
> so what reasons could there be for nary relations ? (011)
There are two separate issues here: (012)
1. Teaching people how to state their problems (assertions, queries,
programs) clearly and precisely. (013)
2. Teaching them to formulate their statements in a way that a computer
can process them efficiently. (014)
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. (015)
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 ? (016)
If you can't keep it simple, nobody will use your system. (017)
John (018)
_________________________________________________________________
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)
|