OK, looks like you convinced me - main points I got from it is that ASK is
query language with less flexibility, but with some inferencing capabilities
and still fast. Making alternative SPARQL / reasoner / formatter
implementation is much bigger task then I expected.
OK, then let's concentrate on different formatters, reasoning features and
query syntax that'll not kill the engine.
BTW, I'd like to discuss already old idea of predefined queries that can be
used to shorten the URLs, provide security restrictions and maybe something
else - will write another email about this.
Sergey
On Tue, Jun 10, 2008 at 5:22 AM, Markus Krötzsch <
[EMAIL PROTECTED]> wrote:
> 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]
>
> -------------------------------------------------------------------------
> 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
>
>
--
Sergey Chernyshev
http://www.sergeychernyshev.com/
-------------------------------------------------------------------------
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
