The workshop was very busy with (I estimate) over fifty attendees; many from Italy, and a surprisingly large number (myself included) from other European countries.

We flew in on Thursday and spent the evening with Danny Ayers, enjoying a few beers outside a small cafe in an Ancona back street, watching the chic, and not so chic, pass by.

The Friday workshop started at about 09:00 and we were still in the building at 19:45, squeezing every drop of chat and demo out of the day. Then we headed off for a rather special social dinner which featured, I think, five courses, plus dessert. This was good because I got to talk some more with Danny, and also with Max from the Semantic HiFi project, Emanuele Ruffaldi who does virtual environments and Paolo from the PlatypusWiki project too; so the conversation was diverse.

The staggering thing about the whole event was that about >80% was conducted in English: accomplished eloquent English – I take my hat off to my fellow presenters, in respect, and in thanks (’cause I can understand only a few handfuls of Italian words and phrases, so the day would have been lost without their exceptional linguistic capabilities).

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.

• 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.

Using indirection, there may be two ways to get an image type:

1. involves the Resource type – this is the more obvious method – but when it’s not available, method B might be a good option.
2. involves objects (as opposed to subjects – what i’ve elsewhere called Dead-End nodes). The image for these nodes can possibly be discerned from the property class in which they are defined. Essentially revere lookup may be useful if a resource does not have a type.

These shall hereafter be referred to as forward and reverse lookup respectively. So, today – after much brain bending, which seems to be common with RDF – I’ve managed to implement forward lookup.

Forward Lookup

What this image shows is that entries of type http://xmlns.com/foaf/0.1/Person have a differnt icon from entries of type http://purl.org/rss/1.0/item – and the important thing here, is that the icon indirection is all performed through RDF – this is becoming a self configuring program. If third parties want to add in new icons – so be it – loading the relevant RDF will let the program know where to look for the resources.

The RDF which handles this indirection is contained here for posterity.

<rdfx:icon rdf:about=”rdfx://icon/person”&gt
<rdfx:url>http://www.rdfx.org/rdfx_32x24.png</rdfx:url&gt
</rdfx:icon&gt

<rdfx:icon rdf:about=”rdfx://icon/type”&gt
<rdfx:file>icons/person.gif</rdfx:file&gt
<rdfx:url>http://www.rdfx.org/icons/person.gif</rdfx:url&gt
</rdfx:icon&gt

<rdfx:iconAssoc rdf:about=”http://purl.org/rss/1.0/item”&gt
<rdfx:hasIcon rdf:resource=”rdfx://icon/person” /&gt
</rdfx:iconAssoc&gt

<rdfx:iconAssoc rdf:about=”http://xmlns.com/foaf/0.1/Person”&gt
<rdfx:hasIcon rdf:resource=”rdfx://icon/type” /&gt
</rdfx:iconAssoc>

More indirection to follow

The succss of the image indirection today, means that text indirection is also possible. Text indirection is desirable because, in the same way that for a Resource type it’s useful to have an image, it’s also useful to have the most descriptive textual field used to represent the Node – having a treefullof URI’s isn’t particularly helpful, however, a tree which, fo reach node, checks the type, and dependent on the type selects which property to display in the tree is going to be useful.

The indirection mechanism will be very similar to the image mechanism.

Of course these are only tried if the default doesn’t work.

This highlights an interesting question. How best should these multiple sources of information be stored and categorised internally – it’s not enough to say that a URI defines where it’s from, because multiple sources may define the same URI, and the properties they define for it combine when unioned.

I can see two possibilities for the RDFX Core:

• Maintain a hashtable of differnt models, passing requests to all of them as necessary and aggregating the results. This has the advantage that serialising those models will be easy.
• Somehow annotate each property as it is loaded by setting it as a property of another Resource whose type is the as-yet-undefined PropertyOrigin – this would have the advantage that the annotation could be browsed in the UI like any other node.

1. added sorting to the list of things the code can do. there’s not much intelligence there yet, but the mechanism is connected.
2. added a menu into the Resource List view so the sort can be selected, and
3. started to use Actions to abstract the users selections from the underlying code which implements them.

essentially, the core functions are “starting to happen” now, so I’m starting to have ideas about user will eventually want to navigate this data.

Perhaps some concept of bookmarks would be good – Perhaps the digger could provide this since it’s nodes will be the most generic.

