[Nepomuk] RFC: The grammar of the new Nepomuk query parser

[Ignacio Serantes]

In a quick review sounds good. But I think there are two missing things:

1) Special values like *nexif:flash* and other nexif ontologies needs an
special treatment like the one in Nepoogle.

2) Direct and inverse relations (nesting using QueryParser documentation).

Actually QueryParser only support one level, "*nmm:Movie**:(title:Avengers)*",
but any levels must be supported like in Nepoogle and I think that syntax
it's not really clever because parentheses are needed to establish
precedence. In Nepoogle I using "->" and "<-" so "*
nmm:Movie:(title:Avengers)*" in Nepoogle is "*nmm:Movie->nie:title:Avengers*
".

 SELECT DISTINCT ?r WHERE { ?r nmm:Movie ?x1 . ?x1 nie:title ?v .
FILTER(bif:contains(?v, "'Avengers'")) . }

And an inverse method is needed to solve several situations, for example to
display all albums released in a year because this information is not in *
nmm:MusicAlbum* but in *nmm:MusicPiece*. In Nepoogle the syntax is "*albums:
nmm:musicAlbum<-released:2012*".

SELECT DISTINCT ?r AS ?id
WHERE {

  {

    SELECT DISTINCT ?r
    WHERE {

      ?r rdf:type nmm:MusicAlbum . ?r nie:title ?v .

    }

  }  {

    SELECT DISTINCT ?r
    WHERE {

      ?x1 nmm:musicAlbum ?r . {
          ?x1 nie:contentCreated ?v . FILTER(bif:year(?v) = 2012) .
        } UNION {
          ?x1 nmm:releaseDate ?v . FILTER(bif:year(?v) = 2012) .
      }

    }

  }

}

*nie:contentCreated* is the old method to store the release date in *
nmm:MusicPiece*.

Shortcuts are a good idea and I'm using it extensively on Nepoogle because
is more comfortable write *pa* than *performeralbum* or *ht* than *hasTag*.
# it's a little bit unclear but this could be solved with a good
documentation.

And a final question. As != means not equal and not exists so how are you
planning to detect when one must be used? In Nepoogle I hardcoded this, and
I don't like it, but I don't know any method to determine when and ontology
is storing a value or a resource.



On Wed, May 29, 2013 at 4:26 PM, Denis Steckelmacher <steckdenis at yahoo.fr>wrote:

> On 05/29/2013 04:07 PM, Ivan Čukić wrote:
>
>> Hi Denis,
>>
>> The proposal looks quite nice. If I may, I'd suggest a shorthand for the
>> hasTag - for example #dog to mean hasTag:dog.*
>>
>> One of the reasons (apart from greater usability) is that according to the
>> proposal hasTag:red herring would mean either
>>   - hasTag:"red herring"
>>   - hasTag:red contains:herring (implied property contains)
>>   - hasTag:red hasTag:herring (implied property hasTag)
>>
>> By allowing a shorthand for hasTag, you remove the need for that property
>> to
>> be an implied one.
>>
>>
>> Cheerio,
>> Ivan
>>
>> * firefox uses + for this, but I guess that # is more widely known thanks
>> to
>> twitter-like services.
>>
>>
> Hi,
>
> This is a great idea ! A string beginning with a # could be considered to
> be a tag and nothing else, and the lexer can be made to end #-prefixed
> strings at the first space encountered (thus making them one-word strings).
>
> I would not remove the implied hasTag, though, as I think that the parser
> must remain friendly to very non-technical people that don't know the
> hashtag syntax or don't know they can use it in a Nepomuk query field. If I
> type "holidays" in KRunner, and I have a "holidays" tag, the most pertinent
> result would be the list of my documents having been tagged as "holidays".
>
> Denis.
>
> ______________________________**_________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/**listinfo/nepomuk<https://mail.kde.org/mailman/listinfo/nepomuk>
>



-- 
Best wishes,
Ignacio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130529/9d87efad/attachment-0001.html>