I notice that several folk are arriving at the rdf namespace oddness page which describes the slightly opaque problem of understanding RDF Schema URI’s and how to go about loading them.
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. Continue reading
The pages discussed here concern the representation of XML within RDF (a very different concept to that of the serialization of RDF in XML). Continue reading
the question of who (or what) should proivide the iconic representation for nodes is playing on my mind. I’m thinking there needs to be a local cache – which can be initially populated with some defaults – but that it should be a dynamic thing basd on resource type, and using an RDF lookup . Continue reading
One of the thgings I’ve added today is a little code to guess where the schema may be – in order to validate or interpret conent the schema needs to be accessible, so the code now checks for index.rdf and schema.rdf files if the supplied namespace is one that does not end in a “#” or if it ends with a “/”.
Of course these are only tried if the default doesn’t work.
An addition to the core today is the ability to load RDF from a URI as well as a file – to demonstrate this I now have a news feed from theregister.co.uk being pulled in to the system when it’s started. Continue reading
- added sorting to the list of things the code can do. there’s not much intelligence there yet, but the mechanism is connected.
- added a menu into the Resource List view so the sort can be selected, and
- started to use Actions to abstract the users selections from the underlying code which implements them.
my comment yesterday about bookmarks triggered somehting this morning – what may be useful would be forward and back buttons in the explorer, so that current, and previous roots could be viewed and reviewed – this should be easy to implement by maintaining the INode tree. having a preference of how many histories would ensure memory isn’t gobbled up.
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.
The List and Explorer views are now working insofar as they can be created and display some content. Double clicking on an entry in the Resource List makes that entry the head node in the Explorer – this mechanism, when combined with filters in the Resource List makes it easy to find the node you want… to a point. another view that would be good – or an interesting twist at least, would be a simple search view. the problem here is that the boundaries between all the views are getting blurred. The list will probably have filters, the explorer too, the Digger will be search based…
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.
i’ve been humming and harring about the core model. to be really capable there is a need to avoid
- over-dependence on Jena and
- 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.
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.
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:
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 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 :)
the idea of dynamic schema validation got me thinking about adaptive resource representation in the UI. It coudl be quite effectively handled with decorators, so the concept could work for more than just schema – it could be extended to information which is owned vs borrowed, trusted vs un-trusted, fresh vs stale vs expired etc…
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 :)
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).
In order to get an RDF Resource displayed in the Properties view it needs to be accessible through an object which implements the IPropertySource interface. My first pass saw me configure my INode interface to extends IPropertySource, however, noting that INode is merely a container for a Resource, not the resource itself, and that several INode’s may point to a single Resource this may not be the best solution – time will tell – i’m sticking with the first idea for expedience.
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).
perhaps a schema for linking icons to node types – should be slightly indirected such that (a) there can be an officially sanctioned representation (b) there can be themed alternate representations and (c) it’s not limited to bitmaps – an SVG based icon, for example, would be most welcome – even if eclipse can’t display it, it would only be a requirement of having a conversion program included – i.e. not a big problem.
XUL looks very interesting – i’ve taken the time to download LUXOR a few days back, but it’s just too much extra technology to get on my brain-radar at the moment. Briefly, XUL the XML UI Language, could enable me to build a single interface, defined in XML for any platform – however – the libraries don’t appear too mature – it’s perhaps something for version x.y.z.
The current use of icons is not brilliant – it needs to be defined such that for any UI widget there is the ability to choose an icon. However, it’s really down to the schema rather than the UI – sounds another job for our retrospectively linked hero RDF, and some kind of indirection mechanism.
I’m a little confused right now WRT where exactly the RDFX core should be started – it’s either in the RDFXView class or in the plugin class – i’m assuming it’s in the plugin class… but… because everything’s event based there’s a risk of the core being ready before the view – and the view missing out on the initial broadcasts – what this means therefore is that there may need to be some kind of regular (i.e. once every n seconds) broadcast from the core to allow interested views to come and go whilst the core remains. This is very similar to the Jini lookup model – and so I’m immediately thinking that there is potential for a two way event with a View announcing it’s arrival and requesting the transmission of a “top node” from the model.
Time passes… Yes, it’s the plugin that should start the RDFX core and then when a view is started it will announce that it would like to know about “any node which can be a top node” or announce that it wants to know about node x” – where x is a URI – this then allows for multiple views and for the user to define the top node URI, should that prove useful – a kind of “start exploring from…” function.
I just noticed that RDFX.org (and just about everything else bar .com is free, so I grabbed .org for the open-source friendly advertising that we want for this. it’ll redirect to the uni’s hosted pages, but it makes it very easy for folk to remember.
In RDF, two resources with the same URI are considered to be the same Node. In an RDFX View this may not the case. Due to the cyclic nature of graphs it is necessary to have repeat entries for certain nodes in order that the graph model be rendered as a navigable tree.
If an RDF schema can be used to automatically generate a java class file, then an RDF ClassLoader could be used to first generate and compile the class before returning it. To achieve this and be truly dynamic it would need access to the internet in order to retrieved the class files.
If linked to a factory mechanism it might be possible to automatically return a collection of all valid objects which can be generated based on a particular starting URI.