On 09/03/14 22:35, Miguel Bento Alves wrote:
Hi Andy,

"I wonder if it might be better to build a new syntax for "SPARQL Rules"
which is SPARQL inspired using BGPs"

Yes, it is a good possibility. You, better than me for sure, know the
issues carried by the syntax.

And, what about something like:
(?r rdf:type ex:Square) <-
        {select ?r
        where {
                ?r ex:width ?width .
                ?r ex:height ?height .
                FILTER(?width = ?height) .
        }}.

The issue is to be able to find the SPARQL string part.

The easiest way to integrate the two is to be able to take a SPARQL
query string out of the rules syntax, and call the SPARQL parser on the
string.

But that needs finding the string to be identified before calling the SPARQL parser.

Putting inside some obvious delimiters is one way but { ... } is not
simple because {} occurs inside SPARQL itself. (yes you can count nestings .. until it appears in a ""-string as a single brace).

It's like the CDATA problem in XML.

One way is to use a delimiter that is not SPARQl related.

``` springs to mind and then just assume it never occurs inside SPARQL, or of it does it's needs special quoting like \''' if used in rules. This is all outside the SPARQL parser. It's just trying to
find the start and end of the string to pass to the SPARQL subsystem.

Whatever way you choose, it's need at least tinkering with the current
rules parser, or building a new syntax for "SPARQL Rules" (more work).

How comfortable are you in modifying the parser or creating a new one?

        
the ideia is combine SPARQL with rules. I will be possible rules like:

(?a ?b ?c) <-
        (?a ?b ?d),
        {select ?a
                where {a? ?e ?f .}
                group by ?a
                having (count(1) > 1)
        }.
        
Do you think that is complicate? However, I think that there is no problem
to have rules only based on SPARQL.

BTW, do you think that I can get a mentor for this project?

As you'll have noticed, we are mentor-limited.

Some of the projects, JENA-632 (Custom JSON output) and JENA-491
(CONSTRUCT quads), aren't going to happen unless a mentor appears.

I can deal with at most 2.

And if it aligns in some way with my day job, that makes 2, rather than
1, more likely.

        Andy


Miguel



On 09/03/14 17:42, "Andy Seaborne" <a...@apache.org> wrote:

On 05/03/14 10:09, Miguel Bento Alves wrote:
Hi Andy,

Below, a first draft how a SPARQL command can be defined in a Jena rule.
In example 1) is defined that a
given student is diligent in a given class if he doesn't fail more than
1
lesson of that class. As this command has an aggregate clause, in the
best
of my knowledge I can’t express the same thing with owl or rules. In a
same situation that I have in a project that i’m developing, I bypassed
using the clause "construct" and load the result to the data repository.
However, I cannot do this with dynamic data.

Example 2) and example 3) I took from http://spinrdf.org/. I know that i
can do the same thing using rules. However, SPARQL is a very expressive
command and there are several situations that we can better express in
SPARQL than in rules.


Example 1)

A given student is diligent in a given class if he doesn't fail more
than
1 lesson of that class.

prefix exa: <http://www.example.org/example#>

(?s ex:isDiligent ?c) <-
        (select ?s ?c
        where {
                ?s exa:enroledAt ?c .
                MINUS {
                        select ?s ?c
                        {
                        select ?s ?c (count(1) AS ?nc)
                        where {
                                ?s exa:failsTo ?l .
                                ?l exa:isLessonOf ?c .
                        }
                        group by ?s ?c
                        having (?nc >= 2)
                }               
        }
        }).

Miguel - combining parsers is hard. Parsers have a nasty tendency to
lookahead in the input stream so you can't just hand an input stream to
a another parser especially one that looks for EOF.

Either some easy delimiter on the SPARQL expression (but messy as it'll
imply escaping in that string) or a use the SPARQL parser machinery.

I wonder if it might be better to build a new syntax for "SPARQL Rules"
which is SPARQL inspired using BGPs


{?s ex:isDiligent ?c } <-
        { select ?s ?c
        where {
                ?s exa:enroledAt ?c .
                MINUS {
                        select ?s ?c
                        {
                        select ?s ?c (count(1) AS ?nc)
                        where {
                                ?s exa:failsTo ?l .
                                ?l exa:isLessonOf ?c .
                        }
                        group by ?s ?c
                        having (?nc >= 2)
                }               
        }
        } .

{?r rdf:type ex:Square} <-
        {select ?r
        where {
                ?r ex:width ?width .
                ?r ex:height ?height .
                FILTER(?width != ?height) .
        }}.


Such a syntax would need to sort the functors out somehow but if SPARQL
forms are inside {} (c.f. nested SELECTs ... and {} are useful as
delimiters fo rthe end of the query) bare "functor(name, name, ..)"
should work (I haven't tried).

        Andy

                

Example 2:
A rectangle is square if the width is equal to the height.

(?r rdf:type ex:Square) <-
        (select ?r
        where {
                ?r ex:width ?width .
                ?r ex:height ?height .
                FILTER(?width != ?height) .
        }).

err - FILTER(?width = ?height) ?!


Example 3:
The area of a rectangle is the product between the width and the height.

        
(?r ex:area ?area) <-
        unbound(?area),
        (select ?r ?area
        where {
                ?r ex:width ?width .
                ?r ex:height ?height .
                bind( ?width * ?height as ?area ) .
        }).

(?r ex:area ?area) <-
        bound(?area),
        (select ?r ?area
        where {
                ?r ex:width ?width .
                ?r ex:height ?height .
                bind( ?width * ?height as ?a ) .
                FILTER (?a = ?area) .
        }).



Miguel

On 05/03/14 08:03, "Andy Seaborne" <a...@apache.org> wrote:

Hi Miguel,

So that we know we're talking about the same thing, do you have some
concrete examples of what the SPARQL commands would look like?

This isn't to fix the design in anyway, just to have an illustration of
the ideas for the moment.

        Andy

On 04/03/14 18:18, Miguel Bento Alves wrote:
Dear all,

I¹m Miguel Bento Alves, I¹m a Phd student in New University of
Lisbon. I
want to develop the project described below, that was proposed by
myself,
in Google Summer code 2014. I need a mentor with knowledge about how
Jena
is implemented to give me the guidelines to implement the project and
supervised my implementation.

Best regards, Miguel Bento Alves

On 04/03/14 18:09, "Miguel Bento Alves (JIRA)" <j...@apache.org>
wrote:

Miguel Bento Alves created JENA-650:
---------------------------------------

               Summary: Define SPARQL commands in Jena rules
                   Key: JENA-650
                   URL: https://issues.apache.org/jira/browse/JENA-650
               Project: Apache Jena
            Issue Type: New Feature
              Reporter: Miguel Bento Alves


The goal of this project is allow the definition of SPARQL commands
in
Jena rules. Thus, we increase the expressiveness of Jena. Something
look
alike is spin-rules, where SPIN means SPARQL Inferencing Notation, a
SPARQL-based rule [1][2]. However, the purpose is not to implement
SPIN
in Jena but provide Jena with the mechanisms to take the same
expressiveness as the spin frameworks.

The main tasks of this project are:
        1. Defining how a SPARQL command can be declared in a rule. This
task
encompass the discussion with the Jena community.
        2. Provide Jena with the mechanisms defined in 1.

[1] http://www.w3.org/Submission/2011/SUBM-spin-overview-20110222/
[2] http://www.w3.org/Submission/2011/SUBM-spin-sparql-20110222/



--
This message was sent by Atlassian JIRA
(v6.2#6252)









Reply via email to