accessing the core

i’ve been humming and harring about the core model. to be really capable there is a need to avoid

  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.

list view

Although not immediately apparent, the usefulness of the list view is large. In a nutshell, the concept of the list view is that it provides a flat list of all Resources thus:

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.

RDF Namespace Oddness

in building RDFSchemaLabelProvider i’ve had some interesting namespace problems. some namespaces are defined, ending with a “#”, which include the name of the definition file, some have no hash, no trailing slash, and define a URL where that file can be assumed to be, for example:

[xml]
[/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

:-?

rdf structures

RDF contains some structures. Bag and Set, for example – then – extensions to the schema can also contain structures – DAM+OIL and OWL for example add concepts of cardinality – should the browser be able to handle these specially, or just treat them as resources (which they are).

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 :)

Programming the UI with RDFS:Label

Although not all schemas are accessible, many are; which is good news. What’s even better is the existence of “rdfs:label” which “Provides a human-readable version of a resource name.”

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 :)

properties linked

Some good news. I now have an RDFX View linked to the properties view so that both Resources and Literals are showing up.

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