A JSON compatible serialization of RDF

JSON is a lightweight text-based open standard designed for human-readable data interchange.

That's not what we need.

We need a lightweight text-based JSON-compatible open standard designed for machine optimized RDF data interchange.

We need it to be JSON compatible because JSON tooling is widely implemented, JSON is well supported, embraced by most web development communities, and of course it's fast and simple.

Stress: It won't be JSON, it'll be JSON-compatible, and to avoid any confusion or indicating that it may be human friendly, we probably would be wise not to put the term "json" in it's name, although we will need to put it in the media type identifier "+json".

We need to standardize because there are numerous competing and differing JSON serializations at the minute, so when somebody asks for a JSON serialization on the web, they get back different results in different places - that's unexpected behaviour, and it's not interoperability - so we need to standardize a JSON-compatible serialization of RDF, with an IANA registered mediatype.

The serialization needs to be machine optimized and usable in multiple different scenarios, else there's no point standardizing it, because other JSON compatible serializations will still be needed and therefore created. Thus we need to define the various use-cases and create a JSON-compatible serialization which caters for them.

An RDF API

There's been a lot of call for cool RDF tooling, specifically in javascript, mentions of a jquery extension and a jquery-like library - I agree that would be nice, but also say why just one? I like and want choice, freedom and to see innovation in the marketplace, I don't just use jquery, I use more libraries and modules than I could name - however..

A library is not an API, and that's not what we need to standardize.

We need to enable interoperability between libraries, and where multiple libraries may or do have overlapping and conflicting functionality, we need to align and standardize it, but only when it produces unexpected behaviour or limits interoperability.

Primarily, this means standardizing interfaces for the RDF Concepts (literals, references, triple and graph) - as soon as we do that, all libraries which implement these interfaces will immediately become interoperable. Web Developers will be able to throw data between libraries, cherry picking the features they want or the coding styles they prefer, library implementers will be able to focus on areas they specialize in, others will be able to stun us with innovative new approaches and tools we'd never have thought of ourselves, and we'll have an open and ever growing truly cool suite of interoperable classes, libraries and tools.

Next up we can standardize interfaces for things like RDF Parsers, because as soon as we do that, all libraries on each specific platform can share parsers, and these can be developed, maintained and improved independent of any specific library - it will also allow the same libraries to be used with specialist low memory parsers optimized for mobile devices, thus broadening their potential user base and giving the end users + developers the best experience possible.

Another set of interfaces which need standardized, are those which are to be implemented by multiple different vendors on the same platform, i.e. the web browsers, i.e. anything near the DOM or HTML, i.e. the RDFa API - which is already being worked on.

Finally, an interface which will make linked data and RDF easier to work with by developers (carrying on from my previous post) is a "Data Object" interface, that is a simple object which holds the description of a single subject, where the properties are keys and the values are native values. I was wrong in my previous post, serving up simple JSON objects will help, but isn't perfect, because we don't know and can't determine whether people will want to use URIs, CURIEs or terms to access properties, thus an interface will be needed to handle this.

This isn't an exhaustive list, and each paragraph above can be considered to handle a different layer in the stack, but standardizing anything substantially more than that will stifle innovation and be counter productive, people need and want different libraries with different coding styles, features and different ways to access and query data. Different tools for different jobs, and for different people doing the same job.

If you disagree, please do share and let me know!

Clarification

Earlier this week I was quoted as follows:

Nathan’s recent post on Opening Linked Data, which is worth reading in its entirety, captures the essence of the issue:

You can’t shoe horn RDF in to JSON, no matter how hard you try - well, you can, but you loose all the benefits of JSON in the first place, because the data is RDF, triples and not objects, rdf nodes and not simple values

In other words, using JSON as the basis for an RDF syntax doesn’t actually win you anything in terms of the ease of processing of that RDF. In fact, I’ll go further and say it has exactly the same bad qualities as RDF/XML.

