Submission v095

Work in progress: Please do not edit this page while you see this. Expecting to finish by about after TDWG — BobMorris Last edit of page on: 2010-09-27 

Work continues at Submission Proposal v1.0. DO NOT EDIT HERE

This page is meant to evolve to the approved normative standard. It is not for the addition of commentary during or after the TDWG submission process. Comments on the proposal are invited at Discussable_v0.9 The page is closed except for by the MRTG committee in furtherance of TDWG submission. Nobody else should edit it. If TDWG accepts our responses, there will be a month of public comment.

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

• Go here for Discussion of theXML Schema For MRTG
• Go here for Discussion of the MRTG in RDF
• TDWG09 MRTG WORKGROUP REPORT

Color Coding for Internal Review

Color coding for TDWG Internal Review

Yellow: Review Comments. If struck out, this means that the green Response is asserting that it is fully addressed.

Green: committee response.

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 will follow 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.
• MRTG terms are devided into two Layers. Those characterised as in the Core Layer, including the six mandatory terms, should be meaningfully handled by all consuming clients applications. Only wholly complete consuming applications need handle those in the Extended Layer'.

Every MRTG term has a plain text Name, a URI, a plain text normative Definition and an optional "Comments" attribute. In addition, a term has an attribute telling whether it is mandatory, one telling whether it is repeatable, and one telling whether it is in the "Core" or "Extended" Layer. The Extended Layer comprises terms likely to only occur for certain media. For example, Date Available will apply only to media that are embargoed, but for which the provider is prepared to make the metadata immediately available. It is strongly recommended that consuming applications be able to meaningfully handle Core terms, and that only wholly complete consuming applications need handle Extended Layer terms. What is meant by "meaningfully handle" is up to implementers of this normative specification. It could be as simple as "gracefully ignore".

Review Substantive Item 1 The normative documentation ought to be free-standing, so some explanation of what is meant by “Layer” would be good.

Response: I would list them in the terminology list above, as "A Core Layer is the combined mandatory or strongly recommended terms that consuming applications should be able to handle" (or somesuch), and then "A Layer, Extended is ....." I'm fuzzy on what our definitions were, but will come back and fill in if have time. AnnetteOlson 20:41, 24 August 2010 (CEST) I've done what Annette suggests, but still not satisfied. What are we really trying to say here? Is it that Extended ones are rare? unimportant? Some standards address this problem through use of named profiles which impose specifications, among other things, on which terms will comprise the profile. For example, Simple Darwin Core specifies that any DwC terms may appear, but it also imposes some restrictions on structure (e. g. flatness) that are not implied by the standard as a whole. Are we skirting around (some future document about) how to construct profiles here? Maybe there should be a paragraph expressing this and saying that profile builders should somehow use the Layer value to characterize the coverage of their profile.--BobMorris 14:38, 27 August 2010 (CEST) I definitely wouldn't say for Extended Fields - unimportant, but instead "likely to only occur for certain subsets of metadata." For instance, only a certain # of habitat images are going to come in with the field "Elevation", definitely not images of species in the lab. By saying there is a Core layer, we are saying there is a 'profile' that should be met. (if I am thinking what you are thinking about profiles). as for structure - flatness, I leave that for others to discuss (not my cup of tea) AnnetteOlson 18:54, 2 September 2010 (CEST) Present wording meets our discussions. Also, removed all mention and use of "Technical Extension" --BobMorris 19:44, 20 September 2010 (CEST)

URI's for terms conform to 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 as follows: 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. A few MRTG properties permit values to be taken from another controlled vocabulary chosen by the user. In this case, those values may involve URIs conforming to a scheme given by that external vocabulary, and MRTG is silent on what that scheme is.

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.

Media Collections

MRTG metadata can describe either individual multimedia resources or collections of resources. A few, but not many, of the MRTG properties have different values for collections than for individual media. If no such distinction is mentioned, MRTG does not assume one.

Management Vocabulary

Name:	Identifier
Normative URI:	dcterms:identifier
	Layer: Core — Required: ‘Yes’ for media collections, ‘No’ for media resources (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).
ReviewComments:	2. “Yes for collections, No for media resource (but preferred if available)” – there has been no prior mention of collections or attempt to separate these from media resources.
Response:	A section in the prologue above now points out that differences between media and media collections are explicitly mentioned when they exist. --BobMorris 04:18, 24 August 2010 (CEST) Should these be listed in the terminology specification list above as well, not just in the prologue? AnnetteOlson 20:45, 24 August 2010 (CEST)
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. Also recommended are PanAndZoomImage , 3DStillImage, and 3DMovingImage.
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.
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.
Name:	Title
Normative URI:	dcterms:title
	Layer: Core — Required: Yes — Repeatable: No
Definition:	Concise title, name, or brief descriptive 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 could be used as display text of hyperlinks or to provide a choice of images in a pick list. The title is therefore highly useful and an effort should be made to provide it, where not already available. When the resource is a collection without an institutional or official name, but with a thematic content, a descriptive title, e. g. “Urban Ants of New England” would be suitable. In individual media resources depicting taxa, the scientific name or names of taxa often form a good title. Common names in addition to or instead of scientific names are also acceptable. Indications of action or roles captured by the media resource, such as predatory acts, are desirable (“Rattlesnake eating deer mouse”, “Pollinators of California Native Plants”).
ReviewComments:	3. “The taxon name(s) will form a good substitute title.” – presumably this could/should be qualified to state that they will form a good title for media resources which portray one or more taxa – not so much e. g. for collections.
Response:	I agree. The phrase "substitute" should be taken out. and I like their phrasing of 'for media resources which portray one or more taxa.' For LIFE, we use a combination of scientific name and common name when one taxa, and just common names when more than one. We also use titles that indicate any action shown in the media - Such as "rattlesnake eating deer mouse." I would suggest adding the phrase: 'Common names in addition to taxonomic names are also acceptable, as are indications of action captured by the media resource, such as predatory acts.' I forgot, do we discuss anywhere about Best Practices documents to be constructed (and by whom)?. Because further instruction for how to construct a title really should be elswhere.AnnetteOlson 20:56, 24 August 2010 (CEST) Enhanced Commentary. Edit at will --BobMorris 22:11, 27 August 2010 (CEST) Reworded, trying to address all comments. Gregor Hagedorn 12:38, 29 August 2010 (CEST) I made some minor wording changes. AnnetteOlson 19:01, 2 September 2010 (CEST)
Name:	Metadata Date
Normative URI:	xmp:MetadataDate
	Layer: Core — Required: No — Repeatable: No
