Search by property

Jump to: navigation, search

This page provides a simple browsing interface for finding entities described by a property and a named value. Other available search interfaces include the page property search, and the ask query builder.

Search by property

A list of all pages that have property "terms-internal:enNote" with value "A person, an organization, or a service.". Since there have been only a few results, also nearby values are displayed.

Showing below up to 26 results starting with #1.

View (previous 50 | next 50) (20 | 50 | 100 | 250 | 500)


    

List of results

  • Iptc4xmpExt:City  + (<b>Audubon Core:</b> Optionall
    <b>Audubon Core:</b> 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. Note: URIs of IPTC terms for Adobe XMP terms are not resolvable. Visit [http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf IPTC Standard Photo Metadata (July 2010)] for further documentation.
    ta (July 2010)] for further documentation.)
  • xmp:MetadataDate  + (<b>Audubon Core:</b> Point in
    <b>Audubon Core:</b> 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 ([http://www.w3.org W3C]) [http://www.w3.org/TR/NOTE-datetime 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 [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40874 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 [http://en.wikipedia.org/wiki/ISO_8601 wikipedia IS0 8601 entry] for further explanation and examples. This is not dcterms:modified, which refers to the resource itself rather than its metadata. See also the [http://en.wikipedia.org/wiki/ISO_8601 wikipedia IS0 8601 entry] for further explanation and examples. Note: URIs of Adobe XMP terms are not resolvable. Visit [http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/XMPSpecificationPart1.pdf XMP Specification Part 1, Sec 8.4] for further documentation. XMP Schema is defined in RDF, not w3c schema.
    Schema is defined in RDF, not w3c schema.)
  • dcterms:temporal  + (<b>Audubon Core:</b> The cover
    <b>Audubon Core:</b> The coverage (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. 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.
    or media with fictional content it is not.)
  • dcterms:available  + (<b>Audubon Core:</b> The date
    <b>Audubon Core:</b> 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 ([http://www.w3.org W3C]) [http://www.w3.org/TR/NOTE-datetime 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 [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40874 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 [http://en.wikipedia.org/wiki/ISO_8601 wikipedia IS0 8601 entry] for further explanation and examples. A use case is the harvesting of metadata published before the media are available, which are pending a formal publication elsewhere. One important example is the case of metadata that documents an occurrence, which metadata harvesters might exploit without use of the media.See also the [http://en.wikipedia.org/wiki/ISO_8601 wikipedia IS0 8601 entry] for further explanation and examples.
    try] for further explanation and examples.)
  • xmp:CreateDate  + (<b>Audubon Core:</b> The date
    <b>Audubon Core:</b> 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 ([http://www.w3.org W3C]) [http://www.w3.org/TR/NOTE-datetime 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 [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40874 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 [http://en.wikipedia.org/wiki/ISO_8601 wikipedia IS0 8601 entry] for further explanation and examples. What constitutes "original" is determined by the metadata author. Example case: 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 in the Resource Creation Vocabulary. See also the [http://en.wikipedia.org/wiki/ISO_8601 wikipedia IS0 8601 entry] for further explanation and examples. Note: URIs of Adobe XMP terms are not resolvable. Visit [http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/XMPSpecificationPart1.pdf XMP Specification Part 1, Sec 8.4] for further documentation. XMP Schema is defined in RDF, not w3c schema.
    Schema is defined in RDF, not w3c schema.)
  • Iptc4xmpExt:CountryCode  + (<b>Audubon Core:</b> The geogr
    <b>Audubon Core:</b> The geographic location of the specific entity or entities documented by the media item, expressed through a constrained vocabulary of countries using 2-letter ISO country code (e. g. "it, si"). 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. Note: URIs of IPTC terms for Adobe XMP terms are not resolvable. Visit [http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf IPTC Standard Photo Metadata (July 2010)] for further documentation.
    ta (July 2010)] for further documentation.)
  • xmpRights:UsageTerms  + (<b>Audubon Core:</b> The licen
    <b>Audubon Core:</b> 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. 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, and “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 open access licenses. In general, this term determines the default licensing for the media. License terms specific to variants or representations of the media resource (e.g., different resolutions) are dealt within the [[Audubon Core Service Access Point Vocabulary]]. Note: URIs of Adobe XMP terms are not resolvable. Visit [http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/XMPSpecificationPart1.pdf XMP Specification Part 1, Sec 8.5] for further documentation. XMP Schema is defined in RDF, not w3c schema.
    Schema is defined in RDF, not w3c schema.)
  • dcterms:extent  + (<b>Audubon Core:</b> The size,
    <b>Audubon Core:</b> The size, dimensions, or duration of the variant of the media resource. 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).
    as file size (using kB, kByte, MB, MByte).)
  • dcterms:title  + (<b>Dublin Core:</b> A second p
    <b>Dublin Core:</b> A second property with the same name as this property has been declared in the dcterms: namespace (http://purl.org/dc/terms/). See the Introduction to the document "DCMI Metadata Terms" (http://dublincore.org/documents/dcmi-terms/) for an explanation. <b>Audubon Core:</b> 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. It is '''strongly''' suggested to provide a title for each media resource. The title facilitates interactions with humans: e.g. it 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 it is 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”).
    Pollinators of California Native Plants”).)
  • dcterms:description  + (<b>Dublin Core:</b> Descriptio
    <b>Dublin Core:</b> Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource. <b>Audubon Core:</b> 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 an AC 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. It optionally allows to present detailed information and will in most cases be shown together with the resource title. If both description and caption are present in the metadata, a description is typically displayed instead of the resource, a caption together with the resource. The description should aim to be a good text-proxy for the underlying media resource in cases where only text can be shown, whereas the caption may only make sense when shown together with the media. Often only one of description or caption is present; choose the concept most appropriate for your metadata.
    oncept most appropriate for your metadata.)
  • dcterms:creator  + (<b>Dublin Core:</b> Examples o
    <b>Dublin Core:</b> Examples of a Creator include a person, an organization, or a service. Equivalent property is http://xmlns.com/foaf/0.1/maker. <b>Audubon Core:</b> The person or organization responsible for creating the media resource. The value may be simple text including contact information. Note that the Creator need not be the Copyright Owner.
    e Creator need not be the Copyright Owner.)
  • dcterms:format  + (<b>Dublin Core:</b> Examples o
    <b>Dublin Core:</b> Examples of dimensions include size and duration. Recommended best practice is to use a controlled vocabulary such as the list of Internet Media Types [MIME]. <b>Audubon Core:</b> The technical format of the resource (file format or physical medium). 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 recommended: (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.
    print. Compare Type for the content-type.)
  • dcterms:identifier  + (<b>Dublin Core:</b> Recommende
    <b>Dublin Core:</b> Recommended best practice is to identify the resource by means of a string conforming to a formal identification system. <b>Audubon Core:</b> An arbitrary code that is unique for the resource, with the resource being either a provider, collection, or media item. 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, an lsid-URI, and a UUID-number). Required for media collections, No for media resources (but preferred if available). In context of GGBN used as gel image uri.
    In context of GGBN used as gel image uri.)
  • dcterms:source  + (<b>Dublin Core:</b> The descri
    <b>Dublin Core:</b> The described resource may be derived from the related resource in whole or in part. Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system. This term is intended to be used with non-literal values as defined in the DCMI Abstract Model (http://dublincore.org/documents/abstract-model/). As of December 2007, the DCMI Usage Board is seeking a way to express this intention with a formal range declaration. <b>Audubon Core:</b> An identifiable source from which the described resources was derived. If the resource (image, sound, movie, identification key, etc.) was digitized from a non-digital resource, or was also previously published in a digital or printed publication, this describes the original. Do not put generally "related" publications in here. This field normally contains a free-form text description, but it may be a URI (e.g. “digitally-published://ISBN=961-90008-7-0”) if that URI can be resolved and dereferenced to provide a description of the source resource. Can be repeatable if a montage of images. Information about further provenance beyond the ultimate source should be put in the ''ac:derivedFrom'' attribute.
    e put in the ''ac:derivedFrom'' attribute.)
  • dcterms:hasVersion  + (<b>Dublin Core:</b> This term
    <b>Dublin Core:</b> This term is intended to be used with non-literal values as defined in the DCMI Abstract Model (http://dublincore.org/documents/abstract-model/). As of December 2007, the DCMI Usage Board is seeking a way to express this intention with a formal range declaration.
    intention with a formal range declaration.)
  • dcterms:rights  + (<b>Dublin Core:</b> Typically,
    <b>Dublin Core:</b> Typically, rights information includes a statement about various property rights associated with the resource, including intellectual property rights. <b>Audubon Core:</b> Copyright Statement contains 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. Do not place just the name of the copyright holder(s) here! That belongs in a list in the xmpRights:Owner field, which should be supplied if dcterms:rights is not 'Public Domain', appropriate only if the resource is known to be not under copyright.
    source is known to be not under copyright.)
  • dcterms:references  + (<b>Dublin Core</b> This term i
    <b>Dublin Core</b> This term is intended to be used with non-literal values as defined in the DCMI Abstract Model (http://dublincore.org/documents/abstract-model/). As of December 2007, the DCMI Usage Board is seeking a way to express this intention with a formal range declaration.
    intention with a formal range declaration.)
  • xmpRights:WebStatement  + (<b>Extensible Metadata Platform (XMP
    <b>Extensible Metadata Platform (XMP):</b> This is a normal (non-URI) simple value because of historical usage. <b>Audubon Core:</b> A URL defining or further elaborating on the license statement (e. g., a web page explaining the precise terms of use). 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. Where different quality variants (e. g. resolutions of images) are published under different licenses, the AC term “Licensing Exception Statement” supports variant-specific licenses. Note: URIs of Adobe XMP terms are not resolvable. Visit [http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/XMPSpecificationPart1.pdf XMP Specification Part 1, Sec 8.5] for further documentation. XMP Schema is defined in RDF, not w3c schema.
    Schema is defined in RDF, not w3c schema.)
  • Iptc4xmpExt:LocationCreated  + (<b>IPTC Photo Metadata:</b> If
    <b>IPTC Photo Metadata:</b> If the location in the image is different from the location the photo was taken the [[Iptc4xmpExt:LocationShown|IPTC Extension property Location Shown]] in the Image should be used. <b>Audubon Core:</b> The location at which the media recording instrument was placed when the media was created. 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, AC is silent about whether the provided one entails the other. A best practices document for a particular AC implementation might address this. Note: URIs of IPTC terms for Adobe XMP terms are not resolvable. Visit [http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf IPTC Standard Photo Metadata (July 2010)] for further documentation.
    ta (July 2010)] for further documentation.)
  • Iptc4xmpExt:LocationShown  + (<b>IPTC Photo Metadata:</b> If
    <b>IPTC Photo Metadata:</b> If the location the image was taken in is different from this location the [[Iptc4xmpExt:LocationCreated|property Location Created]] should be used too. <b>Audubon Core:</b> The location that is depicted the media content, irrespective of the location at which the resource has been created.
    on at which the resource has been created.)
  • ac:variant  + (<br/> * Thumbnail: ServiceAccessPoin
    <br/> * Thumbnail: ServiceAccessPoint provides a thumbnail image, short sound clip, or short movie clip that can be used in addition to the resource 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 provide 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.
    t provides data about an offline resource.)
  • abcd2:EAnnotations  + (>Note that for annotation labels captured from the specimen there is the {{{SpecimenUnit/Marks}}} structure (AbcdConcept0561).)
  • tp:nomenclature-citation  + (A citation can be very detailed including
    A citation can be very detailed including all the elements of a nomenclatorial event, that is the original combination of the name, the original publication including often the page of publication, type specimen and its depository institution and current status. The citation can also be complemented by the indication that this particular taxon is being synonymized with the nominate taxon, its status is being changed, its being a homonym, or all of this happened in an earlier publication which is then followed by a complementary bibliographic reference. A citation can also be a reference to a so far unknown life form (eg. male, larvae), karyotype or chance of the status of type, such as the selection of a neotype or a lectotype.
    the selection of a neotype or a lectotype.)
  • rdfs:domain  + (A domain of the subject property.)
  • skos:notation  + (A notation is different from a lexical label in that a notation is not normally recognizable as a word or sequence of words in any natural language. By convention, skos:notation is used with a typed literal in the object position of the triple.)
  • rdfs:range  + (A range of the subject property.)
  • dc:title  + (A second property with the same name as this property has been declared in the dcterms: namespace (http://purl.org/dc/terms/). See the Introduction to the document "DCMI Metadata Terms" (http://dublincore.org/documents/dcmi-terms/) for an explanation.)
  • tp:taxon-treatment  + (A treatment can be anything from very shor
    A treatment can be anything from very short to very long.<br /> A treatment must have a nomenclature element and at least one of the following:<br /> * a citation list (<[[taxpub:nomenclature-citation-list | tp:nomenclature-citation-list]]>) * a citation of a nomencaltorial act or an earlier published record (<[[taxpub:nomenclature-citation | tp:nomenclature-citation]]>) * a text, commentary or key on the particular taxon (<[[taxpub:treatment-sec | tp:treatment-sec]]>)
    ub:treatment-sec | tp:treatment-sec]]>))
  • abcd2:Gathering-SpatialDatum  + (ABCD Workshop 1)
  • abcd2:Gathering-GridCellCode  + (ABCD Workshop 1<br/><br/>$$Wal
    ABCD Workshop 1<br/><br/>$$Walter$$ Please review the elements relating to coordinates when you get to it - some are missing information, and I have improvised at times (as here). (I know there are a few that are in the EURISCO doc you sent, which I still have to review)
    oc you sent, which I still have to review))
  • dcterms:accessRights  + (Access Rights may include information regarding access or restrictions based on privacy, security, or other policies.)
  • sandbox:accessRights  + (Access Rights may include information regarding access or restrictions based on privacy, security, or other policies.)
  • abcd2:SpecimenUnit-TypifiedName  + (An alternative solution to this unstructur
    An alternative solution to this unstructured element would be the use of the scientific name structure given under identification.<br/><br/>It has been suggested to treat the type assignation as a special case of identification. Although this is without doubt true, it would mean to introduce the entire typification structure to the identification structure (because more than on name may be directly typified by the same specimen). As nomeclatural types are only a subtype of specimens, and these are only a subtype of units, it was decided to assign the typified name in the specimen domain. If it is to be found by a normal name search, it should be repeated as an identified name under identifications.
    an identified name under identifications.)
  • dwc:measurementUnit  + (An explanation of the International System of Units can be found at http://physics.nist.gov/cuu/Units/.)
  • abcd2:TechnicalContact-@preferred  + (As a rule, the group of the "recommended" attribute should be set to the same as the corresponding element.)
  • skos:broader  + (Broader concepts are typically rendered as parents in a concept hierarchy (tree). By convention, skos:broader is only used to assert an immediate (i.e. direct) hierarchical link between two conceptual resources.)
  • skos:broaderTransitive  + (By convention, skos:broaderTransitive is n
    By convention, skos:broaderTransitive is not used to make assertions. Rather, the properties can be used to draw inferences about the transitive closure of the hierarchical relation, which is useful e.g. when implementing a simple query expansion algorithm in a search application.
    pansion algorithm in a search application.)
  • abcd2:Gathering-LocalityText  + (Clarification is needed as to whether this field includes the full locality information from the Continental level down, or just regional locality string excluding the higher level named areas or regions [JRC])
  • abcd2:Gathering-Country  + (Country names and ISO codes can theoretically be part of controlled enumerations but if included within the schema would blow it out to an unacceptable level; is it possible to refer to these lists externally with physically invoking them? [JRC])
  • ggbnvoc:Genetically Modified Organism  + (Currently a placeholder only, might be renamed in the future)
  • dwcattributes:abcdEquivalence  + (Currently mapped to ABCD 2.06b)
  • dcterms:Location  + (Darwin Core location terms can be grouped
    Darwin Core location terms can be grouped into three subcategories - geographic terms, verbatim coordinate terms, and georeference terms. ===Geographic Terms=== Geographic terms include * [[dwc:higherGeography]] * [[dwc:continent]] * [[dwc:countryCode]] * [[dwc:stateProvince]] * [[dwc:county]] * [[dwc:municipality]] A good reference for place names is the Getty Thesaurus of Geographic Names (TGN), which can be found at http://www.getty.edu/research/conducting_research/vocabularies/tgn/. Administrative boundary files can be obtained from the Global Administrative Areas (GADM) data set at http://biogeo.berkeley.edu/gadm/. MARC records for geographic names, including URIs, can be found at http://id.loc.gov/vocabulary/geographicAreas.html. ===Verbatim Coordinate Terms=== Verbatim coordinate terms include: * [[dwc:verbatimLatitude]] * [[dwc:verbatimLongitude]] * [[dwc:verbatimCoordinateSystem]] * [[dwc:verbatimSRS]] The terms beginning with verbatim are meant to capture the original record of the coordinates of the Location. verbatimCoordinates is meant to capture coordinates that have not or cannot be separated into the verbatimLatitude and verbatimLongitude. If the coordinates can be separated, they should be, since there is less chance to misinterpret the content. The verbatimCoordinateSystem and the verbatimSRS both refer to the values in verbatimLatitude and verbatimLongitude, or to the value in verbatimCoordinates. ===Georeference Terms=== * [[dwc:decimalLatitude]] * [[dwc:decimalLongitude]] * [[dwc:geodeticDatum]] * [[dwc:georeferenceProtocol]] * [[dwc:georeferenceVerificationStatus]] * [[dwc:footprintSRS]] Further detailed explanations of the terms associated with georeferences (spatial descriptions of place using points, circles, lines, polygons, etc.) can be found in the Guide to Best Practices for Georeferencing http://www.gbif.org/prog/digit/Georeferencing.
    ://www.gbif.org/prog/digit/Georeferencing.)
  • dcterms:date  + (Date may be used to express temporal information at any level of granularity. Recommended best practice is to use an encoding scheme, such as the W3CDTF profile of ISO 8601 [W3CDTF].)
  • dc:date  + (Date may be used to express temporal infor
    Date may be used to express temporal information at any level of granularity. Recommended best practice is to use an encoding scheme, such as the W3CDTF profile of ISO 8601 [W3CDTF]. A second property with the same name as this property has been declared in the dcterms: namespace (http://purl.org/dc/terms/). See the Introduction to the document "DCMI Metadata Terms" (http://dublincore.org/documents/dcmi-terms/) for an explanation.
    documents/dcmi-terms/) for an explanation.)
  • biorel:derived by descent from  + (Definition in RO: "d derived_by_descent_from a if d is specified by some genetic program that is sequence-inherited-from a genetic program that specifies a.")
  • dc:description  + (Description may include but is not limited
    Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource. A second property with the same name as this property has been declared in the dcterms: namespace (http://purl.org/dc/terms/). See the Introduction to the document "DCMI Metadata Terms" (http://dublincore.org/documents/dcmi-terms/) for an explanation.
    documents/dcmi-terms/) for an explanation.)
  • dwc:pointRadiusSpatialFit  + (Detailed explanations with graphical examples can be found in the "Guide to Best Practices for Georeferencing", Chapman and Wieczorek, eds. 2006.)
  • biorel:participates in  + (Do not use this term for spatial "participation".)
  • biorel:has participant  + (Do not use this term for spatial "participation".)
  • abcd2:PlantGeneticResourcesUnit-AncestralData  + (Example for transfer of EURISCO information to ABCD documentation.)