MPDL Meeting Metadata Handling 2009-07-27-28

MPDL

Application profiles

 * open questions
 * Julia has to provide a list, e.g. metadata profiles with additionally embedded metadata from person in publication items, not pure referencing, )


 * enhancements Publications and other profiles
 * Adding Geo metadata
 * Adding domain-specific metadata to publications (JusCMS)
 * Adding metadata in different language to publications (JusCMS)
 * Only if possible, pls schedule it for 28th morning..would like to participate--Ulla 07:57, 23 July 2009 (UTC)

interoperable metadata in general

 * requirements
 * what is possible for us
 * efforts
 * best practice, tools, technologies


 * JK: The aim to understand:
 * what are in general interoperable metadata
 * what can we do on interoperability
 * what kind of strategy we could proceed with

explanations

 * TK:Traugott's slides
 * Semantic and syntactic interoperability
 * Syntactic: applying common formats and protocols for data transfer and merging
 * Semantic: about shared meaning of the content


 * Approaches to semantic interoperablity
 * agree on standards, cores
 * schema reuse
 * conversion / normalization
 * crosswalks
 * Mappings
 * Metadata enhancements (exact context of usage for a term, e.g. "net" - fishing, IT, linguists etc.)


 * areas for interoperability improvement
 * data structures (esp. for metadata)
 * categoral data - classifications, general subjects, structured vocabularies, subject access (universals)
 * factual data - people, items, places, name authorities and named entities (particulars)


 * metadata interoperability (schema, record and repository level). Usage scenarios:
 * searching in heterogeneus records and across collections
 * re-use in other collections and services

generic handling of metadata

 * Requirements
 * is DSP valid for all profiles?
 * what to do when research data are coming and there are no published profiles but requirements to bring data online as soon as possible?
 * best practices, tools, schemas
 * Input MPDL on current approach:
 * DSP (definition, purpose, validation, working with vocabularis etc.)
 * Solution configuration (i.e our screen configuration)

CoNE - control of named entities and vocabularies

 * check whether SKOS is possible, define approach
 * vocabulary registries (isocat, NSDL Registry)
 * Only if possible, pls schedule it for Tuesday morning...would like to participate--Ulla 07:58, 23 July 2009 (UTC)

Transformation service

 * input from MPDL, further steps
 * input from Traugott on current approach (after presentation)

PubMan
The other one is the cone person (http://colab.mpdl.mpg.de/mediawiki/CoNE_Person) that is additionally used (refered) if the person is registrated in cone and we have more information. So we have sometimes redundant information e.g. person name. As far as I remember this is whished because we want to keep the data as it is typed in (notation). In some cases we would have a property range value that is a composition of a resource (escidoc person) and another external resource (cone person). Maybe we can discuss about a better way howto represent this (e.g. with refinements). publication: (remark: source, event are properties refering to the types source and event - the properties have to be renamed) place, edition, total-number-of-pages, academic degree, location, publishing-info event: start-date, end-date
 * the subject problem: dc subject element for both - keywords and DDC subjects
 * creator: regarding the DC pages it should be fine to use dc:creator with a complex type as range (escidoc person/organization) but it doesn't work with the dc schema
 * person: actually we have two person types. The escidoc person (http://colab.mpdl.mpg.de/mediawiki/ESciDoc_Application_Profile_Person) which doesn't have an identifier and is always used for personal info.
 * you proposed just to provide an interoperable metadata output and not change the internal data model. This might solve many of our issues. Maybe we can continue this discussion with the others according to the topic "what do we have to do for interoperable metadata".
 * Maybe you can have a look at my vocabulary terms URIs. I am not sure about the following terms:

ViRR

 * we are representing our metadata with mods schema. Do we have to provide an extra mapping to vocabulary terms?