finally a bnode with a uri

Posts tagged with: json

Upgrading an outdated CentOS-VServer to PHP 5.3 with JSON enabled

A very easy way to switch from a restricted PHP 5.2.6 to PHP 5.3.6 without destroying Plesk.
I'm slowly migrating my servers away from 1&1 to DomainFactory, a more modern hosting provider here in Germany. Slowly, because 1&1 has long-running contracts and I will have to keep a few machines until the end of the year.

So I still have a spare 1&1 VServer running a slightly outdated CentOS 5.4 or so which I would like to use for site previews and tests. Among other things, I'm exploring the possibilities of a simplified lib for Semantic Web development, which involves some of the newer features of PHP 5.3 in combination with JSON-based data processing (and possibly SQLite). Unfortunately, my VServer didn't provide either, and the server initialization panel doesn't offer any current OS, possibly due to the bundled Plesk.

Although I did manage to upgrade either CentOS or PHP via yum, each time I ended up with a broken Plesk. Day-long story shorter: I eventually found a nice and simple guide at webtatic.com that worked just fine. The trick is to keep the CentOS as-is (Plesk apparently has issues with certain versions of SSL) and to update PHP with 5.3 packages that still use the pre-5.3 naming scheme (i.e. "php-common" instead of "php53-common" etc.). This way you won't get module and dependency conflicts; the new PHP is just handled as a basic update :)

Here is a quick summary of the commands needed (via webtatic):
rpm -Uvh http://repo.webtatic.com/yum/centos/5/latest.rpm
yum --enablerepo=webtatic update php
And that's it. The only thing still missing is SQLite, which I didn't manage to get to work. The PDO extension is there, but PHP itself was initially configured as '--without-sqlite3'. For SQLite experiments, I will probably try JiffyBox, which I played with a little yesterday and which looks very promising.

Update: SQLite is now working, too.

JSONC, JSONI, JSONP: Creating tailored JSON from SPARQL query results

Returning SPARQL results as optimized JSON string
Update (2006-02-05): Elias Torres sent me a pointer to a draft of a related tech note he is working on with other DAWG members. I've adjusted my serialiser, so that its output is closer to their proposal now. After testing the different serialisation options, I've also updated the JSONI format. The examples below show the changes already.

My current sparqlet (SPARQL-driven portlet) implementations mostly use queries generated server-side, the results are returned as application-specific JavaScript. While this approach allows certain bandwidth and convenience optimisations, it always needs custom code on the server.

For generic operations, SPARQL endpoints offer an XML format which can be consumed by in-browser applications via XHR techniques. However, the SPARQL result XML format makes things quite bloated, and what I learned from Web 2.0 coders is that JSON results are often preferred.

It's rather straightforward to generate JSON code equivalent to the XML structure. I know that several people are working on this, but I couldn't find any public versions. I hope my ARC stuff isn't too different, but I can easily tweak it later. Here is a sample of a default SPARQL JSON result returned from an ARC server:
SELECT DISTINCT ?s ?p ?o
WHERE { ?s ?p ?o }
LIMIT 20
{
 head: {
  vars: ["s", "p", "o"]
 },
 results: {
  distinct: true,
  ordered: false,
  compact: false,
  indexed: false,
  bindings: [
   {
    s: {
     type: "bnode",
     value: "b2490b2520bf2872200093194ff36f465_id2245308"
    },
    p: {
     type: "uri",
     value: "http://xmlns.com/foaf/0.1/weblog"
    },
    o: {
     type: "uri",
     value: "http://www.nzlinux.org.nz/blogs/"
    }
   },
   {
    s: {
     type: "uri",
     value: "http://www.nzlinux.org.nz/blogs/"
    },
    p: {
     type: "uri",
     value: "http://www.w3.org/2000/01/rdf-schema#seeAlso"
    },
    o: {
     type: "uri",
     value: "http://www.nzlinux.org.nz/blogs/wp-rdf.php?cat=9"
    }
   },
     ...

  ]
 }
}  
(I'm using associative arrays for the bindings in order to reduce bandwidth a bit. Didn't put too much work into this default serialisation, it's probably going to change when there is a recommended format available.)

However, like the XML result, this JSON alternative is not the most efficient when a consuming app doesn't need the typing info of the individual bindings (uri/bnode/literal). I played around with some pre-defined "compact" JSON formats, but looking at the queries I'm using in my stuff, there are often cases, where I want the typing info for one or two of the bindings, but not for the rest. The solution I implemented for the ARC RDF Store looks like this: The user can specify an optional jsonc argument which defines whether a binding should be serialised entirely or if it can be flattened:
PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
SELECT DISTINCT ?p1 ?p1_name ?p2_name ?p2_mbox_sha1 WHERE { ?p1 foaf:name ?p1_name ; foaf:knows ?p2 . ?p2 foaf:name ?p2_name ; foaf:mbox_sha1sum ?p2_mbox_sha1 . } ORDER BY ?p1_name LIMIT 30
jsonc="p1(),p1_name,p2_name,p2_mbox_sha1";
{
 head: {
  variables: ["p1", "p1_name", "p2_name", "p2_mbox_sha1"]
 },
 results: {
  distinct: true,
  ordered: true,
  compact: true,
  indexed: false,
  bindings: [
   {
    p1: {
     type: "bnode",
     value: "b2e9ddd5ebb264646b852dcd207e13d8a_bn1"
    },
    p1_name: "Jim Ley",
    p2_name: "Jeremiah McElroy",
    p2_mbox_sha1: "f0d988b33153f21479cffa647cbe6faac65a98f8"
   },
   {
    p1: {
     type: "bnode",
     value: "b2e9ddd5ebb264646b852dcd207e13d8a_bn1"
    },
    p1_name: "Jim Ley",
    p2_name: "Mart Sanderson",
    p2_mbox_sha1: "ce3165ecf98cdb6d8153503949b320e24a6138a0"
   },
   ...
 ]
Appending parentheses to a result variable activates the complete serialisation, the other vars will be flattened. The jsonc parameter can also be used to remove selected result variables from the returned JSON. This may be helpful in in cases when they were needed to retrieve the SPARQL result set (e.g. in combination with DISTINCT), but aren't actually used in the client app.

JSONC can help reduce bandwidth and browser memory consumption, but it doesn't really add too much to the front-end developer's convenience. The RDF model is graph-based and resource-oriented, but SPARQL results are tabular with usually a lot of repeated values. Therefore a developer has to process the code before resource-centric views can be displayed. What's missing (if we want to avoid custom, server-side code or heavy pre-processing on the client) is a way to tell the SPARQL endpoint to arrange and index the tabular results before they are serialised as JSON: JSONI. The jsoni parameter works similar to the jsonc one, but it allows nesting of result vars to specify index structures:
jsoni="p1_name(p2_name)";
[codeblock { head: { variables: ["p1_name"] }, results: { distinct: true, ordered: true, compact: false, indexed: true, index: { p1_name: [ { value: "Jim Ley", type: "literal", index: { knows: [ "Jeremiah McElroy", "Mart Sanderson" ] } }, { value: "Leandro Mariano L

Archives/Search

YYYY or YYYY/MM
No Posts found

Feeds