About Me
- Jeremy
- Web person at the Imperial War Museum, just completed PhD about digital sustainability in museums (the original motivation for this blog was as my research diary). Posting occasionally, and usually museum tech stuff but prone to stray. I welcome comments if you want to take anything further. These are my opinions and should not be attributed to my employer or anyone else (unless they thought of them too). Twitter: @jottevanger
Thursday, March 27, 2008
Chris Rusbridge on significant properties
CR has just blogged about this topic again, in the run-up to a JISC workshop that I'll unfortunately miss next week.
Wednesday, March 26, 2008
The Semantic Web now - Alex Iskold's latest great primer
Thursday, March 20, 2008
OT: awesome freestyling
Gollito and Paskowski in fullest effect. Up until recently I could imagine more ridiculous moves than were actually being pulled off by guys like this, but now, well, my imagination would be very stretched to exceed this!
Wednesday, March 19, 2008
What's new
SearchMe beta, a search engine which shows a visual results (images of the web pages) categorised (as e.g. museum, art, shopping, fishing). Quite nice. Silverlight I think. It's a bit SW (in its results clustering, for example), though how it goes about doing this I don't know, but other "semantic" search stuff has shown up lately. TextWise (small "sw", I guess) has just been reviewed by TechCrunch, which was doubtless part of the point of offering a $1m prize for suggesting uses for its technology. Hakia is another such.
Stuff I've been doing the last week or two:
- the Great Fire of London site for Key Stage 1 kids finally soft-launched.
- working on templates for the Londinium site - the bulk of my time right now
- preparing the digital republication of an out of print handbook for identifying roman pottery fabrics. I probably mentioned it before, it involved the export of Quark to PDF, the export of PDF to XML, translation via several XSLT steps and manual clean-up to TEI-Lite, and finally modification of some XSLT to display this as an HTML page. Most of this was a while ago; right now I'm getting ready for the images which will need to be embedded once all the scanned thin sections are ready.
- testing out and integrating Flash interactives with our CMS. Several are pretty much ready for launch, including two from the London Sugar and Slavery exhibition, and two games
- advising as best I can on the development of the replacement map interface for the LSS gallery
- fretting over the re-branding exercise the MoL group is engaged in. how much work is it worth doing right now to fix issues on the sites if we'll be overhauling the whole thing in the autumn?
- testing new search engine SearchMe (see above). Didn't get good results for "roman london" yet, but it's only indexed a billion pages or so....
One-stop shop for non-profits at Google
Monday, March 17, 2008
A few more Paris notes and an update
Those extra points:
Geo search
There are geographical search (and geo plus time) projects going on in eContent Plus and IST, using co-ordinates, place names, changing boundaries etc. We would hope to incorporate these (possibly post-prototype). Everything in Europeana will be public domain (development-wise) therefore the software will be there for the taking (I hope I got that right!)
"Privileged" tags
We mooted the possibility of privileged tags, i.e. those produced by certain authorised users, perhaps agreed by certain groups. Tags created by these users (most likely content contributors) would be treated differently so that we could pull out only certain items with a tag. But probably, rather than giving them some specific "privileged" status, we could achive the same thing just by identify them by contributor, user group or contributor type.
Stuff to clarify
- Licensing data model and assumptions
- Core common data
- Where is the boundary between Europeana and the contributor sites? Maquette seemed to include considerable data and the actual content displayed in-site for some types of asset e.g. images, but others might be held off-site. What are the rules?
- What needs to be added to the API to work well for libraries and archives?
Friday, March 14, 2008
Shock discovery: poor communication wastes resources
- Content maintenance. It mimics the look of our CMS pages, but the content isn't integrated with our CMS. Changes to site structure won't be reflected in the menus, nor would updated content.
- Visual maintenance. The look of this site will change (we dearly hope) and I can't change their pages
- Google. I don't know how they look upon sites that look like copies of existing sites and point at their pages. I suspect it might look like spamming and I wouldn't want to be blacklisted.
- Site stats. We can't (readily) integrate the job site's stats with ours (if we get them at all). Not a huge deal to me but a factor.
- Cost. I don't know what this will have cost, but five minutes after getting hold of an RSS feed from their site I had integrated it into our own, replicating the most important part of what they'd done. I suspect we could have done it cheaper, in short!
Thursday, March 13, 2008
Yahoo semanticises(?) business
Hmm, exciting!
[edit] see this too
The PSP is dead in the water
Tuesday, March 11, 2008
Here's that EDLNet presentation and notes
Yesterday I put the EDLNet Paris slideshow onto Slideshare, but since Scribd also let's me put up other stuff I'm putting that and the notes there too. If you can't see these coz I've screwed up the Scribd embed link or something, go here for the presentation and here for the notes
EDLNet Paris presentation:
Presentation notes:
And just in case...
The previous post with options for API input parameters is also on Scribd (UPDATED 17/3/2008)
Monday, March 10, 2008
New world speed-sailing record
Fingers crossed they might even top that at Southend today. Go Dave White!
Saturday, March 08, 2008
Public API inputs
Public API inputs and outputs
[edited 17/3/2008]
We discussed at the Paris meeting the range of parameters
that we thought that an API might need to handle to perform the sort of (public-facing)
tasks we envisaged. We didn't actually talk about output, except in regard
to the ability to specifiy return fields, but I think that this is actually
much the simpler part to work out. I've reworked our discussion, added a few
bits of my own (including the UGC bit), and split it into sections relating
to general parameters, filters for collections queries, and UGC. No doubt
lots more clarification and revision are needed and I'm pretty unclear on
some bits myself, but it's something!
Input parameters
The “profile” includes various elements defining the operation
in terms of function, languages, values and format of returned data etc. Collections
data requests will be required for some functions, and consist of various
filters. The third table relates to operations on user generated content,
including adding, editing and getting (by user or group). We may decide that
some operations are only open to specific users or categories of user; for
example, accessing UGC of some categories might only be possible for the owner
of that UGC (via their associate API key) or the owner of the collections
related to that UGC. TBC!
Query profile (data access and data addition/editing functions)
|
|
|
| A | search, compare, translate, add, update |
| A, E | DC-XML, RSS, geoRSS, CDWALite, JSON, CSV. This might instead be implicit in the target URL. |
| A | Array of field names, but a default set would perhaps include GUID, title, thumbnail, short description, owner, owner type, media. Might also provide shortcuts to preset field groups. Will vary according to target entities |
| A | Formal metadata; all data; expert and user tags; user tags only; “expert” tags only; specific user/expert/group tags. |
| A | True, false [use/don’t use thesauri etc.] |
| A, E | EN, FR etc. |
| A, E | As above. If only one is present presume the same. |
| A, E | API user key |
| A, E | For the end user. Required for accessing/modifying data attached to specific users or groups. Presumably we need to authenticate and authorise in some way, too, for some operations. |
| A, E | Perhaps multi-value, specifying rights/licensing parameters. Likely to be more complex than one field! |
Collection data filters (access only)
|
|
| Objects, people, places, subjects [if we are enabling anything more than objects] |
| A unique identifier given to every record in Europeana |
| ID for a set of entities, which may require the appropriate key, depending upon privacy settings for that set. |
| Tricycle, ww2, treaty, Anne Briggs, documentary [multi-field search]. |
| Name of object, person or place. If these use different fields, then the right one should be inferred from the target entity. Examples: photograph; sunflowers; Forlì (or Forli); Max Brod (or M Brod); Rockall |
| 14 July 1792; 19th century. “Older than 1850” might be expressed as: “- 20000000 – 1850”; “Younger than” as: “1850-2050”; uncertainty like “1850 +- 5” as a range: “1845-1855”, though this isn’t perfect |
| For returning objects, people and places |
| For returning objects, people and places. See also “geographical” below. |
| |
| Of object, principally, for documents (if this data is well expressed) |
| Good structured data, ideally (we may require an ID), but we could permit a string search across the relevant field. |
| For searching by current location |
| Museum, library, archive, A/V archive |
| Including sub-parameters for grid reference, coordinates, place name, and the location of concern (e.g. place of creation, place of publication, location of subject matter) |
| Keyword occurrence, date precision, location, location relative to user, institution type – perhaps sorting partly inferred from the fields used in search, but if these are mixed e.g. date and place plus keyword, need to sort on one before the other. |
| text, audio, image, video or more specifically PDF, WAV, MPEG etc. |
| Map, book, video perhaps. Is this data held in a structured way, and is it distinct from the media metadata? |
UGC operations (add, edit, view)
These operations will need user ID (or group ID) plus authentication and authorisation for certain operations (but not for viewing public data).
|
|
|
| A, E | For modifying tag i.e. deleting, or viewing associated items |
| A, E | For modifying or viewing |
| A, E | Perhaps multiple values, including groups, so we can look for stuff with a given tag but only when tagged by a certain set of UGC contributors |
| A, E | Content contributor vs. other user |
Friday, March 07, 2008
EDL WP3 Paris meeting
It was a successful meeting, I would say, and it was a pleasure to see a couple of faces I already knew, and meet others for the first time. On Monday (with me still reeling from a 4am start) we were taken through the results of the user testing. These were overwhelmingly positive, which needs to be taken with caution given the guided nature of the demo (especially with the online questionnaire, but also perhaps the expert users and the focus groups). All the same there were criticisms that provided something to get our teeth into, particularly around the home page and the pupose of the "who and what" tab. Search result ordering was an issue, a particularly thorny one in fact that we tackled on Tuesday as best we could. Clearly a lot of users don't really understand tagging, though they thought they liked it. Other plusses were for the timeline and map.
There was a good session with representatives of a French organisation for the blind and visually disabled after lunch (a bloomin' good lunch, in fact. Good wine, too. I love France!). Aside from HTML accessibility they talked extensively about Daisy, and it would be marvellous if some of the text content that may end up there could be daisified. No-one had heard of TEI (or DocBook) but it struck me that these formats are pretty close to what Daisy sounds like, and that there may be TEI material amongst the content we'll be aggregating, so translations to Daisy could be relatively straightforward. Anyone know?
Personalisation took us to the end of the day and we distinguished between activities done for private purposes (though perhaps with public benefits) like bookmarking with tagging, or tailoring search preferences, setting up alerts, or saving searches; and explicitly public activities like enriching content, suggesting and tagging (when not bookmarking). The question of downloads (what? how? assets or data?) and the related issue of licensing came up. I think we worked out that possibly four levels of privacy would be useful, extending the way Flickr and other sites work, with private, public, friends/family, and "share with institutions". The latter is really about saying, I will let me and my mates and the organisation whose objects I'm tagging/annotating look at the data, but not everyone. I think it's important and should be encouraged, as it lets those institutions do interesting stuff with the resulting UGC for everyone's benefit. We ran over into the next day to deal with communities (still plenty to think about there, I would say) and results display, a practical and useful discussion that touched on the fields that might be searched across and how they would be used in ranking.
Finally my bit came up. Although Fleur had suggested that I talk for maybe 15-20 minutes to kick off discussions on the API, I, feeling unsure of my ground, prepared pretty thoroughly with the result that I had material that kept me talking for an hour or more, I think, albeit with some digressions for debating what I was saying. On the whole it went down quite well, I think, but I learned a bit about what I should have added (proper, simple explanations of APIs, and more examples of how they're used) and what I should have left out (a section where for the sake of completeness I referred to the management of collection data, which is not part of the public API anyway and is outside the scope of our WP. This led to a digression that was I think still useful, but not to the topic of that moment). And then, seeding the discussion with a use case related to VLEs, we tried to figure out in more detail what functions and parameters would be needed in an API call, and what would be returned. And that, my friends, I will write up shortly for now I want my dinner. Home calls.
Thursday, March 06, 2008
MS new stuff: IE8 and super-cool image zooming in Silverlight
Also from MS, SeaDragon (see also Photosynth) in Sliverlight 2. More than a bit useful for use cultural heritage types [edit] and I should add that the video on that TechCrunch page is of a cultural heritage application - Hard Rock Cafe's memorabilia application, which was the demo shown at MIX08. They talk about the role of imaging for authentication, for bringing objects to life, and though it's obviously a business, their business is really not so far from ours (albeit for profit)
Sunday, March 02, 2008
Hey MCG Listers!
Cheers, Jeremy
Thursday, February 28, 2008
Tim Berners-Lee talks to Talis, namechecks museums (generally)
I think the Semantic Web is such a broad set of technologies and is going to doWhich is true enough, and not exactly controversial. Good to have it from the Don, though. It's all about repositories in this vision, which is fine as far as it goes but I'm not clear that it gets us all the way, though. TB-L points out that the common worry that SW means marking up HTML pages is looking at a small part of the picture and that really the bulk of the SW effort will be about databases (remember, I'm skimming!).
so many different things for different people. It is really difficult to put it
on one thing. What are the steps necessary right now for the life sciences
community to be able to use it for their data about proteins is probably
different from which steps do we need to be able to get interoperability between
repositories of library data and museum data.
My feeling at the moment is that the semantic web is building, but in good part through the efforts of those who are bypassing the "classical" technology. Inferred semantics are crucial in this phase, at least for the businesses that seem to be making some of the most interesting stuff. RDF and OWL are bit players here, although they have much more of a role in dealing with data that's already nicely structured. As TB-L points out, the steps towards full SWW do have payoffs on the way (as they must, not least in our own sector), and data integration is just such a self-rewarding step:
In fact, the gain from the Semantic Web comes much before that. So maybe we
should have written about enterprise and intra-enterprise data integration and
scientific data integration. So, I think, data integration is the name of the
game. That's happening, it's showing benefits. Public data as well; public data
is happening and it is providing the fodder for all kinds of mashups.
On the public side, light and loosely-coupled stuff will/is giving us payoffs for lower cost than going hardcore SW, and yet provides useful stepping stones on the way. Microformats, public APIs etc.: lowish cost, relatively immediate reward (potentially).
One more quote, and then I'll have to stop even skimming. This is about what to say to a CIO who want to understand what SW could do for their company, but it applies to museum people too:
"Well you should take an inventory of what you have got in the way of data and
you should think about how valuable each piece of data in the company would be
if it were available to other people across the company, or if it were available
publicly, and if it were available to your partners."And then, you should make a list of these things and tackle them in order. You should make sure you don't change the way any of your data is existing, is managed, so you don't mess up the existing systems and so on.
He then goes on to talk about the developing technological picture including SPARQL, GRDDL and the rest, and from that point on I need to read a lot more attentively....
Wednesday, February 27, 2008
The EDL API debate - Museum Computer Group thread
For those in a hurry, the quick summary of recommendations for an API is this:
- be “'open', feature-rich and based on established and agreed metadata models/standards/schemas that allow multiple sources and minimise data loss.”
- feature most of the functionality that can be accessed from the back-end
- include terms and conditions that specifically requires that UGC be flexible enough to allow any reuse with attribution
- include a key to enable differentiated access to services for different types of users
- enable the addition of “crowd-sourced” user-generated metadata
- be lightweight, using REST, XML and possibly RSS and JSON
I'm still extremely interested in any more opinions on the whys and hows of an API for EDL (or even, more generally, for any digital resource built for a museum) so please do comment or e-mail me if you have anything to add.
************************************
Summary of MCG EDL/API thread
Contributors
Jeremy Ottevanger, web developer, Museum of London
Tehmina Goskar
David Dawson, Senior Policy Adviser (Digital Futures), MLA
Mike Ellis, Solutions Architect, Eduserv
Martyn Farrows, Director, Lexara Ltd
Dr John Faithfull, Hunterian Museum, University of Glasgow
Sebastian Chan, Manager, Web Services, Powerhouse Museum
Nick Poole, Chief Executive, MDA
Terry Makewell, Technical Manager, National Museums Online Learning Project
Robert Bud, Science Museum
Matthew Cock, Head of Web, The British Museum
Douglas Tudhope, Professor, Faculty of Advanced Technology University of Glamorgan
Kate Fernie, MLA
Trevor Reynolds, Collections Registrar, English Heritage
Dylan Edgar, London Hub ICT Development Officer
Joe Cutting, consultant (ex-NMSI)
Richard Light, SGML/XML & Museum Information Consultancy (DCMI & SPECTRUM contributor, developer of MODES)
Ian Rowson, General Manager, ADLIB Information Systems
Graham Turnbull, Head of Education & Editorial, Scran
Frankie Roberto, Science Museum, London
Overview
The discussion kicked off with an introduction to EDL from JO, and a request for responses to the idea of an API for it, specifically:
- whether and why an API would be useful to them, or influence their decision on whether to contribute content to EDL
- what features might prove useful
- any examples of APIs or of their application that they think provide a model for what EDL's API could offer or enable
A second e-mail followed, offering some possible use cases for museums, libraries and archives; for strategic bodies; and for third parties.
Responses fell into three main (interconnected) strands:
- attempting to understand the role and purpose of EDL itself, and debating the value of participation
- problems relating to the practicalities of cataloguing and digitisation of collections, and the publication/aggregation of the data
- the API question
As well as providing useful ideas in respect of an API, the discussion made it clear that in the UK at least there is a need for some public relations work to be done to make the case for EDL, to explain its use for museums and to demonstrate that it will be doing something genuinely new and valuable. Barriers need to be as low as possible, and payoffs immediate and demonstrable. An alternative route to ensuring that there are contributors is coercion, so that funding is dependent upon participation, or a backdoor route wherein content aggregated for other purposes is submitted by aggregators, but ensuring institutional buy-in will be the best route to success and garner the most support. As Nick Poole (NP) himself stated:
The real question, to my mind, is whether museums perceive enough value in participating in something like the EDL to be worth the time it takes to get
involved. People have been burned in the past by services such as Cornucopia
which have tended to be relatively resource-intensive, but with little direct
payoff for individual museums - I'm not surprised people are sceptical.
EDL
Questions included, how would EDL fit in with existing EU and UK projects
such as MICHAEL, Cornucopia, and the People’s Network Discover Service. David
Dawson (DD) offered a detailed overview of its position in this network.
Cataloguing and other barriers
As John Faithfull (JF) expressed it:
I think that the current lack of killer "one stop" apps in the museum sector
is not so much due to lack of projects, technologies, or even standards, but
lack of available basic collection content for them to work with.
While supportive of APIs, he felt that it was the lack of online collection data that was the main problem. Infrastructural problems, such as access to a web server to enable automatic content harvesting in a sustainable fashion, were a big challenge. Nevertheless, he suggested that “the amount publicly available online is bizarre, bewildering and indefensible, given how technically simple the basic task has been for a long time.” Getting even flawed records out there is great for users (a point supported by Matthew Cock). Robert Bud raised some objections to this, if it just added “noise” and confusion to the internet.
NP also argued that shiny front ends tended to get financial priority over sorting out the data, but that we should get on and make the best of what we have (EDL being one means). He also felt that curators often put up resistance to getting their data online.
DD explained the planned architecture for content aggregation, which led to a discussion of software capable of acting as an OAI gateway, Trevor Reynolds pointing out that implementing an OAI gateway is not necessarily that simple. Richard Light (RL), Graham Turnbull, Ian Rowson and DD pointed to various products that do or might offer OAI servers (Modes, Scran-in-a-box, Adlib, MimsyXG and possibly others). NP indicated, too, that the solution should not be oriented at one service (EDL) or one protocol, but should be multilingual, and “the burden of responsibility has to be shifted onto the services themselves to ensure that they capture and preserve as much of the value in the underlying datasets as possible.”
Dylan Edgar pointed to the need to measure or demonstrate impact, if only in order to get funding, whilst DD reminded us that Renaissance and Designation funding, at least, came with a requirement to make metadata available to the PNDS.
An API for EDL
Mike Ellis (ME) argued that:
The notion of an API in *any* content-rich application should be moving not
only in our sphere of knowledge ("I know what an API is") but *fast* into our
sphere of requirement ("give me an API or I won't play")…
…EDL should have a
feature-rich API. A good rule of thumb for this functionality is to ask: "how
much of what can be done by back-end and developer built web systems can be done and accessed via the API?" In an ideal world it'd be 100%. If it's 0 then run
away, fast!
Applications must give us “easy, programmatic access into our data”.
Lexara’s Martyn Farrows made the case, from experience in the commercial software sector, that any API should be “'open', feature-rich and based on established and agreed metadata models/standards/schemas that allow multiple sources and minimise data loss.”
Sebastian Chan suggested that APIs may be “a *practical* alternative to the never ending (dis)agreement on 'standards'.” He suggested an API key to manage security levels and access to different services for various types of users. With regard to user generated content:
it would be prudent to have a T&C that specifically requires that UGC be
flexible enough to allow any reuse with attribution. (A CC with attribution
license may be a good option).
NP pointed out that in the cultural heritage sector the APIs of recent years have generally been one way i.e. enabling content aggregation. There is a need for evidence of the value that this returns to the content provider, in exchange for the cost of participation. He suggested that opening up the content to third parties is no different: the value is not gained directly by the content provider, and the cost of providing something adequate to all uses is probably too high. He wondered if therefore an API might be inbound as well as outbound, to allow “crowd-sourcing” of value-adding metadata creation.
JF was sceptical of the idea of working with an application housing his institution’s data, at least if this meant another obligation (providing the data):
We need stuff that makes everything easier/cheaper/faster/better rather than
having extra things to do, at extra cost.
He pointed out that the Hunterian can already do all that they wish with their own data, and doubted that any central initiative could offer much to help them add to their capacity.
Joe Cutting (JC) suggested as his main use-case the creation of exhibition displays and interactives. He indicated the problems such applications can have, such as copyright, data integrity, completeness and validity, and service level. His recommendations could be well inform an API for EDL.
In terms of technology, ME argued “lightweight every step of the way”, meaning widespread and simple technology. REST and XML (perhaps RSS too) were his preferences, rather than SOAP or JSON, which JC backed up. RL added the proviso of XML being in a community-agreed an application (for example SPECTRUM interchange format). Frankie Roberto argued for both XML and JSON, since the latter has advantages for data exchange and overcoming cross-site security issues with JavaScript.
Friday, February 22, 2008
What have I been doing?
The discussion I kicked off on the MCG list about APIs and the EDL was really stimulating, though I never managed to find the time to respond to several of the interesting responses I had. There was interesting feedback on the idea of the EDL itself, or any effort at centralising content. There were also plenty of thoughts about what make good characteristics of APIs and what their uses may be, plus suggestions of examples. I now need to use these in preparing a talk for the EDL WP3 meeting in Paris on the 3-4 March. I've been working on this quite hard, well, sort of, in between the rest, and my own ideas about APIs and indeed the Semantic Web have been evolving a little. Preparation of my survey questionnaire is another area of (out of hours) activity.
What else? I spent 3 days on preparing an out of print guide to pottery fabrics for the web. I started with a PDF of the 200 page Quark document from 10 years ago, exported XML, did some cleaning by hand, passed it through three sets of transformations to structure data and then on to TEILite, and adapted another transformation to display this as HTML. It's not perfect yet and we need to hook all the images in to it, as well as proof read etc., but it was a good proof of how one can take this content and semi-automate the creation of a nicely structured version. The plan had been to database it, and I was just going to get structured data on each fabric out but we seemed to close to what I ended up doing that I went ahead. It felt good.
I did more preparation for moving the events database out of Oracle and into SQL Server; refined some ideas with the help of the microformats list (in short, sod that, it's going to be eRDF for me or something like); met Mike Ellis to talk about the ways that Eduserve can work with museums, gab about microformats and all the rest; talked with a consultant we have working on the Port of London Archives, held at Museum in Docklands, about IT requirements, OAI-PMH and so on (followed up today with a grand assembly of all his interviewees, very interesting); worked on the London's Burning site for key stage 1 kids (more fancy pants XSLT for me, but the good bit will be a great interactive by ON 101); also work on integrating a new game, Family Favourites, soon to be launched at MiD; I got RSS feeds (and other XML sources) drawn into our site server-side (not in a public place yet, but working) and along the way rediscovered a baby REST interface I'd built in the autumn. At present this just lets you search the MoLAS publications, but events and collections are but a short way off if I get a few minutes. I advised on the procurement of a new map application for the London Sugar and Slavery gallery, although we only just made one. Still, there's money to pour away and it must be poured before the end of the financial year. Damn that financial year, it's the bane of my life right now! And I've been trying to get this blasted generic timeline project back on track. Happily today I had a meeting where we got ourselves a plan of action, and just a moment ago spoke to the designer about the next steps so now I hope there's time to get it done before, you guessed it, the end of the financial year...
Quick note: Waibel and Godby reporting on the MCN 2007 (just published in Ariadne) made some interesting observations, including: "During the public CDWA Lite Advisory Committee meeting, Inge Stein (Konrad-Zuse Zentrum für Informationstechnik, Berlin) presented on Museumdat [4], a harmonisation of CDWA (Categories for the Description of Works of Art) Lite with the CIDOC (Committee on Documentation of the International Council of Museums) Conceptual Reference Model). One of the motivations for this effort: with a small amount of changes, CDWA Lite could be used for all objects across the cultural heritage spectrum, whereas currently it is optimised exclusively for fine art. All delegates agreed that the changes proposed by the German museum community should form the basis for the next version of CDWA Lite. Monika Hagedorn-Saupe (Institute for Museums Studies, Germany), Inge Stein and the Advisory Committee agreed that a single international version of the standard would be desirable."
"The Town Hall Meeting on Intellectual Property: Museum Image Licensing – The Next Generation provoked a lively debate, with many points of view represented by both presenters and delegates, and little evidence of an emerging consensus around the business model for sustaining digital image provision: the room seemed divided between those who feel that the museum community can make the most impact in our information economy by providing open access whenever legally possible, and those who favour business models of cost recovery or even revenue generation. "