PhD-level research is very specialised but (as my esteemed supervisor pointed out) most of the content should be comprehensible to anyone capable of reading a daily newspaper, because the more accessible the writing, the more useful it will be to other people (who may not speak English as a first language) and that’s the whole point of the PhD, it’s not just personal advancement, it’s another small step for the research topic, for scientific method and human kind. The thesis is marked and reviewed by respected academics, but the average person is the target audience, so they shouldn’t need to keep a dictionary handy to grasp the majority of the content. Obviously some parts of any field will require specialised knowledge in order to interpret plots or equations, but the majority should be accessible to all. When discussing the work, there are no plots and equations, there are only words. This is why the viva voce is such a powerful tool for final examination.

On numerous occasions however, I’ve observed an odd response from the average person when they learn that my research is about “building models that help us understand what happened when very large computer systems go wrong”. It’s the natural evolution of the “I can’t work the video” discussion: once computers are mentioned then within 3 sentences I’m told about how their child/grandchild/neice/nephew etc (usually aged between aged 2 and 6) can use a mouse already, and how this is in contrast with everyone else in their family. There are probably similar variations on this discussion for every non-computing field, and this is why the viva, in reality, is really enjoyable. It’s great to be able to talk to people who’ve read the thesis, understood it, and want to talk about the details. This is something that my old buddy Gethin (who got his PhD long ago) predicted for me beforehand, and he was spot on.

My viva voce was this Tuesday, and (for the benefit of anyone with a viva approaching) the whole thing was enjoyable (and not just the bit at the end where the examiner said “we’re going to award you the PhD” which was very tingly).

For very complex documents with many thousands (possibly many millions) of elements, knowing that rendering a particular portion of the image is taking n% of the time can help identify which areas of the image need to be re-written to make the image as a whole work better and faster.

SVG optimization is going to become a significant area of development over the coming years, especially for SVG that uses ECMAScript to modify the DOM, because it will help turn todays stuttering experiments into tomorrows smooth graphical web based applications.

So if such a tool doesn’t exist already, someone needs to make it – perhaps as a Firefox plugin. If it does exist… what’s the URL?

Apart from a few technical excursions into geekspeak, what unfolds over the hour is a remarkably accessible, sensible and enjoyable presentation that most geeks mothers will understand.

It’s like watching Eddie Izzard with added protocols, and it’s apparent that Sir Tim is entertained by (and comfortable with) the way that social factors like group misbehaviour, spammers and sociopaths have all affected (and will continue to affect) the growth of the web.

Those who think of the web as some grand design may also need to remove their tinfoil hats: witness the wonderment that’s apparent when wikipedia is discussed:

It happens that; plus or minus a few vandals and the war against them; that it works! And who’d have known?

I could spend hours summarising the entire thing, so much is covered… but you’ll get more by just watching it.

Get it here: Webcast of TimBL in Oxford.

Note: The content is currently published using MPEG-4, so linux users may have difficulty watching it (because of copyright issues). I’m sure if enough people ask nicely Oxford University will provide an alternative format.

Update: Tom King’s kindly extracted the MP3 stream and it’s now available separately, so it can be enjoyed as a podcast! Thanks Tom!

What this suggests to me is that in the world of open-source software, a world where everything is free, it’s not necessarily the technology that is most important: instead, the community is key.

Perhaps this perceived fractiousness of the RDF community is a result of it’s origin – we’ve become accustomed to proclaiming it’s capabilities and have evolved scripts that work well among those we talk with often, but if questions are asked that don’t fit in with the specific keywords that cue up those scripts, then it’s easy to assume complete ignorance on the part of the questioner. This kind of semantic misunderstanding, is something we should know all about… or at least be able to model.

AB begins by introducing his preference for simplicity, and what he calls the virtues of dumbness, he suggests that because complex things break, and simple things work, simple things are better, and highlights that his employer, Google, has the dumbest query language in the world, but because it’s simple, it works.

Anybody that’s studied the underlying scientific concepts of Information Retrieval will know that the Google search interface example is a gross simplification of what’s happening under the surface. AB has blurred the distinction between the usability of the interface and the underlying capabilities of the system for the sake of fitting his talk within the time available.

