On 26 Aug 2008, at 11:17, Richard Light wrote:
> When I set up an interface which gives access to museum data in
> response to external HTTP requests, I don't think that I am
> providing "programming functionality" to the outside world, just
> data. Cool museological Linked Data RDF data, perhaps, but data
> nonetheless. So, in my view, that's not an API.
>
> Or have I got the wrong end of the stick?
It's the same end I had hold of, so we're both struggling with the use
of the term in this instance.
In a more broader sense, I'm still struggling with why it's difficult
to expose museum collections and why there seems to be a conflict
surrounding the best way to do it.
To explain.
I'm presuming that, at the un-exposed level, data about collections is
stored locally and referenced by locally accessible systems (looking
in a catalogue, or a proprietary software application)
At the next level up, collection data (images and catalogue records)
is shared on the Internet as part of a web site.
If done properly a search engine will return results and deep link
into the collection. Then we get the next bit, that I'm finding
difficult to grasp, there seems to be a desire to create collections
of web exposed collections - The mash-up concept.
Why is a mashed up collection of collection data better than a host of
individual collections?
In my mind, that's a bit like saying the Internet would be better if
we collected together all the web sites by topic and just had half a
dozen interesting portals. (something I think has been tried
unsuccessfully numerous times)
So shouldn't this effort be more about how to expose collections on
the web?
I'm just thinking aloud here, but very interested in the debate.
**************************************************
For mcg information and to manage your subscription to the list, visit the website at http://www.museumscomputergroup.org.uk
**************************************************
|