Re: ANN: LDPath - a path-based query language for querying the Linked Data Cloud

<sebastian.schaffert@salzburgresearch.at> wrote:
> Hi Joshua,
>
> Thanks for your hint to Ripple. LDPath was originally designed as a configuration language for our Semantic Search index, i.e. to specify how a resource should be indexed in Apache Solr and mapped to SOLR fields of different types. It turned out that it was used for more and more things, so we turned it into a separate language without much more conceptual thought in the hope that it was useful. So since we originally did not think about a path language for querying RDF or Linked Data, we did not look for existing languages.


Path languages do have a habit of emerging bottom-up.



> However, I see no problem with having YARPL as long as none of them are really standardized. After all, there are hundreds of wiki systems, dozens of databases, several triple store implementation, … ;-)


Sure, and mutual awareness helps to improve the quality of all of those tools.



[...]
> The statement regarding "more in line with Linked Data" is in comparison with SPARQL, which is too expressive to query distributed resources, especially when they are represented in the way Linked Data resources are represented.


SQUIN [1] is a good example of using SPARQL to query the Web of Linked
Data.  LinkedDataSail provides similar functionality.  Of course, not
all SPARQL queries are appropriate for querying Linked Data, but it's
certainly posible to write queries which are.  What with SPARQL 1.1
Property Paths, it's hard to come up with simple path queries over
Linked Data which you can't express in SPARQL.  IMO, some of the main
selling points of a dedicated path language are a less restricted set
of primitive functions, general-purpose control constructs like loops
and recursion, and the ability to reuse simple queries to build up
more complex ones, all of which add to the expressivity of the
language.



> Regarding the comparison you have below: they indeed look very similar. :-)  Personally, however, I prefer the XPath-style because it is what people know from file systems and XPath. Our users typically don't yet have a deep understanding of RDF or of functional programming, so we want to stick to what they already know as much as possible.


Even better, in my opinion, is a syntax which piggybacks on another,
mainstream language.  One of the nice things about the Gremlin
language I mentioned is that comes with Groovy and Scala bindings,
which makes it especially friendly for anyone familiar with either of
those languages.  Ripple now has Clojure (Lisp) bindings.  That way,
the user only needs to learn the abstract syntax of the language, and
it allows the implementation to be more easily embedded in other
applications.  In your case, if it's XPath your users are familiar
with, perhaps there would be some benefit in making LDPath an actual
subset of XPath.



> Greetings,
>
> Sebastian



Best,

Josh


[1] http://squin.sourceforge.net/index.shtml