Based on the simplicity premise, the concept of a low-tech query language for web data is introduced: a language so simple that average programmers and content developers can understand and work with it; a language that doesn’t query data tables, but which queries data that’s on the web.

“To do this needs an open format for data. It has to be one grammar or the engine will have a hard time. It has to be sloppy or Average Joe won’t be able to use it.”

The most suitable target use for this query language appears to be the data aggregator; i.e. it’s not a detailed data model, it’s a a query protocol that can encapsulate diverse result sets, so it’s potentially very useful for agent-based computing, but unlikely to be “the new data model for the web” that the slashdot article portends.

Importantly, although querying web pages is what’s being discussed, the issue of the semantic web is sidestepped:

“this is not the semantic web. I don’t understand top down ontologies. The semantic problem is still yours [so] you have to figure out what [the result data] means.”

So, AB is suggesting a simple query language, not a description of how the queries should be fulfilled on the server end (which will require semantically enhanced databases in many cases) or how the results can be interpreted, which will need semantic inference, which again needs semantic markup, so RDF seems a key supporting technology.

In the questi0ns at the end, AB confirms that RDF (and by proxy the semantic web) is not what he’s talking about, suggesting that it has empirically failed his simplicity test, because people get confused about arcs, nodes, verbs and rdf grammar.

Of course, this isn’t empirical testing at all, it’s conjecture based on his admitted confusion (and a confusion I can empathise strongly with on occasion, having grappled with RDF constantly for the last few years), but just as most of us speak languages without understanding the intricacies of their grammer, so it will also be true that most of us will be able to use RDF and other semantic tools once their libraries and concepts mature.

In summary, the slashdot article hails a seminal lecture and labels the sementic web a failure. In fact, AB gave an interesting presentation about a solution to a rather specific but common problem, that appears to make the importance of the semantic web more obvious to Average Joe.

I’ve long since found a solution, following a discussion on #rdfig a long time back. That solution is content negotiation, so for the record, here’s how I’ve done it.

Negotiation of application/rdf+xml content using Java

This is how to load an RDF file using content negotiation and then pass the content onto Jena (original).

[java]String u = “http://rdfx.org/schema/2004/10/19-java”;
URL url = new URL(u);

URLConnection urlc = url.openConnection();
urlc.setRequestProperty(“Accept”, “application/rdf+xml”);
urlc.connect();

InputStream in = urlc.getInputStream();
model.read(inStream, u);
inStream.close();[/java]

Apache Server Configuration for RDF Content Negotiation

The server for rdfx.org is set up so that if a browser requests http://rdfx.org/schema/2004/10/19-java an html based page is generated, but using the above code and the same URI, a raw RDF file can be aquired.

The configuration for the RDFX.org server is as follows:

[xml]
ServerAdmin rdfx@example.org
DocumentRoot /home/www/rdfx.org/htdocs
DirectoryIndex index.php index.html index.rdf

AllowOverride All
Options MultiViews
AddType application/rdf+xml rdf

[/xml]

I hope this helps someone out there, I got some nasty splinters from all the head-scratching.

term_status describes “the status of a vocabulary term, one of stable, unstable [or] testing“, so at some point, an unstable or untested term may mature and become stable – it can thus be documented as such and thereafter may become relied upon by third party authors*.

additionally, it is a reflection on the infancy of semantic web research that many schema find their way into common usage before the majority of their terms are stable.

the combination of these two factors leads to ambuguitity, which may be acceptable for research work where robust enginering principles can be sidestepped in order to test a few concepts, however for larger projects more explicit stability is needed.

looking forward, if it can be assumed that for any given schema a core set of terms will eventually stabilize and be declared as such:

• is it fair to say that when a term is stable, it is not necessarily complete?

for example, a term might be quite specific in definition of it’s range and domain, and may be declared stable, however it might lack an rdfs:label, rdf:comment or perhaps an owl:inverseOf. such properties (among others) are not necessary for validation of the term’s content, but may be considered equally valuable.