Definition:	Point in time recording when the last modification 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:	This is not dcterms:modified, which refers to the resource itself rather than its metadata. A use case is incremental harvesting: the holder of metadata who also holds the resources may be receiving metadata more frequently than the underlying resources; thus this date information may help a user harvesting the metadata to decide whether updating is necessary.
ReviewComments:	4.“This makes datetime records compliant with 8601:2004 MRTG datetime values may also follow 8601:2004 for ranges by separating two IS0 8601 datetime fields by a solidus ("forward slash", '/').” – needs a period/fullstop before MRTG. Otherwise seems to speak of “8601:2004 MRTG datetime values” and then to slip into syntactic incoherence. 5. Why the mismatch between “Metadata Modified” and xmp:MetadataDate? 6.“Use case: a)” for Metadata Modified implies that b) and perhaps c) may follow.
Response:	4. Note this must be addressed in several places. --BobMorris 19:11, 17 August 2010 (CEST) Actually, the errant full stop was in a template. I have fixed it there and this will fix all occurrences. --BobMorris 22:47, 28 August 2010 (CEST) 5. I have made name and URI consistent. --BobMorris 22:47, 28 August 2010 (CEST) Did Gregor map these fields to xmp? I cannot find the xmp version of the terms using the item uri AnnetteOlson 21:10, 24 August 2010 (CEST) You have to go down to the footnote, which explains that terms in the xmp namespace are not resolvable. Rather, for further information from Adobe documentation, you have to open the referenced PDF document and look around. In this particular case, the footnote needs a little addition, because this particular URI is in "Part 1" of an Adobe document and the citation is to "Part 2" which in the current edition simply refers to Part 1 anyway. I will address this, as it may impact other xmp terms as well. We have to check whether all the xmp we use is in a single Part of the Adobe documentation. I may address it by assigning the problem to Gregor. :-) --BobMorris 22:47, 28 August 2010 (CEST) Gregor: Shouldn't the "NS xmp" template be changed so that there is no link on the URI, since it doesn't resolve. This is how "NS Iptc4xmp" is handled. If yes, please do so; I don't want to break it. Thanks. --BobMorris 22:47, 28 August 2010 (CEST) Good point, thanks Annette! I did change or at least tried. However, cross-checking the PDF Part 1 and 2 is unfortunately beyond my abilities for the coming weeks Gregor Hagedorn 12:38, 29 August 2010 (CEST) After I look at the remainder of the comments, I will carefully check all the xmp citations as to whether they are correctly cited in Part 1 or Part 2. I notice we no longer even have any footnotes citing Part 1, so I am sure that's wrong. Making this bold to remind myself. --BobMorris 23:29, 10 September 2010 (CEST) 6. I have reworded so the problem goes away. --BobMorris 20:10, 17 August 2010 (CEST)
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 multimedia Resource IDs (which are highly recommended to supply). In the face of metadata records of several languages for the same resource, this normative document offers no guidance as to how to disambiguate what language applies to what metadata. To disambiguate this, the metadata provider can provide a separate MRTG object for each different MetadataLanguage, each such MRTG object referring to the same multimedia resource Identifier. This comes at a cost of repeated data for the "language neutral" metadata items, but the alternative is to have a complex hierarchical structure for a MRTG object. Nothing in this document would prevent an implementer, e. g. of an XML-Schema representation, from providing a fully hierarchical schema and disambiguating that way. Users of particular implementation should consult documentation specific for that implementation on this point, but it should always be correct, if convenient, to provide one metadata record per language.
ReviewComments:	7. On Metadata Language, I appreciate the separation of different language versions, but how are these different versions requested and served – are there viable and reasonable standards for this? Otherwise the whole concept of multiple metadata languages may not make sense.
Response:	This is related to a generic problem that we need to address more explicitly perhaps at the beginning, perhaps in a best practices document or perhaps on each of the (many) properties affected. The issue is: to which other MRTG properties does this one apply? To disambiguate this, the metadata provider should provide a separate MRTG object for each different MetadataLanguage, each object referring to the same multimedia resource Identifier. This comes at a cost of repeated data for the "language neutral" metadata items, but the alternative is to have a complex hierarchical structure for a MRTG object. We are trying to keep the normative definitions as flat as possible. Nothing would prevent an implementer, e. g. of an XML-Schema representation, from providing a fully hierarchical schema and disambiguating that way. The proposed XML-Schema and the proposed simple RDF representations do not do that, and so those implementers should document the need to have one MetadataLanguage per MRTG record. In summary, because that architecture is always possible, the normative schema is intentionally silent on disambiguation strategy. --BobMorris 21:03, 17 August 2010 (CEST) I would add above 'multimedia resource' to the phrase 'each object referring to the same 'multimedia resource' Identifier.' (because one can have identifiers for metadata versions as well). Currently LIFE has repeated metadata records (one in English and one in Spanish) for particular resources (not all of our resources, just about 1000 so far). As for the rest of what you talk about Bob regarding XML and RDF - I'm not sure what all that means, so I'll keep quiet on that.AnnetteOlson 21:10, 24 August 2010 (CEST) Although a language-specific resolution (requested and served) may be desirable, this is not in the scope of this standard. Also, the problem may not be urgent in practice, because usually only 1 or few language metadata records will exists. Serving all languages on a generic request is a plausible solution. Gregor Hagedorn 12:38, 29 August 2010 (CEST) I have incorporated the response comments into the normative comments. In general, the normative comments could provide a sort of generic best practices "document" that can guide users and implementers. Due to said incorporation, I am closing this issue, unless people need to reopen it. If you choose to edit my text though, please leave a comment here so we will know it changed. --BobMorris 23:44, 10 September 2010 (CEST)
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 provider's data repositories. It is the provider's decision whether to expose this value or not.
Name:	Rating
Normative URI:	xmp:Rating
	Layer: Core — Required: No — Repeatable: No
