This page lists issues from our discussion while defining the eSciDoc application profile.

Open[edit]

Complex Elements[edit]

The proposed data model for a complex type like "Creator" in eSciDoc looks like this:

Creator, with properties
- CreatorType, which can either be:
  - Person, which has the following properties:
    - Complete Name
    - Family Name
    - Given Name
    - Alternative Name
    - Person Title
    - Pseudonym
    - Organisation
    - Identifier
  - Organisation, with the following properties:
    - Oranisation Name
    - Address
    - Identifier
- Creator Type has a further property:
  - Creator Role, which can be:
    - Author
    - Artist
    - Editor, ....

If we want the Application Profile to be Dublin-Core compliant, an issue with such complex types arises:
The DC Application Profile guidelines define Application Profiles as flat structures by allowing for relational attributes such as

Refines
Refined By
Encoding Scheme For
Has Encoding Scheme
Similar To

One possible solution to the dilemma would look like:

use "person" as an element that refines "creator" with an encoding scheme that defines its components (complete name, family name, ...)
use "organisation" as an element that refines "creator" with a corresponding encoding scheme
either
- attach creatorRole as component of "person" and "organisation" with yet another encoding scheme (not sure whether or not nested encoding schemes are allowed)
- or create an element "creatorRole" on the same level as "person" and "organisation" with a corresponding encoding scheme

Are there other suggestions?

Further resources/requirements under work[edit]

Functional changes under discussion for r3, see https://zim01.gwdg.de/trac/wiki/MDSSpec/Revision
Requirements regarding copyrights, see http://colab.mpdl.mpg.de/mediawiki/EDoc_to_PubMan_migration#Copyright_Information

Namespaces[edit]

Currently, URLs for eSciDoc namespaces do not resolve to anything useful:

This should be changed, and they should be made persistent (possibly using PURL?).

Responsible: Natasa & Lars

Usage of Source[edit]

dc:source has been used against DC semantics and should be changed to "isPartOf". In addition, the element bibliographicCitation has been created to improve interoperability (should be available twice: maschine-readable as well as human-readable). See also: Guidelines for Encoding Bibliographic Citation Information in Dublin Core Metadata

Closed[edit]

Components[edit]

from the discussion on 30th of January: Introduce distinction between metadata (e.g. format, description, content category) and properties (e.g. date-created, etc?)

Further process of splitting the component information agreed with FIZ, see mails between Frank and Natasa --Inga 18:02, 1 February 2008 (CET)

Repeating refinements defined in existing AP?[edit]

Question: Do we need to document refinements which are inherited from external sources? Example: For "alternative" we currently repeat the information ("Refines http://purl.org/dc/elements/1.1/title") from dcterms, the same is not done for "tableofcontents" (refines http://purl.org/dc/elements/1.1/description)

Result from meeting with Traugott, Andreas, Kristina and Inga from 31st of January: The application profile should be self-contained, thus all refinements used by the eSciDoc AP should be explicitly specified, even the information is just replicated from the external AP. --Inga 22:41, 31 January 2008 (CET)

Best Practices[edit]

... are used to provide further remarks and cataloging recommendation to users of the application profile. Inga is responsible to deliver this information.

Talk:ESciDoc Application Profiles

Contents