Talk:ESciDoc Application Profiles

From MPDLMediaWiki
Jump to navigation Jump to search

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

Open[edit]

PURLs / Namespaces[edit]

Natasa reserved the domain http://purl.org/escidoc.

Substructure[edit]

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 eSciDoc-specific term, so I would rather use http://purl.org/escidoc/metadata/terms/degree than http://purl.org/escidoc/metadata/degree... but again, it looks like we are facing terminology problems --Inga 12:48, 10 March 2008 (CET)
Inga, you're right -- Andreas Gros 08:46, 13 March 2008 (CET)
Am I right that http://purl.org/escidoc/metadata/terms/creatorrole/ would only include encoding scheme entries which are used by eSciDoc in addition to those selected from MARC relators? --Inga 16:44, 13 March 2008 (CET)
Yes, that's right Andreas Gros 09:45, 14 March 2008 (CET)

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
"http://purl.org/escidoc/metadata/elements/degree" and
"http://purl.org/escidoc/metadata/terms/degree" -> that point to allowed values?
Maybe is only my confusion, but just to cross check again. --Natasa 13:26, 13 March 2008 (CET)
This URL (http://purl.org/escidoc/metadata/terms/degree/) 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 http://escidoc.org/metadata/terms/degree/index.xxx (for example)). Therefore, I think that it is no problem that the terms belonging to the encoding scheme degree appear under http://purl.org/escidoc/metadata/terms/degree/phd, http://purl.org/escidoc/metadata/terms/degree/staatsexamen, etc. that link to entries on the page mentioned above (http://escidoc.org/metadata/terms/degree/index.xxx). -- Andreas Gros 09:52, 14 March 2008 (CET)

Location[edit]

Furthermore, the PURLs have to link/resolve to somewhere (see discussion on https://zim01.gwdg.de/trac/wiki/MDSSpec/Namespaces). Following this discussion Andreas Gros suggests to use:

During the FIZ-SUB-MPDL-VC-Meeting we agreed on switching from escidoc.de to escidoc.org because of the increasingly international context eSciDoc is used in and linked to.

Would it be http://purl.org/escidoc/metadata/terms/2008/03/xx/reviewmethod/ or http://purl.org/escidoc/metadata/terms/reviewmethod/2008/03/xx/? --Inga 16:53, 13 March 2008 (CET)
Just by creating the first PURL, 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 (UTC)

Elements[edit]

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

Encoding Schemes and Data Types[edit]

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 BMBF 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 ISBN/ISSN/DOI/...-number in this property, but we would need an export mechanism for the external world to access this information.
    • or datatype "URI" where the identifier is encoded into a URI, 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 (GBV) mentioned not to store http-resolver-part with PIDs because the PID then is bound to a specific resolver but to establish some kind of handler that is able to transform a PID to the appropriate URL. So the http-resolver-part is not a part of the PID itself but is part of the resolving system which comes with the PID. Frank 09:31, 11 March 2008 (CET)

Further Tasks[edit]

  • Answer open questions
  • Polishing of AP, e.g. adding best practice examples, define structure and headings of AP?
  • Which consequences need to be derived from the AP 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 https://zim01.gwdg.de/trac/wiki/MDSSpec/Revision
  • Requirements regarding copyrights, see http://colab.mpdl.mpg.de/mediawiki/EDoc_to_PubMan_migration#Copyright_Information
  • Do we need an application model as a basis for this application profile?
  • Recommendation for identifier usage required
  • Check person-pseudonym: Inga
  • AP for file required: Andi
  • Decision on subject vocabulary (DDC) - check this with Traugott: Andi - DONE, see above
  • Input for contributor roles used on edoc: Ulla & Vlad
  • Compare with relators provided by LoC, see http://www.loc.gov/loc.terms/relators/

Process[edit]

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

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?) and in accordance with the provided PURL structure, see PURLs and namespaces

There are PURLs for schema and profiles:

PURLs for ViRR and Faces profiles will be created soon --Kurt 12:12, 18 May 2009 (UTC)

Responsible: Julia

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)

Enhanced Scientific Documentation

Central European Time

MAchine-Readable Cataloging

Uniform Resource Locator

Fachinformationszentrum Karlsruhe

Staats- und Universitätsbibliothek

Max Planck Digital Library

Persistent Uniform Resource Locators

Coordinated Universal Time

Publication Management

Bundesministerium für Bildung und Forschung

International Standard Book Number

International Standard Serial Number

Digital Object Identifier

Uniform Resource Identifier

Gemeinsamer Bibliotheksverbund

Persistent Identifer or Identification

Application Profile

Display Data Channel

Virtueller Raum Reichsrecht

Retrieved from "https://colab.mpdl.mpg.de/mw010/index.php?title=Talk:ESciDoc_Application_Profiles&oldid=34682"