Definition:	A rating of the media resources, provided by users or editors, with -1 defining “rejected”, “0” defining “unrated”, and “1” (worst) to “5” (best).
Comments:	The origin of the rating is not communicated. It may, e. g., be based on user feedback or on editorial ratings. If Rating is not present, a value of 0 may be assumed.
ReviewComments:	8. Does Rating relate to the metadata or the associated media resource or the combination of the two?
Response:	What is the xmp definition? I think we should follow that. If that is not clear, I again think that we should provide a term that provides a description of the rating system. And if that is no longer an option, then we are expected to define it here and recommend best practices - which I really think isn't our call. I know that we (LIFE) would probably implement it in multiple ways - a way to judge the image (this one is suitable for brochures....), the metadata (though we use peer-reviewed for that), or an overall rating that combines them all. How does K2N use it? AnnetteOlson 21:22, 24 August 2010 (CEST) xmp Rating is about the resource, values and definition attempted to be made better congruent with xmp now. See http://www.adobe.com/devnet/xmp/pdfs/XMPSpecificationPart1.pdf Table 5. Gregor Hagedorn 12:38, 29 August 2010 (CEST) Closing this as Gregor's 29 August edit addresses the reviewer's and Annette's comments. Note to self: review if XMP citation is to correct volume --BobMorris 00:05, 11 September 2010 (CEST)
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:	The name of a person, institution, etc. that provided a comment. Must display a name or the literal "anonymous" (= anonymous commenter).
Comments:	Provider is asserting they accept the associated comments, but makes no claim as to competency of the Commenters.
ReviewComments:	9. For Commenter/Comments/Reviewer/Reviewer Comments, there is much that is unclear. As before, are these comments on the metadata, the media resource or the combination of the two? Why is Commenter defined as meaning that the resource has comments? Surely the presence of the Comments makes that clear? Is it intended that there should be series of Commenter/Reviewer elements listing all parties who have commented or reviewed the resource? Are the comments expected just to be text literals? Given the cardinality of Commenter and Comments (and the review equivalents) there seems to be no way that individual comments can be associated with the commenter.
Response:	* Comments and Reviewer Comments may refer to either the resource or the resource and its metadata. Separating these issues is considered to be confusing in practice. A commenter will have usually seen both and will have difficulty separating whether a comment refers to the media item irrespective of metadata, or in the light of metadata (e. g. a taxon identification or location asserted in the metadata). The wording of the MRTG definition and comments was clarified and examples given under comments. Gregor Hagedorn 20:55, 29 August 2010 (CEST) Why is Commenter defined as meaning that the resource has comments? - True, fixed. Gregor Hagedorn 20:55, 29 August 2010 (CEST) ”Is it intended that there should be series of Commenter/Reviewer elements listing all parties who have commented or reviewed the resource?” -- Note sure, OPEN ISSUE Gregor Hagedorn 20:55, 29 August 2010 (CEST) Association between Comment and responsible Agent may be possible in specific schemata based on this vocabulary profile. We are uncertain whether this should be solved in the vocabulary itself. Please also see Linking MRTG elements. Gregor Hagedorn 20:55, 29 August 2010 (CEST) I agree with Gregor's first comment about it is difficult to separate comments on media or metadata, and it would be too confusing to institute separate fields for this. As for separate Comment v. Commentor fields - i.e., the names in one field and the comments in the other, I agree that it is difficult to associate the name with the comments. We originally had them separate in LIFE but recently put them back together in one, text field, of comments and names. When receiving annotations directly from outside sources, such as through a log-in and then a that user using a comment field, the user name is often recorded with the comments when inputted - so they are often in one field. In other words, I am proposing that we make Comments and Commentor one, text field called Comments, and the best practice is that the commentors name is recorded with each comment with date stamps if possible. (but basically it is all text-based). AnnetteOlson 20:46, 2 September 2010 (CEST) For what it's worth, the newly formed Annotation interest group will strive to put forth sufficiently general notions of an Annotation, that all of these issues can be treated unambiguously in a highly structured way, extensible way. I really wonder if the topic is too complex for MRTG and whether we should not try to distinguish such things as peer review from other kinds of comments. After all, if I provide images and assert that my comments are expert, why is that different from when I assert that comments by Gregor are expert? The assertion "X is an expert" really has utility mainly by knowing who is asserting it, which has little to do with who is providing it. Consider especially the case where ReviewerComments come through in a record from an aggregator, and with little or no provenance available. What am I to make of that? Only that somebody made an assertion of expertise. --BobMorris 00:53, 11 September 2010 (CEST) I remain a little confused about what we mean to do. It seems Gregor and Annette want to remove "Commenter" and make "Comments" be a repeatable plain text attribute that includes attribution. I have mixed feelings about that and suggest that we see what, if anything, comes out of TDWG. --BobMorris 19:57, 20 September 2010 (CEST)
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 media resource, as free-form text.
Comments:	Comments may refer to the resource itself (e. g., asserting a taxon name or location of a biological subject in an image), or to the relation between resource and associated metadata (e. g., asserting that the taxon name given in metadata is false, without asserting a positive identification). There is a separate item for reviewer comments, which is defined more as an expert-level review.
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, even if Reviewers Comments are lacking. 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.
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 a reviewer with expertise in the subject, as free-form text.
Comments:	Reviewer Comments may refer to the resource itself (e. g., asserting a taxon name or location of a biological subject in an image), or to the relation between resource and associated metadata (e. g., asserting that the taxon name given in metadata is false, without asserting a positive identification). There is a separate item “Comments” for text from commenters of unrecorded expertise.
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 to be recorded, or if only one is recorded, it is assumed to be the latest.
ReviewComments:	10. I think the items should be reordered to make grouping more logical – why is Modified not before/after Metadata Modified?
Response:	* Should Metadata Modified be moved here? I propose Bob decides. --Gregor. Bob can decide, but I am for it moving here - otherwise people (versus machines) will continue to be confused.AnnetteOlson 21:05, 2 September 2010 (CEST) I presume the reference is now to xmp:MetadataDate (There is no longer any MetadataModified, as it means the same thing as xmp:MetadataDate). Rather than move it now in response to this reviewer comment, I propose that at TDWG Annette and I reconsider the order and categories of the terms. The original categories may not be appropriate. Among other things, we have a few terms that are about metadata, not about the resource, and perhaps it is better to put them in their own category to reduce confusion. I will leave this issue open pending response. --BobMorris 00:32, 11 September 2010 (CEST)
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.
Comments:	A use case is, for example, that metadata, potentially including occurrence records, are published before even before the media are available, which are pending a formal publication elsewhere.
ReviewComments:	11.Can you give some use case for Date Available? Is this to support media embargoes?
Response:	Yes, it supports media embargoes. It allows publication of metadata even before the media are available. For example, an occurrence record could be asserted even if the image is not served.
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.
ReviewComments:	12. Are there any expectations about the form of an Accrual Policy? Is this a URI or a block of text, or just whatever human-readable value makes sense?
Response:	* There is a problem here. dcterms:accrualPolicy is a property whose value is an object of class dcterms:Policy. It also takes a dcterms:Collection as subject. I don't think our intent is anything this complex. I think we want a plain text value, and so have to put it in our namespace. --BobMorris 18:28, 17 August 2010 (CEST) Not sure we should not follow Dublin core. dcterms:Policy is simply a subclass of Resource. I believe this means, we just have to specify that the value of accrualPolicy is a URI, correct? Which would answer the reviewer’s question. Gregor Hagedorn 20:55, 29 August 2010 (CEST) A URI? This is how DC terms defines it by association with Policy which is associated with Resource? I"m afraid we didn't get that deep when we (LIFE) decided to use this term - we are managing this as a plain text field. We do apply it to Collection as subject. I'm not sure how widely AccuralPolicy is currently used in bioinformatics, though it is widely in the library field.AnnetteOlson 21:17, 2 September 2010 (CEST) Ummm, what if we drop it altogether? If not, we should just put it in mrtg namespace, declare it to be plain text, give NBII's values as examples, and point to dcterms:accrualPolicy as a more detailed usage that we are not following. Keep in mind that this normative document (and, I hope, any RDF implementation ) implicitly subscribes to the Open World assumption---although maybe we need to take an explicit position on that. An XML-Schema implementation probably will entail that terms outside the schema cannot be referenced and still maintain validity, but other implementations might not. In open world implementations, a producing app could actually add dc:accrualPolicy if it wishes, and a consuming app can do what it wishes. --BobMorris 00:32, 11 September 2010 (CEST) I think we decided to drop this term altogether as of little value. Leaving it open until that is confirmed. Maybe discuss at TDWG? --BobMorris 20:19, 20 September 2010 (CEST)

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).
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 expresses rights over the media resource, not over the metadata text.
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!)
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/. Where different quality variants (e. g. resolutions of images) are published under different licenses, the MRTG term “Licensing Exception Statement” supports variant-specific licenses.
ReviewComments:	13. How should a provider handle the situation where a CC license applies to low-resolution versions and some other license to high-resolution versions? Incidentally this opens up the question of whether metadata relates to some platonic ideal of the image or to particular size/format representations.
Response:	The use case mentioned by the reviewer is handled by the “Licensing Exception Statement” property of the service access points. Different access points, including different resolutions can have different licenses. Now annotated in comments. Gregor Hagedorn 11:59, 30 August 2010 (CEST) I would add that if different versions of an image are going to be treated differently, then they should be treated as different resources with different ids - and thus different licenses associated with each id, instead of all refering to one resource id. But Gregor's response should answer this comment.AnnetteOlson 21:17, 2 September 2010 (CEST) I favor Gregor's solution over Annette's because I believe that different jurisdictions and individuals may treat them differently or treat them as one work. To whatever extent that may be true, any position of MRTG on the matter would be irrelevant and/or prevent an expression of a locally, legally correct, usage. Pending any further debate, I am closing this issue. --BobMorris 01:09, 11 September 2010 (CEST)
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 a search or reporting user-interface. Example:
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…"
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).
ReviewComments:	14. Should there be more guidance on what is appropriate for an Attribution Logo URL – e. g. on the size of the image returned? My opinion is no. I think there should be best-practices established.
Response:	Among other things, the server may wish to have a policy as may clients. If somebody's client/server architecture can accomplish this, so much the better. MRTG should not intervene in matters like this. --BobMorris 18:55, 17 August 2010 (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.
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 repeatable if a montage of images.
ReviewComments:	15. Why “Published Source” rather than “Source”?
Response:	In the "Discussion" data for this wiki table there was a lot of discussion on this point. The review was to be of what we would publish as the normative document, so I suppressed the public discussion in this rendering. Will it help to turn it back on? Just for specific items? --BobMorris 21:03, 17 August 2010 (CEST) I would be grateful for reviewer’s recommendation on actions after we have passed them the discussion above. We could have own vocabulary term or strictly follow dcterms, with some commentary on best practice in our view, with uses to differentiate from derivedFrom. Gregor Hagedorn 11:59, 30 August 2010 (CEST) Gregor: I don't understand what you are asking for here. --BobMorris 01:09, 11 September 2010 (CEST) In meeting of 17Sep2010, Gregor clarified that by the above he meant to get some advice from the reviewer on better terminology. In unrendered Comments, Steve Baskauf argues that in the case of a specimen image, the dc:source could be a GUID for the specimen. In general, I think we need to put down a variety of cases-- specimens, picture of a published work (e.g. BHL images, image of botanical sketches, of fine art, etc.), Then we can perhaps find the right term. For discussion at TDWG?

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 text including contact information. Note that the Creator need not be the Copyright Owner
ReviewComments:	16. “The value may be simple text or a nested object representing the details of a CI_ResponsibleParty” – define CI_ResponsibleParty – I think the asterisk and the bullet in this block of text should probably be made consistent.
Response:	CI_ResponsibleParty is something in the crosswalk field and so(?) doesn't inherently require definition. However, here it deserves at least a citation. I have no idea what it is. --BobMorris 21:03, 17 August 2010 (CEST) I have no idea what the CI_ResponsibleParty is, for LIFE we use it as the person to contact for permission to use the image, such as for commercial purposes. But I would just change the Definition, adding in - as noted in the Crosswalk. Btw, this Comment (#16) and its responses really belong under the Creator term, not this term, but I didn't want to mess it up by moving it myself.AnnetteOlson 23:10, 2 September 2010 (CEST) I moved it back where it belongs. --BobMorris 04:33, 11 September 2010 (CEST) CI_ResponsibleParty seems to denote "Contact Information of Responsible Party". The "CI_" seems to be applied to a lot of stuff in standards that are from geospatial standards promulgated by OGC and ISO. I can't find them used in dcterms, and I propose we simplify to the text Comments I've given, after removing the struck out text. I have also removed reference to CI_ResponsibleParty that was in the Crosswalk. If agreed I will implement. Agreement by email is fine. For now, I consider the issue closed --BobMorris 04:33, 11 September 2010 (CEST)
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: No
Definition:	Person or organization responsible for presenting the media resource. If no separate Metadata Provider is attributed, this attributes also the metadata.
Comments:	Media items and Metadata may be served from different institutions, e. g. in the case of aggregators adding user annotations, taxon identifications, or ratings.
ReviewComments:	17. Is the definition of Provider correct? If so, it seems to mean the same as MetadataProvider. Otherwise, shouldn’t it be the person or organisation responsible for presenting the media resource or collection rather than the record?
Response:	Yes, and in public discussion we agreed to eliminate this. If there is no further objection, I will do so. --BobMorris 21:03, 17 August 2010 (CEST) Media items and Metadata may be served from different institutions, e. g. in the case of aggregators adding user annotations, taxon identifications, or ratings. Therefore an attempt is being made to allow a separate attribution of providers. I tried to correct the def. and comment under this perspective. Please check whether correct. Gregor Hagedorn 11:59, 30 August 2010 (CEST) I agree with Gregor on purpose, and wording seems okay. AnnetteOlson 21:17, 2 September 2010 (CEST) Me too. Reversing my position and closing this issue. --BobMorris 01:19, 11 September 2010 (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 originally responsible for compiling and presenting providing the resource metadata record.
Comments:	Media items and Metadata may be served from different institutions, e. g. in the case of aggregators adding user annotations, taxon identifications, or ratings. Compare Provider.
ReviewComments:	none
Response:	* I have simplified the Definition to distinguish it from the (reinstated) Metadata Creator. Arguably now Metadata Provider is less important. --BobMorris 04:18, 18 September 2010 (CEST)
Name:	Metadata Creator
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:metadataCreator
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Person or organization originally creating the resource metadata record.
ReviewComments:	none
Response:	new term --BobMorris 04:18, 18 September 2010 (CEST)

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. This normative document is silent on the nature of formatting in the text. It is the role of implementers of a MRTG concrete representation (e.g. an XML Schema, an RDF representation, etc.) to decide and document how formatting advice will be represented in Descriptions serialized according to such representations.
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, a caption together with the resource. Should be a good proxy for the underlying media resource.
ReviewComments:	18. Description – do we need any guidance on line breaks?
Response:	* Note that Description takes its URI from DC. Perhaps we should be more emphatic that it's our intent when we use someone else's namespace, unless otherwise mentioned, the documentation for that term should be applicable. dcterms:description is silent on line breaks hence so should we be. --BobMorris 19:11, 17 August 2010 (CEST) Not sure. I think it is reasonable to give best practices guidance and example about formatting. I would propose to say: The standard is agnostic with respect to the line break character (Windows, Unix, Mac). In general it is best practice to ignore simple line breaks and treat them simply as whitespace. To insert formatting, it is best practice to use simple html commands (<i></i>, <b></b>, <br/>, etc.). In xml transfer this is preferably transmitted in encoded form, i. e. as &lt;i&gt; to avoid creating mixed element content inside the description element. Gregor Hagedorn 11:59, 30 August 2010 (CEST) We should be careful about putting too many best practices here. Only when we differ from the namespace, and only when paramount for interoperability should be get into best practices within the standard itself (I feel). We should state instead that there should be a best practices document separate from this standard for over all TDWG terms. (or we can do one for MRTG specifically - LIFE has a good start with a 30 page document....)AnnetteOlson 23:07, 2 September 2010 (CEST) I think a bigger issue is whether we will or won't impose requirements on implementers. Doing so might be an imposition and might force conflicts with some decisions implementers make for compatability with something else. As I have often argued with Gregor, I am not a fan of putting rendering formats in data. They can make it impossible to actually render in cases where the rendering client is unable or unwilling to do something with the format. In my opinion, formatting is no business of MRTG normative standard, and we should either remain silent---as dcterms does---or warn against it. I prefer remaining silent and let providers bear the brunt of doing something that turns out to be client specific. If we make a separate advice to implementers, it should warn that they should remind users that formatting in client-independent ways is tricky. --BobMorris 16:42, 11 September 2010 (CEST) In the meeting of 17Sep2010, I think I prevailed in the position I took above. I've clarified it in the Definition but am open to further discussion or editing of the Definition. --BobMorris 03:47, 18 September 2010 (CEST)
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.
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).