However I have to point out that I probably didn't make the context clear, I was referring specifically to making a human friendly/optimized JSON serialization of RDF, you can however, very easily, create a machine optimized JSON-compatible serialization of RDF, without the drawbacks of XML (you just don't pin it as being human friendly JSON as outlined above) because unlike XML which requires a full XML stack, and RDF/XML which can be serialized in any one of a billion ways, we have a chance here to make a clean lightweight unambiguous serialization of RDF, one which is based on a lightweight data interchange format and not on a heavy extensible document interchange format.

Hope that clarifies :)

Why? well the sem web community is packed full of the most technically skilled and decent people I've come across so far, so it can't be that, the tooling is pretty damn good, there's loads of data, most of the data's of a high quality, wanted by developers, and certainly more than usable. The concepts, theory and technical aspects are all solid as a rock. In short it's all good, apart from one rather important detail.

Our Linked Open Data isn't really open data, not in the eyes of the common web developer at least. To most web developers on the planet, open data is something they can get access to and use easily.

A good example of 'open data' for most developers, is the Twitter API.

Here's how a developer accesses it in PHP:

  $uri = 'http://api.twitter.com/1/statuses/show/7907258268647424.json';
  $tweet = json_decode(file_get_contents($uri));
  echo $tweet->user->description;

Here's how they access it in Javascript:

  uri = 'http://api.twitter.com/1/statuses/show/7907258268647424.json';
  $.getJSON(uri, function(tweet) {
    write( tweet.user.description );
  });

The reality of the matter is that you can't do this with Linked Open Data, and that's because you can't do it with RDF - and really, honestly, if it's not that simple, the masses won't use it, because, if it's not that simple, they can't use it.

The problems with the RDF formats

They're not perfect, and they are a very mixed bunch, for a change, let's look at the negatives.

RDF/XML
- Requires full XML tooling
- Can't read or write by hand
- butt ugly

Let's be honest, unless you have a full XML and RDF stack and you know what you're doing, RDF/XML is simply a no go zone.

RDFa
- Requires HTML/DOM/XML tooling
- An extension to a markup language, designed to augment annotated documents.

RDFa is great, but not for the general data use case, it's not a simple data interchange format like JSON, and you can't publish or consume it without specialist tooling, in fact it requires an even bigger, more complicated, stack than RDF/XML.

Turtle
- Requires a custom parser
- It's not yet seen as a data format by the masses.
- Doesn't have a registered media type.

If we're all honest, Turtle is the king of RDF serializations, it's small, powerful, easy to write and read, requires minimal tooling to parse. In fact, I'd quite happily say that Turtle is the best all round data format, period.

RDF/JSON and JSON-LD
- Square peg, round hole

You can't shoe horn RDF in to JSON, no matter how hard you try - well, you can, but you loose all the benefits of JSON in the first place, because the data is RDF, triples and not objects, rdf nodes and not simple values - I fear I'd better explain, quickly:

The benefit of JSON is that you can do the following:

  var u = tweet.user;                                // nested, simple objects
  write(u.message);                                  // simply "a string of text"
  if(u.geo_enabled) {                                // a boolean true
    var d = u.statuses_count * u.favourites_count;   // numbers..
  }

Anything more complicated than that and you've lost 95% of the benefits of JSON.

