Hi Andy,
"How do you find the string?"
"The parser sees 'execSPARQL' '(' then what?”
"SELECT * { ?s ?p "I am a string with an unmatched ) characters” }”
Yes, i need to think more carefully on this. Perhaps, I need to do some
tests with the parser before.
About the problem of the mentors, I thought to motivate my supervisor to
be my mentor. Although he doesn’t know details about jena implementation,
he has a plenty of experience in prolog and he can give to me a good
support in inference questions. Issues about jena implementation, I can
always try with the community.
Do you think that this idea is viable?
Miguel
On 11/03/14 12:59, "Andy Seaborne" <a...@apache.org> wrote:
>On 10/03/14 23:07, Miguel Bento Alves wrote:
>> Hi Andy,
>>
>> Why not create a private word?
>>
>> Something like:
>> (?r rdf:type ex:Square) <-
>> execSPARQL(select ?r
>> where {
>> ?r ex:width ?width .
>> ?r ex:height ?height .
>> FILTER(?width = ?height) .
>> }).
>
>How do you find the string?
>
>The parser sees 'execSPARQL' '(' then what?
>
>how does it know where the close is?
>
>You can't call the SPARQL parser - the rules parser has already read
>ahead at least one char to deal with the '(' token. The SPARLQ parser
>needs know when the subparse has finished, especially as SPARQL has
>trailing elements like LIMIT, and if it sees the trailing ')' it will
>throw a parser error.
>
>You need to find the whole string, then pass it to the SPARQL parser.
>So how do you find the string? How do you find the matching ')' The
>SPARQL query has ')' in it. Why isn't that the end?
>
>Caution needed;
>SELECT * { ?s ?p "I am a string with an unmatched ) characters" }
>
>Hence the solution of ```
>
>See ```, skip to find the next ``` and then the bit in between is the
>string. ``` in SPARQL is very unlikely. It can be escaped if you want
>to do a complete job but this escape level is specific to the SPARQL
>string finder (remove before passing to the SPARQL parser).
>
>Let's make this a concrete dicussion. The rules parser is inner class
>Parser in com.hp.hpl.jena.reasoner.rulesys.Rule.
>
>What changes will be needed?
>
> Andy
>
>>
>>
>> Miguel
>>
>> On 10/03/14 15:16, "Andy Seaborne" <a...@apache.org> wrote:
>>
>>> 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)
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