Geography Vocabulary

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 may differ from the current location at which the specimen is held in a collection. In this case, LocationShown should exclusively refer to the location where a specimen was originally collected (gathering or sampling location). Use LocationCreated to express the location where the media was created (a specimen was digitized).

ReviewComment 19: 1.“where the original location differs from the current location at which the specimen is collected” should I assume be “where the original location may differ from the current location at which the specimen is held in a collection”

Response: I have adjusted wording in the Introduction per the suggestion. --BobMorris 22:09, 17 August 2010 (CEST)

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.
Name:	World Region
Normative URI:	http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/WorldRegion
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Name of a world region in some high level classification, such as names for continents, waterbodies, or island groups, whichever is most appropriate. The terms preferably are derived 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. The equivalent DarwinCore fields here forces primary metadata providers to classify world region terms into separate properties for “continent” “waterbody”, “IslandGroup”. By contract the Iptc4xmpExt vocabulary only specifies that a World Region is something at the top of a hierarchy of locations.
ReviewComments:	20. Clarify that World Region is meant to hold the name of the region rather than a category of region (which is one possible way to read what it says now).
Response:	* I have changed the wording, but the issue of what controlled vocabulary for categories remains. Should we be silent? Also, I cannot make sense of the Comments. Can someone edit into something clearer? --BobMorris 22:09, 17 August 2010 (CEST) I tried. Something got cut somewhen… Gregor Hagedorn 11:59, 30 August 2010 (CEST) The wording presently clarifies it per the reviewer's request. Maybe the comment is now confusing. I found only one instance of a use of WorldRegion on the web, and it had only continent names. Let's have a skype about the Comment. --BobMorris 19:37, 11 September 2010 (CEST) Attempted to clarify the Comments especially as to the difference with DwC. Also propose to strike out the remark about XMP. We should educate about that seperately. --BobMorris 03:34, 18 September 2010 (CEST)
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.
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.
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 subject of the media resource (e. g., species, habitats, or events) were located (if such information is available in separate fields).
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 of the media were located.
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 subjects (e. g., species, habitats, or events) were located.
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 of the location of the subjects, down to the village, forest, or geographic feature etc., below the city or other place name, 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 exception of country names etc., which can be separated into dwc:HigherGeography), and Sublocation in the sense of IPTC/XMP, i.e. the further details below a city or other place name, of a free-form text location within a fully hierarchically arranged grouping (earlier IPTC versions used “Location”, but this has been renamed as of 2008).

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

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.
Name:	Latitude
Normative URI:	dwc:verbatimLatitude
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Latitude as separate value; compare Geo-coordinates for further information.
Name:	Decimal Latitude
Normative URI:	dwc:decimalLatitude
	Layer: Core — Required: No — Repeatable: Yes