Here's the code to do that if(u.geo_enabled) with JSON/RDF:

  var tweet = rdf['http://example.org/tweet/12343'];
  var user = rdf[tweet['http://example.org/property/userid']];
  var geoenabled = user['http://example.org/property/geo_enabled'];
  if( Boolean(geoenabled.value) ) {

and JSON-LD:

  var tweet, user;
  for(o in jsonld) {
    if(jsonld[o]["@"] == 'http://example.org/tweet/12343') tweet = jsonld[o];
  }
  for(o in jsonld) {
    if(jsonld[o]["@"] == tweet['twit:userid']) user = jsonld[o];
  }
  if(user['twit:geo_enabled']) {

Remember, those two examples are only for the simple if line from the benefits of JSON example, can you even imagine all four lines?

Clearly, RDF in JSON is of little to no use to anybody, you can see plainly yourself, 95% of the benefits are lost and it's just another RDF serialization that's pretty much unusable without tooling. The only benefit JSON serializations of RDF have, are that you don't require an XML stack, which is quite a large benefit tbh.

The problem with RDF

I've been a little unfair there, you see the problem isn't with the serializations, we can't make a "better" serialization of RDF for general web developers, because the real problem is that the data's RDF, it's triples not simple objects, URIs rather than simple terms, RDF Nodes with a language or type, and not just simple values.

An array of RDF triples, or a structure of RDF, just simply isn't usable in most (all?) programming languages, by a typical web developer, without specialist tooling and libraries or APIs.

Am I saying RDF is bad? no of course not, it's awesomely brilliant in every way, it powers a paradigm shift and will have huge positive effects on the web and the human race. You know the score :)

What I am saying, is that we're not backwards compatible, we're not making our data open in formats which are usable by normal developers, developers who need and want the data, want the links, but not the semwebbery. Hell even most of us who are heavy sem web users only consider the ontology+reasoning side enabled by properties-with-uris some of the time, most of the time <http://xmlns.com/foaf/0.1/name> might as well just be "name".

Opening Linked Data

So, here's what we need to do, we need to just accept that although we publish linked data as RDF, we also need to publish the data as simple objects so the world can use the data.

Given the linked data:

  @prefix : <http://webr3.org/nathan#> .
  @prefix foaf: <http://xmlns.com/foaf/0.1/> .
  @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

  :me a foaf:Person;
    foaf:age 29;
    foaf:holdsAccount [ foaf:accountName "webr3";
        foaf:homepage <http://twitter.com/webr3>;
        rdfs:label "Nathan's twitter account"@en ];
    foaf:homepage <http://webr3.org>;
    foaf:knows <http://example.com/bob#me>;
    foaf:name "Nathan";
    foaf:nick "webr3", "nath" .

  <http://example.com/bob#me> a foaf:Person;
    foaf:name "Bob" .

We also need to publish it like this:

{
  "http://webr3.org/nathan#me": {
    "a": "http://xmlns.com/foaf/0.1/Person",
    "age": 29,
    "holdsAccount": {
      "accountName": "webr3",
      "homepage": "http://twitter.com/webr3",
      "label": "Nathan's twitter account"
    },
    "homepage": "http://webr3.org",
    "knows": "http://example.com/bob#me",
    "name": "Nathan",
    "nick": [ "webr3", "nath" ]
  },
  "http://example.com/bob#me": {
    "a": "http://xmlns.com/foaf/0.1/Person",
    "name": "Bob"
  }
}

and now one can do: me.holdsAccount.label and get back a string, in any language.

What have we lost?
Well nothing in the grand scheme of things because we're still publishing the RDF in other formats via conneg, however in this specific serialization of the data: we've lost the properties, the .language and the .type, although basic types are still there, dates are detectable, numbers are supported, booleans are supported, everything else is just a PlainLiteral, a string.

What's still there?
The data, http names for things, follow your nose, rdf types ++usable-accessible-data in a web standard format. It's 3.5 if not 4.5 star data!

Other considerations
Probably be wise to allow direct access to a .json URI too, so people can simple-GET the data (in addition to exposing via conneg).

Should be an easy hit, any good reasons why not?

The other RDF Serializations

While we're here, there are a few other things that need tidied up, properly.

Turtle
Let's make it the standard RDF serialization, with a proper registered media types of application/turtle and text/turtle, fix any bugs in the spec (if any), and possibly allow an optional comma in those lists (1,2,3).

Let's just accept that RDFa is great, but sometimes you just want to embed a chunk of RDF in an HTML document, you know we all want to on occasion, people are shouting for it, it's easy to do, to deploy, doesn't break anything, and it's a really easy hit - so, in the Turtle standard spec pop a note that shows how to include it in an HTML document.

<script type="text/turtle">
  // turtle in here, as-is, no special encoding
</script>

RDF/XML
Leave it as is, let it run it's course naturally, and in many respects just forget it moving forwards, everybody supports it already, that won't change, but there's approximately zero need to keep pushing it.

RDFa
As awesome as it is, just see it for what it is, RDF in attributes, it's like the missing markup features of HTML, for annotating documents and describing the things described in the documents with annotations. It's not a simple data or RDF format, and it's not really suited to just dropping chunks of machine readable RDF in to an HTML document, Turtle in HTML will do that far better.

RDF/JSON and JSON-LD
Standardize a JSON serialization as a replacement / alternative to XML - but, admit and stipulate before hand that it's not usable as-is, or really writable and is arguably human readable. It simply needs to be a fast, unambiguous, optimized for the machine, RDF serialization - no bells and whistles for humans, no "12^^xsd:type" in a string - just something that you can JSON.parse and run circa 10-20 standardized lines of code over to get back an RDFGraph of RDFTriples.

Fin & end.

There have been some nice examples of combining client and server side js recently, and node knockout is sure to provide many more real soon - if you don't know of node.js I'd recommend taking a look. Also worth noting the realtime client push service, Pusher (for HTML5 WebSockets) - of course there are also node implementations, and here's a nice article with some more details and examples.

I've also been playing with some of google's projects (radar check, you know about the ajax playground ya?), namely Fusion Tables (here's one) which has a full REST API, infact that's what it is, a kinda web db merged with csv merged with RESTful goodness - and you can use them with V3 Maps which gives some really sweet results - like this heatmap of designated beaches on the coast of Brazil. Convergence check, you noticed that protovis can be used with google maps ya?

If there's one app I wish google would opensource, it's Google Moderator for an example see the one for TipJar. Btw, did you see 3D Lego Star Wars running in Chrome with HTML5 (credit to Unity 3D truth be told) - oh, and if you ever wondered how those 3D Lego videos we see on youtube all the time are made, you'll be looking for this.

Generally I'm really admiring ushahidi (projects on github), and especially Swift River and SiLCC - there was a good post on 10 ways to use Swift River which is certainly worth a read. Related, but don't ask why, here's a good post on prediction services which has a few good links. Crossover check, remember earlier I mentioned Fusion Tables w/ Maps V3 and Protovis.

Digital Bazaar have been working on a Javascript implementation of TLS (part2) namely Forge - code on github -explaining why this is such a big deal is outside the scope of this post, but I'd encourage you to look at PaySwarm and Digital Bazaar's fantastic blog which'll give you a good overview of what they're up to. Related and similar, it's worth noting jsSHA - a JavaScript implementation of the entire family of SHA hashes, random.org for all the true random data you could need, Bitcoin a peer-to-peer network based digital currency and amf.js a js implementation of AMF. Also there's the HTTPS Everywhere extension for Firefox.

And in non technical land, I've really been enjoying How to be a Retronaut, it features amazing media from the past, such as Colours of the Rothschilds… which amongst other things has a colour photograph of King Edward VII, taken in 1909 - other recent favourites include the Eiffel Tower being built, the first ever music video (1895) and the instant eye of Jacques Henri Lartigue.

If you haven't seen Hans Rosling's talk on global population growth go watch it now, v recommended - and finally, they figured out what came first, the chicken or the egg..

I'm assuming that if you are reading this, you know what linked data is, and REST as per the dissertation of Roy T. Fielding. If not go do some reading :)

Interface Constraints

REST is defined by four interface constraints:

1. identification of resources
2. manipulation of resources through representations
3. self-descriptive messages
4. hypermedia as the engine of application state.

From here I'll look at each of these four constraints and build up the approach as I go.

What a resource is

Quoting extensively from REST 5.2.1.1 Resources and Resource Identifiers:

The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource...

A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time...

The values in the set may be resource representations and/or resource identifiers...

A resource can map to the empty set, which allows references to be made to a concept before any realization of that concept exists...

The only thing that is required to be static for a resource is the semantics of the mapping, since the semantics is what distinguishes one resource from another...

What a representation is

Again, quoting extensively from REST 5.2.1.2 Representations:

... A representation is a sequence of bytes, plus representation metadata to describe those bytes. Other commonly used but less precise names for a representation include: document, file, and HTTP message entity, instance, or variant...

If the value set of a resource at a given time consists of multiple representations, content negotiation may be used to select the best representation for inclusion in a given message...

The data format of a representation is known as a media type

Identification of resources

To do this properly I need to identify some resources, so for this I'm going to work with "Something" :)

• "Something" - a resource, a non-virtual object

At any point in time I have a description of Something which has multiple representations in different mediatypes, all semantically matching or equivalent:

• "something.rdf" - representation of Something with mediatype RDF+XML
• "something.n3" - representation of Something with mediatype RDF+N3
• "something.en.html" - representation of Something, in english, with mediatype text/html
• "something.de.html" representation of Something, in german, with mediatype text/html

Each one of those representations is also a resource because they can be the target of a hyperlink. Of course by resource I mean a conceptual mapping to each of the things listed, and I haven't assigned URIs but will..

To be able to make this set of representations manageable and to indicate they are in a set, I'm going to add in another resource which is a collection of resources, which can be considered a set of these equivalent representations of Something at a fixed point in time. For the purpose of this exercise, that point in time is today.

• "Something-20100311" - a resource which is a collection of equivalent representations of Something on the 11th March 2010.

Additionally, for the sake of argument, I'm going to say that a new set of representations (or version) is added every day - to handle this I then need one more resource, a collection of resources, where each resource in the collection is itself a collection of resources (one of the aforementioned and including the example "Something-20100311"). This will give me a conceptual mapping which covers time, and therefore everything I could need.

• "Somethings" - a resource which is a collection of resources, see above for full description!

Finally, I'm going to add in two shortcut resources which have no representation and are simply conceptual maps to the first and most current sets of representations.

• "first" - a resource which always maps to the first collection of representations of Something.
• "latest" - a resource which maps to the most recent collection of representations of Something.

Giving the resources URIs

Now to assign some URIs for this use case, there is no set structure and I'm not going to define one because it is up to each server (or manager of) to control it's own URI space, but for the sake of this exercise I'll define mine as follows:


base: http://data.webr3.org
...
/d/Something
/rg/Somethings
/rg/Somethings/first
/rg/Somethings/latest
/rg/Somethings/Something-20100311
/rg/Somethings/Something-20100311/something.rdf
/rg/Somethings/Something-20100311/something.n3
/rg/Somethings/Something-20100311/something.en.html
/rg/Somethings/Something-20100311/something.de.html
...
/rg/Somethings/Something-20100305
/rg/Somethings/Something-20100305/something.rdf
/rg/Somethings/Something-20100305/something.n3
/rg/Somethings/Something-20100305/something.en.html
/rg/Somethings/Something-20100305/something.de.html
...


From the above you can see that every possible representation has its own URI, in addition every collection of equivalent representations has its own URI, as does the collection of all those collections; and so does "Something" our non virtual object.

Also we've exposed multiple resources which could also be RESTful CRUD access points operating on an atompub style protocol. Small sentence, big potential, will cover approaches and protocols in later posts.

The Key resource

The most important thing, which I haven't yet covered, is that we've exposed a key resource, namely /rg/Somethings. This is a resource at the top of the representation chain which can be used to expose content negotiation, be it server or agent driven (or a mix of both), and regardless of the mappings and levels of collection further down the line this can always be a single point of entry to get representations.

I'll cover just how in a moment, but for now something important.

Important

I've had to give a fixed example just to make some progress, but we have to remember that every system has different needs, in some cases it may be that there is only a single fixed representation for a resource, whilst in others each strand of representation (like something.de.html) may take it's own versioning / temporal path. This could indicate that a structure such as the following may be in order:

...
/d/Something
/rg/Somethings
/rg/Somethings/first
/rg/Somethings/latest
/rg/Somethings/Something-20100311
/rg/Somethings/Something-20100305
/rg/Somethings/Something-rdf
/rg/Somethings/Something-rdf/20100311.rdf
/rg/Somethings/Something-rdf/20100305.rdf
/rg/Somethings/Something-html-en
/rg/Somethings/Something-html-en/20100311.html
/rg/Somethings/Something-html-en/20100305.html
/rg/Somethings/Something-html-de
/rg/Somethings/Something-html-de/20100308.html
/rg/Somethings/Something-html-de/20100303.html


The above highlights that whilst we may have added more resources, the core resources are still the same; remember that they are "conceptual maps", meaning that Something-20100311 may "map" to the version of en-html on the 11th and de-html on the 8th, because the de version was written first, then translated to english and from there rdf and so forth, but they are all semantically equivalent, containing the same information even though they were created at different times.

The Conceptual Maps are as follows, from what I can tell this should always cover any use-case, no matter how complex.


Thing 1-1 CollectionOfCollections
CollectionOfCollections 1-* CollectionOfEquivalentRepresentations
CollectionOfEquivalentRepresentations 1-* Representation


aside:At times like this I wish I'd had a chance to study computer science so that I could express these things formally, so you'll have to make sense of it as best you can :( sorry.

Exposing via Content Negotiation

In my research so far, I've been able to figure out how to expose all of the aforementioned via HTTP, RESTfully using content negotiation in a manner which seems to be transparent to existing web browsers, but exposes all the information needed in a manner that is visible to machines; without using any additional extensions headers. As follows:

1 The client does a normal GET request on our "Something", notice that no content negotiation is happening yet, we are simply asserting via a 303 "that the requested resource does not have a representation of its own that can be transferred by the server over HTTP."

#Request
GET /d/Something HTTP/1.1
Host: data.webr3.org
Accept: text/html;q=0.5, application/rdf+xml


#Response
HTTP/1.1 303 See Other
Location: http://data.webr3.org/rg/Somethings


2The client does a GET on the URI we specified in the Location field, namely to our key resource that can be used for content negotiation over all the representations.

#Request
GET /rg/Somethings HTTP/1.1
Host: data.webr3.org
Accept: text/html;q=0.5, application/rdf+xml


#Response
HTTP/1.1 300 Multiple Choices
Location: http://data.webr3.org/rg/Somethings/latest
Content-Type: application/xhtml+xml
Content-Length: 17400


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
version="XHTML+RDFa 1.0" xml:lang="en">
...


Here's where it gets interesting and clients can take different routes; first the route of the typical user agent:

User Agent Route


#Request
GET /rg/Somethings/latest HTTP/1.1
Host: data.webr3.org
Accept: text/html;q=0.5, application/rdf+xml


#Response
HTTP/1.1 307 Temporary Redirect
Location: http://data.webr3.org/rg/Somethings/Something-20100311


#Request
GET /rg/Somethings/Something-20100311 HTTP/1.1
Host: data.webr3.org
Accept: text/html;q=0.5, application/rdf+xml


#Response
HTTP/1.1 302 Found
Vary: Accept
ETag: W/"xyzzy"
Last-Modified: Wed, 11 Mar 2010 12:45:26 GMT
Content-Type: application/xhtml+xml
Content-Length: 17400
Content-Language: en
Content-Location: http://data.webr3.org/rg/Somethings/Something-20100311/something.en.html


<!DOCTYPE html...


First you can see that the user agent simply goes straight through to the most recent content and what they expect to see; which is nice, with additional Server driven content negotiation.

Further, we can see that full cache control is in there which as we know speeds up the net, and further still we have a rather nifty "weak" entity tag; this entity tag is shared by all representations which are semantically equal, and asserts they are equal via the entity tag. It's also worth noting that you could add this entity tag to your RDF graphs and further assert provenance which could come in very handy down the line for POST and PUT implementations.

To recap, common user agents just go straight through to the expected resource via server driven content negotiation and can take full advantage of cache / control data.

The Machine Route

Back at 2 the server returned a 300 Multiple Choices as soon as /rg/Somethings was requested. All important was that the entity returned was XHTML+RDFa (although this could have been Atom or similar..), which means we can give both a human and machine readable list of all our various representations, the "machine" can then select which one it finds most fitting. The choices could be expressed using any suitable ontology; and further both Alternative and Link headers could be added if publishers wished.

I think that covers it all, if there are any errors or things I've missed please do let me know asap; but for now that'll do me - it's verbose, but I like verbose - prove it works then optimise it later :)

To save everything going to waste, here's a quick list of multiple handy resources which I've found (save you a bit of googling and time).

XHTML + RDFa and related techs.

• Wikipedia RDFa
• RDFa info
• W3C RDFa Primer, RDFa for HTML Authors, RDFa Syntax, RDFa Usage Scenarios
• Google RDFa Support help for webmasters.
• Drupal 7 RDFa Intro, RDF / RDFa Details
• ARC RDF/RDFa Classes for PHP
• OpenLink Virtuoso Open Source Database (RDBMS, ORDBMS, virtual database, RDF, XML, free-text, web application server, file server, sparql, ws-* etc)
• Notation3 on W3C, Wikipedia
• Turtle on Wikipedia, W3C, Authors Site
• N-Triples on Wikipedia, W3C
• GRDDL on Wikipedia, W3C Spec, W3C Primer, W3C Usage Scenarios

Semantic Web Resources

• Semantic Linked Data W3C ESW Wiki
• SOIC, FOAF, SKOS
• SPARQL Query Language, SPARQL Protocol, SPARQL Result Format, SPARQL Tutorial
• RDF Schema (RDFS) on Wikipedia, W3C RDFS Spec, Calais RDFS
• DBPedia Applications, and DBPedia Open Access
• Freebase Developer Docs, Freebase RDF
• Yahoo Term Extraction Service
• Zemanta Contextual Information Service Developer Documentation
• Open Calais Documentation
• AlchemyAPI
• Common Tag

Hopefully that'll be enough to get most people going!

Figured this one out years ago and have just never used it, you can display your rss feeds however you want using XSL to apply XHTML and CSS.

Take a look at mine here to see.

I'm not going to tell you too much about it, except for the fact that you need to pad out a chunk of atleast 512 bytes before the <rss> block in order for the xsl to be applied by browsers ;) check the source of my feed and you'll see a couple of comments - ahh something so simple that has stopped the entire world from skinning there rss and making it pretty.

should be fun to see what people do with this one!

Seeing as most of the audience of this blog will be using more recent browsers, I've opted for XSLT templates and small XML descriptors for each item - this saves me writing tonnes of html, saves the server some weight, saves you some bandwidth and let's me palm off all rendering on to the client.

Inkeeping with the spirit of experiments, one of the main reasons I've done this is to see how the xml documents get listed in google (if at all); and to check if analytics works with XSLT.

On this note, I had to do a little bit of fiddling with the recommended embed code from google to get it to work; if anybody else hits this problem here's a modified version.


<script src="http://www.google-analytics.com/ga.js" type="text/javascript"></script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-3391780-6");
pageTracker._trackPageview();
} catch(err) {}
</script>


And as for the listings, well thats just a quick and dirty PHP 5 class which iterates the directories, loads them in to a dom document and spits out the xml - ultra simples.