Difference between revisions of "Talk:ESciDoc Application Profiles"
(34 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
== Complex Elements == | This page lists issues from our discussion while defining the eSciDoc application profile. | ||
= Open = | |||
=== PURLs / Namespaces === | |||
Natasa reserved the domain http://purl.org/escidoc. | |||
==== Substructure ==== | |||
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: | |||
* http://purl.org/escidoc/metadata/terms/ -- for the list of eSciDoc-specific terms | |||
* http://purl.org/escidoc/metadata/terms/types/ -- for our own genre encoding scheme entries (e.g. + talkatevent) | |||
* http://purl.org/escidoc/metadata/terms/reviewmethod/ -- review method encoding scheme entries (e.g. + noreview) | |||
* http://purl.org/escidoc/metadata/terms/degree/ -- degree encoding scheme entries (e.g. +phd) | |||
* http://purl.org/escidoc/metadata/terms/invitationstatus/ -- invitation status (e.g. invited) for describing an event | |||
* http://purl.org/escidoc/metadata/terms/creatorrole/ -- encoding scheme for roles of contributors (e.g. author, photographer,...) | |||
* http://purl.org/escidoc/metadata/profiles -- for the list of our application profiles | |||
: 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 --[[User:Inga|Inga]] 12:48, 10 March 2008 (CET) | |||
:: Inga, you're right -- [[User:Andi|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? --[[User:Inga|Inga]] 16:44, 13 March 2008 (CET) | |||
:::: Yes, that's right [[User:Andi|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: | |||
* http://purl.org/escidoc/metadata/terms/types/ | |||
* http://purl.org/escidoc/metadata/terms/degree/ | |||
and refer to the property itself, e.g. degree, without the slash: | |||
* http://purl.org/escidoc/metadata/terms/degree | |||
: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. --[[User:Natasab|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''). -- [[User:Andi|Andreas Gros]] 09:52, 14 March 2008 (CET) | |||
==== Location ==== | |||
Furthermore, the PURLs have to '''link/resolve''' to somewhere (see discussion on https://zim01.gwdg.de/trac/wiki/MDSSpec/Namespaces). Following this discussion [[User:Andi|Andreas Gros]] suggests to use: | |||
* for profiles: http://www.escidoc.org/metadata/profiles/2008/03/xx/ | |||
* for terms: http://www.escidoc.org/metadata/terms/2008/03/xx/ | |||
* and likewise for types, reviewmethod, etc. like above | |||
* and link the most recent version to the corresponding default URL: | |||
* for profiles: http://www.escidoc.org/metadata/profiles/ | |||
* for terms: http://www.escidoc.org/metadata/terms/ | |||
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/? --[[User:Inga|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 --[[User:Natasab|Natasa]] 09:48, 8 September 2008 (UTC) | |||
=== Elements === | |||
I moved the discussions concerning an element on the discussion pages of the application profile containing the element. --[[User:Kristina|Kristina]] 13:53, 16 September 2008 (UTC) | |||
=== Encoding Schemes and Data Types === | |||
* '''ReviewMethod''': Eprints calls it "status" (http://purl.org/eprint/status/PeerReviewed and http://purl.org/eprint/status/NonPeerReviewed). Our PubMan set includes the following review methods: ''no review, internal'', and ''peer''. As our ''peer'' matches the meaning of ''PeerReviewed'' of Eprints, the following substructure suggests itself: use http://purl.org/eprint/status/PeerReviewed for ''peer'', and use | |||
** http://purl.org/escidoc/metadata/reviewmethod/internal | |||
** http://purl.org/escidoc/metadata/reviewmethod/noreview | |||
* '''Degree''': I have not found any good encoding scheme for academic degrees. The PubMan set contains this list of degrees: ''master, diploma, magister, staatsexamen, phd, habilitation''. What about using the following domain for the scheme/non-predefined terms: | |||
** http://purl.org/escidoc/metadata/terms/degree/staatsexamen ... | |||
:: However, ''degree'' is a rather ambiguous term, wouldn't it be better to use ''academic_degree'' instead? | |||
:: [[User:Andi|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. [[User:Frank|Frank]] 09:31, 11 March 2008 (CET) | |||
=== Further Tasks === | |||
* 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 === | |||
# finish AP | |||
# register PURLs | |||
# revise pubman xsd to reference definitions (ours and externals) | |||
== Namespaces == | |||
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?) and in accordance with the provided PURL structure, see [[Talk:ESciDoc_Application_Profiles#PURLs_.2F_Namespaces|PURLs and namespaces]] | |||
There are PURLs for schema and profiles: | |||
* schemas: | |||
**http://purl.org/escidoc/metadata/schemas/0.1/publication | |||
**http://purl.org/escidoc/metadata/schemas/0.1/file | |||
**http://purl.org/escidoc/metadata/schemas/0.1/organization | |||
**http://purl.org/escidoc/metadata/schemas/0.1/escidocprofile | |||
**http://purl.org/escidoc/metadata/schemas/0.1/enumtypes | |||
**http://purl.org/escidoc/metadata/schemas/0.1/types | |||
**http://purl.org/escidoc/metadata/schemas/0.1/idtypes | |||
**http://purl.org/escidoc/metadata/schemas/0.1/virrelement | |||
**http://purl.org/escidoc/metadata/schemas/0.1/transcription | |||
**http://purl.org/escidoc/metadata/schemas/0.1/translation | |||
**http://purl.org/escidoc/metadata/schemas/0.1/language | |||
**http://purl.org/escidoc/metadata/schemas/0.1/languagefeature | |||
**http://purl.org/escidoc/metadata/schemas/0.1/collection | |||
**http://purl.org/escidoc/metadata/schemas/0.1/image | |||
**http://purl.org/escidoc/metadata/schemas/0.1/film | |||
**http://purl.org/escidoc/metadata/schemas/0.1/source | |||
**http://purl.org/escidoc/metadata/schemas/0.1/event | |||
**http://purl.org/escidoc/metadata/schemas/0.1/person | |||
* PubMan profiles | |||
**http://purl.org/escidoc/metadata/profiles/0.1/publication/ | |||
**http://purl.org/escidoc/metadata/profiles/0.1/person/ | |||
**http://purl.org/escidoc/metadata/profiles/0.1/organization/ | |||
**http://purl.org/escidoc/metadata/profiles/0.1/file/ | |||
**http://purl.org/escidoc/metadata/profiles/0.1/event/ | |||
**http://purl.org/escidoc/metadata/profiles/0.1/source/ | |||
PURLs for ViRR and Faces profiles will be created soon --[[User:Kurt|Kurt]] 12:12, 18 May 2009 (UTC) | |||
'''Responsible''': Julia | |||
= 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) | |||
== 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 eSciDoc looks like this: | The proposed data model for a complex type like "Creator" in eSciDoc looks like this: | ||
Line 24: | Line 172: | ||
**** Editor, .... | **** Editor, .... | ||
Has been solved by introducing own application profiles for persons and organization --[[User:Inga|Inga]] 12:24, 29 February 2008 (CET) | |||
== 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 --[[User:Inga|Inga]] 12:22, 29 February 2008 (CET) |
Latest revision as of 15:11, 18 May 2009
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:
- http://purl.org/escidoc/metadata/terms/ -- for the list of eSciDoc-specific terms
- http://purl.org/escidoc/metadata/terms/types/ -- for our own genre encoding scheme entries (e.g. + talkatevent)
- http://purl.org/escidoc/metadata/terms/reviewmethod/ -- review method encoding scheme entries (e.g. + noreview)
- http://purl.org/escidoc/metadata/terms/degree/ -- degree encoding scheme entries (e.g. +phd)
- http://purl.org/escidoc/metadata/terms/invitationstatus/ -- invitation status (e.g. invited) for describing an event
- http://purl.org/escidoc/metadata/terms/creatorrole/ -- encoding scheme for roles of contributors (e.g. author, photographer,...)
- http://purl.org/escidoc/metadata/profiles -- for the list of our application profiles
- 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)
- 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)
- Inga, you're right -- Andreas Gros 08:46, 13 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:
- for profiles: http://www.escidoc.org/metadata/profiles/2008/03/xx/
- for terms: http://www.escidoc.org/metadata/terms/2008/03/xx/
- and likewise for types, reviewmethod, etc. like above
- and link the most recent version to the corresponding default URL:
- for profiles: http://www.escidoc.org/metadata/profiles/
- for terms: http://www.escidoc.org/metadata/terms/
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]
- ReviewMethod: Eprints calls it "status" (http://purl.org/eprint/status/PeerReviewed and http://purl.org/eprint/status/NonPeerReviewed). Our PubMan set includes the following review methods: no review, internal, and peer. As our peer matches the meaning of PeerReviewed of Eprints, the following substructure suggests itself: use http://purl.org/eprint/status/PeerReviewed for peer, and use
- Degree: I have not found any good encoding scheme for academic degrees. The PubMan set contains this list of degrees: master, diploma, magister, staatsexamen, phd, habilitation. What about using the following domain for the scheme/non-predefined terms:
- 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]
- finish AP
- register PURLs
- revise pubman xsd to reference definitions (ours and externals)
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?) and in accordance with the provided PURL structure, see PURLs and namespaces
There are PURLs for schema and profiles:
- schemas:
- http://purl.org/escidoc/metadata/schemas/0.1/publication
- http://purl.org/escidoc/metadata/schemas/0.1/file
- http://purl.org/escidoc/metadata/schemas/0.1/organization
- http://purl.org/escidoc/metadata/schemas/0.1/escidocprofile
- http://purl.org/escidoc/metadata/schemas/0.1/enumtypes
- http://purl.org/escidoc/metadata/schemas/0.1/types
- http://purl.org/escidoc/metadata/schemas/0.1/idtypes
- http://purl.org/escidoc/metadata/schemas/0.1/virrelement
- http://purl.org/escidoc/metadata/schemas/0.1/transcription
- http://purl.org/escidoc/metadata/schemas/0.1/translation
- http://purl.org/escidoc/metadata/schemas/0.1/language
- http://purl.org/escidoc/metadata/schemas/0.1/languagefeature
- http://purl.org/escidoc/metadata/schemas/0.1/collection
- http://purl.org/escidoc/metadata/schemas/0.1/image
- http://purl.org/escidoc/metadata/schemas/0.1/film
- http://purl.org/escidoc/metadata/schemas/0.1/source
- http://purl.org/escidoc/metadata/schemas/0.1/event
- http://purl.org/escidoc/metadata/schemas/0.1/person
- PubMan profiles
- http://purl.org/escidoc/metadata/profiles/0.1/publication/
- http://purl.org/escidoc/metadata/profiles/0.1/person/
- http://purl.org/escidoc/metadata/profiles/0.1/organization/
- http://purl.org/escidoc/metadata/profiles/0.1/file/
- http://purl.org/escidoc/metadata/profiles/0.1/event/
- http://purl.org/escidoc/metadata/profiles/0.1/source/
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
- 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:
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)