RDF development in PHP with a PostGreSQL triple store thanks to the LibRDF OO wrapper for redland/librdf

Redland/librdf offers powerful features like being able to persist an RDF model to a relational database (only PostGreSQL seems to work on my setup with 1.0.16, but I may have misconfigured it). You can then do SPARQL queries over the model, and lots of other nice things.

Unfortunately, the default PHP bindings are not really object-oriented, so the code isn’t looking so good.

But thanks to a gentleman named David Shea, there is an object-oriented library named LibRDF (case is sensitive), that helps write nice looking PHP.

I discovered it via the blog post of Felix Ostrowski, who took over the maintenance of the LibRDF library (still the docs live on the original author’s site).

In his post, Felix illustrates how you may use it to parse Richard Cyganiak’s FOAF profile.

But the examples he gives don’t illustrate the full potential of persistence of the RDF graph into the DB.

Here’s my contribution in 2 examples that will hopefully help : first, one that load Richard’s FOAF to the DB, and one, that later retrieve the saved model and perform the same query (both pushed to my github clone of the library).

There may be some problems with the use of librdf, including its availability, as it is not full PHP of course… and I’ve heard of memory management problems, but, depening on your needs, this may be quite handy for writing Linked Data applications.

The Debian Package Tracking System now publishes Turtle RDF meta-data

The Debian PTS now speaks the Turtle representation format for the export of RDF meta-data about Debian source packages.

Alongside HTML pages for humans, and the RDF/XML that had already been added to it this means that a new flavour of RDF is now available.

The Turtle format offers the benefits of both machine-readable meta-data, and a somehow human readable textual format too.

For instance, you may check the apache2 Turtle meta-data from the command-line with :
$ curl -L -s -H "Accept: text/turtle" http://packages.qa.debian.org/apache2

Here’s a link to a colorized HTML preview of http://packages.qa.debian.org/a/apache2.ttl.

Under the hood, the XSLT stylesheets of the PTS have been reworked to produce the Turtle format by default, and later convert them to RDF/XML.

Every Debian source package then has a reference URI in the Linked Data word, in the form http://packages.qa.debian.org/PACKAGE_NAME, that redirects, through proper content-negociation (the HTTP Accept header) to the HTML, RDF/XML or Turtle documents. For apache2, these are, resp. at http://packages.qa.debian.org/a/apache2.html, http://packages.qa.debian.org/a/apache2.rdf and http://packages.qa.debian.org/a/apache2.ttl.

The meta-data uses the model of the ADMS.SW ontology (1.0), and the content has also been slightly updated to make it more conformant to the ADMS.SW specifications (checks done with the ADMS.SW validator).

Let’s hope this makes RDF more familiar to Debian folks, and allows more Linked Data interlinking with other resources about FLOSS packages.

Debian Package Tracking System now produces RDF description of source packages

Here’s a second post on the subject of RDF descriptions for Debian source packages (see the previous post for some context).

From now on, the Debian Package Tracking System (PTS) will produce, alongside HTML pages meant for humans, RDF pages meant for Linked Data / Semantic Web aware applications.

Every Debian source package, which used to have an HTML page like http://packages.qa.debian.org/packagename now has a corresponding RDF/XML document available provided that the application/rdf+xml content-type is required (the HTTP client being redirected to the proper HTML or RDF document).
Continue reading “Debian Package Tracking System now produces RDF description of source packages”

Generating RDF description of Debian package sources with ADMS.SW

Edit : I’ve now managed to roll out my contribution which is now in production on packages.qa.debian.org. See a later post I’ve made on the subject, and beware that the generated RDF has changed a bit also.

ADMS.SW proposes specifications for description of software present in software catalogues.

I’ve tried and apply it to the contents of the Debian Package Tracking System (PTS), using transformation of the information known by the PTS to RDF+XML.

The result is not yet in production, but here’s an example of what can be done, using the Turtle syntax (more readable) :
Continue reading “Generating RDF description of Debian package sources with ADMS.SW”

Dynamically querying external (sub) projects properties with RDF in FusionForge

I’ve been working recently on two plugins for FusionForge. The work is somehow a POC for some COCLICO dynamic interoperability work-package, but some outcomes may actually be of use someday in real life, who knows 😉

The first plugin is called extsubproj, and allows the definition of links to external subprojects (i.e. hosted on another forge), in the properties of a FusionForge project. It’s basically managing a set of stored URLs and displaying them in the top project’s summary page. Nothing fancy, so far, and the code is not yet finished, nor pushed to FusionForge’s trunk yet.

The second plugin, called doaprdf, allows the publication, by the forge, on the same URL as the project summary page (those URLs are standardized in FusionForge in the form : http://.../projects/projname), of a RDF+XML description of some of the project’s metadata, using the DOAP dialect. This works with content-negotiation, following principles of the Linked Data paradigm, so that the same URL, when requested for HTML, renders a Web page (the forge project’s summary page) meant for humans^geeks, and when queried with a special content type Accept HTTP header (Accept: application/rdf+xml), meant for machines.

Now, when you combine these two, you gain the possibility of having extsubproj display not only the suprojects’ URLs, but also some of their meta-data, for instance a link in the form of <a href="http://.../projects/projname">fetched doap:name</a>.

The POC illustrates how one may then construct a hierarchy of (public so far) projects and sub-projects accross the buondaries for different forges databases, and display them in a similar manner as local projects (for instance, what the FusionForge plugin projects-hierarchy provides), through dynamic query of the remote project’s properties fetched on demand and modeled in a generic dialect (RDF with common ontologies such as DOAP).

Note that a similar FusionForge plugin “foafprofile" is being developped too for users profiles, using RDF and FOAF.

Stay tuned for more content in the same vein.