Anyhow, the image below is of the plugin as it ran this afternoon showing the default content in the List the initial content in the Explorer was /people/rich however, double-clicking on (activating) hong’s entry in the list defocused the explorer on the hong resource. The properties view shows the content of /rich which was selected in the Explorer view.

Note that “?>” in the properties is a flag to show that this name wasn’t looked up successfully – I need to look at decorators to understand how to best represent such things dynamically.

1. over-dependence on Jena and
2. over-engineering the API.

i’d like the core to be abstracted from Jena so that as if an alternative model comes along, or if/when Jena release version 2, there shouldn’t be any major problem switching the current code out, or augmenting it.

since RDF has an XML serialisation mechanism, that is the obvious choice for the API – it relies not on objects but on a stream of data, whose structure and syntax are all pre-defined and controlled.

So, that may be a suitable API – by using XML to serialise and reconstitute objects, different models may be used – this would mean the concern I raised earlier about plug-ins for non-java languages can be laid to rest.

To list is very basic, so perhaps the resource type could be included in a table rather than a list view. Filters could be added based on Type, Source, Content etc… the important thing is that it provides a neat way of displaying all the data model so that, upon a double click (possibly) the RDF Explorer root can be set – perhaps in an existing view, perhaps in a new view – this could be set in the prefs.

Such niceties are for further down the line anyway – for now, the mechanism is just that when a node is clicked, it is selected in an existing RDF explorer if it exists, and when double-clicked the explorer tree root is set to the chosen node.

[xml] xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:foaf="http://xmlns.com/foaf/0.1">
[/xml]

This is a pain when trying to work out (a) which file to load and then (b) what the actual namespace should be for the content of that file – in the case of the rdf namespace the file is exactly as described – http://www.w3.org/1999/02/22-rdf-syntax-ns but in the case of foaf namespace the file is http://xmlns.com/foaf/0.1/index.rdf

Essentially – is there a need for a mechanism which interprets the resource type and substitutes a replacement, bespoke INode implementation, and if there is that need, can it be done? Answers: No, not for UISB and Yes, but it might prove interesting

So now any unknown label should be retrievable by going to the URI specified in the NS, downloading the RDF Schema document, pulling out the appropriate resource and getting the label property.

If it’s that simple, then programming with RDF is frankly more orgasmic than a nice cup of tea and a biscuit.

Note: when auto loading rdf schema the HTTP method of looking for index.rdf may be utilised if no document is specified – this, for example is used by FOAF.

OK, so where are they stuck? It’s perfectly feasible to load the schema into the main RDF store for now, but a concept i’ve not discussed here yet is the separation of the RDF store to a separate plugin whose role it is to supply RDF services – this plugin can then be a front for (a) other RDF services and (b) provide transient or permanent RDF stores.

Well, a couple of hours later and it’s working.

When a label is required the RDFSchemaLabelProvider does the job of checking for it, and if possible, loading it. Currently I’m using a separate jena Model to store the namespaces. Also, there’s some strange behaviour with namespace naming oddness, where some namespaces are not exactly what they seem, this may be down to conten negotiation but there are no RFC’s for that yet…

One last thing: “label” is not always used – there’s likely to be usage of “name” and “title” – perhaps some search order preference should be configurable – just not by me, and not right now, this is good enough – however – assuming there were a few preferred content elements, one of those could be substituted for the URI in the Query Tree… or maybe not since each Query should/could have a name – in which case this becomes a good argument for having an RDF Explorer and an RDF exploder. Ah – but then again – a Query node could be treated differently.. it’s very late, i’m sorry

Still to do however:

1. Stop showing the triple, just show the RDF object value
2. Display resources and Literals in different twisties within the Properties View (and add user preference)
3. You may also notice that the content of the RDFX View tree has been frigged – this is currently a big to do.
4. Also, for twisties, are cases where there are multiple values for a particular property.
5. Add a lookup for the Property Name so that if it has a “plain english” value defined somewhere it can be used – (using schemas notes added on this later).

Time passes…

OK, so scratch that – having read some more I’m getting convinced that’s what’s needed is to take the [official] alternative path to implementing IPropertySource which is to implement IAdaptable. An object which does this will return an adapter object when requested – this adapter object contains the code used by the Properties view, and queries the underlying object for the information required.

This, I think will give me a nice abstraction so I can use different RDF API’s (should an alternative to Jena be required).