Definition:	Latitude as decimal separate value; Usage as defined at dwc:decimalLatitude.
Name:	Longitude
Normative URI:	dwc:verbatimLongitude
	Layer: Core — Required: No — Repeatable: No
Definition:	Longitude as separate value; compare Geo-coordinates for further information.
Name:	Decimal Longitude
Normative URI:	dwc:decimalLongitude
	Layer: Core — Required: No — Repeatable: No
Definition:	Longitude as separate decimal value; compare Geo-coordinates for further information.
ReviewComments:	23. Isn’t it worth simply stating at least that Decimal Latitude and Decimal Longitude should contain decimal coordinate values? The Decimal Longitude definition is (incorrectly) a verbatim repetition of the Longitude definition.
Response:	Fixed as suggested. --BobMorris 22:53, 17 August 2010 (CEST)
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.
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 values are those at http://code.google.com/p/darwincore/wiki/Location#verbatimCoordinateSystem
ReviewComments:	24. For Verbatim Coordinate System, are there recommended vocabularies to use?
Response:	I believe that there are official names for different coordinate systems, so a controlled vocabulary could be generated. We have not done so yet at LIFE - its a backburner item.AnnetteOlson 23:07, 2 September 2010 (CEST) DwC now takes a position on this, so I have referenced it in the Comments and am closing the issue. If anybody feels that the DwC values and comments should be copied here, please edit. --BobMorris 05:51, 12 September 2010 (CEST)
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.
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). Elevation is the position of the ground, not the position of camera. Often the difference will be negligible, where this is not the case the additional altitude of the camera or subject itself should be put in description.
ReviewComments:	25. You have Verbatim Elevation – did you also want an elevation in meters?
Response:	* My opinion is that we should, since dwc data may well have it, and when it is there, consuming apps don't have to parse units, which may vary wildly. In fact, a best practices document should encourage it. If nobody objects, I will add it. --BobMorris 22:53, 17 August 2010 (CEST) Specifying to leave the measurement unit away might result in a verbatim elevation in feet, with no indication that it is feet…, thus interpreted as meters. I think it is safer to recommend best practice of adding the unit. Also, I do not believe a verbatim elevation should contain a converted value, like “elevation 91.44 meters” Gregor Hagedorn 11:59, 30 August 2010 (CEST) I've changed my opinion. DwC is silent on the matter, hence so should we be. In the DwC googlecode site, they don't even presently discuss altitude, elevation, and depth. In the (obsolescent) wiki site, they give some examples, and we could use those too at some risk that the promised replacement of the wiki by the code site discussion will make the citation obscure. On the grounds of deferring to DwC practice, so I am closing the issue. Feel free to edit the Comments and/or reopen the issue. --BobMorris 06:06, 12 September 2010 (CEST) Glad y'all agree now - and I too! I agree that 1) we should not encourage the conversion of values, as precision is lost, 2) so we should recommending add the units; and 3) there should be best practices on the coding of the units (surely there's a list out there). Then good luck to those (or the machines) combining the data.... AnnetteOlson 20:45, 16 September 2010 (CEST) In terms of altitude versus elevation, Altitude includes elevation by definition. Elevation typically involves a point on the ground, but altitude is really just a vertical distance from a reference point (MSL) - so it can also correspond both to a ground elevation, or to the observer height. In most cases, as you said the difference would be neglible, and how users use these would vary. Very few users would record both ground elevation and camera altitude - it be either the first one (from maps) or the second one from an instrument. The first one would have precision off so much anyway (and we don't have a field for precision). So, to sum up my take on this: 1. Since altitude is the encompassing term, it should be given as the preferred measure. It should be used for both height and depth. A reference point needs to be given. Since we are global, the preferred reference point should be mean sea level, which we would need to state in the comments section. And altitude would need a minus for measurements of depth. 2. There should not then be a separate field for ground elevation, as that would be confusing to folks. And I don't want to see us add a precision field in here, or a separate units field - we could get too detailed here. and scare off too many users. fyi, LIFE hardly has anyone recording elevation - and nobody recording altitude - so far it is not a top prioirty to folks (though we're going to be working with water people here soon). 3. I think that we should just stick to Altitude and explain that ground elevation can be used in place, as long as indicated in text. Which answers the other point - I agree with Gregor about needing the ability to have text blocks in there. And finally, if test cases show a need for more refined information later, then that can be developed. AnnetteOlson 20:45, 16 September 2010 (CEST) At the meeting of 17Sep2010 it was decided that all mrtg terms relating to altitude, elevation, depth, be removed and replaced with a single statement listing the eight such terms in DwC and declaring them to be MRTG terms by inclusion. We could consider that for all the DwC Location terms perhaps except for making the distinction between Location Shown and LocationCreated--BobMorris 03:27, 18 September 2010 (CEST)

