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 who provides the icons?
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 core additions
- 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.