W3C home > Mailing lists > Public > semantic-web@w3.org > December 2011

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

From: Sebastian Schaffert <sebastian.schaffert@salzburgresearch.at>
Date: Thu, 1 Dec 2011 17:18:26 +0100
Cc: Linking Open Data <public-lod@w3.org>, "semantic-web@w3.org >> semantic-web@w3.org" <semantic-web@w3.org>
Message-Id: <EFB6DB2C-CDDE-4E89-BE6B-D5057EE21E08@salzburgresearch.at>
To: Joshua Shinavier <josh@fortytwo.net>
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. 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,  ;-)

Advantages/Use Cases of LDPath:
- it is completely backend agnostic and works directly with the data model of the underlying backend, so you can use it on whatever backend you have; this was a strong requirement for us, since the Linked Media Framework is using its own triple store, and Apache Stanbol is using Apache Clerezza as abstraction
- it is very lightweight - no new data models in your project, no conversions, no adapters between data models
- it is very efficient to evaluate, a criterion that was especially important for Apache Stanbol with its billions of triples
- it is used in industry applications based on Apache Stanbol and the LMF

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.

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.


Greetings,

Sebastian


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 16:19:11 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:41:30 UTC