Temporal Coverage Vocabulary

Name:	Temporal Coverage
Normative URI:	dcterms:temporal
	Layer: Extended — Required: No — Repeatable: No
Definition:	The extent or scope of the content of the resource. Temporal coverage will typically include temporal period (a period label, date, or date range) to which the subjects of the media or media collection relate. If dates are mentioned, they should follow ISO 8601. When the resource is a Collection, this refers to the temporal coverage of the collection.
Comments:	Examples in English: "Jurassic", "Elizabethan", "Spring, 1957". 2008-01-01/2008-06-30. If the resource is video or audio, it refers to the time span, if any, depicted by the resource. For live-media this is closely related to Creation Date and time (Example: the time depicted by a time-lapse video file of organism development), but for media with fictional content it is not.
ReviewComments:	26. Clarify that Temporal Coverage presumably relates to collections and Original Date and Time to media resources?
Response:	Actually it doesn't. I have clarified language. Curiously, in our unrendered Discussion I speculated that the confusion might arise. As to Original Date and Time is also about the subject of the media, but is meant to disambiguate when the original of a derived resource was created. --BobMorris 23:07, 17 August 2010 (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 media 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 a photographic work of art including the same map as its content may give the date 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)
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.

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: 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.
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 to support broad classification of media items. 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: tha NASA Global Change Master Directory (GCMD) , K2N , the BioComplexity Thesaurus, and the European Environmental Agency GEneral Multilingual Environmental Thesaurus(GEMET) . The vocabulary may include major taxonomic groups (such as “vertebrates” or “fungi”) or ecosystem terms (“savannah”, “temperate rain forest”, “forest fires”, “aquatic vertebrates”). In the case where the unqualified terms from different vocabularies are homographs, the MRTG recommendation provides an 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.
ReviewComments:	27. Subject Category comments needs cleaning up.
Response:	The Comments field lacks references. We can all work on any of these we know. --BobMorris 15:58, 18 August 2010 (CEST) I don't know how to do footnotes here, so Bob, if you can add in for the Biocomplexity thesaurus the url: http://thesaurus.nbii.gov, under which a list of controlled vocabularies is also provided via the menu on the left (but the direct url sucks).AnnetteOlson 23:22, 2 September 2010 (CEST) Added citations. However, I don't know what we meen by "In the case where the unqualified terms from different vocabularies are homographs, the MRTG recommendation provides an order of preference for assigning terms to specific vocabularies." so I am leaving this open. --BobMorris 04:26, 18 September 2010 (CEST)
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 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.
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.

Taxonomic Coverage Vocabulary

