Talk:ESciDoc Application Profiles

From MPDLMediaWiki
Jump to: navigation, search

This page lists issues from our discussion while defining the eSciDocEnhanced Scientific Documentation application profile.


PURLs / Namespaces

Natasa reserved the domain


To be able to move forward we have to define a substructure for the domain. We agreed on following conventions for th path: all lower case, without delimiters

Suggested structure:

Andi, I thought that "degree" would be a eSciDocEnhanced Scientific Documentation-specific term, so I would rather use than but again, it looks like we are facing terminology problems --Inga 12:48, 10 March 2008 (CETCentral European Time)
Inga, you're right -- Andreas Gros 08:46, 13 March 2008 (CETCentral European Time)
Am I right that would only include encoding scheme entries which are used by eSciDocEnhanced Scientific Documentation in addition to those selected from MARCMAchine-Readable Cataloging relators? --Inga 16:44, 13 March 2008 (CETCentral European Time)
Yes, that's right Andreas Gros 09:45, 14 March 2008 (CETCentral European Time)

The standard procedure is to indicate that something is an encoding scheme with a forward slash at the end:

and refer to the property itself, e.g. degree, without the slash:

Andi, i did not got the last paragraph exactly probably. I think with "/" or without "/" is a very very small difference. This means that somehow we are really heavily "linking" the possible values (encoding schemas) to be specific to the metadata elements themselves. Why we put metadata elements (only without "/" in under the "terms"?) Are all of our metadata under "terms" namespace (those that are escidoc specific)? Or to be more precise: Is there a big reason not to have
"" and
"" -> that point to allowed values?
Maybe is only my confusion, but just to cross check again. --Natasa 13:26, 13 March 2008 (CETCentral European Time)
This URLUniform Resource Locator ( is only an identifier that is listed in an application profile together with a descriptive text (and links to the list of terms that appear on the page (for example)). Therefore, I think that it is no problem that the terms belonging to the encoding scheme degree appear under,, etc. that link to entries on the page mentioned above ( -- Andreas Gros 09:52, 14 March 2008 (CETCentral European Time)


Furthermore, the PURLs have to link/resolve to somewhere (see discussion on Following this discussion Andreas Gros suggests to use:

During the FIZFachinformationszentrum Karlsruhe-SUBStaats- und Universitätsbibliothek-MPDLMax Planck Digital Library-VC-Meeting we agreed on switching from to because of the increasingly international context eSciDocEnhanced Scientific Documentation is used in and linked to.

Would it be or --Inga 16:53, 13 March 2008 (CETCentral European Time)
Just by creating the first PURLPersistent Uniform Resource Locators, came up to this page... Inga what is the difference between these two? My first feeling is that the first alternative should be used.. but i am not aware of the differences at the moment --Natasa 09:48, 8 September 2008 (UTCCoordinated Universal Time)


I moved the discussions concerning an element on the discussion pages of the application profile containing the element. --Kristina 13:53, 16 September 2008 (UTCCoordinated Universal Time)

Encoding Schemes and Data Types

However, degree is a rather ambiguous term, wouldn't it be better to use academic_degree instead?
Andreas Gros sent an E-Mail to the BMBFBundesministerium für Bildung und Forschung to ask for a list of standardized terms of academic degrees used internationally and within Germany
  • Publication identifier: which data type to use?
    • either datatype "string" with a corresponding encoding scheme for the plain-text entries. Taking this option would mean that we can store just the ISBNInternational Standard Book Number/ISSNInternational Standard Serial Number/DOIDigital Object Identifier/...-number in this property, but we would need an export mechanism for the external world to access this information.
    • or datatype "URIUniform Resource Identifier" where the identifier is encoded into a URIUniform Resource Identifier, e.g.: http://...&ISSN=... Using this option would mean that we are more interoperable with the outside world as others would access such URIs directly, but for internal usage we would have to decode the information again.
Konstantin (GBVGemeinsamer Bibliotheksverbund) mentioned not to store http-resolver-part with PIDs because the PIDPersistent Identifer or Identification then is bound to a specific resolver but to establish some kind of handler that is able to transform a PIDPersistent Identifer or Identification to the appropriate URLUniform Resource Locator. So the http-resolver-part is not a part of the PIDPersistent Identifer or Identification itself but is part of the resolving system which comes with the PIDPersistent Identifer or Identification. Frank 09:31, 11 March 2008 (CETCentral European Time)

Further Tasks

  • Answer open questions
  • Polishing of APApplication Profile, e.g. adding best practice examples, define structure and headings of APApplication Profile?
  • Which consequences need to be derived from the APApplication Profile to existing escidoc publication xml schemas? (e.g. usage of dc:creator, dc:source and dc:type; re-use foaf elements; integrate links to terms?)
  • Functional changes under discussion for r3, see
  • Requirements regarding copyrights, see
  • Do we need an application model as a basis for this application profile?
  • Recommendation for identifier usage required
  • Check person-pseudonym: Inga
  • APApplication Profile for file required: Andi
  • Decision on subject vocabulary (DDCDisplay Data Channel) - check this with Traugott: Andi - DONE, see above
  • Input for contributor roles used on edoc: Ulla & Vlad
  • Compare with relators provided by LoC, see


  1. finish APApplication Profile
  2. register PURLs
  3. revise pubman xsd to reference definitions (ours and externals)


Currently, URLs for eSciDocEnhanced Scientific Documentation namespaces do not resolve to anything useful:

This should be changed, and they should be made persistent (possibly using PURLPersistent Uniform Resource Locators?) and in accordance with the provided PURLPersistent Uniform Resource Locators structure, see PURLs and namespaces

There are PURLs for schema and profiles:

PURLs for ViRRVirtueller Raum Reichsrecht and Faces profiles will be created soon --Kurt 12:12, 18 May 2009 (UTCCoordinated Universal Time)

Responsible: Julia



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 FIZFachinformationszentrum Karlsruhe, see mails between Frank and Natasa --Inga 18:02, 1 February 2008 (CETCentral European Time)

Repeating refinements defined in existing APApplication Profile?

Question: Do we need to document refinements which are inherited from external sources? Example: For "alternative" we currently repeat the information ("Refines") from dcterms, the same is not done for "tableofcontents" (refines

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 eSciDocEnhanced Scientific Documentation APApplication Profile should be explicitly specified, even the information is just replicated from the external APApplication Profile. --Inga 22:41, 31 January 2008 (CETCentral European Time)

Best Practices

... 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

The proposed data model for a complex type like "Creator" in eSciDocEnhanced Scientific Documentation 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 (CETCentral European Time)

Complex Element: Date

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 (CETCentral European Time)