Discussable v0.9

→ Information about submission as TDWG standard
→ MRTG Wiki Homepage
→ Current Schema Draft. This version is under internal review as part of the submission to TDWG.
→ Audubon Core Non normative document
→ MRTG Development History
→ MRTG Meeting Notes
→ MRTG Best Practices
→ XML Schema representation of Audubon Core
→ RDF representation of Audubon Core
→ MediaWiki Help

To reduce edit conflicts, please read and apply the suggestion in Template:WIP. Remember that the WIP warning will not be visible until you save. Sign and date your comment entries. This is best done by using the signature icon in the edit button collection at the top of the edit window.

The proposed normative specification is here. It should coincide with this page except for discussion and crosswalk entries. Discussants will not usually need to look there. All public commentary on the normative specification should be on this page.

To comment on the draft XML Schema, go here.

To comment on the draft RDF representation go here .

If you are unfamiliar with MRTG, please read the MRTG Non normative document before editing this page. It lays out why there is perceived a need for a biodiversity media resource metadata schema, and how we attempt to use existing metadata standards where possible. This page should be largely confined to discussion of what's missing, and what's good or bad about the specifications that are here. Critique of the architecture as a whole should be at MRTG Architecture

The Comments field in the item description should be used for comments proposed to be part of the standard. Comments about the standard should be in the Discussion section.

Remarks on namespaces.

1. The precise namespace for mrtg elements is yet to be determined, based on requirements of TDWG.
2. The dcterms namespace is given as http://dublincore.org/documents/dcmi-terms/. In email, Steve Baskauf observes that this is not the common url for the dcterms namespace uri. He also makes several other good observations which are discussed on mrtg element namespaces. The current namespaces make it easier for discussants to find the actual usage in dcmi by hitting the link. However, we probably need to use a namespace consistent with DarwinCore's use of Dublin Core terms. Please keep any discussion of these issues to mrtg element namespaces--BobMorris 05:25, 21 February 2010 (CET)

1 Terminology of this specification