Name:	Taxon 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 genus or higher, that covers all taxa that are the primary subject of the resource (which may be a media item or a collection).
Comments:	Example: Where the subject of an image is several species of ducks with trees visible in the background, Taxon Coverage would still be Anatidae (and not Biota). Example: “Aves” for a bird key or a bird image collection. Do not add a rank (“Class Aves”) in this field. Note that this somewhat expands the usage of ncd:taxonCoverage, which specifies at the Family level or higher. For collections it is recommended to follow ncd:taxonCoverage to avoid conflicts between a MRTG record and a record arising from NCD. If the resource contains a single taxon, this should be placed in Scientific Name. In this case Taxon Coverage may be left empty, but if not, care should be taken that the entries do not conflict. Example: If Scientific Name is Quercus alba then Taxon Coverage, if provided at all, should be Quercus.
ReviewComments:	28: “A higher taxon (e. g. a genus, family, or order) at the level of the family or higher” – are genera allowed or not? The Taxonomic Coverage comments seem to include “Lowest Common Taxon” as a synonym.
Response:	28. The intention is to include genera, and I have clarified that in the Comments. Also added a warning that this is a slight extension to NCD, but that restriction to Family should be followed for a collection object. -- Bob Agree. -- Gregor Replaced "Lowest Common Taxon" with "taxonCoverage". Separately: the recommendation to leave taxonCoverage empty if the resource contains only a single taxon fails to distinguish the case where coverage is a single taxon from the case where the coverage is unknown. This violates the implicit open world assumption of the normative schema (which, by the way, should perhaps be documented in the introduction). Comments? Suggestions? --BobMorris 20:29, 19 August 2010 (CEST) sorry, no. I see no real use case for a distinction between “unknown” and “discoverable”, or perhaps it just confuses me… Gregor Hagedorn 17:02, 30 August 2010 (CEST) I agree with Gregor AnnetteOlson 23:22, 2 September 2010 (CEST) Suppose one makes a query of the form "Return all records with taxonCoverage empty". From such a recordset one cannot conclude that the taxonCoverage for those records is indeed empty, because the recommendation is to leave it empty in case the coverage is exactly one taxon, which is to be found in ScientificName. If it is to be a requirement that the only way to determine if the coverage is indeed empty is to also query ScientificName, then this has to be part of the definition, not part of the Comments. Personally, I oppose tight coupling of two terms that have no deep semantic reason to be coupled. I think it will ultimately bite us in some way. But if someone wants to have a go at making the Definition unambiguous, I'll leave it open for further discussion. Anyway, even my position needs something added to the Discussion, e.g. the remark that the content of ScientificName may need to be repeated in the case that there is only one taxon. Yes, the same data in two places risks lowering robustness, but if the alternative is ambiguity so be it. --BobMorris 06:24, 12 September 2010 (CEST) Edited discussion per telecon of 17Sep2010. Closing, but feel free to improve description (in which case leave a note here). Still have the concerns above about empty content. --BobMorris 22:12, 17 September 2010 (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 term rather than here (i. e. “Abies cf. alba” is deprecated, to be replaced with Scientific Name = “Abies cf. alba” and Identification Qualifier = “cf.”).
ReviewComments:	30. Scientific Name raises the question of Identification Qualifier.
Response:	I agree we should add dwc:identificationQualifier and will do so barring objections. --BobMorris 20:29, 19 August 2010 (CEST) I agree adding identificationQualifier Gregor Hagedorn 17:02, 30 August 2010 (CEST) Done. --BobMorris 06:29, 12 September 2010 (CEST)
Name:	Identification Qualifier
Normative URI:	dwc:identificationQualifier
	Layer: Core — Required: No — Repeatable: Yes
Definition:	A brief phrase or a standard abbreviation ("cf. genus", "cf. species", "cf. var.", "aff. species", etc.) to express the determiner's doubts about the identification given in Scientific Name.
Comments:	Examples: 1) For the determinations “cf. Quercus agrifolia var. oxyadenia”, “Quercus cf. agrifolia var. oxyadenia”, “Quercus agrifolia cf. var. oxyadenia”, Scientific Name would always be “Quercus agrifolia var. oxyadenia”, with Identification Qualifier “cf. genus”, “cf. species” and “cf. var.”, respectively. For discussion of Darwin Core usage see http://code.google.com/p/darwincore/wiki/Identification
ReviewComments:	30. Scientific Name raises the question of Identification Qualifier.
Response:	Added Identification Qualifier. I've copied in the Definition and Comments from dwc:identificationQualifier but I must say they are written so that only a taxonomist would understand them. I don't. Should someone rephrase more friendly examples? Maybe then people could put in crosswalks. --BobMorris 17:39, 27 August 2010 (CEST) Adapted the comments. The Darwin core recommendations assume the presence of atomic taxon name parts, to make the property usable with combined Scientific names the vocabulary of the Identification Qualifier has to be changed relatively to DwC. However, since DwC allows “phrases”, this seems permissible. Gregor Hagedorn 17:02, 30 August 2010 (CEST)
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);'.
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".
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.
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.
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.
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)
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: No
Definition:	An exact or estimated number of taxa at the lowest applicable taxon rank (usually species or infraspecific) represented by the media resource (item or collection).
Comments:	Primarily intended for resource collections and singular resources dealing with sets of taxa (e. g., identification tools, videos). It is recommended to give an exact or estimated number of specific taxa when a complete list of taxa is not available or practical. The count should 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 on the side 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; taxon count would then indicate the known number of species in this interaction. This should be a single integer number. Leave the field empty if you cannot estimate the information (do not enter 0). Additional taxon counts at higher levels (e. g. how many families are covered by a digital Fauna) should be given verbatim in the resource description, not here.
ReviewComments:	31.Taxon Count seems rather problematic. I have images of several species in the genus Proteuxoa and many images not assigned to species in the same genus. Do I count the fully-identified species and add one for the genus? In many cases, this gets even messier. What is the use case for this element?
Response:	Removed the case of higher taxa (originally there were separate properties, the previous combination was an attempt to simplify. Now higher taxon counts referred to description free from text. Use case: identification tool “Key to Birds of Danube Delta”, or video “Birds of Danube Delta” with taxon count = 10 has greatly different utility than the same titles with taxon count = 250. Gregor Hagedorn 17:02, 30 August 2010 (CEST) I made some minor wording changes above, plus added in a follow-up to the multiple species statement (after the hyphen). Please doublecheck Gregor that I caught your meaning. AnnetteOlson 23:28, 2 September 2010 (CEST) Closing per discussion of today --BobMorris 18:53, 17 September 2010 (CEST)
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)
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.
ReviewComments:	32. For Sex, is it worth mentioning that GBIF has a vocabulary under development?
Response:	My feeling is that such information belongs in an ancillary "Release Notes" or an Applicability document, at least until such a vocabulary is in circulation. This document should only refer to widely available and preferably widely used vocabularies. Comments? --BobMorris 20:29, 19 August 2010 (CEST) I agree, having made similar comments earlier. AnnetteOlson 23:31, 2 September 2010 (CEST) I am closing this and hope and expect we will argue forcefully that this is not where best practices or applicability statements belong. If the Reviewer or the community is adamant, we can reconsider this position. This is an excellent example of the problem of putting stuff in the normative document, because practice will be quite different for plants and animals. --BobMorris 05:08, 15 September 2010 (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.
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.
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.

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. It is recommended that the Location Shown field above always be used when known. However, in the case of position data automatically recorded by the instrument (e. g. EXIF GPS data) Location Created should be used to maintain information accuracy. When one but not both of Location Shown and Location Created are present, MRTG is silent about whether the provided one entails the other. A best practices document for a particular MRTG implementation might address this.
ReviewComments:	33. The description of Location Created mentions “location shown” (which doesn’t seem to be a recommended element) – is there some distinction which MRTG metadata is expected to support in this context?
Response:	Yes, and it is documented in the original comments in the Geography Vocabulary Introduction, in Location Shown, and here. I have expanded the Comments here for further clarification, so committee should especially look that over. Also, is expansion needed in Location Shown? --BobMorris 20:29, 19 August 2010 (CEST) I am completely uncertain about the present form. I understand that in Iptc4xmpExt is a class having properties (like Geographic Coordinates, etc.), not a simple literal. I don’t understand whether this is clear here. Gregor Hagedorn 17:02, 30 August 2010 (CEST) This may need more thought. The Iptc documents refer to "basic datatype" as "structure" but I find no formal statement of what that might mean. There is some reference to the fact that the normative document doesn't take a position on representation, nor in this case does it take a position on what other attributes should form part of the structure of a LocationCreated or LocationShown. Do we need instead (in addtion?) a mrtg:VerbatimLocationCreated and mrtg:VerbatimLocationShown. --BobMorris 05:24, 15 September 2010 (CEST) Right now, Bob's new wording of the Comments field seems clear to me, but I haven't read the iptc....(and won't~ ;-))AnnetteOlson 23:31, 2 September 2010 (CEST) I have closed this since the ReviewComments are addressed by clarifying wording. Note however that it really should be in the same section as Location Shown. At the meeting of 17Sep2010 it was decided that Annette and Bob would rearrange terms in a more rational way. The fact that this is related to Location Shown is far more important than that it can often be provided by the imaging device automatically. We agreed that "Technical Metadata" as a name for things provided by the device is not a useful category, and will take it out during the rearrangement. --BobMorris 03:15, 18 September 2010 (CEST)
Name:	Date and Time Digitized
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:digitizationDate
	Layer: Extended — 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.
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: Extended — 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)".
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: Extended — 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.