>
>
> Am 01.12.2011 um 16:02 schrieb Joshua Shinavier:
>
>> Hi Sebastian,
>>
>> This is a nice and simple RDF path language.  The type system seems
>> especially handy.  However, you must be aware of the other RDF and
>> Linked Data path languages out there (particularly Ripple [1] and its
>> popular cousin Gremlin [2] when used with Ripple's Linked Data query
>> layer, LinkedDataSail [3]).  Can you talk about your use cases in the
>> Linked Media Framework which led you to invent a YARPL (Yet Another
>> RDF Path Language) instead of using one of those existing languages?
>> How is LDPath more in line with the way Linked Data resources are
>> accessed?
>>
>> Best regards,
>>
>> Josh
>>
>>
>> [1] https://github.com/joshsh/ripple
>> [2] https://github.com/tinkerpop/gremlin/wiki
>> [3] https://github.com/joshsh/ripple/wiki/LinkedDataSail
>>
>>
>> P.S. as a quick comparison, here's the example from your wiki:
>>
>> @prefix foaf : <http://xmlns.com/foaf/0.1/> ;
>> @prefix geo : <http://www.w3.org/2003/01/geo/wgs84_pos#> ;
>> title      = foaf:name | fn:concat(foaf:givename," ",foaf:surname) ::
>> xsd:string ;
>> summary    = dc:description :: lmf:text ;
>> lng        = foaf:based_near / geo:long :: xsd:double ;
>> lat        = foaf:based_near / geo:lat :: xsd:double ;
>> interest   = foaf:interest / (rdfs:label[@en] | rdfs:label[@none] |
>> <http://rdf.freebase.com/ns/type.object.name>[@en]) :: xsd:string;
>> friends    = foaf:knows / (foaf:name | fn:concat(foaf:givename,"
>> ",foaf:surname)) :: xsd:string;
>> contrycode = foaf:based_near /
>> <http://www.geonames.org/ontology#countryCode> :: xsd:string ;
>> type       = rdf:type :: xsd:anyURI ;
>>
>> And here's almost exactly the same example in Ripple:
>>
>> @prefix foaf : <http://xmlns.com/foaf/0.1/>
>> @prefix geo : <http://www.w3.org/2003/01/geo/wgs84_pos#>
>> @list p title:    (p foaf:name.) (p foaf:givenname. " " p
>> foaf:surname. concat.) both. apply.
>> @list summary:    dc:description.
>> @list lng:        foaf:based_near. geo:long.
>> @list lat:        foaf:based_near. geo:lat.
>> @list interest:   foaf:interest. rdfs:label
>> <http://rdf.freebase.com/ns/type.object.name> both. apply.
>> @list friends:    foaf:knows. :title.
>> @list contrycode: foaf:based_near.
>> <http://www.geonames.org/ontology#countryCode>.
>> @list type:       rdf:type.
>>
>> A couple of differences: 1) there's no filter on a null language tag
>> in Ripple, although you could filter on any non-null tag like "en". 2)
>> the Ripple version references the "title" path in the "friends" path
>> instead of repeating that logic.
>>
>>
>>
>> On Thu, Dec 1, 2011 at 7:22 AM, Sebastian Schaffert
>> <sebastian.schaffert@salzburgresearch.at> wrote:
>>> Dear all,
>>>
>>> I am proud to announce the availability of our path query language LDPath as Open Source query language for Linked Data. For example, you could select the names of all friends of a person using the following path statement:
>>>
>>>    foaf:knows / foaf:name :: xsd:string
>>>
>>> The full language is documented (more or less) at http://code.google.com/p/ldpath/wiki/PathLanguage .
>>>
>>> You can download LDPath at the project website at:
>>>
>>> http://code.google.com/p/ldpath/
>>>
>>> LDPath is a simple path-based query language similar to XPath or SPARQL Property Paths that is particularly well-suited for querying and retrieving resources from the Linked Data Cloud by following RDF links between resources and servers. The LDPath project is a collection of generic libraries that are independent of the underlying RDF implementation. Currently, there are backends for Sesame, for RDF files, and for Linked Data. You can easily implement your own backends by implementing a straightforward interface (RDFBackend).
>>>
>>> LDPath can serve many different purposes. It can e.g. serve as
>>> * a simple query language for selecting nodes or values in your own triple store programmatically from Java
>>> * a query language for transparently querying resources in the Linked Data Cloud and following links between datasets
>>> * a foundation for templating languages to render results based on RDF or Linked Data
>>> * a foundation for building a semantic search index (used e.g. in the Linked Media Framework and in Apache Stanbol)
>>> * a query language for experimenting with the Linked Data Cloud
>>>
>>> LDPath is obviously not the only implementation of a (path-based) query language for RDF or Linked Data. But we still thought it might be useful, as it is easier than SPARQL for novice users or simple tasks, and it is more in-line with the way resources in the Linked Data Cloud are accessed.
>>>
>>> LDPath has currently been integrated in our Linked Media Framework (as a means to configure Semantic Search) and in the Apache Stanbol project (for querying the cached data).
>>>
>>> If you want to try out the language, you can download one of the standalone jar packages. If you want to use it inside your own project, feel free to use our Maven repository to access the individual modules as dependencies.
>>>
>>> In case you encounter problems or have suggestions, feel free to contact us ;-)
>>>
>>> Greetings,
>>>
>>> Sebastian
>>> --
>>> | Dr. Sebastian Schaffert          sebastian.schaffert@salzburgresearch.at
>>> | Salzburg Research Forschungsgesellschaft  http://www.salzburgresearch.at
>>> | Head of Knowledge and Media Technologies Group          +43 662 2288 423
>>> | Jakob-Haringer Strasse 5/II
>>> | A-5020 Salzburg
>>>
>>>
>>>
>
> Sebastian
> --
> | Dr. Sebastian Schaffert          sebastian.schaffert@salzburgresearch.at
> | Salzburg Research Forschungsgesellschaft  http://www.salzburgresearch.at
> | Head of Knowledge and Media Technologies Group          +43 662 2288 423
> | Jakob-Haringer Strasse 5/II
> | A-5020 Salzburg
>

Received on Thursday, 1 December 2011 17:48:55 UTC