Difference between revisions of "Talk:ESciDoc Application Profiles"
| Line 1: | Line 1: | ||
This page lists issues from our discussion while defining the eSciDoc application profile. | |||
= Open = | |||
== Complex Elements == | == Complex Elements == | ||
| Line 23: | Line 27: | ||
**** Artist | **** Artist | ||
**** Editor, .... | **** Editor, .... | ||
If we want the Application Profile to be Dublin-Core compliant, an issue with such complex types arises:<br /> | If we want the Application Profile to be Dublin-Core compliant, an issue with such complex types arises:<br /> | ||
| Line 42: | Line 45: | ||
'''Are there other suggestions?''' | '''Are there other suggestions?''' | ||
== Further resources/requirements under work == | == Further resources/requirements under work == | ||
| Line 56: | Line 53: | ||
== Best Practices == | == Best Practices == | ||
... are used to provide further remarks and cataloging recommendation to users of the application profile. | |||
'''Responsible''': Inga | '''Responsible''': Inga | ||
== Namespaces == | == Namespaces == | ||
| Line 76: | Line 67: | ||
'''Responsible''': Natasa & Lars | '''Responsible''': Natasa & Lars | ||
---- | |||
= Closed = | |||
== Components == | |||
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 --[[User:Inga|Inga]] 18:02, 1 February 2008 (CET) | |||
== Repeating refinements defined in existing AP? == | |||
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. --[[User:Inga|Inga]] 22:41, 31 January 2008 (CET) | |||
Revision as of 17:02, 1 February 2008
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
- Person, which has the following properties:
- Creator Type has a further property:
- Creator Role, which can be:
- Author
- Artist
- Editor, ....
- Creator Role, which can be:
- CreatorType, which can either be:
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
Best Practices[edit]
... are used to provide further remarks and cataloging recommendation to users of the application profile.
Responsible: Inga
Namespaces[edit]
Currently, URLs for eSciDoc namespaces do not resolve to anything useful:
- http://escidoc.mpg.de/metadataprofile/schema/0.1/types
- http://escidoc.mpg.de/metadataprofile/schema/0.1/idtypes
This should be changed, and they should be made persistent (possibly using PURL?).
Responsible: Natasa & Lars
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)