Service Access Point Vocabulary

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

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.

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.
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.
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.
ReviewComments:	34. How do Service Access Point Variants relate to the use of pan-and-zoom image viewers?
Response:	* Excellent question. But I wonder if a pan-and-zoom object isn't a separate resource from any of its constituents, This goes to the question of whether MRTG metadata is about the resource, or the abstract object depicted in the resource. Our intent is the former, which to my mind suggests this means we need another recommended value for Type, perhaps "pan-and-zoom-image." In such a case, there might still be variants of the resource, just as for any other video. Comments? --BobMorris 20:29, 19 August 2010 (CEST) I agree with Bob: pan-and-zoom is a separate subtype interactive resource, having special properties that make it substantially different from a single image resource. I see it as a new form, like video to still-image. At least for pan-resources, different quality variants are quite conceivable (for zoom this is less likely, but it is still possible to have different depth of zoom made available under different access points or licenses). Gregor Hagedorn 17:02, 30 August 2010 (CEST) makes sense to me.AnnetteOlson 00:07, 3 September 2010 (CEST) I added " Also recommended are PanAndZoomImage , 3DStillImage, and 3DMovingImage." to the "Type" attribute. But an issue remains first raised by Steve Bauskauf in MRTGv08_Type_term_inconsistent_with_DwC. Some of that inconsistency has been resolved in DwC, but what still remains for us is that the particular vocabulary we (and dc) recommend is the names of classes from the dcmi type vocabulary. Are we there recommending a class, or just the name of a class? In the latter case, what do we mean by adding suggestion values to the dcmi type vocabulary? Does it matter? Do we need to add to the commentary in Type? In any case, I am closing this issue because any discussion belongs in Type. --BobMorris 05:59, 15 September 2010 (CEST)
Name:	Extent
Normative URI:	dcterms:extent
	Layer: Extended — Required: No — Repeatable: No
Definition:	The size, dimensions, or duration of the variant 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).
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: Extended — Required: No — Repeatable: No
Definition:	The URL of a Web site that provides additional information about (this version of) the media resource
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: Extended — Required: No — Repeatable: No
Definition:	The licensing statement for this variant of the media resource if different from that given in the “License Statement” property 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
Name:	Availability Exception
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: Extended — Required: No — Repeatable: No
Definition:	The availability statement for this variant of the media resource if different from that given in the Availability property of the resource
ReviewComments:	35. Explain “Availability Exception (see Key2Nature)”
Response:	Removed "(see Key2Nature)". --BobMorris 20:29, 19 August 2010 (CEST)
Name:	Variant 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:variantDescription
	Layer: Extended — Required: No — Repeatable: No
Definition:	Text that describes this Service Access Point variant

Related Resources Vocabulary

Name:	Containing Collection 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".
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".
ReviewComments:	36. The definition of Collection Member By ID is “A link” – not clear, and not supported by the examples given.
Response:	* The unrendered "Discussion" field reveals some confusion on our part too. Somebody want to attack this? --BobMorris 20:29, 19 August 2010 (CEST) I don’t understand this item. I propose to delete it. Was it meant as a discussion alternative to containingCollectionID? Gregor Hagedorn 17:02, 30 August 2010 (CEST) I think that, the way we have these fields titled, that "Containing Collection ID" is very confusing (it gives the impression that it this resource CONTAINS subcollections), and I think it should be renamed to MemberofCollectionID (not "by ID", as "by ID" implies that the method of relating is given the ID, not the collection; I think that most users do equate Resource ID, Collection ID okay), and that we only have one field, instead of two. There is no need to have a field that is just a link, since this is about IDs, not links. Alternatively, I do like Bob's suggestion of: How about "ID of Containing Collection" with another item "Name of Containing Collection", perhaps with the first being preferred. AnnetteOlson 00:07, 3 September 2010 (CEST) Also, The MRTG section header is confusing - what is meant by an ID must reference a collection ID?AnnetteOlson 00:07, 3 September 2010 (CEST)
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 Time-lapse series Different orientations/angles of view
Name:	Provider 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 current MRTG metadata record.
Comments:	Only to be used if the annotated resource is not a provider itself - 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. -
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 number, or URL.. Simple name of parent for human readable. Can be repeatedable if a montage of images.
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:	a 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.
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:	A reference to an observation associated with this resource.

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

---