There are many ways to organize metadata specifications, particularly as to the nomenclature of the constituents of the metadata. In this document and the associated non-normative documentation, we willfollow closely (sometimes verbatim) a portion of the Dublin Core Metadata Initiative (DCMI) metadata nomenclature as described in Section 2.3 of the DCMI Abstract Model (http://www.dublincore.org/documents/abstract-model/).

• A term is a metadata item that forms part of the description of a multimedia resource.
• A term has a type which is one of "Property" or "Class", We refer to a term of type Property as simply a Property, similarly for Class.
• A value is a resource - the physical, digital or conceptual entity or literal that is associated with a property when a property-value pair is used to describe a resource. Therefore, each value is either a literal value or a non-literal value.
• A literal value is a value which is a literal.
• A non-literal value is a value which is a physical, digital or conceptual entity.
• A literal is an entity which uses a Unicode string as a lexical form, together with an optional language tag or datatype, to denote a resource. In MRTG, the language tag appears as a value assigned to the metadata record.
• A Property is a term that has a value. The datatypes of values are specified in this document. Typically the values are either a member of a fixed set of literals, a URI, a numerical type, free text, or the datatype and values from an external controlled vocabulary referenced in the standard.
• A Class is a term that has a set of Properties. Thus, the values of the properties in this set define what it means for a resource (whether multimedia or not) to be a member of the class.. Typically if M is a resource and C is a class, we say "M is a C". We attempt to minimize the number of classes, because we want to support simple serializations, notably text files such as "Comma Separated Values" (CSV), in which structured representation is cumbersome or impossible.
• A Vocabulary is a set of terms.
• Multimedia Resource is anything that a provider identifies as belonging to one of the possible values of the MRTG Type term and one of the Subtype term values. A mechanism is provided by which providers can supply a privately defined subtype that will not collide with the MRTG defined Subtype values.
• A MRTG record is a set of terms with any property values conforming to this document, and which contain at least the six mandatory terms described below, and which describes a single multimedia resource (possibly including a Collection). One of these, the value of Identifier is a Globally Unique IDentifier (GUID), which may have been assigned to the resource by an external authority or by the provider of the metadata record.

Every MRTG term has a plain text Name, a URI and a plain text normative Definition. URI's for terms conform the the http URI scheme (See, http://en.wikipedia.org/wiki/URI_scheme, http://www.w3.org/TR/uri-clarification/, or http://www.ietf.org/rfc/rfc2396.txt ). Informally, one may understand this thusly: an http URI has the syntax of an http URL, but there is no expectation that putting it in a web browser will result in any information being returned to the browser, and if there is, it may have no relevance. This conformance requirement applies only to the URIs that identify MRTG terms. Any others, such as might arise if the values of MRTG propertiers are taken from another controlled vocabulary chosen by the user, as a few MRTG properties permit. In this case, those values may involve URIs conforming to a scheme given by that external vocabulary.

Because http URIs are rather lengthy, MRTG documents follow a standard practice of introducing a short abbreviation comprising a "namespace qualifier" and a mnemonic name closely related to the term's Name. The result is known in XML parlance as a qualified name. For example the documentation below for the Identifier term renders its URI as " dcterms:identifier" but hovering over it will reveal that its actual URI is http://dublincore.org/documents/dcmi-terms/#identifier. In fact, most of the URIs for terms borrowed from external vocabularies (about half of them) do in fact resolve to something in relevant documentation for that external standard. Sometimes it is not precise because the documentation is a PDF document and several (different!) URIs might apparently resolve to the same place. Keep in mind that any fortuitous resolution of an http URI is not related to its use as an identifier, no matter how informative that resolution may be. That said, MRTG solicits discussion on the wiki at points where contributors find our association of a MRTG term with that from another standard as misleading or otherwise inappropriate.

2 Management Vocabulary

Name:	Identifier
Normative URI:	dcterms:identifier
	Layer: Core — Required: Yes for collections, No for media resource (but preferred if available) — Repeatable: Yes
Definition:	An arbitrary code that is unique for the resource, with the resource being either a provider, collection, or media item.
Comments:	Recommend to follow dwc best practices. Using multiple identifiers implies that they have a same-as relationship, i.e. they all identify the same object (e.g. an object may have an http-URL, and lsid-URI, and a GUID-number).
Crosswalk:	DublinCore: dcterms:identifier — XMP: — DarwinCore: — NCD: ncd:collectionId — Morphbank: URL with id — NBII: System ID — K2N: k2n:Resource_ID — MIX2.0: mix2:BasicDigitalObjectInformation/ObjectIdentifier
Discussion	See ResourceID Discussion Use same mechanism as NCD for Collections. Shouldn't use "ResourceID" just ID. Recommend same to NCD. We should make sure we either have a "ReferableID" already or we need to provide one. yes? Greg. From Recommendations to GBIF: support metadata provider GUID schemes for identifying resource.' Are we adequately documentng that URI element does this? --BobMorris 16:35, 27 February 2009 (CET) NISO Object Identifier is a compound object of Type and Value. Should we recommend a parseable concatenation? --BobMorris 00:56, 7 March 2009 (CET) xmpMM (Media Management) identifiers are probably also complex, further analysis is needed! --GregorHagedorn 09:03, 7 March 2009 (CET) We need clarification about "unique". I favor GUID so that the Identifier unambiguously identifies the resource, no matter how one has acquired the metadata record. If we had a GUID for the metadata originator (provider?), then the pair <originatorGUID, Identifier> would suffice, but we don't have that. Even in that case we will need to say something like "the Identifier uniquely specifies the resource within all MRTG resources offered by the organization originating the metadata record"--BobMorris 01:12, 30 March 2009 (CEST) Must/may a forwarder change the Identifier? --BobMorris 01:12, 30 March 2009 (CEST) I do not understand how an Identifier is repeatable. Can someone please explain what this means? Particularly if we seek a GUID, there should be a one-to-one correspondence between an identifier and a resource. --Steve Baskauf 20:29, 7 May 2009 (CEST) Multiple identifiers must have a same-as relationship, i.e. all identifiers point to the same object. Requiring that the object has only a single identifier I believe is asking too much. Books have multiple ISBNs, a specimen will often have already have a museum-barcode identifier, etc. - still providing a URI for those in addition to existing identifiers would be desirable. I believe fitness for purpose of identifiers differs, depending on purpose... --GregorHagedorn 00:17, 11 May 2009 (CEST) I understand the need of more than a single <dcterms:identifier> in the same context, but I'm afraid that it may create implementation problems: we may need to distinguish different <identifier>s because they should be rendered or processed in different way. In our case they only could be distinguished by their contents, that may not be always possible. To make schema more flexible and extensible, I would allow attributes from user's namespace (unspecified by schema like my:process_url="http://example.com/getMyImage/"). Such 'foreign' attributes are not allowed by DwC schemas but why not to have a different, <mrtg:identifier>? If an idea of any Attribute is not acceptable, I would suggest, at the very least, an optional id attribute for every element in MRTG namespaces (particularly in wrappers like <MRTGCore id="value">: another problem with <identifier> elements that they may not be suitable as primary key in the relational database, and in any case, ID attribute are so handy that I would not ignore such an opportunity. --AlexeyZinovjev 13:37, 27 November 2009 (CET)
Name:	Type
Normative URI:	dcterms:type
	Layer: Core — Required: Yes — Repeatable: No
Definition:	Any dcmi type term from http://dublincore.org/documents/dcmi-type-vocabulary/ may be used. Recommended terms are Collection, StillImage, Sound, MovingImage, InteractiveResource, Text.
Comments:	A Collection should be given type http://purl.org/dc/dcmitype/Collection. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be marked as Text.
Crosswalk:	DublinCore: dcterms:type — XMP: — DarwinCore: — NCD: ncd:CollectionType — Morphbank: — NBII: Type — K2N: k2n:Type pro parte — MIX2.0:
Discussion	Do we mean to require the dcmi URL, or do we accept these dcmi Labels? --BobMorris 17:38, 14 March 2009 (CET) Now that DwC has been accepted as a TDWG standard, I have returned to a previous task, which was to try to hammer out a schema for the SERNEC plant image collection. This collection will integrate live plant images with images from specimens. Thus the schema will mostly be imported from the DwC schema (for specimen metadata) and the MRTG schema (for images) when it is done. Both schemas include the "dcterms:" namespace and accept dcterms:type as the element to identify the class into which the resource falls. However, the problem is that the recommended terms given under the DwC dcterms:type and the terms given here for dcterms:type are in conflict. Discussion Continues on MRTGv08 Type term inconsistent with DwC Steve Baskauf 05:34, 14 October 2009 (CEST)
Name:	Subtype
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:subtype
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Any of Drawing, Painting, Logo, Icon, Illustration, Graphic, Photograph, Animation, Film, SlideShow, DesignPlan, Diagram, Map, MusicalNotation, IdentificationKey, ScannedText, RecordedText, RecordedOrganism, TaxonPage, MultimediaLearningObject, VirtualRealityEnvironment, GlossaryPage. These values may either be used in their literal form, or with their full namespace (e.g. → Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:identificationKey ).
Comments:	This does not apply to Collection objects. The vocabulary may be extended by users provided they identify the term by a URI which is not in the mrtg namespace (for example, using "http://my.inst.org/namespace/metadata/subtype/repair-manual". Conforming applications may choose to ignore these.
Crosswalk:	DublinCore: dcterms:type — XMP: — DarwinCore: — NCD: Collection->collectionType — Morphbank: — NBII: Type Details — K2N: k2n:Type pro parte — MIX2.0:
Discussion	I don't follow the extension suggestion. Values of mrtg:Subtype are not given a URI. Is the suggestion that people can define, e.g. myURI:Subtype? Is this kind of extension permitted anywhere? Do we mean to specify a recommended semantics for it? --BobMorris 04:17, 22 March 2009 (CET) I think values of mrtg:Subtype are in the mrtg namespace. I added an example, does this make it clear? --BobMorris 23:28, 15 August 2009 (CEST) says: This seems difficult to model in OWL 1.0 and maybe in XML Schema. In OWL, supports enumerated data types via the use of owl:DataRange, albeit clumsily. However, reasoning on enumerations is limited and may not support the ability to reason on extensions, possibly unless we simply make the Subtype values be of type xsd:string: "Tools may vary in terms of support for datatype reasoning. As a minimum, tools must support datatype reasoning for the XML Schema datatypes xsd:string and xsd:integer. OWL Full tools must also support rdf:XMLLiteral. For unsupported datatypes, lexically identical literals should be considered equal, whereas lexically different literals would not be known to be either equal or unequal. Unrecognized datatypes should be treated in the same way as unsupported datatypes. OWL 1.0 DatatypeSupport Oh, wait. In order to make MRTG Type be identical to dc:type, the type names have to be the names of subclasses of MediaResource. Thus so should be these. Then the extension issue goes away in RDFS at least.
Name:	Title
Normative URI:	dcterms:title
	Layer: Core — Required: Yes — Repeatable: No
Definition:	Concise title, name, or label of institution, resource collection, or individual resource. This field should include the complete title with all the subtitles, if any.
Comments:	The title facilitates interactions with humans: e.g. the title would be used as display text of hyperlinks or to provide a choice of images through pick list. The title is therefore highly desirable and an effort should be made to provide it where not already available. The taxon name(s) will form a good substitute title.
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: dcterms:title — Morphbank: — NBII: Title for media resource, or Collection Title for a collection, for Provider or institution it matches the Name/Roles pair combination — K2N: k2n:Title — MIX2.0:
Discussion	I recommended adding a phrase, that the title should be descriptive of the resource when not an official label.AnnetteOlson 00:11, 4 February 2010 (CET)
Name:	Metadata Modified
Normative URI:	xmp:MetadataDate
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Point in time recording when the last change to metadata (not necessarily the media object itself) occurred. The date and time must comply with the World Wide Web Consortium (W3C) datetime practice, which requires that date and time representation correspond to ISO 8601:1998, but with year fields always comprising 4 digits. This makes datetime records compliant with 8601:2004. AC datetime values may also follow 8601:2004 for ranges by separating two IS0 8601 datetime fields by a solidus ("forward slash", '/'). See also the wikipedia IS0 8601 entry for further explanation and examples.
Comments:	Use case: a) for incremental harvesting: holder of metadata who also holds resource may be receiving metadata more frequently than underlying resources and can figure out whether updating the resource is necessary. This is not dcterms:modified, which is referring to the resource itself, but not its metadata.
Crosswalk:	DublinCore: dcterms:modified referring to a "metadata resource". — XMP: xmp:MetadataDate. IPTC Extension 1.0 also provides IPTC Metadata Last Edited = http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/IptcLastEdited - which, however, seem to be limited to modifications of IPTC fields alone. — DarwinCore: — NCD: dcterms:modified Collection->formationPeriod? — Morphbank: BaseObject.dateModified — NBII: Date Record Modified — K2N: k2n:Metadata_Modified — MIX2.0:
Discussion	W3C datetime types were based on IS0 8601 but these standards are not the same. For example, xs:date or dateTime used by XML Schemas do not allow date ranges like 2009-01-01/2009-12-01; see also notes to another term(s) of datetime type below. --AlexeyZinovjev 21:12, 11 December 2009 (CET)
Name:	Metadata Language
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:metadataLanguage
	Layer: Core — Required: Yes — Repeatable: No
Definition:	Language of description and other metadata (but not necessarily of the image itself) represented in ISO639-1 or -3.
Comments:	This is NOT dcterms:language , which is about the resource, not the metadata. This is deliberately single-valued, imposing a requirement that multi-lingual metadata be represented as separate, complete, metadata records in which also the language-neutral items appear. Consumers can re-combine records by identity of Resource IDs (which is highly recommended to supply).
Crosswalk:	DublinCore: dcterms:language referring to a "metadata resource". — XMP: — DarwinCore: — NCD: — Morphbank: "English" — NBII: Language of Cataloging — K2N: k2n:Metadata_Language — MIX2.0:
Name:	Provider Managed ID
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:providerManagedID
	Layer: Extended — Required: No — Repeatable: No
Definition:	A free-form identifier (a simple number, an alphanumeric code, a URL, etc.) that is unique and meaningful primarily for the data provider.
Comments:	Ideally, this would be a globally unique identifier (GUID), but the provider is encouraged to supply any form of identifier that simplifies communications on resources within the project and help to locate individual data items in the providers data repositories. It is the providers decision whether to expose this value or not.
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: ncd:collectionId — Morphbank: id — NBII: NA — K2N: k2n:Resource_ID — MIX2.0:
Discussion	, it should be together with Resource ID in management.--GregorHagedorn 08:48, 23 February 2009 (CET) used by providers for resources located locally, offline.
Name:	Rating
Normative URI:	xmp:Rating
	Layer: Core — Required: No — Repeatable: No
Definition:	A rating from 1 (worst) to 5 (best), where the metadata provider is able to provide resource ratings.
Comments:	The origin of the rating is left unknown, it may, e.g., be based on user feedback or on editorial ratings.
Crosswalk:	DublinCore: — XMP: xmp:Rating — DarwinCore: — NCD: — Morphbank: — NBII: NA — K2N: k2n:Rating — MIX2.0:
Discussion	If we have this field, should we not also have a field that provides a description of the rating system?AnnetteOlson 00:11, 4 February 2010 (CET)
Name:	Commenter
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:commenter
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	If present, then resource has comments. Provider is NOT asserting Commenter has expertise. Must display a name or the literal "anonymous" (= anonymously reviewed).
Comments:	Provider is asserting they accept these comments, but makes no claim as to competency of the Commenter.
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: NA — K2N: not available — MIX2.0:
Discussion	Should this be part of the extended set, not core? (From spreadsheet) Yes. Now it is. --BobMorris 20:54, 2 February 2010 (CET) There is a problem more general than associating a Commenter with their Comments if we allow repeatable Commenters. See Linking MRTG elements. --BobMorris 20:54, 2 February 2010 (CET) We have the Reviewer Comments below, and the definition states for Commenter that the provider is NOT asserting Commenter has expertise, so I changed the Comments section for this item to read "makes no claim as to competency," and I took out the word "review," so as not to confuse it with the Reviewer Comments belowAnnetteOlson 00:11, 4 February 2010 (CET)"
Name:	Comments
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:comments
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	Any comment provided on the subject featured in the media item.
Comments:	There is a separate item for reviewer comments, which is defined more as an expert-level review.
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: ncd:note — Morphbank: — NBII: Outside Comments — K2N: not available — MIX2.0:
Discussion	"Issue of linked fields again. (Should this be part of the extended set, not core?)" (From spreadsheet) there are 8 "comments" elements in DwC: SampleRemarks; SamplingEventRemarks; GeoreferenceRemarks; SamplingLocationRemarks; IdentificationRemarks; RelationshipRemarks; SampleAttributeRemarks; EventAttributeRemarks also in NCD Header: http://www.w3.org/2001/vcard-rdf/3.0#Note There is a problem more general than associating a Commenter with their Comments if we allow repeatable Commenters. Please see Linking MRTG elements. --BobMorris 20:54, 2 February 2010 (CET)
Name:	Reviewer
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:reviewer
	Layer: Extended — Required: No — Repeatable: No
Definition:	If present, then resource is peer-reviewed. The notation of whether an expert in the subject featured in the media has reviewed the media item (or collection?) and approved its metadata description. Must display a name or the literal "anonymous" (= anonymously reviewed).
Comments:	Provider is asserting they accept this review as competent.
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: Peer Reviewed (may change our item name to Reviewer) — K2N: k2n:Reviewer_Names — MIX2.0:
Discussion	Should this be part of the extended set, not core? (From spreadsheet) Bob will comment later on the issue of linking reviewer comments with reviewer name. Why do we have just "Commenter" above, but "Reviewer Name" here - do we need the name as part of this item's official name?AnnetteOlson 00:11, 4 February 2010 (CET)
Name:	Reviewer Comments
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:reviewerComments
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	Any comment provided by an expert in the subject featured in the media item.
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: PeerReviewerComments — K2N: k2n:Reviewer_Comments — MIX2.0:
Discussion	"Issue of linked fields again. (Should this be part of the extended set, not core?)" (From spreadsheet) Bob will comment later on the issue of linking reviewer comments with reviewer name.
Name:	Modified
Normative URI:	dcterms:modified
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	Date that the media resource was altered. The date and time must comply with the World Wide Web Consortium (W3C) datetime practice, which requires that date and time representation correspond to ISO 8601:1998, but with year fields always comprising 4 digits. This makes datetime records compliant with 8601:2004. AC datetime values may also follow 8601:2004 for ranges by separating two IS0 8601 datetime fields by a solidus ("forward slash", '/'). See also the wikipedia IS0 8601 entry for further explanation and examples.
Comments:	dcterms:modified permits all modification dates or if one, only assumed latest.
Crosswalk:	DublinCore: Same as dcterms:modified — XMP: xmp:ModifyDate — DarwinCore: — NCD: dcterms:modified — Morphbank: — NBII: Date Modified — K2N: k2n:Modified — MIX2.0: mix2:ChangeHistory/ImageProcessing/dateTimeProcessed
Discussion	DwC uses DublinCore term "Modified" I doubt that this can always comply to both standards at the same time -- W3C datetime (e.g., xs:date, xs:dateTime) and IS0 8601. For example, xs:date or dateTime used by XML Schemas do not allow date ranges like 2009-01-01/2009-12-01. At the same time, when looking at definition of dcterms:modified, I did not notice any restrictions to format in their schemas. This raises a question if using dcterms:modified with a claim that it should confirm to ISO is allowed, unless it's only a recommendation.--AlexeyZinovjev 21:12, 11 December 2009 (CET)
Name:	Date Available
Normative URI:	dcterms:available
	Layer: Extended — Required: No — Repeatable: No
Definition:	The date (often a range) that the resource became or will become available. The date and time must comply with the World Wide Web Consortium (W3C) datetime practice, which requires that date and time representation correspond to ISO 8601:1998, but with year fields always comprising 4 digits. This makes datetime records compliant with 8601:2004. AC datetime values may also follow 8601:2004 for ranges by separating two IS0 8601 datetime fields by a solidus ("forward slash", '/'). See also the wikipedia IS0 8601 entry for further explanation and examples.
Crosswalk:	DublinCore: same as dcterms:available — XMP: — DarwinCore: — NCD: — Morphbank: dateToPublish — NBII: Date Published — K2N: (not supported) — MIX2.0:
Discussion	Even following DublinCore I would not change this to "available". The risk of misunderstanding is very high. --GregorHagedorn 17:18, 22 February 2009 (CET) We are following W3C-DTF - http://www.w3c.org/TR/NOTE-datetime, which apparently includes date ranges.--AnnetteOlson 22:41, 6 March 2009 (CET) I find it ambiguous whether it includes ranges---probably it does. Anyay, I have added a template invoked by {{MRTGdatetime}} intended to be in every term requiring a datetime. It attempts to disambiguate the range issue by refering to ISO 8601:2004, which explicitly includes ranges. Discussion and improvement of the issue should take place in the Template:MRTGdatetime --BobMorris 17:35, 29 March 2009 (CEST) There is a semantic issue here: a resource may be available and later be made unavailable, but the metadata could usefully remain available, e.g. for occurrence evidence. As defined, that case is not covered. Is it important? --BobMorris 23:35, 13 March 2009 (CET) I agree with this field referring to the resource, not the metadata…, so for this should be good. I do not think it is important to note when metadata is available unless the metadata is copyrighted, which is very rare in our community. If someone seeks info on date available for metadata, we can add it to the next version?…AnnetteOlson 00:11, 4 February 2010 (CET).
Name:	Accrual Policy
Normative URI:	dcterms:accrualPolicy
	Layer: Extended — Required: No — Repeatable: No
Definition:	A policy governing addition of items to a collection. Examples are planned deliverables and estimate for future changes.
Comments:	Although an important management item, the relevance of this to consumers of metadata is limited to specific cases; e.g. where the Accrual Policy specifies that data are available only for a limited period.
Crosswalk:	DublinCore: dcterms:accrualPolicy — XMP: — DarwinCore: — NCD: ncd:developmentStatus ? — Morphbank: — NBII: AccrualPolicy — K2N: (not supported) — MIX2.0:

3 Attribution Vocabulary

Name:	Copyright Owner
Normative URI:	xmpRights:Owner
	Layer: Core — Required: Yes — Repeatable: No
Definition:	The name of the owner of the copyright. 'Unknown' is an acceptable value.
Comments:	ALA uses dcterms:publisher for this purpose, but it seems doubtful that the publisher is by necessity the copyright owner. Copyright owner cannot be repeated (only a single owner is possible).
Crosswalk:	DublinCore: dcterms:rights or dcterms:rightsHolder — XMP: xmpRights:Owner type bag ProperName, "An unordered array specifying the legal owner(s) of a resource". — Note: IPTC Extension 1.0: also has Copyright Owner, using plus:CopyrightOwner (Problem: Namespace for plus prefix is not given in the IPTC documents, and the plus = http://ns.useplus.org/ldf/vocab/ namespace does not contain a "CopyrightOwner" (but a CopyrightOwnerName, which may be appropriate here...) — DarwinCore: — NCD: — Morphbank: — NBII: contained within Rights Statement = — K2N: k2n:Copyright_Owner — MIX2.0:
Discussion	See MRTG Copyright Owner Discussion If the media item is in the public domain there will be no copyright owner. What is the appropriate value in that case given that this is a required element? In other words, how does one represent a null value? In XML, one could use an empty element tag. In a database an empty string? That seems bad. A value of "null"? Steve Baskauf 22:49, 14 March 2010 (CET)
Name:	Copyright Statement
Normative URI:	dcterms:rights
	Layer: Core — Required: Yes — Repeatable: No
Definition:	Information about rights held in and over the resource. A full-text, readable copyright statement, as required by the national legislation of the copyright holder. On collections, this applies to all contained objects, unless the object itself has a different statement. Examples: “Copyright XY 2008, all rights reserved”, “© 2008 XY Museum” , "Public Domain." Do not place just the name of the copyright holder here!
Comments:	This expressed rights over resource, not over the metadata text.
Crosswalk:	DublinCore: dcterms:rights — XMP: related boolean term: xmpRights:Marked type: Boolean, "Indicates that this is a rights-managed resource"; if this is false it indicates a resource in the public domain. — DarwinCore: — NCD: dcterms:rights — Morphbank: — NBII: Rights — K2N: k2n:Copyright_Statement — MIX2.0:
Discussion	Dublin core "rights" is potentially more general, but we follow the more specific use of IPTC CORE 1.1, i.e. focussing on copyright here. --GregorHagedorn 07:48, 4 May 2009 (CEST) One of the problems is multiple languages. Plain text, but make recommended guidelines for originating nation. Responsibility of metadata provider to get that right. IF this information is not available, a mechanism should be provided to state that this. (not that it is empty for other reasons)" (From spreadsheet) -- I can't really parse this comment so I don't know how opine what is needed in the proposed item. --BobMorris 18:58, 7 February 2009 (CET) For resources in the public domain, would a statement such as "public domain" be used to populate this element? There would be some value to having at least one element in the schema having a controlled vocabulary that would include "public domain" as a value so that users could search for copyright-free resources. Maybe a controlled vocabulary is excessive; rather one could simply state that this element should be give the value "public domain" if the resource is not subject to copyright. --Steve Baskauf 21:30, 28 April 2009 (CEST) I would agree with Steve - it is common practice to put public domain in this field if a resource is not copyrighted. NBII definitely puts in public domain here, and with us moving to GBIF and others a large number of federal, public domain resources, I think it is important to allow this. I would recommend revising the Definition above to indicate that option. I did go ahead and add it is an example AnnetteOlson 00:32, 4 February 2010 (CET)
Name:	License Statement
Normative URI:	xmpRights:UsageTerms
	Layer: Core — Required: No — Repeatable: No
Definition:	The license statement defining how resources may be used. Information on a collection applies to all contained objects unless the object has a different statement.
Comments:	Example: "Available under Creative Commons by-nc-sa 2.5 license".This also informs on the commercial availability of items. Buying an identification tool or media resource is essentially the purchase of an individual license. Examples for such License statements: “Available through bookstores” for a commercially published CD, in License; “Individual licenses available for purchase” for a high-resolution image (note that the medium or low resolution levels of the same image may be available under Creative Commons!)
Crosswalk:	DublinCore: dcterms:rights — XMP: — DarwinCore: — NCD: ncd:usageRestrictions — Morphbank: — NBII: License Statement — K2N: k2n:License Statement — MIX2.0:
Discussion	Gregor wants this mandatory with default value something like 'Consult copyright owner'. I find that superfluous and favor at most a best practice statement, or just remain silent on the point. Gregor argues that license is key to determining fitness for use, but I think that is true only when the use involves copy. Simply examining the object requires no license, nor, in some jurisdictions copying it for internal use without republishing. In addition, fitness for use of the underlying object is irrelevant to some uses of the metadata itself, e.g. as evidence of species occurrence, biological relationships, etc.--BobMorris 01:12, 30 March 2009 (CEST) For many purposes such as creating species pages or identification keys, a permission is required. Embedding an image or deep linking to a video or sound stored on a different server is still considered a copyright violation in many countries. Linking to a portal where the user can find the image or sound (Bob's scenario) is not a violation, but also not very acceptable to the user. — Key to Nature would welcome incentive or additional motivation to point publishers to consider their position on a license but this could also be in instructions. It is also unfortunate, but probably on purpose, that the xmp term (UsageTerms) will point most publishers into another direction than "License Statement" --GregorHagedorn 07:48, 4 May 2009 (CEST) This should not be mandatory, as it would not apply/is unnecessary for any public domain resources, which are the majority of ours media resources; we (NBII) do require it for copyrighted images but that is only because our policy is to serve only images under a Creative Commons license or similar defined usage; Other image galleries also have a history of recording Copyright info, but not License Statement, so requiring this field would need the creation of additional metadata. Finally, I would argue that linking to a portal where the user can find the image or sound is a very acceptable practice to many users, as it is the basis for users discovering our gallery, and thus permission to practice that does not need to be defined using License Statement. Strongly recommend this field, yes, require noAnnetteOlson 00:32, 4 February 2010 (CET)
Name:	License URL
Normative URI:	xmpRights:WebStatement
	Layer: Core — Required: No — Repeatable: No
Definition:	A URL defining or further elaborating on the license statement (e.g. a web page explaining the precise terms of use).
Comments:	The value of this field may provide a complete definition of the terms of use. For Creative Commons, the appropriate value is the URL of the defining Web page for the license. Example: http://creativecommons.org/licenses/by-nc-sa/3.0/us/
Crosswalk:	DublinCore: dcterms:rights — XMP: xmpRights:WebStatement type: URL, defined as "The location of a web page describing the owner and/or rights statement for this resource." — DarwinCore: — NCD: ncd:usageRestrictions — Morphbank: value is contained in Image.creativeCommons — NBII: License Statement — K2N: k2n:License_URL — MIX2.0:
Name:	License Logo URL
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:licenseLogoURL
	Layer: Core — Required: No — Repeatable: No
Definition:	A URL providing access to a logo that symbolizes the License.
Comments:	The legal responsibility for choosing a correct graphical representation must lie with the provider of metadata and can not be assumed by a service that offers are search or reporting user-interface. Example:
Crosswalk:	DublinCore: dcterms:rights — XMP: — DarwinCore: — NCD: — Morphbank: value is contained in Image.creativeCommons — NBII: NA (added service on top of license statement) — K2N: — MIX2.0:
Name:	Attribution Statement
Normative URI:	http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/CreditLine
	Layer: Core — Required: No — Repeatable: No
Definition:	free text for "please cite this as…"
Crosswalk:	Creative Commons with cc = http://creativecommons.org/ns# currently has the following properties: cc:attributionURL — "The URL to use when attributing this work" and cc:attributionName — "The creator's preferred name to use when attributing this work." — DublinCore: ? — XMP: — DarwinCore: — NCD: — Morphbank: info may be in Image.copyrightText — NBII: Credit line — K2N: k2n:Credit Line — MIX2.0:
Discussion	I find the citation to photo: no more compelling than the IPTC "Generic Specification" 'Credit Line, which could be given the IPTC namespace without having to introduce the "Photoshop Implementation" citation. --BobMorris 03:15, 30 March 2009 (CEST) . I have changed the URI by fiat --BobMorris 18:55, 29 January 2010 (CET)
Name:	Attribution Logo URL
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:attributionLogoURL
	Layer: Core — Required: No — Repeatable: No
Definition:	The URL of icon or logo image to appear in source attribution.
Comments:	Entering this URL into a browser should only result in the icon (not in a webpage including the icon).
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: User.userLogo — NBII: MODs name/role combination for Contributing Partner - added service on top of name — K2N: k2n:Attribution Link URL . K2N also has object logo, but defined as logo of resource (where a collection or institution is a resource. This does not apply here because of strict limitation to media. — MIX2.0:
Discussion	The item name "Object Logo URL" and definition seem to be in contradiction. Either it is a logo of the resource (e.g. a logo for an institution or movie, or an attribution logo (e.g., for an image the owners or providers logo). I therefore propose to change the item name to "Attribution Logo URL". --GregorHagedorn 11:30, 29 March 2009 (CEST)
Name:	Attribution Link URL
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:attributionLinkURL
	Layer: Core — Required: No — Repeatable: No
Definition:	The URL where information about ownership, attribution, etc. of the resource may be found.
Comments:	This URL may be used in creating a clickable logo. Providers should consider making this link as specific and useful to consumers as possible, e.g., linking to a metadata page of the specific image resource rather than to a generic page describing the owner or provider of a resource.
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: Resource identifier — K2N: k2n:Attribution Link URL — MIX2.0:
Discussion	The term "Object Link URL" should be renamed - the definition and comment imply that it is tied to attribution. The desire to link this to specific metadata may be expressed in comments. --GregorHagedorn 11:30, 29 March 2009 (CEST)
Name:	Published Source
Normative URI:	dcterms:source
	Layer: Core — Required: No — Repeatable: Yes
Definition:	An identifiable source from which the described resources was derived. It may be digital, but in any case should be a source for which the originator intended long-term availability.
Comments:	If image, key, etc. was taken from (i.e. digitized) or was also published in a digital or printed publication. Do not put generally "related" publications in here. This field normally contains a free-form text description; it may be a URI: (“digitally-published://ISBN=961-90008-7-0”) if this resource is also described separately in the data exchange. Can be repeatedable if a montage of images.
Crosswalk:	DublinCore: dcterms:source — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: Source — K2N: k2n:Published_Source — MIX2.0:
Discussion	think important for copyrighted works, but question of definition of "published." includes when Flickr and YouTube. But needs to be a stable, long-term preserved resource. Will not change and disappear. Libraries best practice document says "Use [Source] only when the described resource is the result of digitization of non-digital originals. Otherwise, use Relation." Possible use of Relation field is "IsAVersionOf" The IPTC Core Source field differs from what is considered DC source, which is "A related resource from which the described resource is derived." We use a similar definition - The related, non-digital resource from which the described resource is derived, but I think we all agreed that non-digital is not critical here, and should include both digital and printed publications. But I agree with point above that if digital needs to be a long-term stable resource, that is an official "publication, otherwise use Relation field." --AnnetteOlson 22:53, 6 March 2009 (CET) I think that it is a mistake to give the name "Published Source" to the Dublin Core element "Source". As noted above, DC element "Source" references the resource from which the focal resource (e.g. an image resource) is derived. In many (perhaps the majority) of cases of images in a biodiversity context, the image will be of a physical resource such as a museum specimen, an herbarium specimen, or an individual live organism in its environment. All of these resources can and should be assigned LSIDs which would be the appropriate resource to reference in this element. If the focal resource (e.g. an image) were at some point were published, the image as seen in the publication would be derived from the focal resource, not the other way round as it seems to be intended here. I think that this somewhat "backward" way of conceptualizing Source results from the assumption that many images included in databases that may use the MRTG schema will be gleaned from resources on the web. That may be true initially, but eventually many (if not most) images that will be valuable in a biodiversity context will be created by people who are imaging collections or photographing live organisms. The Source element needs to be understood in its correct DC context and instances where an image is found elsewhere as a part of another media resource should be noted using one of the other terms mentioned in this discussion. I understand that an image digitized from something like a journal article or key would in a philosophical sense be derived from the article or key itself, but if one contacted the author to obtain the image directly (a desirable outcome because the quality would be better than a scan) would you say that the image came from the article? I think most people would say that it was the other way round. --Steve Baskauf 05:57, 28 April 2009 (CEST) I think I am on Steve's side on some of this. I also have some concern that the commentary in the spec for dcterms:source suggest that it will ultimately change taking a class range and become more complex than we desire here. There is a further problem, in that the dc spec recommends as best practice the use of a URI. We seem to discourage that in our Comments, and also seem to impose the further requirement that if a URI is provided, it must identify something that is also described in the same metadata document. --BobMorris 06:55, 1 May 2009 (CEST) I don't think I agree with all of Steve's arguments, only his conclusion. In particular, whatever the outcome, it must not depend on there being only one object depicted in the medium, nor must it assume that it is an organism, nor that if part of an organism that the taxon is relevant. For example a single picture might have some twigs from several species in it to represent an illustration of "stipule". --BobMorris 06:55, 1 May 2009 (CEST) TO Do : The dcterms:source definition is at variance from our Comments here in several ways: It recommends that a formal identifier be used where possible. It is silent about free form It does not require that the source have "previously described in the data exchange" I have proposed a Definition. --BobMorris 16:47, 4 April 2009 (CEST) Steve's arguments are certainly worth considering. I wonder however, whether some sources, like publication and specimen, don't merit special, inheritable information. Essentially, if source IS a publication, resulting in image A and this has been modified by image processing to create image B, source of image B would only inform about image A, but no longer about the publication. Even worse, if the same thing happens with a specimen, tracing the fact that image B is an image of a specimen would require access to the metadata on the "source", i.e. image A. Essentially, splitting "published source" and "Associated Specimen Reference" from "Derived From" is meant to handle this: direct source in a chain of digital modification in "Derived From", ultimate sources in "Published Source" and "Associated Specimen Reference". However, Steve is certainly right in asking to consider the future, where little is "scanned" from publications. So if generalizing: Which source information should be inherited down a derivation chain and which not? --GregorHagedorn 00:17, 11 May 2009 (CEST) I think this is generically a problem of record provenance, but it is clouded by the case of images of specimens that are vouchers for some kind of scientific inferences which are meant to be supported by the specimen. Part of the problem may also arise from the controversial nature of "electronic vouchers", such as pictures. Some use cases of an image in a chain of modifications might require easy access to the ultimate (i.e. "original") image of the specimen. Others might require knowledge of the actual manipulations (e.g. by retrieving the elements of the derivation chain). To the extent that one may consider an original publication as a voucher for a scientific inference ("This paper is evidence that species A is different from species B"), I think that the problem is more general than Steve's remarks might lead one to conclude. Images are often the only voucher for observations. Even for traditional voucher specimens, I have heard it proposed that imaging live, or otherwise unprocessed specimens before preserving them should be adopted. Hence, it seems to me that this is not a problem that will go away in the future. Quite the contrary, it will become more important as the preponderance increases of scientific inferences being drawn from images of biota. OK, OK, I don't know where I stand on the issue for the schema. I just think we have to get it right. Does this need to be on a new page with summary and link here? --BobMorris 07:21, 11 May 2009 (CEST) There is an rdfs semantic issue having nothing to do with the above. It is that dcterms:source is defined to have "non-literal value" as defined by the DCMI Abstract Model. These are defined to be "physical, digital or conceptual" objects, whereas "literal" values are "A literal is an entity which uses a Unicode string as a lexical form, together with an optional language tag or datatype, to denote a resource (i.e. "literal" as defined by [RDF])." I cannot see what a non-literal value should be in RDF for dcterms:source, and if in RDFS this is a Class property, what class should be its range. --BobMorris 20:18, 7 September 2009 (CEST) I have returned to this issue again because of my need to consider the simultaneous databasing of media resources with physical resources. At SERNEC we want to have a database that contains records for physical individual organisms in the wild, physical preservedSpecimens, direct digital images of the individual organisms, and digital images of the specimens. Metadata for the latter three categories of resources can be placed as records in a single database using Darwin Core terms to describe the biodiversity aspects of all the resources and MRTG terms to describe the media aspects of the two categories of images. However, to keep this straight, we need to be able to have a field that indicates an identifier for the resource from which the subject resource was derived. For example, we need to say that a specimen was derived from a certain individual, a live plant image was derived from a certain individual, and that a specimen image was derived from a certain specimen. Under Dublin Core, the appropriate element to describe this relationship would seem to be dcterms:source "A related resource from which the described resource is derived." Arguments given above have supported and opposed the use of dcterms:source in this way for images. However, what occurs to me now is that if dcterms:source is specifically adopted by MRTG to mean a "Published Source" rather than source in a "derivation chain" sense as I would like to use it in our circumstances, it is setting up a conflict for users like me similar to what we just finished going through with dcterms:type. I really can't use dcterms:source to indicate that an individual in the wild was the source of a physical specimen if that term is then going to have a different interpretation for the images that also inhabit the same database (i.e. I can't say that the specimen was the dcterms:source of the digital image of the specimen because MRTG says that dcterms:source means a published source for the digital image). After looking at the DC terms again, it seems like there may be other DCMI terms that have meanings closer to "Published Source" than dcterms:source. For example, dcterms:isPartOf is defined as "A related resource in which the described resource is physically or logically included." That seems to me to be closer to the situation where an image was originally part of a digital or print publication than "from which the described resource is derived" (i.e. dcterms:source). dcterms:isPartOf suffers from the same problem as dcterms:source in that its DCMI definition also states that it should "be used with non-literal values". I may be misunderstanding this since I'm a novice, but it seems like the intention here is that both of these terms should be used with a unique identifier, ISBN, etc. rather than a literal. That could certainly be the case in the SERNEC situation where the value for dcterms:source would be the globally unique identifier for the specimen or individual, and in the use for a Published Source where the value of dcterms:isPartOf might be something like an ISBN. Anyway, my point is that the use of dcterms:source as it is described here could prevent someone from using dcterms:source in other circumstances where it is probably the most appropriate term to apply. Steve Baskauf 04:33, 28 October 2009 (CET)

4 Agents Vocabulary

Name:	Creator
Normative URI:	dcterms:creator
	Layer: Core — Required: No — Repeatable: Yes
Definition:	The person or organization responsible for creating the media resource
Comments:	* The value may be simple text or a nested object representing the details of a CI_ResponsibleParty Note that the Creator need not be the Copyright Owner
Crosswalk:	Derived from ISO NAP Metadata CI_ResponsibleParty — DublinCore: dcterms:creator — XMP: — DarwinCore: — NCD: — Morphbank: Image.photographer — NBII: MODS name/role Creator — K2N: k2n:Creators — MIX2.0:
Name:	Provider
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:provider
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Person or organization responsible for compiling and presenting the record. FIXME: DEFINITION OF PROVIDER AND METADATA PROVIDER IS IDENTICAL
Crosswalk:	Derived from ISO NAP Metadata CI_ResponsibleParty — DublinCore: dcterms:creator — XMP: — DarwinCore: — NCD: — Morphbank: Contributor (Image.userId) — NBII: Mods Name/Role Contributing Partner — K2N: k2n:Service Attribution URI — MIX2.0:
Discussion	For DwC, InstitutionCode is closest match NCD "Author of metadata" uses dcterms:creator Either this is the same as Metadata Provider or it isn't. If it is, let's dump it. The crosswalks confuse me.--BobMorris 05:49, 4 April 2009 (CEST)
Name:	Metadata Provider
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:metadataProvider
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Person or organization responsible for compiling and presenting the record. FIXME: DEFINITION OF PROVIDER AND METADATA PROVIDER IS IDENTICAL
Crosswalk:	Derived from ISO NAP Metadata CI_ResponsibleParty — DublinCore: dcterms:creator — XMP: — DarwinCore: — NCD: — Morphbank: morphbank.net — NBII: MODS name/role Metadata Contributor? — K2N: k2n:Metadata Creator ??? — MIX2.0:
Discussion	First, how does the definition of Metadata Provider differ from the item above - Provider? Currently the same. Provider is more the metadata plus the resource. Metadata provider is just the metadata provider, but I think it isn't that useful here. provider covers it. I agree in part with action note below about creator, though NBII only has Metadata Contributor, not Metadata Provider or Creator. Contributor is vague and can cover both provider who compiles metadata and a creator, multiple people can be Metadata contributors. However, we are going to set up a system where the metadata can be copyrighted also. we just haven't worked out the details.--AnnetteOlson 23:04, 6 March 2009 (CET) I agree, this is not useful. In K2N we have dropped the idea of "Provider" and use "Service Provider" and "Metadata Creator" (which usually will be an institution. I have further up annotated further up that Metadata Creator has no longer a place. Do we consider this not useful? --GregorHagedorn 11:45, 29 March 2009 (CEST) Action Note: when restructuring into an "Agent" schema in Copenhagen 2009, the metadata creator seems to have been dropped. This role is different from the Metdata Provider, which provides a service (e.g. database access) but does not necessarily claim a copyright on descriptions or abstracts. To our legal requirements, the role of a metadata creator is important. IIM, photoshop and XMP recognize an equivalent agent in the metadata item in IPTC CORE 1.1: Description Writer, using the term photoshop:CaptionWriter (modified --GregorHagedorn 09:42, 9 September 2009 (CEST)) Gregor - you keep forgetting to sign your name! --AnnetteOlson 23:04, 6 March 2009 (CET) (I apologize - you are right! --GregorHagedorn 09:42, 9 September 2009 (CEST)) NCD "Author of metadata" uses dcterms:creator

5 Content Coverage Vocabulary

Name:	Description
Normative URI:	dcterms:description
	Layer: Core — Required: No — Repeatable: No
Definition:	Description of collection or individual resource, containing the Who, What, When, Where and Why as free-form text.
Comments:	It optionally allows to present detailed information and will in most cases be shown together with the resource title. If both description and caption (see below) are present, a description is typically displayed instead of the resource. Should be a good proxy for the underlying media resource. Interpretation depends on type.
Crosswalk:	DublinCore: dcterms:description — XMP: — DarwinCore: — NCD: dcterms:description — Morphbank: description — NBII: Description — K2N: k2n:Description — MIX2.0:
Discussion	should the description have a relation has languages?
Name:	Caption
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:caption
	Layer: Extended — Required: No — Repeatable: No
Definition:	As alternative or in addition to description, a caption is free-form text to be displayed together with (rather than instead of) a resource that is suitable for captions (especially images).
Comments:	Often only one of description or caption is present; choose the concept most appropriate for your metadata.
Crosswalk:	DublinCore: dcterms:description — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: NA — K2N: k2n:Caption — MIX2.0:
Name:	Language
Normative URI:	dcterms:language
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Language(s) of resource itself represented in ISO639-1 or -3
Comments:	An image may contain language such as superimposed labels. If an image is of a natural scene or organism, without any language included, the resource is language-neutral (ISO code “zxx”). Resources with present but unknown language are to be coded as undetermined (ISO code “und”). Resources only containing scientific organism names should be coded as "zxx-x-taxon" (do not use the incorrect “la” for Latin). If there is no language code available, you must use the ISO extension mechanisms (x-XXX or XXXXXXX, CITE).
Crosswalk:	DublinCore: dcterms:language — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: language — K2N: k2n:Language — MIX2.0:
Discussion	A part match is ncd:descriptionForSpecialists which has attribute for language of the text

6 Geography Vocabulary

6.1 Introduction

Location created and Location shown are separated in the current version of IPTC, and the metadata working group (MWG 2008) also recommends this. We will follow this, to support the expected future increase of automatic GPS based coordinate recording in recording devices. As a special case, the MRTG group recommends to change the semantics of location shown in the case of biodiversity specimens, where the original location differs from the current location at which the specimen is collected. In this case, LocationShown should exclusively refer to the location where a specimen was originally collected (gathering or sampling location). Use LocationCreation to express the location where the media was created (a specimen was digitized).

• I implore you not to relegate decimal latitude and longitude to an extension. There is no more fundamental way to express a location on the surface of the earth and it is at least theoretically (if not already actually) possible to generate many of the other elements listed here from the latitude and longitude. Given that it is likely that in the near future most images will have this information automatically embedded, it will become very easy information to obtain and provide. Therefore MRTG should encourage users of the schema from the start to include latitude and longitude with all of their media resources as what is effectively a GUID for location. I think that having only verbatum latitude and longitude and putting them in an extension will prove to be a mistake in the long run.

Steve Baskauf 15:51, 15 September 2009 (CEST)

I completely agree with Steve and unless there is strong objection I intend to do the following:

• • add decimalCoordinates, decimalLatitude, decimalLongitude items
  • Write some guidance following the current DwC on the subject, especially calling attention to this sentence in the DwC verbatim georeferencing: "If possible, these coordinates should also be translated into the combination of decimalLatitude, decimalLongitude, geodeticDatum, and coordinateUncertaintyInMeters, but only if you really know what you are doing - coordinate transformations can be challenging"
  • possibly add the additional stuff DwC adds that lets you know whether the coordinates you list are known to be dependable.
  • Suggests that MRTG's recommendation is that applications may be skeptical about the authority and accuracy of coordinates if they do not follow the recommendations of DwC. I'm pretty sure that the importance of this is highly dependent on applications. For example, niche modelers or other users of GIS layers (should) already understand that even decimal coordinates without a known datum can have seriously misplaced position on the globe.
  • Possibly add the entirety of

The above tells me that we will have a serious documentation problem to serve both the needs of lightweight users like people using images from their cell phones and other consumer-grade location aware capture devices, and users whose need is for highly accurate occurrence location that has to be coordinated correctly with other GIS layers.

Here's an idea: We recommend, that, and provide support for, a user who wants the full expression of a DwC Location (or other DwC also serve a real DwC record and we give a service address for it.) This sounds like a big deal which might deserve a special page for discussion....

--BobMorris 23:18, 15 September 2009 (CEST)

• LocationShown only: MRTG desires to supports Bounding Box. dwc used the concept of a bounding box in earlier versions [1], but as of 2009-02 it seems to have been replaced by the item "dwc:FootprintWKT". MRTG supports dwc:FootprintWKT and FootprintSpatialFit.

A bounding box describes an approximation on the horizontal extent of the subject coverage represented by a rectangle-like shape. A reference of structuring the polygon data must be added.

• Iptc does not seem to have elevation, depth, or altitude. Any other geo-reference elements present in dwc may be used.

Location created is especially relevant where automatic GPS data are recorded in the media recording device.

TODO: There should be Coordinates in xmp??? Is this only under the EXIF to XMP mapping? In Exif's GPS Latitude / Longitude GPS data: Exif GPS (34853:[1-6], 0x8825:[1-6]). Details on GPS embedded in EXIF may be found in Table 12 "Exchangeable image file format for digital still cameras: Exif Version 2.2 (the most recent version as of 2009-02).

All geoelements are repeatable, because individual resources (like a movie or a combination of several images into a plate) may relate to subjects in different geolocations).

• NOT SURE whether this should apply to properties, or rather to the structures (Location Shown and Location Created) --GregorHagedorn 00:30, 2 March 2009 (CET)

• After reading this section I was left wondering to what kind of media this group thinks this schema will be applied? Since this group is affiliated with GBIF and TDWG, I was assuming the media would be primarily associated with documenting occurrences and after a web search have concluded that my assumption was correct. Then why are the locality-related elements in this section based primarily on IPTC (a press telecommunications organization) standards and not Darwin Core??? I will be the first to admit that there are problems with DwC, but the solution is to fix DwC, not to use a different system. There are a number of us at SERNEC who at this moment working to create a community image collection that integrates live-plant images and images of plant specimens and we plan to use this schema together with DwC to allow the live plant images to serve as occurrence records. If this schema adopts the IPTC locality elements, then people like us who are considering live plant images to document occurrences will be put in a position of choosing between: 1. including duplicate locality metadata under two systems (MRTG/IPTC and DwC), which would be confusing and silly, 2. ignoring the MRTG/IPTC locality elements entirely and just using DwC, which would put us at odds with other biodiversity image providers that are using the MRTG schema, or 3. ignoring DcW and using the MRTG/IPTC elements, which would make it impossible for us to have a unified system and difficult for our live plant images to feed into the stream of biodiversity metadata that feeds GBIF. Who are we trying to facilitate here, news photographers or the biodiversity community? I really think that the purpose of this schema should be to add metadata elements that are currently missing and which are needed to service media resources, but not to invent what is essentially a competing system with what is currently being used by the biodiversity community.

--Steve Baskauf 13:02, 29 April 2009 (CEST)

• • I don't follow Steve's point above. This is a superset of DwC geography, and all of it is optional. Anybody who has data with DwC geography tags can just hang them on a mrtg:MediaResource and can also ignore those outside DwC --BobMorris 20:33, 7 September 2009 (CEST)
  • Also, the MRTG committee rebelled against its original charge of only providing for MRTG to document species occurrence and went way further, including to cover identification tools, ecological images, and perhaps things at least as broad as media illustrating the SPMInfoItems types--BobMorris 20:33, 7 September 2009 (CEST)

• I feel like this has coalesced into something usable and without significant conflict with DwC (for those in the media community who want to use DwC). The basic universal identifier is: DecimalLatitude, DecimalLongitue (the coordinates), CoordinateUncertaintyInMeters (the uncertainty), and GeodeticDatum (the reference systeim). The basic hierarchic descriptors are: WorldRegion, CountryCode, ProvinceState, and Sublocation. I have one remaining question. I cannot find the controlled values for WorldRegion in the IPTC documentation. I'm hoping that this will be the two letter continent codes listed at http://en.wikipedia.org/wiki/List_of_countries_by_continent_(data_file) but I'm having trouble finding out what they are called officially. Darwin Core says to use the "ISO 3166 Continent code" in the "Continent" term, but I'm having trouble finding that on the web - mostly I find ISO 3166 COUNTRY codes. Anyway, assuming that these two letter codes are synonymous between IPTC WorldRegion and DwC Continent (for non-marine users), then at least for most users the first three levels are likely to be synonymous between the IPTC and DwC systems: Iptc4xmpExt:WorldRegion=dwc:Continent, Iptc4xmpExt:CountryCode=dwc:CountryCode, and Iptc4xmpExt:ProvinceState=dwc:StateProvince. To provide the remaining free-form description at the lowest level Iptc4xmpExt:Sublocation=dwc:Locality. Any other MRTG and DwC elements can be used at the provider's discretion. Am I getting this right?

Steve Baskauf 13:46, 31 October 2009 (CET)

Following should be OK:

---

The IPTC location detail structure contains the following properties (arranged hierarchically top-down) (Designers of representation, e.g. XML/Schema and MRTG/RDF are urged where possible to follow the http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/[2] hierarchy. Examples of instance markup should be provided by such designers.)

Name:	Location Shown
Normative URI:	http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/LocationShown
	Layer: Core — Required: No — Repeatable: Yes
Definition:	The location that is shown or the place of the media content, irrespective of the location from which the resource has been created.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: — K2N: (K2N is flat and does not support classes) — MIX2.0:
Discussion	The closest in NCD is "Place Name Coverage" ncd:geospatialCoverage I don't really understand with what this element and the following one will be poplulated?? Is it some kind of identifier? A value made by concatenating other terms? I have a somewhat philosophical problem with these two terms because I believe that in the circumstance where a physical object is digitized, there really should be two separate records with their own identifiers for the physical object and its digital representation. For example, if there is a 35 mm slide of a habitat which is then digitized, the location given in the 35 mm slide record should be the "location shown", and the location given in the digital image record should be the "location created". In this circumstance, there isn't really a need to have two different terms, rather one term "location" (i.e. the location where the thing was created) works for both. This is assuming that there is a machine-readable mechanism to indicate that the digital image was derived from the 35 mm slide so that the digital image consumer can discover the location shown through resolving the metadata from the 35 mm slide that from which the digital image was derived. Likewise, if an herbarium is imaging its specimens, the location in the specimen record would be the "location shown" and the location in the digital image record would be the "location created". Again a means would be required for connecting the record for the digital image to the record for the physical specimen in order for the location shown to be discovered. There is a similar problem with "Date and Time Digitized" and "Original Time and Date" about which I've already commented. These two issues are really the same and whatever the solution is to one of them is the solution to the other. I realize that many users will not care about this distinction and will just want to have a record for the digital object and use the two fields that you define. But what I'm still trying to figure out is how users such as the herbaria that are digitizing specimens will use these elements if they have two separate records (one for the image and one for the specimen). Steve Baskauf 13:46, 31 October 2009 (CET) There are scenarios where both LocationShown and LocationCreated are important, e.g. a remote sensing image. For most biodiversity media, the LocationShown is likely the more important if the metadata author feels that the LocationCreated is irrelevant and should not be provided. However, in no case should consumers of MRTG metadata assume any particular value for missing metadata. BobMorris 11:46, 1 February 2010 (CET)
Name:	World Region
Normative URI:	http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/WorldRegion
	Layer: Core — Required: No — Repeatable: Yes
Definition:	World region classification, such as continent, waterbody, island group, or island names, preferred from a controlled vocabulary (to be defined).
Comments:	We believe it is important to follow the XMP and IPTC standard set for media metadata and implemented in media management software. DarwinCore here forces primary metadata providers to classify world region terms into. This can, however, relatively easy be achieved by metadata aggregators (e.g. using biogeomancer-like services).
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:continent or dwc:waterbody or dwc:IslandGroup or dwc:island — NCD: — Morphbank: — NBII: Continent/Ocean — K2N: k2n:World Region — MIX2.0:
Name:	Country Code
Normative URI:	http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/CountryCode
	Layer: Core — Required: No — Repeatable: Yes
Definition:	The geographic location of the specific entity(ies) documented by the media item, expressed through a constrained vocabulary of countries using 2-letter ISO country code (e. g. "it, si").
Comments:	Accepted exceptions to be used instead of ISO codes are: "Global", "Marine", "Europe", “N-America”, “C-America”, “S-America”, "Africa", “Asia”, “Oceania”, ATA = "Antarctica", XEU = "European Union", XAR = "Arctic", "ZZZ" = "Unknown country" (3 letter abbreviations from IPTC codes). This list may be extended as necessary.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:countryCode — NCD: Collection->spatialCoverage? — Morphbank: — NBII: Country? — K2N: k2n:Country_Codes — MIX2.0:
Discussion	In the example given ("it, si") the two letter country codes are in lower case. I believe that they should be upper case (see: http://www.iso.org/iso/english_country_names_and_code_elements) Steve Baskauf 04:06, 12 March 2010 (CET)
Name:	Country Name
Normative URI:	http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/CountryName
	Layer: Core — Required: No — Repeatable: Yes
Definition:	This field can be free text, but where possible, the use of http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/CountryCode is preferred.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:country — NCD: — Morphbank: Locality.country — NBII: Country — K2N: k2n:Country_Names — MIX2.0:
Name:	Province or State
Normative URI:	http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/ProvinceState
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Optionally, the geographic unit immediately below the country level (individual states in federal countries, provinces, or other administrative units) in which the subjects (e. g., species, habitats, or events) were recorded by the media (if such information is available in separate fields).
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:stateProvince — NCD: Collection->spatialCoverage? — Morphbank: Locality.state — NBII: state or province — K2N: k2n:State_or_Province — MIX2.0:
Name:	County or Subprovince
Normative URI:	dwc:county
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	The Counties, subprovinces, or sub-administrative units in which the subjects were recorded by the media.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:county — NCD: Collection->spatialCoverage? — Morphbank: Locality.county — NBII: county or subprovince — K2N: k2n:County_or_Subprovince — MIX2.0:
Name:	City or Place Name
Normative URI:	http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/City
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	Optionally, the name of a city or place commonly found in gazetteers (such as a mountain or national park) in which the subject (e.g., species, habitats, or events) was recorded by the media.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: (no equivalent in DarwinCore seems to exist) — NCD: Collection->spatialCoverage? — Morphbank: — NBII: city or place name — K2N: k2n:City or Place Name — MIX2.0:
Discussion	DwC "Locality" is closest match
Name:	Sublocation
Normative URI:	http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/Sublocation
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Free-form text location details down to the village, forest, or geographic feature etc., especially information that could not be found in a gazetteer.
Comments:	We distinguish Locality in the sense of dwc (= a complete description of a locality, with the possible except of country names etc. separted in the dwc:HigherGeography, and Sublocation in the sense of IPTC/XMP, i.e. the remainder free-form text location within a fully hierarchically arranged grouping (earlier IPTC versions used “Location”, but this has been renamed as of 2008).
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: related to dwc:location, but dwc:location may be a complete location, while sublocation is the remainder in a hierarchy — NCD: — Morphbank: — NBII: Locality — K2N: (not supported, compare Location) — MIX2.0:
Discussion	dwc:Location? - no such term. I think dwc:Locality was meant. I don't think that the description in the comments of the sense of Locality in dwc (at least as it stands now) is accurate. DwC:locality is defined as "Less specific geographic information can be provided in other geographic terms (higherGeography, continent, country, stateProvince, county, municipality, waterBody, island, islandGroup)", not a complete description of all levels in the hierarchy. Maybe I'm just not understanding the comments, but I think that the current dwc:locality is the same as what we are defining here as sublocation. Steve Baskauf 13:53, 31 October 2009 (CET)

(End of hierarchically ordered properties of the location detail structure)

6.2 Secondary free-form text geography

Name:	Verbatim Higher Geography
Normative URI:	dwc:higherGeography
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	Optionally, as free-form text and a complement to Locality, any information from continent etc. down to country, i.e. everything that is less specific than the content of the Locality field.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:higherGeography — NCD: Collection->spatialCoverage? — Morphbank: — NBII: — K2N: not available yet — MIX2.0:
Discussion	Not sure if ncd:geospatialCoverage is right here: "Place names from which material in the collection originated".
Name:	Locality
Normative URI:	dwc:locality
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	Actual geolocation of observation as free-form text. This may be either complete, or be all information except those present in Higher Geography.
Comments:	This is place to put a free form text description.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:locality — NCD: Collection->spatialCoverage? — Morphbank: Locality.locality — NBII: Locality — K2N: k2n:Locality — MIX2.0:

6.3 Coordinates, elevation, etc.

Name:	Geo-coordinates
Normative URI:	dwc:verbatimCoordinates
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Latitude and longitude of geographic coordinates. Both decimal representation (use "." as decimal point) or degree-minute-second (use " for minutes and ' for seconds) may be used. End the latitude with N or S, or prefix the value with "+" for northward and "-" for southward. . End the longitude with the letters E or W, or prefix the value with "+" for eastward and "-" for westward. Use the comma (",") to separate latitude from longitude. If positive/negative values are being used instead of prefix letters, it is essential to place the latitude first; otherwise it is recommended. A geodetic datum (such as WGS84 used for GPS measurements) may optionally be added in parentheses at the end. Examples: "27°59'16?N, 86°56'40?E (WGS84)" or "+49.5000°,-123.5000°" (for decimal degrees and using positive/negative values).
Comments:	This may be derived from the GPS of camera, not location shown. Where the provider has the data separated, recommended best practice is to the separately provided Latitude and Longitude metadata items; this item is in support of metadata where the coordinates are not separated and the provider is unable to provide reliable separation.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:verbatimCoordinates — NCD: ncd:geospatialCoordinates — Morphbank: — NBII: Latitude, Longitude — K2N: k2n:Geocoordinates — MIX2.0: mix2:ImageCaptureMetadata/DigitalCameraCapture/CameraCaptureSettings/GPSData/gpsLatitude and gpsLongitude
Discussion	"Recommendation to adopt OGC if TDWG does - but may need to accept other formats (and convert). Mapping."" (From spreadsheet)
Name:	Latitude
Normative URI:	dwc:verbatimLatitude
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Latitude as separate value; compare Geo-coordinates for further information.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:verbatimLatitude — NCD: — Morphbank: Locality.latitude — NBII: Latitude — K2N: k2n:Geocoordinates pro parte — MIX2.0:
Discussion	It would seem to me that it would make more sense to have the term named "Latitude" refer to the DwC element "DecimalLatitude" rather than VerbatimLatitude. Both the verbatim latitude and longitude (perhaps pulled directly from EXIF data) can be examined by a human user if desired through examination of the Geo-coordinates (= DwC VerbatumCoordinates) item. If a provider is going to go to the trouble to parse out the individual latitudes and longitudes (which many will!), they will undoubtedly convert them to the most machine-readable format (DecimalLatitude and DecimalLongitude) which can then be used without further conversion in GIS or Web (e.g. Google Maps) applications. Those two elements (DecimalLatitude and DecimalLongitude) are not at present found in this schema. --Steve Baskauf 06:31, 28 April 2009 (CEST)
Name:	decimalLatitude
Normative URI:	dwc:decimalLatitude
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Latitude as separate value; Usage as defined at dwc:decimalLatitude.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:verbatimLatitude — NCD: — Morphbank: Locality.latitude — NBII: Latitude — K2N: — MIX2.0:
Discussion	It would seem to me that it would make more sense to have the term named "Latitude" refer to the DwC element "DecimalLatitude" rather than VerbatimLatitude. Both the verbatim latitude and longitude (perhaps pulled directly from EXIF data) can be examined by a human user if desired through examination of the Geo-coordinates (= DwC VerbatumCoordinates) item. If a provider is going to go to the trouble to parse out the individual latitudes and longitudes (which many will!), they will undoubtedly convert them to the most machine-readable format (DecimalLatitude and DecimalLongitude) which can then be used without further conversion in GIS or Web (e.g. Google Maps) applications. Those two elements (DecimalLatitude and DecimalLongitude) are not at present found in this schema. --Steve Baskauf 06:31, 28 April 2009 (CEST)
Name:	Longitude
Normative URI:	dwc:verbatimLongitude
	Layer: Core — Required: No — Repeatable: No
Definition:	Longitude as separate value; compare Geo-coordinates for further information.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:verbatimLongitude — NCD: — Morphbank: Locality.longitude — NBII: Longitude — K2N: k2n:Geocoordinates pro parte — MIX2.0:
Discussion	Again, I would suggest that DecimalLongitude would be far more valuable here than VerbatimLongitude for the same reasons I gave above. --Steve Baskauf 06:31, 28 April 2009 (CEST)
Name:	decimalLongitude
Normative URI:	dwc:decimalLongitude
	Layer: Core — Required: No — Repeatable: No
Definition:	Longitude as separate value; compare Geo-coordinates for further information.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:decimalLongitude — NCD: — Morphbank: Locality.longitude — NBII: Longitude — K2N: k2n:Geocoordinates pro parte — MIX2.0:
Discussion	Again, I would suggest that DecimalLongitude would be far more valuable here than VerbatimLongitude for the same reasons I gave above. --Steve Baskauf 06:31, 28 April 2009 (CEST) Needs crosswalks re-examined to see whether the other system's usage is decimal or verbatim
Name:	Coordinate Precision
Normative URI:	dwc:coordinatePrecision
	Layer: Extended — Required: No — Repeatable: No
Definition:	An estimate of how precisely the locality was recorded, expressed as a distance, in meters, that corresponds to a radius around the lat-long coordinates.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:coordinatePrecision — NCD: — Morphbank: Locality.coordinatePrecision — NBII: Coordinate Precision — K2N: (not supported) — MIX2.0:
Discussion	Not sure, perhaps over-atomized? Description needs explanation how circular versus rectangular precision (the latter occurs if longitude/latitude have separate precision estimates) is to be expressed, and how to express the measurement unit. --GregorHagedorn 07:59, 23 February 2009 (CET) I do not think that this is a correct representation of CoordinatePrecision, at least in the most recent DwC schema. What is described in the definition here is actually CoordinateUncertaintyInMeters. CoordinatePrecision is "A decimal representation of the precision of the coordinates given in the DecimalLatitude and DecimalLongitude" which I think is actually a more useful element than CoordinateUncertaintyInMeters, at least if we are planning for a future when most data will be collected by GPS enabled cameras. For most current GPS receivers, the value for CoordinatePrecision would be 0.00001 (decimal degrees) which could be automatically assigned by the provider given the source of the data (i.e. GPS). In cases where data providers are limiting public access to precise locality data by reducing the precision of the coordinates that are provided (see DwC Generalizations), they are most likely to do so by lopping off digits from their raw coordinates. Under that circumstance, providing a value for CoordinatePrecision would be much more straightforward than providing a value for CoordinateUncertaintyInMeters. Providers who are crunching "old" data (e.g. from museum specimen data) are going to have to do some kind of calculation or conversion anyway and they can just as easily give their precision in decimal degrees as meters. --Steve Baskauf 06:31, 28 April 2009 (CEST) I agree. Need to update definition to follow DwC. --GregorHagedorn 00:17, 11 May 2009 (CEST)
Name:	Coordinate system
Normative URI:	dwc:verbatimCoordinateSystem
	Layer: Extended — Required: No — Repeatable: No
Definition:	The official name of the spatial coordinate system used for recording the coordinates (Latitude, Longitude or Geo-coordinates) of the place shown in the media.
Comments:	Recommended best practice is to use a controlled vocabulary.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:verbatimCoordinateSystem — NCD: — Morphbank: — NBII: Coordinate Authority — K2N: (not supported) — MIX2.0:
Discussion	I would make this an enumeration. --BobMorris 18:34, 8 February 2009 (CET) I believe introducing this is over-atomized, making it too difficult for normal providers to participate. --GregorHagedorn 07:59, 23 February 2009 (CET) There are many different styles of coordinates, this information commonly is selected in gazeteers. And it is optional of course.--AnnetteOlson 23:17, 6 March 2009 (CET)
Name:	Depth
Normative URI:	dwc:verbatimDepth
	Layer: Extended — Required: No — Repeatable: No
Definition:	The depth or range of depth at which the media was recorded. Quantitative expressions including measurement units are preferred.
Crosswalk:	Related terms in dwc are MinimumDepthInMeters and MaximumDepthInMeters — DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:verbatimDepth — NCD: — Morphbank: Locality.minimumDepth, Locality.maximumDepth — NBII: Depth — K2N: k2n:Depth — MIX2.0:
Discussion	"This field combined with depth could be altitude instead (positive elevation, negative depth ) " (From spreadsheet) This may be correct for altitude/height, but not elevation. Elevation is correct for geolocation, altitude for observer or subject position. However, it seems at the moment there is no altitude or height above local surface (e.g. for shots from a tower) present in MRTG --GregorHagedorn 15:20, 18 June 2009 (CEST)
Name:	Elevation
Normative URI:	dwc:verbatimElevation
	Layer: Extended — Required: No — Repeatable: No
Definition:	The specific elevation or range of elevation at which the media was recorded, including units (elevation is defined as zero being mean sea level). This is the position of camera - any additional elevation of the subject itself should be put in description.
Crosswalk:	Related terms in dwc are MinimumElevationInMeters and MaximumElevationInMeters — DublinCore: dcterms:coverage — XMP: — DarwinCore: dwc:verbatimElevation — NCD: Collection->temporalCoverage? — Morphbank: Locality.minimumElevation, Locality.maximumElevation — NBII: Elevation — K2N: k2n:Elevation — MIX2.0:
Discussion	Semantics of Elevation versus Altitude: According to definitions of elevation versus altitude in Wikipedia, elevation is correct for geolocation, altitude for observer or subject position. --GregorHagedorn 07:59, 23 February 2009 (CET) I believe some field should record the elevation of the geolocation, another the camera altitude. It may be that this is not currently captured, since a geolocation elevation may be missing. -- Proposed description of geolocation-elevation: "Elevation (height of ground level above mean sea level) of observation position. For human-held digital cameras (recording GPS-based height) it is permissible to use the position of the camera instead. A geodetic reference datum may be added in parentheses." --GregorHagedorn 07:59, 23 February 2009 (CET) I'm unhappy about including units. Would require parsing for machine use. Better to have everything that needs units have a units property.--BobMorris 20:30, 8 February 2009 (CET) I think computers should work where they easily can, so I prefer to keep it simple and allow various expressions of elevation, including textual ones. --GregorHagedorn 14:08, 22 February 2009 (CET)

7 Temporal Coverage Vocabulary

Name:	Temporal Coverage
Normative URI:	ncd:temporalCoverage
	Layer: Extended — Required: No — Repeatable: No
Definition:	The extent or scope of the content of the resource. Coverage will typically include temporal period (a period label, date, or date range). If dates are mentioned, they should follow ISO 8601
Comments:	Examples in English: "Jurassic", "Elizabethan", "Spring, 1957". 2008-01-01/2008-06-30
Crosswalk:	DublinCore: dcterms:date or dcterms:coverage  ? — XMP: — DarwinCore: dwc:earliestDateCollected and dwc:latestestDateCollected — NCD: ncd:temporalCoverage — Morphbank: — NBII: Temporal Coverage — K2N: not available yet — MIX2.0:
Discussion	Any reason not to just adopt NCD URI here? Do we risk raising the question of whether this applies only to collections? (It doesn't). Alternative is mrt namespace. --BobMorris 06:40, 4 April 2009 (CEST)
Name:	Original Date and Time
Normative URI:	xmp:CreateDate
	Layer: Core — Required: No — Repeatable: No
Definition:	The date of the creation for the original resource from which the digital object was derived or created. The date and time must comply with the World Wide Web Consortium (W3C) datetime practice, which requires that date and time representation correspond to ISO 8601:1998, but with year fields always comprising 4 digits. This makes datetime records compliant with 8601:2004. AC datetime values may also follow 8601:2004 for ranges by separating two IS0 8601 datetime fields by a solidus ("forward slash", '/'). See also the wikipedia IS0 8601 entry for further explanation and examples.
Comments:	What is what constitutes "original" is determined by the metadata author. Example: Digitization of a photographic slide of a map would normally give the date at which the map was created; however an photographic work of art including the same map as its content, may give the data of the original photographic exposure. Imprecise or unknown dates can be represented as ISO dates or ranges. Compare also Date and Time Digitized. Is this redundant? BobMorris 18:31, 1 February 2009 (CEST)
Crosswalk:	DublinCore: dcterms:date — XMP: — DarwinCore: — NCD: Collection->temporalCoverage? — Morphbank: — NBII: Date Original — K2N: k2n:Original_Creation_Date — MIX2.0:
Name:	Time of Day
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:timeOfDay
	Layer: Core — Required: No — Repeatable: No
Definition:	Free text information beyond exact clock times.
Comments:	Examples in English: afternoon, twilight.
Crosswalk:	DublinCore: dcterms:date — XMP: — DarwinCore: dwc:startTimeOfday and dwc:endTimeOfDay — NCD: — Morphbank: — NBII: Time of Day — K2N: (not available) — MIX2.0:
Discussion	Should perhaps be rename "Verbatim Time of Day"? --GregorHagedorn 00:30, 2 March 2009 (CET) Note that DwC is not free text - "expressed as decimal hours from midnight, local time".

8 Subject of Resource Vocabulary

Name:	Physical Setting
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:physicalSetting
	Layer: Content-Coverage-Extended — Required: No — Repeatable: yes
Definition:	The Setting of the content represented in a medium like images, sounds, movies. Constrained vocabulary of: "Natural" = Unmodified object in a natural setting of unmodified object (e. g. living organisms in their natural environment); "Artificial" = Unmodified object in artificial setting of (e. g. living organisms in artificial environment: Zoo, Garden, Greenhouse, Laboratory; photographic background or background sound suppression). "Irrelevant" (e.g. background of Museum shots).
Comments:	Multiple values may be needed for movies.
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: Nature of Content (in part) — K2N: — MIX2.0:
Discussion	So we provide only an English controlled vocabulary here? I think anything else is too cumbersome. --BobMorris 06:40, 4 April 2009 (CEST)
Name:	Subject Category
Normative URI:	http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/CVterm
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Controlled vocabulary of subjects that help provide search capabilities. Terms from various controlled vocabularies may be used. MRTG-recommended vocabularies are preferred and may be unqualified literals (without a URI). For terms from other vocabularies either a precise URI should be used, or, when providing unqualified terms, to provide the source vocabulary in Subject Category Vocabulary.
Comments:	Recommended sets include: (PROVIDE REFS) Nasa GCMD, K2N BioComplexityThesaurus, GEMET, Can include major groups such as vertebrates, fungi; ecosystem terms?? apparatus terms?? such as…, aquatic vertebrates, forest fires. In the case where the unqualified terms from different vocabularies are homographs, the MRTG recommendation provides and order of preference for assigning terms to specific vocabularies. This includes other formal classifications (published in print or online) such as habitat, fuel, invasive species, agroproductivity, fisheries, migratory species etc
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: — NCD: Collection->taxonCoverage? — Morphbank: — NBII: Controlled subject; Formal Classification — K2N: k2n:Subject Category — MIX2.0:
Discussion	Comment on mapping this to http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/CVterm "Maybe. But we tend to do the same thing in the places where we need to, so I am not sure why we would do this. Again, for it to have any utility, a query agent would need to always search it, no matter what its specific desires." Bob Morris, 2009-03-02 Major TODO: finalize Comments with specific recommendations. --BobMorris 06:40, 4 April 2009 (CEST) Typo in comments: I think "an order" is intended rather than "and order". I actually do not understand that sentence. By what mechanism does MRTG provide an order of preference? Also, references are not here yet and need to be before this can be adopted as a standard. Steve Baskauf 22:56, 14 March 2010 (CET)
Name:	Subject Category Vocabulary
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:subjectCategoryVocabulary
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	Any vocabulary or formal classification from which additional terms in Subject Category have been drawn.
Comments:	The MRTG recommended vocabularies do not need to be cited here. There is no linkage between individual Subject Category terms and the vocabulary; the mechanism is intended to support discovery of the normative URI for a term, but not guarantee it.
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: Formal Classification Source (plus the BioComplexity Thesaurus) — K2N: not available — MIX2.0:
Discussion	File:Warning.gif Oops, now "Vocabulary" has a confusing sense. Suggestions? How about making the other be MRTG Something Vocabulary and leave this as is --BobMorris 06:58, 23 March 2009 (CET)
Name:	Tag
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:tag
	Layer: Core — Required: No — Repeatable: Yes
Definition:	General keywords or tags.
Comments:	Tags may be multi-worded phrases. Where scientific names, common names, geographic locations, etc. are separable, these should go into the more specific metadata items provided further below. Examples: "flower diagram". Character or part keywords like "leaf", "flower color" are especially desirable.
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: — NCD: — Morphbank: View.specimenPart — NBII: Uncontrolled Subject — K2N: k2n:General Keywords — MIX2.0:

9 Taxonomic Coverage Vocabulary

Name:	Taxonomic Coverage
Normative URI:	ncd:taxonCoverage
	Layer: Core — Required: No — Repeatable: No
Definition:	A higher taxon (e.g. a genus, family, or order) at the level of the family or higher, that covers all taxa that are subject of the resource.
Comments:	Example: “Aves” for a bird key or a bird image collection. Do not add a rank (“Class Aves”) in this field. If the resource contains a single taxon, this should be placed only in Scientific Name, leaving Lowest Common Taxon empty. Where the subject of an image are several species of ducks with trees visible in the background, Taxonomic Coverage would still be Anatidae (and not Biota).
Crosswalk:	DublinCore: dcterms:subject (not coverage!) — XMP: — DarwinCore: — NCD: ncd:taxonCoverage — Morphbank: Specimen.scientificName — NBII: NA — K2N: k2n:Taxonomic Coverage — MIX2.0:
Discussion	for DwC, "HigherTaxon" is closest but is "A list (concatenated and separated) of the names for the taxonomic ranks less specific than the ScientificName." also for NCD ncd:kingdomCoverage I propose adopting ncd URI --BobMorris 06:40, 4 April 2009 (CEST) For an RDF representation of MRTG, there is a problem here and in a few other places where the Item URI comes from an RDF ontology. It is this: ncd:taxonCoverage is an object property, but the commentary seems to suggest here that we mean a datatype property, e.g. a string. --BobMorris 00:02, 11 October 2009 (CEST)
Name:	Scientific Name
Normative URI:	dwc:scientificName
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Scientific taxon names of organisms represented in the media resource (with date and authorship information if available) of the lowest level taxonomic rank that can be applied.
Comments:	The Scientific Name may possibly be a Genus or Family name, if this is the most specific identification available. Where multiple taxa are the subject, multiple names may be given. If possible, add this information here even if the title or caption of the resource already contains scientific names. Where the list of scientific names is impractically large (e. g., media collections or identification tools), the number of taxa should be given in Taxon Count (see below). If possible, please do not repeat the Taxonomic Coverage here. Do not use abbreviated Genus names ("P. vulgaris"). It is recommended to provide author citation to scientific names, to avoid ambiguities in the presence of homonyms (the same name created by different authors for different taxa). Identifier qualifications should be supplied in the Identification Qualifier (DO WE HAVE THIS???) term rather than here.
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: dwc:scientificName — NCD: Collection->taxonCoverage? — Morphbank: Specimen.scientificName — NBII: Scientific Name — K2N: k2n:Scientific Names — MIX2.0:
Name:	Common Name
Normative URI:	dwc:vernacularName
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Common (= vernacular) names of the subject in one or several languages. The ISO language name should be given in parentheses after the name if not all names are in Metadata Language.
Comments:	Applicable only if the resource relates to a single taxon. The ISO language codes after the name should be formatted as in the following example: 'abete bianco (it); Tanne (de); White Fir (en)'. If names are known to be male- or female-specific, this may be specified as in: 'ewe (en-female); ram (en-male);'.
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: — NCD: ncd:commonNameCoverage — Morphbank: — NBII: Common Name — K2N: k2n:Common Names — MIX2.0:
Name:	Taxon According To
Normative URI:	dwc:taxonAccordingTo
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	The taxonomic authority used to apply the name to the taxon, e. g., a book or web service from which the name comes from.
Comments:	Examples are "ITIS", "Catalogue of Life", "Peterson's guide for birds".
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: dwc:taxonAccordingTo — NCD: — Morphbank: Tree.nameSource — NBII: Scientific Name Source — K2N: not supported — MIX2.0:
Discussion	"This field needs to be defined more, and intent decided on, but could be important." (From spreadsheet) "this is a Darwin Core question; can refers to one of the authoritiative GSD, such as IT IS. Question comes up here of matching names and sources, and the capabilities of coding that." (From spreadsheet) taxonAccordingTo is not in the final DwC. We probably mean either dwc:nameAccordingTo or dwc:nameAccordingToID. In email, Tim Robertson suggests looking at the thread in the the DwC mail discussion about name attribution --BobMorris 14:15, 1 March 2010 (CET).
Name:	Scientific Name GUID
Normative URI:	dwc:taxonID
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	Equivalent to Scientific Name, but using GUIDs such to refer to the taxon names or concepts.
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: dwc:taxonID — NCD: — Morphbank: Tree.tsn — NBII: TSN — K2N: not supported — MIX2.0:
Name:	Scientific Name Synonym
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:scientificNameSynonym
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	One or several scientific names that are synonyms to the Scientific Name may be provided here.
Comments:	The primary purpose of this is in support of resource discovery, not developing a taxonomic synonymy. Misidentification or misspellings may thus be of interest. Where multiple taxa are present in a resource and multiple Scientific Names are given, the association between synonym and name is not discoverable.
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: (implemented through record relations and TaxonomicStatus) — NCD: — Morphbank: — NBII: NA — K2N: k2n:Scientific Name Synonyms — MIX2.0:
Name:	Identified By
Normative URI:	dwc:identifiedBy
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	The name(s) of the person(s) who applied the Scientific Name to the sample.
Crosswalk:	DublinCore: — XMP: — DarwinCore: dwc:identifiedBy — NCD: — Morphbank: Specimen.name — NBII: NA — K2N: k2n:Identified By — MIX2.0:
Name:	Date Identified
Normative URI:	dwc:dateIdentified
	Layer: Extended — Required: No — Repeatable: No
Definition:	The date on which the person(s) given under Identfied By applied a Scientific Name to the resource.
Comments:	What happens if there is more than 1 taxon on the media resource? --BobMorris 18:50,30 February 2010 (CEST)
Crosswalk:	DublinCore: — XMP: — DarwinCore: dwc:dateIdentified — NCD: — Morphbank: Specimen.dateIdentified — NBII: NA — K2N: not available — MIX2.0:
Name:	Taxon Count
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:taxonCount
	Layer: Core — Required: No — Repeatable: Yes
Definition:	An exact or estimated number of taxa represented by the media resource.
Comments:	It is recommended to give an exact or estimated number of specific taxa in any case, even were a complete list of taxa is not available or practical. Please try to give this information even where not required. The count should best contain only the taxa covered fully or primarily by the resource. For a taxon page and most images this will be “1”, i. e. other taxa mentioned or in the background should not be counted. However, sometimes a resource may illustrate an ecological or behavioral entity with multiple species, e. g. a host-pathogen interaction. This should be a single integer number. Leave the field empty if you cannot estimate the information (do not enter 0).. Has to be featured in the media. A single number in this item is assumed to be a count of taxa at the lowest applicable taxon rank. Where it is desired to specify counts of genera, families, etc., additional taxon counts may be added which in parentheses provide the rank (in the metadata language) at which the count was taken. Example: "12 (family)". Although of special interest for collections, this is also highly relevant to singular resources addressing many taxa (such as identification tools).
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: NA — K2N: k2n:Taxon Count — MIX2.0:
Name:	Subject Part
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:subjectPart
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	The portion of the organism, environment, etc. shown or particularly well illustrated.
Comments:	No formal encoding scheme as yet exists. Examples are "whole body", "head", "flower", "leaf", "canopy" (of a rain forest stand). See comment in discussion below about a nascent encoding scheme.--Steve Baskauf 16:42, 30 April 2009 (CEST)
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: — NCD: — Morphbank: View.specimenPart — NBII: Part of Subject — K2N: k2n:Subject Part — MIX2.0:
Discussion	I would suggest the use of standardized views (Vulpia 7:16-30) as a way to deal with this element and the following three elements. A standardized view represents an orientation of a particular organism part that has been found to present useful taxonomic characters or recognizable features for identification. I have found through experience that there are a limited number of such views for a particular group of organisms and have defined sets of standardized views for woody angiospermsherbaceous angiosperms and Gymnosperms as collections in Morphbank. If standardized views became a part of this schema, one element would probably be required to specify the view set and another element would be required to specify the view within the set. It would also be necessary to figure out how to formally define the views, establish controlled vocabulary, and to define view sets for other groups of organisms based on the knowledge of photographers with experience in that group. The advantage of this system is that the view sets would be contain views that were relevant to that group - it is difficult to create generic views applicable to all organisms because of morphological differences among groups and because on a large taxonomic scale organisms don't even have the same features. Having a way to specify a particular useful view (such as a frontal view of a flower) makes it much easier for users to search for the specific type of image they want. Although I don't have experience with defining view sets beyond plants, this concept could theoretically be extended to other non-organismal subject of biological interest, such as ecoregions, habitats, etc. --Steve Baskauf 13:06, 30 April 2009 (CEST)
Name:	Subject Sex
Normative URI:	dwc:sex
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	A description of the sex of any organisms featured within the media, when relevant to the subject of the media, e.g., male, female, hermaphrodite, dioecious.
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: dwc:Sex — NCD: — Morphbank: Specimen.sex, View.sex — NBII: Sex — K2N: k2n:Subject Sex — MIX2.0:
Discussion	Although this element is generally useful for animals, it is problematic or even irrelevant for most plants. In most cases, sex is a property of a plant part, not the organism itself. For many plant features (e.g. bark, leaves, buds) sex is irrelevant or undeterminable. In a plant context, including sex in the definition of a view (see above) of floral parts or cones makes more sense. A given individual plant may have an image of a male cone, a female cone, and bark where sex is irrelevant. --Steve Baskauf 16:42, 30 April 2009 (CEST)
Name:	Subject Life Stage
Normative URI:	dwc:lifeStage
	Layer: Extended — Required: No — Repeatable: Yes
Definition:	A description of the life-cycle stage of any organisms featured within the media, when relevant to the subject of the media, e.g., larvae, juvenile, adult.
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: dwc:lifeStage — NCD: — Morphbank: Specimen.developmentalStage, View.developmentalStage — NBII: Stage — K2N: k2n:Subject Life Stage — MIX2.0:
Discussion	In a similar vein to my comment on sex, this element has very limited use for many plants. For example, most long-lived trees cycle annually through an "immature" (from a meristematic point of view) stage - budburst, to sexual maturity (anthesis), to fruit development. Thus "life stage" is really more relevant to a plant part than the plant as a whole, except in the case of a seedling where unquestionably the entire plant is immature. Again, the concept of a view can handle this by referencing life stage for individual parts or the whole organism (e.g. floral development) when relevant and leaving it out when it is not (e.g. for leaf images). --Steve Baskauf 16:42, 30 April 2009 (CEST)
Name:	Subject Orientation
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:subjectOrientation
	Layer: Extended — Required: No — Repeatable: No
Definition:	Specific orientiation (= direction, view angle) of the subject represented in the media resource with respect to the acquisition device.
Comments:	Examples: "dorsal", "ventral", "frontal", etc. No formal encoding scheme as yet exists.
Crosswalk:	DublinCore: dcterms:subject — XMP: — DarwinCore: — NCD: — Morphbank: View.viewAngle — NBII: View of Subject — K2N: k2n:Subject Orientation — MIX2.0: mix2:ImageCaptureMedadata/orientation
Discussion	Again, included in the view concept when relevant. --Steve Baskauf 16:42, 30 April 2009 (CEST)
Name:	Subject Preparation Technique
Normative URI:	dwc:preparations
	Layer: Extended — Required: No — Repeatable: No
Definition:	Free form text describing the techniques used to prepare the subject prior or while creating the media resource.
Comments:	Examples for such techniques are: Insect under CO2, cooled to immobility, preservation with ethanol or formaldehyde. See also Resource Creation Technique for technical aspects of digital media object creation.
Crosswalk:	DWC= dwc:preparations — DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: View.imagingPreparationTechnique and maybe Specimen.preparationTechnique — NBII: Comments on Collection; Capture Details — K2N: k2n:Creation Technique — MIX2.0:
Discussion	related NCD element: ncd:specimenPreservationMethod

10 Technical Metadata Vocabulary

Name:	Location Created
Normative URI:	http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/LocationCreated
	Layer: Core — Required: No — Repeatable: Yes
Definition:	The location at which the media recording instrument was placed when the media was created.
Comments:	The distinction between location shown and created is often irrelevant, and metadata may be assumed to be referring to location shown. However, in the case of position data automatically recorded by the instrument (e.g. EXIF GPS data) LocationCreated should be used to maintain information accuracy.
Crosswalk:	DublinCore: dcterms:coverage — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: — K2N: (K2N is flat and does not support classes) — MIX2.0:
Name:	Date and Time Digitized
Normative URI:	k2n:Digitization_Date
	Layer: Technical-Extension — Required: No — Repeatable: No
Definition:	Date the first digital version was created, where different Date and Time Original (e.g. where photographic prints have been scanned). The date and time must comply with the World Wide Web Consortium (W3C) datetime practice, which requires that date and time representation correspond to ISO 8601:1998, but with year fields always comprising 4 digits. This makes datetime records compliant with 8601:2004. AC datetime values may also follow 8601:2004 for ranges by separating two IS0 8601 datetime fields by a solidus ("forward slash", '/'). See also the wikipedia IS0 8601 entry for further explanation and examples.
Comments:	This is often not the file creation or modification date. Use the international (ISO/xml) format yyyy-mm-ddThh:mm (e. g. "2007-12-31" or "2007-12-31T14:59"). Where available, timezone information should be added. In the case of digital images containing EXIF, whereas the exif capture date does not contain time zone information, exif GPSDateStamp and GPSTimeStamp may be relevant as these include time-zone information. Compare also MWG (2008), which has best practice on handling time-zone-less EXIF date/time data.
Crosswalk:	For digital cameras, this maps to the exif capture date — DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: Date Digital — K2N: k2n:Digitization_Date — MIX2.0: mix2:ImageCaptureMetadata/GeneralCaptureInformation/dateTimeCreated
Discussion	As of the date in which I'm making this comment, this term doesn't yet have a normative URI. I don't know if that means that the normative URI hasn't yet been decided, if this was overlooked, or if there was some disagreement of what it should be. It seems clear to me that it should be dcterms:created which is defined in a straightforward manner as "Date of creation of the resource". I am, however, left scratching my head as to why this element (which seems to me to be a very fundamental property of a digital media resource) has been relegated to a "Technical extension" rather than as one of the core elements. I suspect that this is another instance where my experience has caused me to have a different outlook than others. 99.9% of my images are taken of existing physical objects with a digital camera rather than scanned from existing artwork, film slides, or taken from a publication. In my circumstance, the "Original Time and Date" either doesn't mean anything or is the same as "Date and Time Digitized". If I take a picture of a tree, what does the core term Original Time and Date ("The date of the creation for the original resource from which the digital object was derived or created.") mean? The date the tree was planted? The date I discovered it? If the tree isn't the original resource and the digital image is the original resource, then the definition of "Original Time and Date" doesn't make any sense. I'm not sure what the answer is to these questions, I just know that I don't understand how I would use Original Time and Date. With my orientation, if I were writing the schema, I would probably have made Date and Time Digitized a core element (since all digital media resources have it) and relegated Original Time and Date to an extension (since it only applies to a subset of digital media resources which are digital representations of physical media representations of physical objects). If it were ten years ago, I would consider my outlook as the unusual one because at that time probably most digital media resources were being created by digitizing existing physical media items. However, I would venture to say that at the present, the fraction of new digital media items that are being generated directly (either through digital photography or generated directly from software such as GIS or animation software) is much higher than the fraction being created from digitizing physical media items. The fraction will probably be even greater in the future. So why is the digital creation date part of an extension (i.e. I'm assuming considered less important than Original Time and Date)? Steve Baskauf 05:22, 28 October 2009 (CET) There is a huge amount of legacy digital media, e.g. people's slides. If you took a picture on such media and subsequently digitized it, the Original Time and Date is the date at which the photograph was taken, and the Date and Time Digitized is the date and time at which the digital record was made. If you are extracting a time and date recorded by the device itself, and you intend that the subject was that originally depicted, e.g. the digital record is a picture of a tree, not a picture of a picture of a tree because you are imaging a photograph, then these two notions of date are generally different. The Original Time and Date is usually the more biologically interesting and that is why it is in the core. The Date and Time Digitized may be more of curatorial interest than scientific interest. Indeed, there are ongoing arguments about whether a image of intellectual property is new or derivative property, and in such arguments, the distinction may be especially important. We felt that the date at which the scene was originally captured has greater scientific import than the date at which the digital record is made---in case they are different---we put the former in the core but not the latter. People putting metadata on images made by contemporary cameras are likely to find that their best practice is to make Original Time and Date be that recorded by the device, assuming it is properly set. --BobMorris 20:19, 23 January 2010 (CET)
Name:	Capture Device
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:captureDevice
	Layer: Technical-Extension — Required: No — Repeatable: No
Definition:	Free form text describing the device or devices used to create the resource.
Comments:	It is best practice to record the device; this may include a combination such as camera plus lens, or camera plus microscope. Examples: "Canon Supershot 2000", "Makroscan Scanner 2000", "Zeiss Axioscope with Camera IIIu", "SEM (Scanning Electron Microscope)".
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: View.imagingTechnique — NBII: capture device, capture detail — K2N: — MIX2.0:
Name:	Resource Creation Technique
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:resourceCreationTechnique
	Layer: Technical-Extension — Required: No — Repeatable: No
Definition:	Information about technical aspects of the creation and digitization process of the resource. This includes modification steps ("retouching") after the initial resource capture.
Comments:	Examples: Encoding method or settings, numbers of channels, lighting, audio sampling rate, frames per second, data rate, interlaced or progressive, multiflash lighting, remote control, automatic interval exposure. Annotating whether and how a resource has been modified or edited significantly in ways that are not immediately obvious or expected to consumers is of special significance. Examples for images are: Removing a distracting twig from a picture, moving an object to a different surrounding, changing the color in parts of the image, or blurring the background of an image. Modifications that are standard practice and expected or obvious to users are not necessary to document; examples of such expected include changing resolution, cropping, minor sharpening or overall color correction, clearly perceptable modifications (adding arrows or labels, combination or multiple pictures into a table. If it is only known that significant modifications were made, but no details are known, a general statement like “Media may have been manipulated to improve appearance” may be appropriate. See also Subject Preparation Technique.
Crosswalk:	DublinCore: dcterms:description — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: Digitization Technique — K2N: replace this — MIX2.0: mix2:ImageCaptureMetadata/methodology

11 Service Access Point Vocabulary

See Discussion at ServiceAccessPoint especially as to whether Class structure is correct. --BobMorris 04:10, 15 August 2009 (CEST)

11.1 ServiceAccessPoint Class

Name:	Access Point
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:hasServiceAccessPoint
	Layer: Core — Required: No — Repeatable: Yes
Definition:	reference to an instance of a class describing network access to the media resource, or related resources, that the metadata describes. What constitutes a class is dependent on the representation (i.e. XML Schema, RDF, etc.)
Comments:	Use with the properties below. In particular, there is little point to having an instance of this class without a value for the Access URL and perhaps the Format. Implementers in specific constraint languages such as XML Schema or OWL may wish to make those two properties mandatory on instances.
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: — K2N: — MIX2.0:

11.2 Service Access Point Properties

Name:	Access URL
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:accessURL
	Layer: Core — Required: no — Repeatable: No
Definition:	URL of the resource itself
Comments:	For individual resources only. Use this field if only one quality level is available (as it is typical for taxon pages or keys!) Value might point to something offline, such as a published CD, etc.
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: http://www.morphbank.net/?id=XX&imgType=orig — NBII: Resource ID, (QualityLevel)URL — K2N: (QualityLevel)URL — MIX2.0:
Name:	Format
Normative URI:	dcterms:format
	Layer: Core — Required: no — Repeatable: No
Definition:	The technical format of the resource (file format or physical medium).
Comments:	Recommended best practice is to use a controlled vocabulary such as the list of Internet Media Types [MIME]. This item is recommended for offline digital content. In cases where the provided URL includes a standard file extension from which the format can be inferred it is permissible to not provide this item. Three types of values are acceptable: (a) any MIME type; (b) common file extensions like txt, doc, odf, jpg/jpeg, png, pdf; (c) the following special values: Data-CD, Audio-CD, Video-CD, Data-DVD, Audio-DVD, Video-DVD-PAL, Video-DVD-NTSC, photographic slide, photographic print. Compare Type for the content-type.
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: ncd:digitalFormat or ncd:digitalMedium — Morphbank: Image.imageType — NBII: File Format — K2N: (QualityLevel) Format — MIX2.0:
Discussion	NCD distinguishes format ("Use for digital collections, recording MIME Types or PUIDs.") from medium ("Use for digital collections, recording the material or physical carrier of the resource e.g. DVD-R.") (CET)
Name:	Variant
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:variant
	Layer: Core — Required: No — Repeatable: Yes
Definition:	What this ServiceAccessPoint provides. Permitted values are "Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good Quality", "Best Quality", "Offline"
Comments:	*Thumbnail: ServiceAccessPoint provides a thumbnail image, short sound clip, or short movie clip that can be used to represent the media object, typically at lower quality and higher compression than the preview object. A typical size for a tiny thumbnail image may be 50-100 pixels in the longer dimension. Trailer: ServiceAccessPoint provides video clip preview, in the form of a specifically authored "Trailer", which may provider somewhat different content than the original resource Lower Quality: ServiceAccessPoint provides a lower quality version of the media resource, suitable e.g. for web sites. Medium Quality: ServiceAccessPoint provides a medium quality version of the media resource, e.g. shortened in duration, or reduced size, using lower resolution or higher compression causing moderate artifacts. Good Quality: ServiceAccessPoint provides a good quality version of the media resource intended for resources displayed as primary information; e.g. an image between 800 and 1600 px in width or height. Best Quality: ServiceAccessPoint provides the highest available quality of the media resource, whatever its resolution or quality level. Offline: ServiceAccessPoint provides data about an offline resource.
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: — K2N: — MIX2.0:
Discussion	Since some of these are important and some not, it is unclear to me what advice to offer as to whether application builders are in trouble if they ignore some of them. --BobMorris 19:14, 28 January 2010 (CET) Since the permitted values are identifiers, not labels, I really think it better to have them in CamelCase, with no whitespace. If there are no persuasive arguments otherwise, I will change them to that.--BobMorris 19:14, 28 January 2010 (CET)
Name:	Extent
Normative URI:	dcterms:extent
	Layer: Technical-Extension — Required: no — Repeatable: No
Definition:	The size, dimensions, or duration of the media resource.
Comments:	Best practices are: Extent as length/running time should use standard abbreviations of the metadata language (for English "20 s", "54 min"). Extent of images or video may be given as pixel size ("2000 x 1500 px"), or as file size (using kB, kByte, MB, MByte).
Crosswalk:	ORE:Extent — DublinCore: dcterms:extent (refines dcterms:format ) — XMP: — DarwinCore: — NCD: — Morphbank: Image.imageWidth, Image.imageHeight — NBII: extent — K2N: (QualityLevel) Extent — MIX2.0: mix2:BasicImageInformation/BasicImageCharacteristics/imageWidth, and imageHeight
Discussion	I'm worried that this term is too comprehensive and in particular not amenable to machine processing. Note that IS0 8601 provides standards for duration. Maybe we should refactor this term into separate, machine parseable, fields. Surely IPTC has size fields. --BobMorris 17:35, 29 March 2009 (CEST) IPTC has neither size nor extent. XMP has Rendition Class with attributes specifying some aspects of size, plus xmp:Thumbnails, an array of thumbnail objects. It further has xmpDM:videoPixelDepth and color depth properties. I could not find an image pixel extent property, although I believe it should exist there. --GregorHagedorn 08:53, 3 April 2009 (CEST) However, I am not too worried about machine processing here. If we want to provide users with help to estimate fitness of purpose prior to access the media object itself, as is stated in our MRTG reports, we need this. Nothing wrong with making it better machine processable, but in the absence of a good solution for that, keep it human accessible. And I believe good programmers can make such information machine accessible... --GregorHagedorn 08:53, 3 April 2009 (CEST) It seems to me that this term is so broad as to be unusable. In playing around with the use of MRTG terms to create XML for my website, I ignored this term entirely an instead used mix:imageWidth and mix:imageHeight to specify the dimensions of variant image forms that I had defined using mrtg:hasServiceAccessPoint. Those mix: terms have a well-understood meaning and format, while dcterms:extent without a controlled format could be just about anything. Steve Baskauf 20:05, 6 April 2010 (CEST)
Name:	Further Information URL
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:furtherInformationURL
	Layer: Technical-Extension — Required: No — Repeatable: No
Definition:	The URL of a Web site that provides additional information about (this version of) the media resource
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: — K2N: under consideration — MIX2.0:
Discussion	Is this different from attribution link URL?
Name:	Licensing Exception Statement
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:licensingException
	Layer: Technical-Extension — Required: No — Repeatable: No
Definition:	The licensing statement for this version of the media resource if different from that given in the Licensing Statement field of the resource
Comments:	Required only if this version has different licensing than that of the media resource. E.g. the highest resolution version may be more restricted than lower resolution versions
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: — K2N: under consideration — MIX2.0:
Name:	Availability Exception (see Key2Nature)
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:availabilityException
	Layer: Technical-Extension — Required: No — Repeatable: No
Definition:	The licensing statement for this version of the media resource if different from that given in the Licensing Statement field of the resource
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: — K2N: under consideration — MIX2.0:
Discussion	There is no availability field in the main body of the resource. --GregRiccardi 14:53, 13 March 2009 (CET)
Name:	Version Description
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:versionDescription
	Layer: Technical-Extension — Required: No — Repeatable: No
Definition:	Text that describes this version
Crosswalk:	DublinCore: — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: — K2N: considered detrimental, blurring the distinction between multiple (related) resources and versions of a single resource — MIX2.0:
Discussion	The definition of version should be limited to content that is identical except for quality, availability, license, etc. When is a descriptions necessary? Such cases are probably better served if handled as separate resources, and given a resource to resource relation like derived from. the version-specific description should thus be dropped. --GregorHagedorn 12:11, 29 March 2009 (CEST)

12 Related Resources Vocabulary

Name:	Collection Reference By ID
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:containingCollectionID
	Layer: Core — Required: no — Repeatable: No
Definition:	An arbitrary code that is unique among a provider's metadata records of type “Collection” and by which the media resources are linked to their collection.
Comments:	If the resource is not a collection - this field is for relating a collection to the resource. Each image, sound or taxon page should belong to a collection. Examples: "1", "BrdSng", "328423".
Crosswalk:	DublinCore: dcterms:relation — XMP: — DarwinCore: — NCD: — Morphbank: URL for collection id, if present — NBII: Other Related Resources (in part) — K2N: k2n:XXX — MIX2.0:
Discussion	Definition is too vague about "and by which the media resources are linked to their collection." --BobMorris 20:53, 13 February 2009 (CET) We had issues with people misunderstanding CollectionID as ID of , rather than ID to. I propose to rename this to MemberOfCollectionByID? --GregorHagedorn 12:23, 23 February 2009 (CET) Why not just MemberOfCollection with spec being that the value is an ID? We don't have any other MemberOfCollection? --BobMorris 23:54, 13 March 2009 (CET) the natural response by non-programmers for "member of which collection"? would, in my opionion, be to give the collection by its title. We know that is not unique enough. I like names to be clear, but if MemberOfCollectionByID is sounding too complicated, we just have to make sure that the definition is clear. Problem when not specifying which ID or what form is that we cannot validate that MemberOfCollection = "XYZ Butterfly images" is invalid. --GregorHagedorn 18:34, 14 March 2009 (CET) WE NEED TO SETTLE THIS NAME. How about "ID of Containing Collection" with another item "Name of Containing Collection", perhaps with the first being preferred. --BobMorris 18:52, 14 March 2009 (CET)  ?? We need a comment that this need not be the ID specified in the Identifier metadata item, although that is a recommended practice. --BobMorris 17:38, 14 March 2009 (CET) Do we need to specify semantics of inheritance? If R is a MemberOfCollection A, which is a MemberOfCollection B, are applications allowed to conclude that R is a MemberOfCollection B? --BobMorris 17:38, 14 March 2009 (CET)
Name:	Collection Member By ID
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:memberIDinCollection
	Layer: Extended — Required: no — Repeatable: No
Definition:	A link
Comments:	If the resource is not a collection - this field is for relating a collection to the resource. Each image, sound or taxon page should belong to a collection. Examples: "1", "BrdSng", "328423".
Crosswalk:	DublinCore: dcterms:relation — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: — K2N: k2n:XXX — MIX2.0:
Discussion	Usage remains unclear to me. duplicate of Resource ID? Why restricted to media resources, but not Collections? Should this be something like "relation or unknown kind"? --GregorHagedorn 12:23, 23 February 2009 (CET) Definition is too vague about "and by which the media resources are linked to their collection." --BobMorris 20:53, 13 February 2009 (CET) Is there no requirement that the ID be the MRTG ID? --BobMorris 17:38, 14 March 2009 (CET)
Name:	Related Resource By ID
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:relatedResourceID
	Layer: Extended — Required: no — Repeatable: No
Definition:	Resource related in ways not specified through a collection. Before-after images Timelapse series Different orientations/angles of view
Crosswalk:	DublinCore: dcterms:relation — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: — K2N: k2n:XXX — MIX2.0:
Name:	Provider By ID
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:providerID
	Layer: Extended — Required: no — Repeatable: No
Definition:	a Globally unique ID of the provider of the MRTG record that is being provided.
Comments:	If the resource is not a provider - this item is for relating the resource to a provider, using an arbitrary code that is unique for a provider, contributing partner, or aggregator, or other roles (potentially defined by MARC, OAI) and by which the media resources are linked to the provider. -
Crosswalk:	DublinCore: dcterms:relation — XMP: — DarwinCore: — NCD: ncd:institutionId — Morphbank: URL for group — NBII: see MARC Name/Roles - specific combinations — K2N: k2n:XXX — MIX2.0:
Discussion	"need to figure out how to handle aggregation depending on whether cataloging the collection, or an individual media (or a provider), this would be the dc identifier or relation field" (from the spreadsheet). - Definition is too vague about "and by which the media resources are linked to their collection." --BobMorris 20:53, 13 February 2009 (CET) We discussed possible misunderstandings of provider in Woods Hole. Should this perhaps be: ServiceAttributionURI: "A URI that identifies the primary provider of either the data or metadata, whichever is desired and agreed upon by media resource and metadata provider. Client software displaying the results of metadata searches are being requested to display for each resource the following attributions (if available): resource creator, copyright owner, collection context, and the ServiceAttributionURI. If ServiceAttributionURI matches a homepage of a data or service provider record, in addition to the URI title, description, or logo are requested to display." --GregorHagedorn 12:23, 23 February 2009 (CET) for NCD Institution Identifier comes closest: "The URI (LSID or URL) of the institution. In RDF this will be used as URI of the institution resource." Not sure if my Definition herewith added is clear --BobMorris 03:48, 14 February 2010 (CET)
Name:	Derived From
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:derivedFrom
	Layer: Core — Required: No — Repeatable: Yes
Definition:	A reference to an original resource from which the current one is derived.
Comments:	Derivation of one resource from another is of special interest for identification tools (e. g. a key from an unpublished data set, as in FRIDA, or a PDA key from a PC or web key) or web services (e. g. a name synonymization service being derived from a specific data set). It may very rarely also be known where one image or sound recording is derived from another (but compare the separate mechanism to be used for quality/resolution levels). – Human readable, or doi#, or URL.. Simple name of parent for human readable. Can be repeatedable if a montage of images.
Crosswalk:	DublinCore: dcterms:relation — XMP: xmpMM:, which however has a special document identifier scheme of document, instance and version IDs. — DarwinCore: — NCD: — Morphbank: — NBII: Source, also Related Media — K2N: k2n:XXX — MIX2.0: mix2:ChangeHistory/ImageProcessing/sourceData
Discussion	This is not intended for different display resolutions, for which different quality level URLs are available What is the difference between Derived From and Published Source? This is more general and published source carries a special semantics of published item. I am not sure both are needed though! --GregorHagedorn 01:21, 3 March 2009 (CET) This element suffers from the same problem of confusion about "what is the source from which a resource is derived" as I discussed in the Published Source item. --Steve Baskauf 17:25, 30 April 2009 (CEST) For NCD Derived Collection ncd: comes closest "A "derived" collection record. The record has been derived from a query on an item-level database e.g. all items from Australia.".
Name:	Associated Specimen Reference
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:associatedSpecimenReference
	Layer: core — Required: no — Repeatable: No
Definition:	Reference to a specimen associated with this resource.
Comments:	Supports to find a specimen resource, where additional information is available. If several resources relate to the same specimen, these are implicitly related. Examples: for NHM “BM 23974324” for a barcoded or “BM Smith 32” for a non-barcoded specimen; for UNITS: “TSB 28637”; for PMSL: “PMSL-Lepidoptera-2534781”. Ideally this could be a URI identifying a specimen record that is online available.
Crosswalk:	DublinCore: dcterms:relation — XMP: — DarwinCore: — NCD: — Morphbank: Image.specimenId — NBII: Specimen ID — K2N: k2n:XXX — MIX2.0:
Discussion	"question of whether we have both an encoded URI/vocab, but also get a free text." from spreadsheet Is this the same as DwC:RelatedResourceID - "A global unique identifier to a related resource." I won't repeat what I already wrote in the discussion of Published Source, but again it seems to me that what we need here is simply Dublin Core "Source", which is clearly defined as "A related resource from which the described resource is derived". It seems to me that we are creating unnecessary complexity by defining separate terms depending on if an image came from a specimen, a live plant, or a digitized slide. All of these physical resources can be referenced by the URL of their online record (and they should have one) or eventually by their LSID (assuming LSIDs ever get off the ground). If there aren't online references, then create a VerbatimSource field to be populated with whatever text description there is for locating the resource. But don't create several different elements when one will do. --Steve Baskauf 17:25, 30 April 2009 (CEST) At the moment, I somewhat agree with Steve, but (a)MRTG metadata need not refer to a digital object, so there is not necessarily an existing URL to give context and (b)dc:Source seems too vague to me. If something is marked as dc:Source, how do we know it refers to a specimen? --BobMorris 22:08, 23 January 2010 (CET)
Name:	Associated Observation Reference
Normative URI:	→ Information about submission as TDWG standard → MRTG Wiki Homepage → Current Schema Draft. This version is under internal review as part of the submission to TDWG. → Audubon Core Non normative document → MRTG Development History → MRTG Meeting Notes → MRTG Best Practices → XML Schema representation of Audubon Core → RDF representation of Audubon Core → MediaWiki Help mrtg:associatedObservationReference
	Layer: Core — Required: no — Repeatable: No
Definition:	REference to an observation associated with this resource.
Crosswalk:	DublinCore: dcterms:relation — XMP: — DarwinCore: — NCD: — Morphbank: — NBII: Other Related Resources — K2N: k2n:XXX — MIX2.0:
Discussion	This will need coordination with the Observation Working Group --BobMorris 20:53, 13 February 2009 (CET) Same thing here as above. Why are we creating another specific field when one generic field will do? If it is necessary to know what kind of resource the source is, then create an element called SourceType and populate it with valid Type terms from a controlled vocabulary, i.e. Darwin Core Type vocabulary. Thus a more generalized system could be: Source (hopefully an LSID or URL to an online record), VerbatumSource (a human-readable text description of where to find the source), and SourceType (a controlled DwC vocabulary, including physical specimen, observation, still image, etc.) --Steve Baskauf 17:25, 30 April 2009 (CEST) Same thing here as above. :-) --BobMorris 22:08, 23 January 2010 (CET)

→ Information about submission as TDWG standard
→ MRTG Wiki Homepage
→ Current Schema Draft. This version is under internal review as part of the submission to TDWG.
→ Audubon Core Non normative document
→ MRTG Development History
→ MRTG Meeting Notes
→ MRTG Best Practices
→ XML Schema representation of Audubon Core
→ RDF representation of Audubon Core
→ MediaWiki Help

Areas we address weakly or not at all:

• Provenance --- data quality authority, history of custody etc.
• modifications, etc.
• Fitness for use --- How will I know from metadata whether this resource is going to be useful to me.

13 Controlled Vocabularies

In several cases MRTG requires or recommends controlled vocabularies. In addition to being referenced in the respective fields, we provide some links to analyses here.

• MRTG Summary of IPTC vocabularies

---