It should be easy for projects outside Pleiades to assert relationships between their content (primary and secondary sources, images, find records etc.) and ours. It should be easy for Pleiades users to stumble upon (or search for) these assertions (via maps or other means). It should be easy to harvest these assertions and pump them through our editorial workflow.
We already use Atom + GeoRSS, as well as KML, to expose Pleiades content for discovery and reuse by others. It's clean, simple, standard and RESTful. No heavy architecture. No elaborate call-and-response rituals. No home-made schemas or protocols.
Can we turn the telescope around and ask other projects to use the same mechanisms -- maybe with a little semantic sugar in the form of a simple relationships thesaurus -- to communicate with us (and each other)?
So, I tried to imagine an Atom+GeoRSS feed for an inscription from Aphrodisias that's already published to the web. You'll see from the comments that there are a number of distinctions I'd like to see from the Pleiades side that just don't fit. Bruce Robertson has lately got me thinking about RDF, so I tried my hand at an RDF encoding of the missing stuff too. Maybe an XML version of the RDF could go into the Atom feed using its standard extension mechanisms.
Thoughts? Corrections? Suggestions?
Sean and I chatted about the Atom example briefly on IRC this morning, and he had a couple of good ideas.
ReplyDeleteFirstly, my example doesn't exploit the full power of the "rel" attribute on the <link> tag in atom. As Sean put it: "atom gives you more power to express link relationships ... the value of rel can be any url." These URLs could be used to type links according to some mutually-agreed thesaurus.
Secondly, there's no good way to type or qualify <georss:where>. This is problematic given that epigraphists (for example) may know about a number of discrete locations associated with a single text (where it originally was placed, where it was first found, where it was subsequently observed). Of most interest to Pleiades are probably the original location and place(s) of finding, but we'd like to be able to tell which is which.
Sean suggested we try breaking down the "one text = one <atom:entry>" paradigm implied by my example, and instead provide an <atom:feed> populated by however many typed <atom:entry> elements we need to effect communication.
I'll try to have a go at refactoring the example with these suggestions in mind soon. Meantime, I'd be interested in others' reactions.