On Montag, 9. Juni 2008, Sergey Chernyshev wrote: > Actually, since this discussion turned to general query language > functionality, I want to voice another question I had some time ago - why > not to go standards way with complex cases? In two words, let's leave #ask > language for simple cases and current uses and employ SPARQL or other > standard languages to query the dataset, plus it'll allow to use separate > tools for that, e.g. that RAP instance that SMW started to integrate with, > second, it'll allow to use external sources as well.
Well, we already did that, and we plan to continue with this (support there
would be appreciated -- e.g. one could make new RDF-store bindings to stores
other than RAP). In any case, this way of SPARQL integration remains
available.
Using SPARQL in place of #ask looks not very attractive to me, because it
would require much additional syntax, without making current #ask features
obsolete (you still need the formatting parameters). Also, the way ?printout
statements work in #ask makes sure that you do not get results multiple times
for multiple combinations of parameters. Using SPARQL, many queries would not
work as in SMW, since one result table line in SPARQL can hold just one
element in each cell (compare #ask, where you could have a query for all
Persons each with all their affiliations and all their categories given in
one table row).
>
> I have a feeling that building querying functionality into SMW is a dead
> end as it's limited by so many factors and it's better to integrate
> external querying with ASKs presentation layer.
"Dead end" sounds like if you would wish to go further but can't. I think this
might be quite true in some sense. But also note that, right now, SPARQL and
#ask both have features that the other one lacks, e.g.:
SPARQL: more output filters, more complex query patterns, OPTIONALs in queries
#ask: logical inferences (equality, hierarchies), extra printout statements,
support for wiki datatypes & multi-valued properties
Note that the wiki datatypes in SMW are not in 1-to-1 correspondence with XML
Schema datatypes or RDF concepts that SPARQL uses. For example, wikipages
already have multiple components: a title-string, a namespace, an
interwiki-prefix. SMW allows you to use those components in querying. If you
map that to SPARQL, then you need an explicit auxiliary node for each
wikipage. Values with units of measurement have similar issues. Many wiki
types also have their own sanity checks (e.g. enumerated values, even when
used in queries, are checked for validity), and these checks are not
available in an off-the-shelf SPARQL engine. Casting #ask into SPARQL
therefore requires more syntax than one may at first expect.
Another (maybe minor) point is that SPARQL is conceived for RDF only, so that
it supports neither class/property hierarchies nor equality statements
natively (not to mention other features we may wish to add at some point).
There are extensions that still provide SPARQL engines with some reasoning
support, but that is not so widespread yet.
But the main problem with SPARQL is probably performance. SPARQL is inherently
much more complex to process than #ask (for those who know that stuff:
complexity of SPARQL is PSpace, which is beyond NP; #ask with reasoning is
P). But even besides this conceptual argument, many SPARQL filters are rather
hard to implement, and are not really working on many current
implementations. Regular expression matches on property values are an
example. Even simple SPARQL queries can be trouble. For example, you can
solve any Sudoku puzzle with a SPARQL query by just generating *all* possible
ways of completing the puzzle, and then filtering for those that are valid
solutions -- and this needs only very simple filtering and query conditions,
and a database with 9 elements (for 3x3 Sudoku)! Imagine how one would
implement such features efficiently in practice ... (theoretical facts on
computational complexity tell us that general Sudoku cannot be solved by any
#ask query, unless the query is very very large [1]).
This is also the reason why we do not publicly setup any RAP-based SPARQL
endpoint for our wikis. RAP's implementation is not bad, but it is really
very easy to make queries that freeze the server for minutes. So this is our
pragmatic reason for not using SPARQL: we are aware of no implementation of
SPARQL that does not easily blow up on certain queries, and it would be much
work to try building such a "safe" query engine from scratch.
Similar issues are of course found for SQL even though this is still a very
important and useful query language. One just rarely sees systems that let
users enter SQL queries to retrieve data ;-)
>
> Hope this makes some sense, please advise.
Summing up, we do not think of #ask as a non-standard replacement for SPARQL,
but as a UI concept of SMW that simplifies the syntax of queries. In
addition, #ask is constrained in such a way that it can be implemented rather
efficiently, which is an open problem for SPARQL. We still would like to have
some SPARQL webservice, maybe one that checks if a query can be expressed via
#ask and then computes the results for those and returns a SPARQL conformant
result set. Any takers?
Another remark: #ask is closely related to OWL (closer than to SPARQL). It is
very easy to map an #ask query to an OWL class description (the query then is
the task of finding all elements of the class description). One could also
offer a query service for that, maybe using DIG as a protocol.
Cheers,
Markus
[1] Or, of course, if P=NP. ;-)
>
> Thank you,
>
> Sergey
>
>
> On Sun, Jun 8, 2008 at 9:45 AM, Markus Krötzsch <
>
> [EMAIL PROTECTED]> wrote:
> > On Freitag, 6. Juni 2008, Sergey Chernyshev wrote:
> > > Can I suggest to use '->' instead of dots - this will make it much less
> > > probable to have in Property names, but still reasonable as syntax.
> >
> > I though about that one too, but I was not sure if it is preferred
> > internationally. Would the right-to-left languages be OK with that too
> > (it would of course be right-to-left as well, but still)? Do you think
> > there could ever be name clashes on "."? (Is there anyone who ever used a
> > "." within a property name?) I can do both ... whatever most users
> > prefer.
> >
> > Here is again the new proposal in comparison to the old one:
> >
> > {{#ask: [[works at->located in->population::>1000000]] }}
> >
> > Old:
> >
> > {{#ask: [[works at.located in.population::>1000000]] }}
> >
> > (Personally, I find the old slightly more readable, maybe because the .
> > is smaller and just one symbol).
> >
> > -- Markus
> >
> > > On Fri, Jun 6, 2008 at 6:02 AM, Markus Krötzsch <
> > >
> > > [EMAIL PROTECTED]> wrote:
> > > > Hi all,
> > > >
> > > > I have a proposal for a simplification in #ask query syntax that I
> >
> > would
> >
> > > > like
> > > > to get some feedback on.
> > > >
> > > > If you currently ask for property chains, you need something like the
> > > > following:
> > > >
> > > > {{#ask: [[works at::<q>[[located
> > > > in::<q>[[population::>1000000]]</q>]]</q>]]}}
> > > >
> > > > to find someone working at an organisation located in a place with
> > > > more than
> > > > 1000000 inhabitants. The many [[ and <q> are sure annoying.
> > > >
> > > > My proposal is to instead allow writing
> > > >
> > > > {{#ask: [[works at.located in.population::>1000000]] }}
> > > >
> > > > with exactly the same interpretation as above.
> > > >
> > > > Effects:
> > > > * "." in property names become problematic (though some escape can be
> > > > provided
> > > > to allow them),
> > > > * the syntax becomes shorter, and maybe also more readable.
> > > >
> > > > Would that be an improvement? Other comments? (There is also another
> > > > issue regarding the syntax with <q>, but I will have to check what
> > > > can
> >
> > be
> >
> > > > done there before proposing alternatives.)
> > > >
> > > > Cheers
> > > >
> > > > Markus
> > > >
> > > > --
> > > > Markus Krötzsch
> > > > Semantic MediaWiki http://semantic-mediawiki.org
> > > > http://korrekt.org [EMAIL PROTECTED]
> >
> > -------------------------------------------------------------------------
> >
> > > > Check out the new SourceForge.net Marketplace.
> > > > It's the best place to buy or sell services for
> > > > just about anything Open Source.
> > > > http://sourceforge.net/services/buy/index.php
> > > > _______________________________________________
> > > > Semediawiki-devel mailing list
> > > > Semediawiki-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
> >
> > --
> > Markus Krötzsch
> > Semantic MediaWiki http://semantic-mediawiki.org
> > http://korrekt.org [EMAIL PROTECTED]
> >
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________
> > Semediawiki-devel mailing list
> > Semediawiki-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
--
Markus Krötzsch
Semantic MediaWiki http://semantic-mediawiki.org
http://korrekt.org [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
