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