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

Open[edit]

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 dc:source[edit]

dc:source is 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

Usage of dc:creator[edit]

dc:creator is used against DC semantics. Two options:

* introduce the understanding of "primary creator" to pubman (-> could be stored in dc:creator)
* use the dc:contributor element + role (re-use from loc)

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.

Complex Elements: Creator and Organization[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, ....

Has been solved by introducing own application profiles for persons and organization --Inga 12:24, 29 February 2008 (CET)

Complex Element: Date[edit]

Date: We do have more date types, e.g. publication, publication-online

Has been flatten to explicit elements, e.g. dcterms:created --Inga 12:22, 29 February 2008 (CET)

Talk:ESciDoc Application Profiles

Contents