Dear all,

as a preparation for the IKS Hackathon after the General Assembly and the 
step-wise integration of LMF with Apache Stanbol, I wanted to announce that we 
have now factored out the first LMF component into a separate, generic module: 
LDPath. 

LDPath is a query language for querying triple data similar to XPath, i.e. you 
follow edges through the RDF graph represented by a triple store or the Linked 
Data Cloud. I have created a homepage for the subproject under:

http://code.google.com/p/ldpath/

Currently, we have implemented the following modules:
- ldpath-api contains the interfaces for the implementation of the path 
language, in particular the interface 
at.newmedialab.ldpath.api.backend.RDFBackend that needs to be implemented by 
RDF backends
- ldpath-core implements the core functionality of the path language. The most 
central class in this module is simply called at.newmedialab.ldpath.LDPath and 
provides methods for evaluating simple paths or more complex path programs over 
the underlying triple backend
- ldpath-backend-sesame contains a generic backend implementation for Sesame 
triple stores; you can use it as an example for implementing your own backends
- ldpath-backend-file allows evaluating queries over a single file; a 
command-line interface for testing is provided (see project homepage)
- ldpath-backend-linkeddata allows evaluating queries over the Linked Data 
Cloud and implements the LMF Linked Data Caching mechanism for locally caching 
Linked Data Resources; a command-line interface for testing is provided

LDPath is completely independent of the underlying triplestore implementation, 
i.e. it would be easy to implement backends for Jena, Clerezza, ... Look at the 
RDFBackend interface and on the generic Sesame implementation on how to do it. 
We are using Java Generics in a perhaps unexpected way, so this might be a bit 
tricky at first ;-)

The LDPath modules are currently built using the Gradle build system, because 
it is the build system we are using in Salzburg NewMediaLab. It can, however, 
produce Maven artifacts that we have uploaded to our Maven repository.

The LDPath Maven modules can be used as a dependency (jar, source, javadoc) 
using the following settings:

Snapshots:
http://devel.kiwi-project.eu:8080/nexus/content/repositories/snapshots/

Releases (none available yet)
http://devel.kiwi-project.eu:8080/nexus/content/repositories/releases/

Both repositories can also be accessed through our maven proxy:
http://devel.kiwi-project.eu:8080/nexus/content/groups/public/

Group: at.newmedialab
Artifacts: ldpath-api, ldpath-core, ldpath-backend-sesame, 
ldpath-backend-linkeddata, ldpath-backend-file
Version: 0.9-SNAPSHOT (currently)


Lincense for all modules is Apache License 2.0. We took care using only modules 
as a dependency that are compatible with the Apache guidelines (so we had to 
e.g. replace XOM as XML framework with JDOM), but an additional check cannot 
hurt. I hope you can figure out how to work with LDPath based on these 
descriptions ;-)

Open tasks: better documentation, better configuration, more methods in LDPath 
main class, better OSGi support (currently we simply provide standard 
.jar-archives), and maybe a GUI for working with LDPath queries.

For the future, we are also considering moving additional parts into separate 
modules, which might make them easily usable for both, Stanbol and the LMF. One 
of these could be the LMF Reasoner, I am still considering how this can be 
achieved and what impact it might have.


Sebastian
-- 
| Dr. Sebastian Schaffert          [email protected]
| 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

Reply via email to