boakes.org

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 .

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_32×24.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.