London, October 2007
Following introductions the meeting began with a presentation by Pete J and Julie on the Dublin Core Abstract Model and the Scholarly works Application Profile.
DCMI Abstract Model and Application Profiles
- Pete Johnston, Eduserv Foundation
The Dublin Core element set published in 1995.
A resource is anything that can be identified by a URI. Resources have property value pairs associated with them
DCAM defines the DC description set and is composed of
- Resource model
- Description set model
- Vocabulary model
DCAM does not describe how to represent description sets in concrete terms and doesn not specify a fixed set of terms.
Descriptions sets are composed or one of more descriptions which may have a resource URI. Each description is composed of one or more statements. Each statement must have a property URI and literal or non literal value surrogates.
The DCMI Description Set Profile is a way of describing structural constraints on a description set “ this is not part of DCAM. Mikael Nilssen is developing a model and XML syntax for DSP and Fredrik Enoksson is developing wiki syntax for DSP.
A DCAM compatible application profile consists of
- Functional requirements
- Domain model
- Description Set Profile
- Two other components
Methodology for Images Application Profile
– Mick Eadie, AHDS Visual Arts
Have looked at a range of existing application profiles including SWAP and Jorum and have drafted attributes, a model, usecases and functional requirements which are available form the project wiki.
The primary objective of the project is to develop a working application profile along the lines of SWAP (this was prioritised by members of the panel) and the team intend to follow the SWAP development model.
Getting the profile implemented and used will be the most challenging aspect of the project. The project team hope to engage with repository vendors and developers asap and are meeting with the ePrints team to discuss their potential involvement. (ePrints (Tim Brody) and Fedora (Richard Green, Chris Awre) people are represented on the panel.)
Models the project will look at in more detail
- VRA Core 4.0 http://www.vraweb.org/projects/vracore4/index.html
- CIDOC CRM http://cidoc.ics.forth.gr/
- FRBR – http://www.ifla.org/VII/s13/wgfrbr/
- IPTC International Press Telecommunications Council
May be beneficial for JISC to fund some kind of synthesis or over arching project that could map the relationship between the various application profile creation projects.
- Need to be careful if you state you want rich metadata “ why do you want it?
- Users need to be able to find images about or of a particular thing., the content of the image is crucial
- Is this about metadata exchange or resource discovery? Its about exchange to support resource discovery.
- The images and time based media profile projects must work together.
- The context of use is crucial so provenance needs to be recorded.
- The national repositories section of the usecases document really refers to aggregator services.
- Will the profile accommodate 3d models that can be manipulated e.g. molecular models?
- The draft model scoped by the project is too simple and needs revision.
- The concept of the master image is problematic and ambiguous. The underlying model must be as neutral as possible and should be based on relationships. œMaster should be regarded as a class of relationship rather than a class of artefact.
- Many images are composite objects so the whole – part relationship needs to be considered.
- FRBR is designed with textual resources in mind so the model may not fit visual images. In FRBR the work is always an abstract thing. In the case of images there may be no work e.g. in the case of a photograph of a giraffe, the giraffe can not be considered as œwork
- In order to describe images relationships are key. The profile must make provision for be bi-directional relationships and relationships to identifiers elsewhere.
- User generated tags can be accommodated by the œhas annotation field.
- The simplest approach may be to identify metadata that is about the image and its creation and metadata that is about the content of the image. These two will overlap and the relationship between them is crucial. (Grant Young, TASI)
- Dimensionality of images is very important. Images have other dimensions than x and y.
- The model should stop short of describing the work.
- Colour space, coverage and encoding (i.e. what does a pixel encode – colour, temperature, etc) should be included as attributes.
- The relationship between images and time based media needs to be clarified
- œWhy not just define a core element set that could have extensions built on to it (!!)
- The team will start drafting an Ariadne article as it was generally agreed that this was highly beneficial to the SWAP project.
- Project should consider presenting at Open Repositories Conference in Southampton in April 2008 as the SWAP profile was presented at the 2007 conference.
- Project needs to work very closely with Intute and the time based media application profile project. It will also be important to work with the cultural heritage sector.
- Acceptance should be at an international level.
- Acceptance takes a long time as software is developed in long cycles.
- Need an exemplar that demonstrates key benefits to the community.
- Need to be aware that many people are simply storing their images in Flickr. This is the world the profile must work in.
- Need to demonstrate advantages from depositor and repository point of view.
A few thoughts¦
Julie and co have made the creation of SWAP look awfully easy :-}
It was notable, and a little worrying, that that there was very little discussion of tagging (raised once by Pete), use of sites like Flickr (raised once by me) or Web 2.0 technologies and approaches in general. However there was significant discussion of semantic web technologies and approaches.
It also became clear that its debatable how far the FRBR model can be stretched before it breaks. FRBR worked well for SWAP, but will it work equally well for images, learning materials etc?
It was also painfully clear that metadata creation is still a serious problem and that it is not always easy to distinguish between issues that relate to a profile and issues that relate to implementations of that profile.
As Father Jack would say œThat would be an implementation issue¦.