with this in mind:

• is there (or should there be) a set of criteria that should be met so that schema completeness is a consistent concept?
• does there exist (or is there a need for) a property which describes the “completeness” of a vocabulary term?

• Bridging
  the Gap between RDF and XML
• Simplified Syntax for RDF
• Web Design Issues
• rdf-ns-prefix-confusion

  Need to ensure that the rgenerated RDF does not fall foul of this – to do so, any generated attributes must be namespace qualified.

  My current thinking is that this means wherever I douse a namespace, i must create a qualified name for it and use it.

• Using XML Schema Datatypes in RDF and DAML+OIL

  Discusses the use of XML Schema Datatypes in RDF – useful for converting any XML into RDF.

• do XML Datatypes work for RDF?

  An interesting discussion of user defined datatypes and the more generic problem of identifying a defining fragment within a defining decoment.

• Mapping XML to RDF via XSLT (rdfp.xsl)

  This an is RDF parser written in XSLT which is intended to transform stuff that’s already in RDF into other forms, so as to make it’s reuse easier.

• XSLT RDF Parser

• A Parser by Jason Diamond which (like rdfp.xsl) converts existing RDF into other forms – this one is dessigned to make it more readable.

• Bridging the gap between RDF and XML

• Some work from Stanford which defines an RDF API and which may suggest that any XML document can be rendered in RDF (it’s ambiguous though).

• Experiments with Mapping XML to RDF (SWAD Europe)
• generic XML to RDF triple mapping

  A very interesting thread which pretty much exactly describes my mental ideal for converting genmeric XML into RDF – amnd discusses some of the problems.

  The problems are what some later research can look into, so these are just opportiunities.

• Extracting and reifying RDF from XML

  The most promising of the rdf xslt’s. This one seems to get close to what I’ve done, but dows so using triples as follows:

  <rdf:Statement> <rdf:predicate rdf:resource="#binding"/>
     <rdf:subject rdf:resource="#/1/6/1"/>
     <rdf:object>tns:StockQuoteSoapBinding</rdf:object>
     </rdf:Statement>
  

  This has a few differnces to mine, though I need to look more closely to understand how they affect things.

If you take they key points at face value, as they appeared on slashdot recently, it appears to be a rather negative read, however, each point illustrates neatly why metadata that is pervasively authored can work.

• People lie
  True, but not all people do, and part of the concept of the semantic web is that you can decide who’s metadata you trust, and to what degree you trust it.
• People are lazy
  True again, the article describes the laziness of people writing (for example) a document. This is good, the documents over which people have taken more time will have more potential to be discovered.
• People are stupid.
  The “Plam Pilot” example is beautiful and the semantic web presents so many possibilities for how this issue could be overcome. The RDF and OWL recommendations are only the simplest building blocks, and any one or a combination of concepts could be built on these to retrospectively correct spelling mistakes. The author suggests that “Plam Pilot” is a common error, so it’s not difficult to envisage a (trusted) resource which matches common spelling errors to their correct version – the required process of inference that enables this to be of benefit is what the semantic web is about.
• Know thyself
  Provides an excellent insight into the fact that metadata can be authored by anyone (humans) and anything (machines), so the two distinct sets of information described could happily coexist withing the Semantic Web. It further illustrates the fact that there is some beautiful maths which can be applied with semantic web data through statistical analysis in order to discover hitherto unrecognised relationships.
• Schemas aren’t neutral
  True. I described just such a mismatch (finding a plumber) in this paper at ccgrid 2004. Other schema which bridge the gap between mismatched schema will exist and over time, common standards and recommendations do emerge.
• Metrics influence results.
  The thing to remember with the semantic web is that anyone can author the metrics, so you don’t just get to decide which metrics you’re interested in, you also get to decide who you’ll believe. And you can also compare the metrics of someone you trust with someone you distrust to see just how evil they really are.
• There’s more than one way to describe something
  Again a very attractive argument because here the author hints at the underlying philosophical debate that schema limit expressiveness. However, just as language enables the communication of concepts for humans, rather than limiting it, so schema enable the communication of facts for computers.