Re: LDPath: a path language for querying Linked Data

[Enrico Daga <en...@gmail.com>]

Dear Sebastian, all,

I answer to this mail to re-start a discussion about the LMF reasoner
and Stanbol.
AFAIK, it is event based, so it can be efficiently used as incremental
reasoner, bound to the triple store.
I am interested on implementing this, possibly jointly with someone
that already knows LMF.
What do you think could be the right starting point for achieving this?
In my idea it would be:
1) having an event handler bound to the clerezza tcmanager
2) define an interface for event based reasoners
3) implement bindings to the LMF reasoner, giving the possibility to
configure multiple reasoners using component factories.

For 1) and 2) I would like to start seeing how this is done in the
current implementation. Can you describe (just in general) how this is
done?

And, of course, WDYT?

Enrico

On 15 November 2011 17:46, Sebastian Schaffert
<se...@salzburgresearch.at> wrote:
> 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          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
>



-- 
Enrico Daga

--
http://www.enridaga.net
skype: enri-pan