fix refs to ancillary doc; change italics to inline code

This commit is contained in:
Steve Baskauf 2018-09-26 22:13:24 -05:00
parent fa02fcd3d4
commit 2f9d30353c
1 changed files with 97 additions and 97 deletions

View File

@ -56,7 +56,7 @@ The RDF model itself is independent of any specific serialization syntax. The fo
![](rdf-graphical-example.png)
Each arrow represents a statement about the image, called a "triple" in RDF. The set of triples is called an RDF graph. Resources (represented by ovals) are identified by IRIs. The described resource (in this example the image http://bioimages.vanderbilt.edu/kirchoff/ac1490 at the tail of the arrow) is called the subject of the triple. Properties of the subject resource are identified by term IRIs shown here with their namespaces abbreviated (e.g., _dcterms:_ = "http://purl.org/dc/terms/"). The property is called the predicate of the triple. The values of the properties are called the object of the statement, with literal values (consisting of text) represented by rectangles.
Each arrow represents a statement about the image, called a "triple" in RDF. The set of triples is called an RDF graph. Resources (represented by ovals) are identified by IRIs. The described resource (in this example the image http://bioimages.vanderbilt.edu/kirchoff/ac1490 at the tail of the arrow) is called the subject of the triple. Properties of the subject resource are identified by term IRIs shown here with their namespaces abbreviated (e.g., ```dcterms:``` = "http://purl.org/dc/terms/"). The property is called the predicate of the triple. The values of the properties are called the object of the statement, with literal values (consisting of text) represented by rectangles.
This RDF graph can be serialized in a somewhat human-friendly syntax called Terse RDF Triple Language (Turtle) [[TURTLE](http://www.w3.org/TR/turtle/)]:
@ -90,7 +90,7 @@ In this document, the following formatting conventions will be used. Full IRIs w
http://bioimages.vanderbilt.edu/contact/kirchoff#coblea
```
Abbreviated UIRIs will be shown in _italics_ in the form _namespace:localName_, e.g., _rdf:type_. Namespace abbreviations when shown by themselves will also be shown in italics, e.g., _dwc:_ . Examples will be displayed in Courier type.
Abbreviated UIRIs will be shown as ```inline code``` in the form ```namespace:localName```, e.g., ```rdf:type```. Namespace abbreviations when shown by themselves will also be shown in italics, e.g., ```dwc:``` . Examples will be displayed in Courier type.
XML is a widely understood form of RDF serialization. Therefore, all examples given here will be shown as RDF/XML. In most cases, they will also be shown in Turtle. For more detailed information about RDF serialization, see part 3 of the Beginner's Guide to RDF [[RDF-BEGINNERS-GUIDE](http://code.google.com/p/tdwg-rdf/wiki/Beginners)] and the references cited there.
@ -140,7 +140,7 @@ Because RDF assumes no pre-existing agreement between data providers and consume
#### 1.4.2 Appropriate use of terms (normative)
Because of the machine-oriented nature of RDF, a provider must assume that a consuming client will not infer any meaning from a statement other than what is directly stated or what can be inferred logically from other statements made about the resources and terms involved in the statement. For example, a provider might use the name of a resource in a triple with the intention that the name represent the resource itself. However, if the term used as the predicate in the triple is designed to refer to resources themselves rather than names of resources, the client may fail to make the connection between the name and the resource itself. Depending on how the term is defined, the client may detect an inconsistency or draw unintended conclusions as described below. Inappropriate use of terms as RDF predicates can have unintended consequences because unlike text-based data transfer protocols, RDF is designed to allow clients to infer additional facts based on information contained in the definitions of the terms. For example, the definition of the term _foaf:depicts_ [[FOAF](http://xmlns.com/foaf/spec/)] contains a statement declaring its domain to be _foaf:Image_ . Thus a provider which describes a resource using a _foaf:depicts_ property is also implicitly (and perhaps unknowingly) declaring the resource to be an image. Terms which are defined using a form of RDF known as Web Ontology Language (OWL) [[OWL](http://www.w3.org/TR/owl2-overview/)] may have restrictions placed on their use. For example, declaring a term to be an _owl:ObjectProperty_ indicates that it is inconsistent for the value of that property to be a string literal (i.e., the value should be an IRI).
Because of the machine-oriented nature of RDF, a provider must assume that a consuming client will not infer any meaning from a statement other than what is directly stated or what can be inferred logically from other statements made about the resources and terms involved in the statement. For example, a provider might use the name of a resource in a triple with the intention that the name represent the resource itself. However, if the term used as the predicate in the triple is designed to refer to resources themselves rather than names of resources, the client may fail to make the connection between the name and the resource itself. Depending on how the term is defined, the client may detect an inconsistency or draw unintended conclusions as described below. Inappropriate use of terms as RDF predicates can have unintended consequences because unlike text-based data transfer protocols, RDF is designed to allow clients to infer additional facts based on information contained in the definitions of the terms. For example, the definition of the term ```foaf:depicts``` [[FOAF](http://xmlns.com/foaf/spec/)] contains a statement declaring its domain to be ```foaf:Image``` . Thus a provider which describes a resource using a ```foaf:depicts``` property is also implicitly (and perhaps unknowingly) declaring the resource to be an image. Terms which are defined using a form of RDF known as Web Ontology Language (OWL) [[OWL](http://www.w3.org/TR/owl2-overview/)] may have restrictions placed on their use. For example, declaring a term to be an ```owl:ObjectProperty``` indicates that it is inconsistent for the value of that property to be a string literal (i.e., the value should be an IRI).
For these reasons, terms should be used as predicates in RDF only after the data provider has carefully examined the documentation and usage guidelines associated with the vocabulary or ontology which defines the term and has determined that use of that term is consistent with the meaning which the provider intends to impart to the triple in which the term is to be used as a predicate.
@ -148,17 +148,17 @@ For more detailed information about the implications of using terms that have ra
#### 1.4.3 Use of Darwin Core terms in RDF (normative)
The general Darwin Core vocabulary, whose terms are in the _dwc:_ namespace (http://rs.tdwg.org/dwc/terms/), is designed primarily to facilitate the transfer of text-based records from relatively "flat" database tables. Because of this, the term recommendations associated with the general vocabulary suggest using text strings to refer to physical and conceptual entities, i.e., names to represent people, citations to represent articles, codes to represent institutions, etc. (The several kinds of roles intended for text strings are detailed in [Section 1.5](./index.htm#1.5_Roles_of_text_strings_as_values_of_properties_in_dwc:_namesp).) When a record has multiple values for a property, the general Darwin Core term definitions recommend that the multiple strings be concatenated and delineated in a single field to avoid forcing the creation of a more normalized data structure.
The general Darwin Core vocabulary, whose terms are in the ```dwc:``` namespace (http://rs.tdwg.org/dwc/terms/), is designed primarily to facilitate the transfer of text-based records from relatively "flat" database tables. Because of this, the term recommendations associated with the general vocabulary suggest using text strings to refer to physical and conceptual entities, i.e., names to represent people, citations to represent articles, codes to represent institutions, etc. (The several kinds of roles intended for text strings are detailed in [Section 1.5](./index.htm#1.5_Roles_of_text_strings_as_values_of_properties_in_dwc:_namesp).) When a record has multiple values for a property, the general Darwin Core term definitions recommend that the multiple strings be concatenated and delineated in a single field to avoid forcing the creation of a more normalized data structure.
However, in RDF, identification of physical and conceptual entities is generally accomplished by IRI references rather than literals. If there are multiple values for a property, each value should be referenced in a separate triple. Thus we face a situation where it is desirable in the context of RDF for certain DwC properties to be represented by one to many triples having non-literal (IRI reference) objects, while the actual definitions of the terms in the general DwC vocabulary which represent those properties specify that a single literal (text string) object be provided.
In a perfect world, all data providers wishing to serve RDF would immediately replace literal references to physical and conceptual resources (names, citations, codes, etc.) with IRI GUIDs that identify those resources and which are reused by other members of the community. However, it is more realistic to assume that at least initially many providers will have few (if any) GUIDs available to use as IRI references, so requiring non-literal resources to be referenced exclusively by IRIs would impede the exposure of data in the form of RDF. Therefore, it would be advantageous to provide an alternative set of DwC terms intended for use in RDF with IRI-referenced objects, while continuing to use the general DwC terms for literal objects where providers are unable to convert their existing (string) database fields to IRI references.
This guide introduces the namespace **_dwciri:_** (http://rs.tdwg.org/dwc/iri/) whose terms are intended for use with non-literal objects. If a term in the _dwciri:_ namespace has an analogue in the _dwc:_ namespace having the same local name, the _dwciri:_ term will have the same meaning as its _dwc:_ counterpart. For example, _dwciri:recordedBy_ has the same meaning as _dwc:recordedBy_, but as an RDF predicate _dwciri:recordedBy_ is intended to be repeatable and have an IRI-reference object. Providers whose databases include the field _dwc:recordedBy_ with records containing concatenated lists of names can publish those values immediately as single RDF triples using _dwc:recordedBy_ as the predicate and containing one literal object which is the concatenated list string. In this manner, publication of data as RDF can begin immediately using the _dwc:_ terms without the requirement that every resource have an assigned IRI GUID. As the community develops mechanisms for discovering and reusing IRIs, data providers can make the shift to _dwciri:_ terms. As a part of their data updating and cleaning process providers or aggregators may eventually parse the strings, search a community IRI repository, and match strings with existing IRIs or create new ones if they do not already exist.
This guide introduces the namespace **```dwciri:```** (http://rs.tdwg.org/dwc/iri/) whose terms are intended for use with non-literal objects. If a term in the ```dwciri:``` namespace has an analogue in the ```dwc:``` namespace having the same local name, the ```dwciri:``` term will have the same meaning as its ```dwc:``` counterpart. For example, ```dwciri:recordedBy``` has the same meaning as ```dwc:recordedBy```, but as an RDF predicate ```dwciri:recordedBy``` is intended to be repeatable and have an IRI-reference object. Providers whose databases include the field ```dwc:recordedBy``` with records containing concatenated lists of names can publish those values immediately as single RDF triples using ```dwc:recordedBy``` as the predicate and containing one literal object which is the concatenated list string. In this manner, publication of data as RDF can begin immediately using the ```dwc:``` terms without the requirement that every resource have an assigned IRI GUID. As the community develops mechanisms for discovering and reusing IRIs, data providers can make the shift to ```dwciri:``` terms. As a part of their data updating and cleaning process providers or aggregators may eventually parse the strings, search a community IRI repository, and match strings with existing IRIs or create new ones if they do not already exist.
#### 1.4.4 Limitations of this guide (non-normative)
This guide provides general guidance about how Darwin Core property terms should be used as RDF predicates and specifies that Darwin Core class terms should be used in _rdf:type_ declarations ([Section 2.3.1.5](./index.htm#2.3.1.5_Classes_to_be_used_for_type_declarations_of_resources_de)). However, the Darwin Core standard does not specify precisely which resources should be included as instances of its classes nor does it declare domains for its property terms. Although the Darwin Core Quick Reference Guide [[DWC-GUIDE](http://rs.tdwg.org/dwc/terms/index.htm)] suggests which properties might be applied to instances of classes by organizing those property terms under class headings, Darwin Core leaves specific decisions about type declaration and property assignment to community consensus. Some examples which show varying approaches to assigning resources to Darwin Core classes and connecting them with object properties defined outside Darwin Core are provided in the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://code.google.com/p/tdwg-rdf/wiki/DwCAncillary)].
This guide provides general guidance about how Darwin Core property terms should be used as RDF predicates and specifies that Darwin Core class terms should be used in ```rdf:type``` declarations ([Section 2.3.1.5](./index.htm#2.3.1.5_Classes_to_be_used_for_type_declarations_of_resources_de)). However, the Darwin Core standard does not specify precisely which resources should be included as instances of its classes nor does it declare domains for its property terms. Although the Darwin Core Quick Reference Guide [[DWC-GUIDE](http://rs.tdwg.org/dwc/terms/index.htm)] suggests which properties might be applied to instances of classes by organizing those property terms under class headings, Darwin Core leaves specific decisions about type declaration and property assignment to community consensus. Some examples which show varying approaches to assigning resources to Darwin Core classes and connecting them with object properties defined outside Darwin Core are provided in the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://github.com/tdwg/rdf/blob/master/DwCAncillary.md)].
### 1.5 Roles of text strings as values of properties in dwc: namespace (non-normative)
@ -166,7 +166,7 @@ When humans communicate in written language, they use strings of text characters
In text-based data transfer systems, text strings are the predominant means by which information is conveyed. It would be a relatively simple matter to simply “translate” existing Darwin Core text-based data into RDF by making every string value be the literal object of a predicate that is the Darwin Core property. But that would not result in RDF that conveys the kind of “meaning” that RDF was designed to impart.
Because text-based systems depend on predetermined understandings about the meanings of data fields, users are not forced to consider carefully the role that the string values are intended to play. However, in RDF one cannot assume that a client will “know what I mean” when a string is provided. For that reason, it is worth examining the kinds of meanings that we intend when we provide string values for Darwin Core properties in the _dwc:_ namespace.
Because text-based systems depend on predetermined understandings about the meanings of data fields, users are not forced to consider carefully the role that the string values are intended to play. However, in RDF one cannot assume that a client will “know what I mean” when a string is provided. For that reason, it is worth examining the kinds of meanings that we intend when we provide string values for Darwin Core properties in the ```dwc:``` namespace.
#### 1.5.1 Situations where a string is the standard means for encoding a resource (non-normative)
@ -178,7 +178,7 @@ Humans commonly use name strings to represent resources that are physical or con
#### 1.5.3 Situations where a string value serves as a keyword to enable searching (non-normative)
Imagine that a person identifies an oak tree as “Quercus alba”. The data associated with that identification may provide the property/value pair _dwc:scientificName_=”Quercus alba”. This implies that the person asserted that the tree was a representative of a taxon associated with the name _Quercus alba_. The data associated with the identification may also provide the property/value pair _dwc:order_=”Fagales”. One might think that this would imply that the person who asserted the identification also asserted that the tree was included in the order Fagales. However, it is likely that the person did not make such an assertion and in fact may have never even heard of the order Fagales. Rather, a database manager subscribing to a particular taxonomic hierarchy asserted that all identifications with a _dwc:scientificName_ value of “Quercus alba” should also have a property/value pair of dwc:order=”Fagales” in order to allow users of the database to search for identifications that were related because they shared the common value for that _dwc:order_ property.
Imagine that a person identifies an oak tree as “Quercus alba”. The data associated with that identification may provide the property/value pair ```dwc:scientificName```=”Quercus alba”. This implies that the person asserted that the tree was a representative of a taxon associated with the name ```Quercus alba```. The data associated with the identification may also provide the property/value pair ```dwc:order```=”Fagales”. One might think that this would imply that the person who asserted the identification also asserted that the tree was included in the order Fagales. However, it is likely that the person did not make such an assertion and in fact may have never even heard of the order Fagales. Rather, a database manager subscribing to a particular taxonomic hierarchy asserted that all identifications with a ```dwc:scientificName``` value of “Quercus alba” should also have a property/value pair of dwc:order=”Fagales” in order to allow users of the database to search for identifications that were related because they shared the common value for that ```dwc:order``` property.
The point is that in order to more accurately describe the real situation, there should be two separate sets of information: one which asserts that the person identified the tree as a representative of a taxon for which the scientific name “Quercus alba” is applied, and one which asserts the relationship between that taxa and higher taxa such as one to which the name “Fagales” is applied.
@ -188,7 +188,7 @@ A number of Darwin Core properties specify that their values should be an identi
#### 1.5.5 Implications for expressing Darwin Core string values as RDF (non-normative)
To facilitate achieving the clarity that RDF makes possible, this guide provides different approaches for each of these four situations in which string values are provided. In the first three situations, the existing term from Darwin Core namespace _dwc:_ can be used with a literal value to expose the string value as it currently exists in a text-based database. This allows for the rapid deployment of RDF described in [Section 1.4.3](./index.htm#1.4.3_Use_of_Darwin_Core_terms_in_RDF) and is all that is required in the first situation ([Section 1.5.1](./index.htm#1.5.1_Situations_where_a_string_is_the_standard_means_for_encodi)). In the second situation ([Section 1.5.2](./index.htm#1.5.2_Situations_where_a_string_value_serves_as_a_proxy_for_a_no)), analogues of the existing _dwc:_ terms have been created in the _dwciri:_ namespace which are intended to be used with IRI-references rather than names. In the third situation ([Section 1.5.3](./index.htm#1.5.3_Situations_where_a_string_value_serves_as_a_keyword_to_ena)), new _dwciri:_ terms have been created to relate subject resources to IRI-identified object resources which form part of a hierarchy. If such a hierarchy already exists, the need is eliminated for separate terms (“convenience terms”) which relate the subject resource to all parts of the hierarchy, although those terms can still be used if they are convenient for facilitating string searches. The last situation ([Section 1.5.4](./index.htm#1.5.4_Situations_where_a_string_value_serves_as_an_identifier)) is more complex and a significant part of the implementation guide is devoted to the ways in which RDF should be structured to handle various kinds of identifiers.
To facilitate achieving the clarity that RDF makes possible, this guide provides different approaches for each of these four situations in which string values are provided. In the first three situations, the existing term from Darwin Core namespace ```dwc:``` can be used with a literal value to expose the string value as it currently exists in a text-based database. This allows for the rapid deployment of RDF described in [Section 1.4.3](./index.htm#1.4.3_Use_of_Darwin_Core_terms_in_RDF) and is all that is required in the first situation ([Section 1.5.1](./index.htm#1.5.1_Situations_where_a_string_is_the_standard_means_for_encodi)). In the second situation ([Section 1.5.2](./index.htm#1.5.2_Situations_where_a_string_value_serves_as_a_proxy_for_a_no)), analogues of the existing ```dwc:``` terms have been created in the ```dwciri:``` namespace which are intended to be used with IRI-references rather than names. In the third situation ([Section 1.5.3](./index.htm#1.5.3_Situations_where_a_string_value_serves_as_a_keyword_to_ena)), new ```dwciri:``` terms have been created to relate subject resources to IRI-identified object resources which form part of a hierarchy. If such a hierarchy already exists, the need is eliminated for separate terms (“convenience terms”) which relate the subject resource to all parts of the hierarchy, although those terms can still be used if they are convenient for facilitating string searches. The last situation ([Section 1.5.4](./index.htm#1.5.4_Situations_where_a_string_value_serves_as_an_identifier)) is more complex and a significant part of the implementation guide is devoted to the ways in which RDF should be structured to handle various kinds of identifiers.
## 2 Implementation Guide
@ -216,11 +216,11 @@ GeoSciML Geologic Timescale model Ontology | gsml: | http://resource.geosciml.or
Virtual International Authority File | viaf: | http://viaf.org/viaf/
Extensible Metadata Platform Rights Management vocabulary | xmpRights: | http://ns.adobe.com/xap/1.0/rights/
For brevity, the examples do not include namespace declarations, nor an _rdf:RDF_ container element. If a user wishes to test or validate an example, insert it into the container element defined in [Section 2.1.2](./index.htm#2.1.2_Generating_graphical_diagrams_and_triple_tables_for_the_ex).
For brevity, the examples do not include namespace declarations, nor an ```rdf:RDF``` container element. If a user wishes to test or validate an example, insert it into the container element defined in [Section 2.1.2](./index.htm#2.1.2_Generating_graphical_diagrams_and_triple_tables_for_the_ex).
#### 2.1.2 Generating graphical diagrams and triple tables for the examples (non-normative)
The W3C RDF Validation Service [[W3C-RDF-VALIDATOR](http://www.w3.org/RDF/Validator/)] can be used to generate both a tabular listing and a graphical diagram of the triples that are included in the example XML serializations. Text from the examples can be placed inside the _rdf:RDF_ container element below, then pasted into the validator box to generate the desired output.
The W3C RDF Validation Service [[W3C-RDF-VALIDATOR](http://www.w3.org/RDF/Validator/)] can be used to generate both a tabular listing and a graphical diagram of the triples that are included in the example XML serializations. Text from the examples can be placed inside the ```rdf:RDF``` container element below, then pasted into the validator box to generate the desired output.
```rdf
<?xml version="1.0" encoding="UTF-8"?>
@ -273,7 +273,7 @@ Turtle
foaf:maker <http://viaf.org/viaf/9854560>.
```
The Dublin Core Metadata Initiative (DCMI) Abstract Model [[DCAM](http://dublincore.org/documents/abstract-model/)], which was designed to be compatible with RDF, describes subject resources using property-value pairs, which correspond to pairs of predicates and objects. When referring to Dublin Core terms (as well as Darwin Core, which is modeled on Dublin Core) "property" is used synonymously with "predicate" and "value" is used synonymously with "object". In Example 1, _foaf:maker_ is a property and _viaf:9854560_ is the value associated with that property. Predicates must be identified by IRIs. Objects of triples may be identified in three ways: 1) the object resource can be identified by an IRI reference, 2) the object can be identified by a non-IRI string, in which case it is called a literal, and 3) the object resource can also be left unidentified, in which case it is called a blank node or an anonymous node. Blank nodes are undesirable if it is important that other data providers be able to refer to the resource they represent. However, blank nodes may be preferable if external references to the resource are not relevant, or if the data provider is unable or unwilling to provide a stable IRI to identify the resource. IRI references and blank nodes can be the subjects of RDF triples, but literals cannot.
The Dublin Core Metadata Initiative (DCMI) Abstract Model [[DCAM](http://dublincore.org/documents/abstract-model/)], which was designed to be compatible with RDF, describes subject resources using property-value pairs, which correspond to pairs of predicates and objects. When referring to Dublin Core terms (as well as Darwin Core, which is modeled on Dublin Core) "property" is used synonymously with "predicate" and "value" is used synonymously with "object". In Example 1, ```foaf:maker``` is a property and ```viaf:9854560``` is the value associated with that property. Predicates must be identified by IRIs. Objects of triples may be identified in three ways: 1) the object resource can be identified by an IRI reference, 2) the object can be identified by a non-IRI string, in which case it is called a literal, and 3) the object resource can also be left unidentified, in which case it is called a blank node or an anonymous node. Blank nodes are undesirable if it is important that other data providers be able to refer to the resource they represent. However, blank nodes may be preferable if external references to the resource are not relevant, or if the data provider is unable or unwilling to provide a stable IRI to identify the resource. IRI references and blank nodes can be the subjects of RDF triples, but literals cannot.
### 2.2 Subject resources (normative)
@ -281,7 +281,7 @@ If the subject of an RDF triple is identified (i.e., not an anonymous node), it
#### 2.2.1 Identifying subject resources using IRIs (normative)
The _rdf:about_ attribute of the _rdf:Description_ element is used in RDF/XML to identify the subject of a triple:
The ```rdf:about``` attribute of the ```rdf:Description``` element is used in RDF/XML to identify the subject of a triple:
```rdf
<rdf:Description rdf:about="http://arctos.database.museum/guid/MVZ:Mamm:165861">
@ -289,7 +289,7 @@ The _rdf:about_ attribute of the _rdf:Description_ element is used in RDF/XML to
#### 2.2.2 Associating a string identifier with a subject resource (normative)
The Dublin Core term _dcterms:identifier_ should be used to associate a string literal identifier (e.g., UUID, "Darwin Core Triplet", or ARK) with an IRI-identified resource as shown here in RDF/XML:
The Dublin Core term ```dcterms:identifier``` should be used to associate a string literal identifier (e.g., UUID, "Darwin Core Triplet", or ARK) with an IRI-identified resource as shown here in RDF/XML:
```rdf
<dcterms:identifier>58D31D52-713D-44B4-9FE9-CB2D9249C422</dcterms:identifier>
@ -299,7 +299,7 @@ The Dublin Core term _dcterms:identifier_ should be used to associate a string l
<dcterms:identifier>ark:/12025/654xz321</dcterms:identifier>
```
If an HTTP IRI is considered to be the identifier for a subject resource, it is acceptable to present it as a string literal value for _dcterms:identifier_ in addition to using it in the _rdf:about_ attribute of the subject resource, as in Example 2:
If an HTTP IRI is considered to be the identifier for a subject resource, it is acceptable to present it as a string literal value for ```dcterms:identifier``` in addition to using it in the ```rdf:about``` attribute of the subject resource, as in Example 2:
**Example 2:**
@ -312,7 +312,7 @@ If an HTTP IRI is considered to be the identifier for a subject resource, it is
#### 2.2.3 Associating a URN with its HTTP-proxied equivalent (normative)
The TDWG LSID Applicability Statement standard [[GUID-STANDARD](http://www.tdwg.org/standards/150/)] specifies in Recommendation 30 that "The description of all objects identified by an LSID **must** contain an _owl:sameAs_, _owl:equivalentProperty_ or _owl:equivalentClass_ statement expressing the equivalence between the object identifier in its standard form and its proxy version". This is illustrated by Example 3:
The TDWG LSID Applicability Statement standard [[GUID-STANDARD](http://www.tdwg.org/standards/150/)] specifies in Recommendation 30 that "The description of all objects identified by an LSID **must** contain an ```owl:sameAs```, ```owl:equivalentProperty``` or ```owl:equivalentClass``` statement expressing the equivalence between the object identifier in its standard form and its proxy version". This is illustrated by Example 3:
**Example 3:**
@ -331,21 +331,21 @@ Turtle
owl:sameAs <urn:lsid:biocol.org:col:35115>.
```
Since LSIDs follow the URN IRI scheme, they can serve as the subject of any RDF triple. However, it is better to use the http-proxied form as the subject (i.e., the value of the _rdf:about_ attribute) in the description of the resource. See the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://code.google.com/p/tdwg-rdf/wiki/DwCAncillary)] for more information about implementing LSIDs.
Since LSIDs follow the URN IRI scheme, they can serve as the subject of any RDF triple. However, it is better to use the http-proxied form as the subject (i.e., the value of the ```rdf:about``` attribute) in the description of the resource. See the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://github.com/tdwg/rdf/blob/master/DwCAncillary.md)] for more information about implementing LSIDs.
This practice can be extended to any URN. For example, _owl:sameAs_ can be used to relate the URN <urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6> to its HTTP-proxied equivalent <http://provider.org/f81d4fae-7dec-11d0-a765-00a0c91e6bf6> in a manner analogous to Example 3.
This practice can be extended to any URN. For example, ```owl:sameAs``` can be used to relate the URN <urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6> to its HTTP-proxied equivalent <http://provider.org/f81d4fae-7dec-11d0-a765-00a0c91e6bf6> in a manner analogous to Example 3.
### 2.3 Predicates (normative)
Most terms in the Darwin Core vocabulary can be used as predicates in triples to represent properties of subject resources. The full term IRI must be used, although with an appropriate namespace declaration, the namespace can be abbreviated ([Section 2.1.1](./index.htm#2.1.1_Namespace_abbreviations_used_in_XML_qualified_names_(QName)). RDF does not restrict the source of predicates, therefore Darwin Core terms can be mixed with terms from other vocabularies. This includes the important predicate _rdf:type_ which is used to indicate the class of which the subject resource is an instance. There is no prohibition in RDF against repeating properties.
Most terms in the Darwin Core vocabulary can be used as predicates in triples to represent properties of subject resources. The full term IRI must be used, although with an appropriate namespace declaration, the namespace can be abbreviated ([Section 2.1.1](./index.htm#2.1.1_Namespace_abbreviations_used_in_XML_qualified_names_(QName)). RDF does not restrict the source of predicates, therefore Darwin Core terms can be mixed with terms from other vocabularies. This includes the important predicate ```rdf:type``` which is used to indicate the class of which the subject resource is an instance. There is no prohibition in RDF against repeating properties.
#### 2.3.1 Declaring the type of the resource (non-normative)
In RDF, a resource may be characterized by declaring that it is an instance of a class. Indicating that a resource is an instance of a class provides several benefits. It allows a consumer to narrow the results of a search by limiting the search to certain types of resources. It suggests to data providers what sorts of properties should be used to describe a resource. It allows consumers to anticipate what sorts of properties they might expect to be provided for that resource and allows developers to build applications that exploit those expectations. Because of these benefits, RDF provides several built-in mechanisms for asserting class membership, most notably the _rdf:type_ property [[RDF-TYPE](http://www.w3.org/TR/rdf-schema/#ch_type)] which is used to state that a resource is an instance of a class. There is nothing that prohibits assigning more than one _rdf:type_ property to a resource. In fact, there may be a benefit in describing a resource as a member of both a class which has specific meaning within a narrow community and a more well-known class which has a broader meaning and is therefore more likely to be understood by generic clients. For instance, a resource may be typed as both a _dwc:PreservedSpecimen_ and a _dcmitype:PhysicalObject_.
In RDF, a resource may be characterized by declaring that it is an instance of a class. Indicating that a resource is an instance of a class provides several benefits. It allows a consumer to narrow the results of a search by limiting the search to certain types of resources. It suggests to data providers what sorts of properties should be used to describe a resource. It allows consumers to anticipate what sorts of properties they might expect to be provided for that resource and allows developers to build applications that exploit those expectations. Because of these benefits, RDF provides several built-in mechanisms for asserting class membership, most notably the ```rdf:type``` property [[RDF-TYPE](http://www.w3.org/TR/rdf-schema/#ch_type)] which is used to state that a resource is an instance of a class. There is nothing that prohibits assigning more than one ```rdf:type``` property to a resource. In fact, there may be a benefit in describing a resource as a member of both a class which has specific meaning within a narrow community and a more well-known class which has a broader meaning and is therefore more likely to be understood by generic clients. For instance, a resource may be typed as both a ```dwc:PreservedSpecimen``` and a ```dcmitype:PhysicalObject```.
##### 2.3.1.1 rdf:type statement (normative)
The predicate _rdf:type_ is defined to have an object that is a class. The class should be identified by an IRI reference (not by a literal) as in Example 4:
The predicate ```rdf:type``` is defined to have an object that is a class. The class should be identified by an IRI reference (not by a literal) as in Example 4:
**Example 4:**
@ -366,7 +366,7 @@ Turtle:
     dcterms:created "2002-06-11T09:37:33"^^xsd:dateTime.
```
In Turtle serialization, _rdf:type_ can be abbreviated as "_a_" (Example 4). In XML serialization, the RDF specification provides an abbreviated way to specify the type of a described resource. This method is called a typed node element [[TYPED-NODE](http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-typed-nodes)]. The _rdf:Description_ element is replaced by an element whose name is an XML qualified name that identifies a class of which the described resource is an instance as in Example 5:
In Turtle serialization, ```rdf:type``` can be abbreviated as "```a```" (Example 4). In XML serialization, the RDF specification provides an abbreviated way to specify the type of a described resource. This method is called a typed node element [[TYPED-NODE](http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-typed-nodes)]. The ```rdf:Description``` element is replaced by an element whose name is an XML qualified name that identifies a class of which the described resource is an instance as in Example 5:
**Example 5:**
@ -375,23 +375,23 @@ In Turtle serialization, _rdf:type_ can be abbreviated as "_a_" (Example 4). In
</dcmitype:StillImage>
```
This example serializes the exact same two triples as Example 4. The _rdf:type_ triple is implied by the container element name.
This example serializes the exact same two triples as Example 4. The ```rdf:type``` triple is implied by the container element name.
##### 2.3.1.2 rdf:type assertion through domain and range declarations (normative)
The RDF Schema (RDFS) specification [[RDFS](http://www.w3.org/TR/rdf-schema/)] defines two terms that assert _rdf:type_ implicitly when certain predicates are used. When a predicate _P_ having the property
The RDF Schema (RDFS) specification [[RDFS](http://www.w3.org/TR/rdf-schema/)] defines two terms that assert ```rdf:type``` implicitly when certain predicates are used. When a predicate ```P``` having the property
```
P rdfs:domain C
```
is used to describe a subject resource, a client can infer that the subject resource is an instance of class _C_. For example, the term _dcterms:bibliographicCitation_ is assigned the property
is used to describe a subject resource, a client can infer that the subject resource is an instance of class ```C```. For example, the term ```dcterms:bibliographicCitation``` is assigned the property
```rdf
<rdfs:domain rdf:resource="http://purl.org/dc/terms/BibliographicResource"/>
```
in its definition. If that term were used as the property of a specimen, a client could infer that the specimen had _rdf:type_ _dcterms:BibliographicResource_:
in its definition. If that term were used as the property of a specimen, a client could infer that the specimen had ```rdf:type``` ```dcterms:BibliographicResource```:
**Example 6:**
@ -410,19 +410,19 @@ Turtle
     dcterms:bibliographicCitation "Ctenomys sociabilis (MVZ 165861)".
```
When a predicate _P_ having the property
When a predicate ```P``` having the property
```
P rdfs:range C
```
is used with a value, a client can infer that the value is an instance of class _C_. The term _dcterms:language_ is assigned the property
is used with a value, a client can infer that the value is an instance of class ```C```. The term ```dcterms:language``` is assigned the property
```rdf
<rdfs:range rdf:resource="http://purl.org/dc/terms/LinguisticSystem"/>
```
in its definition. If the object of that term in an RDF triple is a reference to the IRI for English assigned by the MARC ISO 639-2 Codes for the Representation of Names of Languages [[MARC-LANGUAGES](http://id.loc.gov/vocabulary/iso639-2)] (Example 7), then it can be inferred that http://id.loc.gov/vocabulary/iso639-2/eng is a _dcterms:LingisticSystem_ even though the MARC description in RDF does not assert that directly in its definition.
in its definition. If the object of that term in an RDF triple is a reference to the IRI for English assigned by the MARC ISO 639-2 Codes for the Representation of Names of Languages [[MARC-LANGUAGES](http://id.loc.gov/vocabulary/iso639-2)] (Example 7), then it can be inferred that http://id.loc.gov/vocabulary/iso639-2/eng is a ```dcterms:LingisticSystem``` even though the MARC description in RDF does not assert that directly in its definition.
**Example 7:**
@ -445,7 +445,7 @@ No terms defined within the Darwin Core namespace have range or domain declarati
##### 2.3.1.3 Explicit vs. inferred type declarations (normative)
Because the use of a predicate having a range or domain declaration implies the _rdf:type_ of a resource, data providers should exercise caution in using any such term in a non-standard way. For example, if the property _foaf:familyName_ were used with a specimen (e.g., to indicate the taxonomic family), that use would imply that the specimen was a _foaf:Person_ . However, it cannot be assumed that all clients will perform the reasoning necessary to infer the _rdf:type_ declarations implied by range and domain declarations. Therefore, if a data provider feels that it is important for a consumer to know that a resource is an instance of a particular class, the provider should type the resource using an explicit _rdf:type_ triple even if that asserts the same information that could be inferred from a domain or range declaration. For example, if providers of images want to assure that an image will be found in a query for resources having _rdf:type_ _foaf:Image_, they should not assume that describing the image using the property _foaf:depicts_ will accomplish that because of the range declaration of _foaf:depicts_. It would be safer to include
Because the use of a predicate having a range or domain declaration implies the ```rdf:type``` of a resource, data providers should exercise caution in using any such term in a non-standard way. For example, if the property ```foaf:familyName``` were used with a specimen (e.g., to indicate the taxonomic family), that use would imply that the specimen was a ```foaf:Person``` . However, it cannot be assumed that all clients will perform the reasoning necessary to infer the ```rdf:type``` declarations implied by range and domain declarations. Therefore, if a data provider feels that it is important for a consumer to know that a resource is an instance of a particular class, the provider should type the resource using an explicit ```rdf:type``` triple even if that asserts the same information that could be inferred from a domain or range declaration. For example, if providers of images want to assure that an image will be found in a query for resources having ```rdf:type``` ```foaf:Image```, they should not assume that describing the image using the property ```foaf:depicts``` will accomplish that because of the range declaration of ```foaf:depicts```. It would be safer to include
```rdf
<rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Image"/>
@ -457,11 +457,11 @@ in the description of the image. In fact, the provider would probably also want
<rdf:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
```
in the description so that clients searching for instances of either _foaf:Image_ or _dcmitype:StillImage_ class resources would find the image.
in the description so that clients searching for instances of either ```foaf:Image``` or ```dcmitype:StillImage``` class resources would find the image.
##### 2.3.1.4 Other predicates used to indicate type (normative)
Both the Dublin Core and Darwin Core define terms that can be used to describe the nature of a resource: _dcterms:type_ and _dwc:basisOfRecord_ respectively. However, using these terms to describe the nature of the subject resource is not a substitute for use of _rdf:type_. The DCMI notes on RDF semantics [[DC-RDF-SEMANTICS](http://dublincore.org/documents/dc-rdf/#sect-5)] recommend that "applications implementing this specification primarily use and understand _rdf:type_ in place of _dcterms:type_ when expressing Dublin Core metadata in RDF, as most RDF processors come with built-in knowledge of _rdf:type_." A similar argument could be made for the use of _rdf:type_ over _dwc:basisOfRecord_. Including _dc:type_, _dcterms:type_, and _dwc:basisOfRecord_ in an RDF description should be considered optional, while including _rdf:type_ should be considered highly recommended. A _dwciri:_ analogue ([Section 2.5](./index.htm#2.5_Terms_in_the_dwciri:_namespace)) of _dwc:basisOfRecord_ should not be used. Use _rdf:type_ instead when the object is an IRI reference. Here is an example that describes a specimen using several of the terms that define the nature of a resource explicitly, including multiple _rdf:type_ declarations:
Both the Dublin Core and Darwin Core define terms that can be used to describe the nature of a resource: ```dcterms:type``` and ```dwc:basisOfRecord``` respectively. However, using these terms to describe the nature of the subject resource is not a substitute for use of ```rdf:type```. The DCMI notes on RDF semantics [[DC-RDF-SEMANTICS](http://dublincore.org/documents/dc-rdf/#sect-5)] recommend that "applications implementing this specification primarily use and understand ```rdf:type``` in place of ```dcterms:type``` when expressing Dublin Core metadata in RDF, as most RDF processors come with built-in knowledge of ```rdf:type```." A similar argument could be made for the use of ```rdf:type``` over ```dwc:basisOfRecord```. Including ```dc:type```, ```dcterms:type```, and ```dwc:basisOfRecord``` in an RDF description should be considered optional, while including ```rdf:type``` should be considered highly recommended. A ```dwciri:``` analogue ([Section 2.5](./index.htm#2.5_Terms_in_the_dwciri:_namespace)) of ```dwc:basisOfRecord``` should not be used. Use ```rdf:type``` instead when the object is an IRI reference. Here is an example that describes a specimen using several of the terms that define the nature of a resource explicitly, including multiple ```rdf:type``` declarations:
**Example 8:**
@ -488,21 +488,21 @@ Turtle
     dwc:basisOfRecord "PreservedSpecimen".
```
Refer to [Sections 2.4.3](./index.htm#2.4.3_Object_resources_that_have_been_previously_represented_by) and [2.5](./index.htm#2.5_Terms_in_the_dwciri:_namespace) for an explanation of the distinction between terms in the _dc:_, _dcterms:_, _dwc:_, and _dwciri:_ namespaces.
Refer to [Sections 2.4.3](./index.htm#2.4.3_Object_resources_that_have_been_previously_represented_by) and [2.5](./index.htm#2.5_Terms_in_the_dwciri:_namespace) for an explanation of the distinction between terms in the ```dc:```, ```dcterms:```, ```dwc:```, and ```dwciri:``` namespaces.
##### 2.3.1.5 Classes to be used for type declarations of resources described using Darwin Core (normative)
The TDWG GUID Applicability Statement standard [[GUID-STANDARD](http://www.tdwg.org/standards/150/)] specifies that an object in the biodiversity domain that is identified by a GUID should be typed using a well-known vocabulary. With this recommendation in mind, it should be considered a best practice to provide information about the type (i.e., class membership) of any resource that is assigned a persistent identifier in the form of an IRI. Since Darwin Core is a well-known vocabulary and a ratified TDWG standard, its classes should be used for typing in preference to classes in parts of the TDWG ontology which are not ratified standards and are effectively deprecated. The human-readable definitions of the Darwin core classes provide guidance for deciding the types to assign to resources, although community consensus may be necessary to classify some of the more complex kinds of resources. ([Section 1.4.4](./index.htm#1.4.4_Limitations_of_this_guide))
Any Darwin Core class IRI may be used as a value for _rdf:type_, although it is not clear whether _dwc:ResourceRelationship_ instances make sense in the context of RDF. The following list summarizes classes included in the Dublin Core type vocabulary (but which are not part of Darwin Core) that should also be used for typing biodiversity-related resources:
Any Darwin Core class IRI may be used as a value for ```rdf:type```, although it is not clear whether ```dwc:ResourceRelationship``` instances make sense in the context of RDF. The following list summarizes classes included in the Dublin Core type vocabulary (but which are not part of Darwin Core) that should also be used for typing biodiversity-related resources:
_dcmitype:StillImage_
```dcmitype:StillImage```
_dcmitype:MovingImage_
```dcmitype:MovingImage```
_dcmitype:Sound_
```dcmitype:Sound```
_dcmitype:PhysicalObject_
```dcmitype:PhysicalObject```
### 2.4 Object resources (non-normative)
@ -545,7 +545,7 @@ Turtle
     dwc:coordinateUncertaintyInMeters "20"^^xsd:int.
```
If the string expresses information in a particular language, a provider should include an _xml:lang_ attribute [[XML-LANG](http://www.w3.org/TR/REC-xml/#sec-lang-tag)] to indicate the language of the string through the RFC 4646 language code [[LANG-CODES](http://www.ietf.org/rfc/rfc4646.txt)] for that language. In addition to specifying the language of the string, providing a language tag entails that the described resource has the type _rdf:langString_.
If the string expresses information in a particular language, a provider should include an ```xml:lang``` attribute [[XML-LANG](http://www.w3.org/TR/REC-xml/#sec-lang-tag)] to indicate the language of the string through the RFC 4646 language code [[LANG-CODES](http://www.ietf.org/rfc/rfc4646.txt)] for that language. In addition to specifying the language of the string, providing a language tag entails that the described resource has the type ```rdf:langString```.
**Example 10:**
@ -566,23 +566,23 @@ Turtle
                                   "S. Claramunt, et al. 2009. Polifilia de Campylorhamphus y la Descripción de un Nuevo Género para C. pucherani (Dendrocolaptinae). The Awk 127(2):430-439."@es.
```
In the RDF 1.1 specification, datatype D-entailment is a direct extension to basic RDF. [[RDF-DATATYPE-SEMANTICS](http://www.w3.org/TR/rdf11-mt/#literals-and-datatypes)] The specification establishes that literals without explicit datatype attributes or language tags have an implicit datatype _xsd:string_. That also entails that the _rdf:type_ of those literals is _xsd:string_ [[RDF-ENTAILMENT-RULES](http://www.w3.org/TR/rdf11-mt/#entailment-rules-informative)]. The practical implication of this is that literals that are exposed without datatype attributes or language tags should be interpreted by clients to be a sequence of characters, and not some other abstract or non-information resource that a human might interpret the sequence of characters to represent. This has practical implications in [Section 2.4.3](./index.htm#2.4.3_Object_resources_that_have_been_previously_represented_by) (where untyped literals are value strings intended to represent non-literal resources) and [Section 2.7](./index.htm#2.7_Darwin_Core_convenience_terms) (where untyped literals provide a convenient means for facilitating string-based searches). Although it is likely that many providers may initially choose to expose literals without datatype attributes, they should move towards replacing them with URIs or datatyped literals that accurately represent the type and properties of the resource that the untyped literals are intended to represent.
In the RDF 1.1 specification, datatype D-entailment is a direct extension to basic RDF. [[RDF-DATATYPE-SEMANTICS](http://www.w3.org/TR/rdf11-mt/#literals-and-datatypes)] The specification establishes that literals without explicit datatype attributes or language tags have an implicit datatype ```xsd:string```. That also entails that the ```rdf:type``` of those literals is ```xsd:string``` [[RDF-ENTAILMENT-RULES](http://www.w3.org/TR/rdf11-mt/#entailment-rules-informative)]. The practical implication of this is that literals that are exposed without datatype attributes or language tags should be interpreted by clients to be a sequence of characters, and not some other abstract or non-information resource that a human might interpret the sequence of characters to represent. This has practical implications in [Section 2.4.3](./index.htm#2.4.3_Object_resources_that_have_been_previously_represented_by) (where untyped literals are value strings intended to represent non-literal resources) and [Section 2.7](./index.htm#2.7_Darwin_Core_convenience_terms) (where untyped literals provide a convenient means for facilitating string-based searches). Although it is likely that many providers may initially choose to expose literals without datatype attributes, they should move towards replacing them with URIs or datatyped literals that accurately represent the type and properties of the resource that the untyped literals are intended to represent.
[Section 3.4](./index.htm#3.4_Terms_defined_by_Darwin_Core_that_are_expected_to_be_used_on) indicates which Darwin Core terms would be appropriately used with values having datatype or language attributes.
##### 2.4.1.2 Terms intended for use with literal objects (normative)
The definitions of some terms make it clear that they should be used with literal objects. Darwin Core specifically "imports" several Dublin Core terms [[DC-TERMS](http://dublincore.org/documents/DC-TERMS/)] into its vocabulary for use in describing biodiversity data. In some cases, terms in the _dcterms:_ namespace have range declarations of _rdfs:Literal_ and are therefore understood to be intended for use with literal objects (strings). In some vocabularies, certain terms are required to have literal objects because in their definitions they are declared to be _owl:Datatype_ properties. In the case of Darwin Core terms in the _dwc:_ (http://rs.tdwg.org/dwc/terms/) namespace, the normative term definitions in RDF do not include any declarations that indicate whether the terms should be used with literal or IRI reference objects. (Exceptions to this are the various date-related terms, which inherit the range _rdfs:Literal_ because they are _rdfs:subPropertyOf_ _dcterms:date_.) However, because the _dwc:_ terms were originally designed to accommodate text and XML data transfer, their definitions generally specify how term values should be expressed as string literals. This guide establishes the convention that terms in the _dwc:_ namespace should be restricted to use with literal objects so that their use in RDF will be consistent with their definitions. As discussed in [Section 1.4.3](./index.htm#1.4.3_Use_of_Darwin_Core_terms_in_RDF) and [Section 2.5](./index.htm#2.5_Terms_in_the_dwciri:_namespace), this guide introduces a separate namespace http://rs.tdwg.org/dwc/iri/ (abbreviated as _dwciri:_) for additional Darwin Core terms which are intended to have objects that are IRI references.
The definitions of some terms make it clear that they should be used with literal objects. Darwin Core specifically "imports" several Dublin Core terms [[DC-TERMS](http://dublincore.org/documents/DC-TERMS/)] into its vocabulary for use in describing biodiversity data. In some cases, terms in the ```dcterms:``` namespace have range declarations of ```rdfs:Literal``` and are therefore understood to be intended for use with literal objects (strings). In some vocabularies, certain terms are required to have literal objects because in their definitions they are declared to be ```owl:Datatype``` properties. In the case of Darwin Core terms in the ```dwc:``` (http://rs.tdwg.org/dwc/terms/) namespace, the normative term definitions in RDF do not include any declarations that indicate whether the terms should be used with literal or IRI reference objects. (Exceptions to this are the various date-related terms, which inherit the range ```rdfs:Literal``` because they are ```rdfs:subPropertyOf``` ```dcterms:date```.) However, because the ```dwc:``` terms were originally designed to accommodate text and XML data transfer, their definitions generally specify how term values should be expressed as string literals. This guide establishes the convention that terms in the ```dwc:``` namespace should be restricted to use with literal objects so that their use in RDF will be consistent with their definitions. As discussed in [Section 1.4.3](./index.htm#1.4.3_Use_of_Darwin_Core_terms_in_RDF) and [Section 2.5](./index.htm#2.5_Terms_in_the_dwciri:_namespace), this guide introduces a separate namespace http://rs.tdwg.org/dwc/iri/ (abbreviated as ```dwciri:```) for additional Darwin Core terms which are intended to have objects that are IRI references.
#### 2.4.2 Non-literal object resources (normative)
Resources that are physical or conceptual often cannot be intrinsically represented as string literals and if identified, they are referenced in RDF by IRIs. Digital resources (e.g., images, web pages, etc.) could be represented as literals (the encoded content of the resource), but because many characters would be required to do that, they are usually referenced as independent entities through IRIs. In RDF/XML an IRI reference to a non-literal object can be made using the attribute _rdf:resource_ in an empty XML element:
Resources that are physical or conceptual often cannot be intrinsically represented as string literals and if identified, they are referenced in RDF by IRIs. Digital resources (e.g., images, web pages, etc.) could be represented as literals (the encoded content of the resource), but because many characters would be required to do that, they are usually referenced as independent entities through IRIs. In RDF/XML an IRI reference to a non-literal object can be made using the attribute ```rdf:resource``` in an empty XML element:
```rdf
<dcterms:rightsHolder rdf:resource="http://biocol.org/urn:lsid:biocol.org:col:15666"/>
```
A description of the referenced non-literal object may be found within the same document, among data from another provider, or there may be no description of the object. If the RDF document will describe further properties of the non-literal, IRI-identified resource, those properties can be placed within an _rdf:Description_ container element having an _rdf:about_ attribute whose value is the IRI of the resource:
A description of the referenced non-literal object may be found within the same document, among data from another provider, or there may be no description of the object. If the RDF document will describe further properties of the non-literal, IRI-identified resource, those properties can be placed within an ```rdf:Description``` container element having an ```rdf:about``` attribute whose value is the IRI of the resource:
**Example 11:**
@ -593,7 +593,7 @@ A description of the referenced non-literal object may be found within the same
<dcterms:rightsHolder>
```
If the non-literal object is not identified by an IRI (i.e., it is a blank node), its properties can be placed within an _rdf:Description_ container element that has no _rdf:about_ attribute and which is itself within a container element for the property:
If the non-literal object is not identified by an IRI (i.e., it is a blank node), its properties can be placed within an ```rdf:Description``` container element that has no ```rdf:about``` attribute and which is itself within a container element for the property:
**Example 12:**
@ -665,7 +665,7 @@ the rights holder object IRI is managed by an institution other than the image o
###### 2.4.2.1.1 Objects identified by LSIDs (normative)
In the previous example, the HTTP IRI used as the object of the _dcterms:rightsHolder_ property was an HTTP-proxied form of an LSID. Because an LSID is a URN and therefore a type of IRI, the RDF specification does not prohibit the use of an LSID as an IRI referenced object. However, the TDWG LSID Applicability Guide standard dictates that LSIDs must not be used as the object of RDF triples (Recommendation 31 of [[GUID-STANDARD](http://www.tdwg.org/standards/150/)]) because a client would not necessarily be able to dereference the LSID to discover additional information about the object resource. The HTTP-proxied version of the LSID should be used instead (see [Section 2.2.3](./index.htm#2.2.3_Associating_a_URN_with_its_HTTP-proxied_equivalent)). See the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://code.google.com/p/tdwg-rdf/wiki/DwCAncillary)] for more information about using LSIDs in RDF.
In the previous example, the HTTP IRI used as the object of the ```dcterms:rightsHolder``` property was an HTTP-proxied form of an LSID. Because an LSID is a URN and therefore a type of IRI, the RDF specification does not prohibit the use of an LSID as an IRI referenced object. However, the TDWG LSID Applicability Guide standard dictates that LSIDs must not be used as the object of RDF triples (Recommendation 31 of [[GUID-STANDARD](http://www.tdwg.org/standards/150/)]) because a client would not necessarily be able to dereference the LSID to discover additional information about the object resource. The HTTP-proxied version of the LSID should be used instead (see [Section 2.2.3](./index.htm#2.2.3_Associating_a_URN_with_its_HTTP-proxied_equivalent)). See the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://github.com/tdwg/rdf/blob/master/DwCAncillary.md)] for more information about using LSIDs in RDF.
##### 2.4.2.2 Objects which are blank (anonymous) nodes (non-normative)
@ -696,11 +696,11 @@ Turtle
                         dc:creator "Joe Curator"].
```
the described subject resource refers to an object resource that is not identified with an IRI, that is, an object resource represented by a blank node. From the properties of the unidentified resource we know that the object resource is a _foaf:Document_ from 2003 entitled "Collection notes" and created by Joe Curator. By using a blank node to represent the resource, the properties of that resource can be described and collectively associated with the _dcterms:references_ property without requiring the data provider to mint an IRI for that resource. The data provider may feel that there is no need for another provider to refer to that resource, or the provider may be unwilling or unable to maintain a separate identifier for the resource. For example, in Example 12, the data provider may not have had access to an IRI identifier for the Trustees of the University of Lavonia and might not be interested in taking on the job of assigning one. At some future point, the provider could replace the blank node with an IRI reference if an IRI for the Trustees of the University of Lavonia were discovered.
the described subject resource refers to an object resource that is not identified with an IRI, that is, an object resource represented by a blank node. From the properties of the unidentified resource we know that the object resource is a ```foaf:Document``` from 2003 entitled "Collection notes" and created by Joe Curator. By using a blank node to represent the resource, the properties of that resource can be described and collectively associated with the ```dcterms:references``` property without requiring the data provider to mint an IRI for that resource. The data provider may feel that there is no need for another provider to refer to that resource, or the provider may be unwilling or unable to maintain a separate identifier for the resource. For example, in Example 12, the data provider may not have had access to an IRI identifier for the Trustees of the University of Lavonia and might not be interested in taking on the job of assigning one. At some future point, the provider could replace the blank node with an IRI reference if an IRI for the Trustees of the University of Lavonia were discovered.
#### 2.4.3 Object resources that have been previously represented by literals but which are actually non-literal resources (non-normative)
In databases the names of entities have frequently been used to represent the entities themselves. For example, the name of a person is often used as a proxy for the person, or an abbreviation for a language has been used to represent the language itself. Prior to the creation of the DCMI Abstract Model, many data which were described using terms in the legacy Dublin Core namespace _dc:_ (http://purl.org/dc/elements/1.1/) followed the historical practice of using the name of an entity to represent a non-literal entity. Extending this practice to RDF would result in representations such as this:
In databases the names of entities have frequently been used to represent the entities themselves. For example, the name of a person is often used as a proxy for the person, or an abbreviation for a language has been used to represent the language itself. Prior to the creation of the DCMI Abstract Model, many data which were described using terms in the legacy Dublin Core namespace ```dc:``` (http://purl.org/dc/elements/1.1/) followed the historical practice of using the name of an entity to represent a non-literal entity. Extending this practice to RDF would result in representations such as this:
**Example 17:**
@ -723,7 +723,7 @@ However, over time, the community of RDF users has come to consider it a best pr
##### 2.4.3.1 Literal values for non-literal resources in Dublin Core (normative)
The introduction of the DCMI Abstract Model (DCAM) and subsequent guidelines for the use of Dublin Core terms in RDF [[DC-RDF](http://dublincore.org/documents/dc-rdf/#sect-4)] were intended to clarify the use of Dublin Core terms with literal and non-literal objects [[DC-RDF-NOTES](http://dublincore.org/documents/2008/01/14/dc-rdf-notes/#sect-3)]. In particular, ranges were declared for terms in the _dcterms:_ namespace (http://purl.org/dc/terms/) with the intention of clarifying whether each term was intended for use with a literal or a non-literal value. For example, _dcterms:bibliographicCitation_ has the range _rdfs:Literal_, while _dcterms:creator_ has range _dcterms:Agent_. Because the term _dcterms:creator_ has a non-literal range, it should be used with an object that is an IRI reference as illustrated in the following example:
The introduction of the DCMI Abstract Model (DCAM) and subsequent guidelines for the use of Dublin Core terms in RDF [[DC-RDF](http://dublincore.org/documents/dc-rdf/#sect-4)] were intended to clarify the use of Dublin Core terms with literal and non-literal objects [[DC-RDF-NOTES](http://dublincore.org/documents/2008/01/14/dc-rdf-notes/#sect-3)]. In particular, ranges were declared for terms in the ```dcterms:``` namespace (http://purl.org/dc/terms/) with the intention of clarifying whether each term was intended for use with a literal or a non-literal value. For example, ```dcterms:bibliographicCitation``` has the range ```rdfs:Literal```, while ```dcterms:creator``` has range ```dcterms:Agent```. Because the term ```dcterms:creator``` has a non-literal range, it should be used with an object that is an IRI reference as illustrated in the following example:
**Example 18:**
@ -741,11 +741,11 @@ Turtle
<http://dbpedia.org/resource/Starry_night>dcterms:creator <http://viaf.org/viaf/9854560>.
```
The Dublin Core RDF guidelines [[DC-RDF](http://dublincore.org/documents/dc-rdf/#sect-4)] provided a mechanism using the term _rdf:value_ to permit legacy string literal data to be associated with Dublin Core terms in the _dcterms:_ namespace that were not intended for use with literal objects. Using this mechanism, a non-literal resource could be represented by a blank node having an _rdf:value_ property whose value was the legacy string literal. This value is known as a “value string”. However, the mechanism which involves using _rdf:value_ as a predicate has not been widely implemented. At the time when the _dcterms:_ terms were defined, terms in the _dc:_ namespace were left without range declarations. Thus it has been considered acceptable to use the _dc:_ namespace terms with legacy string literals (i.e., value strings) as shown in Example 15 [[DC-LINKED-DATA](http://wiki.dublincore.org/index.php/User_Guide/Publishing_Metadata#Legacy_namespace)]. Many providers of non-RDF data may have used literal values for terms in the _dcterms:_ namespace that have non-literal ranges. Note that all terms in the _dcterms:_ namespace that have corresponding terms in the _dc:_ namespace (i.e., terms with identical local names sensu [[RDF-VOCAB-PUB](http://www.w3.org/TR/swbp-vocab-pub/#naming)]) are declared to be _rdfs:subPropertyOf_ those _dc:_ namespace terms [[DC-SUBPROPERTIES](http://dublincore.org/usage/decisions/2008/dcterms-changes/#sect-2)]. So if a data provider's non-RDF database contains string values for terms in the _dcterms:_ namespace having non-literal ranges, it is appropriate to expose those literals in RDF as values of corresponding _dc:_ terms.
The Dublin Core RDF guidelines [[DC-RDF](http://dublincore.org/documents/dc-rdf/#sect-4)] provided a mechanism using the term ```rdf:value``` to permit legacy string literal data to be associated with Dublin Core terms in the ```dcterms:``` namespace that were not intended for use with literal objects. Using this mechanism, a non-literal resource could be represented by a blank node having an ```rdf:value``` property whose value was the legacy string literal. This value is known as a “value string”. However, the mechanism which involves using ```rdf:value``` as a predicate has not been widely implemented. At the time when the ```dcterms:``` terms were defined, terms in the ```dc:``` namespace were left without range declarations. Thus it has been considered acceptable to use the ```dc:``` namespace terms with legacy string literals (i.e., value strings) as shown in Example 15 [[DC-LINKED-DATA](http://wiki.dublincore.org/index.php/User_Guide/Publishing_Metadata#Legacy_namespace)]. Many providers of non-RDF data may have used literal values for terms in the ```dcterms:``` namespace that have non-literal ranges. Note that all terms in the ```dcterms:``` namespace that have corresponding terms in the ```dc:``` namespace (i.e., terms with identical local names sensu [[RDF-VOCAB-PUB](http://www.w3.org/TR/swbp-vocab-pub/#naming)]) are declared to be ```rdfs:subPropertyOf``` those ```dc:``` namespace terms [[DC-SUBPROPERTIES](http://dublincore.org/usage/decisions/2008/dcterms-changes/#sect-2)]. So if a data provider's non-RDF database contains string values for terms in the ```dcterms:``` namespace having non-literal ranges, it is appropriate to expose those literals in RDF as values of corresponding ```dc:``` terms.
##### 2.4.3.2 Literal values for non-literal resources in Darwin Core (normative)
Because there are many legacy data composed of string values of _dwc:_ namespace (http://rs.tdwg.org/dwc/terms/) terms whose objects actually represent non-literal entities (i.e., value strings sensu DCAM), it is likely that many providers will at least initially expose such data in RDF as string literals served directly from their existing databases [[RDB2RDF](http://www.w3.org/TR/r2rml/)]. To make it possible for the legacy data to be exposed as RDF while also ensuring that the meaning of those data is preserved, in RDF the literal value of an existing Darwin Core term in the _dwc:_ namespace should have the same structure as that described in the term's description, as in Example 19.
Because there are many legacy data composed of string values of ```dwc:``` namespace (http://rs.tdwg.org/dwc/terms/) terms whose objects actually represent non-literal entities (i.e., value strings sensu DCAM), it is likely that many providers will at least initially expose such data in RDF as string literals served directly from their existing databases [[RDB2RDF](http://www.w3.org/TR/r2rml/)]. To make it possible for the legacy data to be exposed as RDF while also ensuring that the meaning of those data is preserved, in RDF the literal value of an existing Darwin Core term in the ```dwc:``` namespace should have the same structure as that described in the term's description, as in Example 19.
**Example 19:**
@ -764,20 +764,20 @@ Turtle
     dwc:recordedBy "Oliver P. Pearson | Anita K. Pearson".
```
The terms in the _dwc:_ namespace should NOT be used for IRI reference objects, even if the term definition suggests that the object resource is of a non-literal type. Instead, IRI reference objects should be used with terms in the _dwciri:_ namespace as defined by this guide in [Section 2.5](./index.htm#2.5_Terms_in_the_dwciri:_namespace). When a string value is provided as the object of a _dwc:_ namespace term whose definition suggests that the object is of a non-literal type, that string is understood to be serving as a value string.
The terms in the ```dwc:``` namespace should NOT be used for IRI reference objects, even if the term definition suggests that the object resource is of a non-literal type. Instead, IRI reference objects should be used with terms in the ```dwciri:``` namespace as defined by this guide in [Section 2.5](./index.htm#2.5_Terms_in_the_dwciri:_namespace). When a string value is provided as the object of a ```dwc:``` namespace term whose definition suggests that the object is of a non-literal type, that string is understood to be serving as a value string.
### 2.5 Terms in the dwciri: namespace (normative)
Terms in the namespace _dwciri:_ (http://rs.tdwg.org/dwc/iri/) are intended for use with IRI reference objects and should NOT be used with literal objects. They may also be used with blank node objects, although in most cases this will probably be unnecessary.
Terms in the namespace ```dwciri:``` (http://rs.tdwg.org/dwc/iri/) are intended for use with IRI reference objects and should NOT be used with literal objects. They may also be used with blank node objects, although in most cases this will probably be unnecessary.
#### 2.5.1 Definition of dwciri: terms (normative)
If a term in the _dwciri:_ namespace has a corresponding term with the same local name [[RDF-VOCAB-PUB](http://www.w3.org/TR/swbp-vocab-pub/#naming)] in the _dwc:_ namespace, the _dwciri:_ namespace term is defined to have the same meaning as its _dwc:_ namespace term analogue. In defining a _dwciri:_ term that has a _dwc:_ analogue, the definition of the _dwc:_ term is understood to be modified in the following ways:
If a term in the ```dwciri:``` namespace has a corresponding term with the same local name [[RDF-VOCAB-PUB](http://www.w3.org/TR/swbp-vocab-pub/#naming)] in the ```dwc:``` namespace, the ```dwciri:``` namespace term is defined to have the same meaning as its ```dwc:``` namespace term analogue. In defining a ```dwciri:``` term that has a ```dwc:``` analogue, the definition of the ```dwc:``` term is understood to be modified in the following ways:
- when a _dwciri:_ term is used as an RDF predicate, its non-literal object will be identified by an IRI reference rather than a string literal
- the object of the _dwciri:_ term predicate will be a single resource. If the _dwc:_ term definition specifies that multiple values should be a concatenated list, the resource described by a _dwciri:_ property should be the subject of a triple for each value on the list. Alternatively, a single triple can be used to describe the subject if the object is a single resource composed of component resources described using additional RDF triples.
- when a ```dwciri:``` term is used as an RDF predicate, its non-literal object will be identified by an IRI reference rather than a string literal
- the object of the ```dwciri:``` term predicate will be a single resource. If the ```dwc:``` term definition specifies that multiple values should be a concatenated list, the resource described by a ```dwciri:``` property should be the subject of a triple for each value on the list. Alternatively, a single triple can be used to describe the subject if the object is a single resource composed of component resources described using additional RDF triples.
Several terms in the _dwciri:_ namespace do not have _dwc:_ namespace analogues (_dwciri:inCollection_, _dwciri:toTaxon_, _dwciri:inDescribedPlace_, _dwciri:earliestGeochronologicalEra_, _dwciri:latestGeochronologicalEra_, _dwciri:fromLithostratigraphicUnit_, and _dwciri:inDataset_). Their definitions are given in [Section 3.6](./index.htm#3.6_dwciri:_terms_having_local_names_that_don%E2%80%99t_correspond_to).
Several terms in the ```dwciri:``` namespace do not have ```dwc:``` namespace analogues (```dwciri:inCollection```, ```dwciri:toTaxon```, ```dwciri:inDescribedPlace```, ```dwciri:earliestGeochronologicalEra```, ```dwciri:latestGeochronologicalEra```, ```dwciri:fromLithostratigraphicUnit```, and ```dwciri:inDataset```). Their definitions are given in [Section 3.6](./index.htm#3.6_dwciri:_terms_having_local_names_that_don%E2%80%99t_correspond_to).
#### 2.5.2 Using terms in the Darwin Core dwciri: namespace with non-literal objects identified by IRI references (non-normative)
@ -805,11 +805,11 @@ where <http://viaf.org/viaf/263074474> is a persistent IRI identifier for the pe
#### 2.5.3 Expectation of clients encountering RDF containing dwc: and dwciri: terms (normative)
A client that encounters a triple having a term from the _dwciri:_ namespace as its predicate can expect the object of the triple to be an IRI reference and subsequently may be able to dereference that IRI to obtain additional information about the entity that it represents. A client encountering a triple having a term from the _dwc:_ namespace should be prepared to accept a literal object, although it is possible that some data providers unaware of this guide may have used _dwc:_ terms with IRI references as _rdf:resource_ attributes. Application developers should be flexible in their expectations for the values of properties from the _dwc:_ namespace.
A client that encounters a triple having a term from the ```dwciri:``` namespace as its predicate can expect the object of the triple to be an IRI reference and subsequently may be able to dereference that IRI to obtain additional information about the entity that it represents. A client encountering a triple having a term from the ```dwc:``` namespace should be prepared to accept a literal object, although it is possible that some data providers unaware of this guide may have used ```dwc:``` terms with IRI references as ```rdf:resource``` attributes. Application developers should be flexible in their expectations for the values of properties from the ```dwc:``` namespace.
### 2.6 Darwin Core ID terms and RDF (normative)
Darwin Core contains a number of "ID" terms intended to designate identifiers, e.g., _dwc:occurrenceID_, _dwc:identificationID_, _dwc:locationID_, etc. The "ID" terms provide two functions, specifying the class of the resource and indicating that value of the term is an identifier. These functions are illustrated by the non-RDF XML below, which is part of an example provided in the Darwin Core XML Guide [[DWC-XML](http://rs.tdwg.org/dwc/terms/guides/xml/index.htm)]:
Darwin Core contains a number of "ID" terms intended to designate identifiers, e.g., ```dwc:occurrenceID```, ```dwc:identificationID```, ```dwc:locationID```, etc. The "ID" terms provide two functions, specifying the class of the resource and indicating that value of the term is an identifier. These functions are illustrated by the non-RDF XML below, which is part of an example provided in the Darwin Core XML Guide [[DWC-XML](http://rs.tdwg.org/dwc/terms/guides/xml/index.htm)]:
**Example 21:**
@ -824,7 +824,7 @@ Darwin Core contains a number of "ID" terms intended to designate identifiers, e
</dwc:Identification>
```
This example could also be represented by the following database table in which each record (row) represents an _dwc:Identification_ instance and in which each column represents a property of the _dwc:Identification_ instance as indicated by the column heading:
This example could also be represented by the following database table in which each record (row) represents an ```dwc:Identification``` instance and in which each column represents a property of the ```dwc:Identification``` instance as indicated by the column heading:
**Table 3** (non-normative)
@ -832,7 +832,7 @@ dwc:identificationID | dwc:identifiedBy | dwc:dateIdentified | dwc:taxonID
--- | --- | --- | ---
"http://guid.mvz.org/identifications/23459" | "Richard Sage" | "2000" | "urn:lsid:catalogueoflife.org:taxon:d79c11aa-29c1-102b-9a4a-00304854f820:col20120721"
In Example 21 and Table 3, the "ID" terms are used to specify both the identifier of a resource which is the subject of the record itself (using the term _dwc:identificationID_) and to specify an object resource related to the subject resource by a foreign key (using the term _dwc:taxonID_). Because the ID terms are not designated to be used with subjects or objects specifically, the resource they identify must be made clear by the context in which they are used. In the case of the database table, a pre-existing understanding between the data provider and consumer would indicate that the rows of the table represent _dwc:Identification_ instances and therefore the _dwc:identificationID_ property would provide the identifier of the subject and any other ID terms would refer to object resources that are related to that particular identification instance. In the XML example, the type of the subject resource is made clear through the record's container element and hence a consumer would know that the _dwc:identificationID_ property referred to the subject resource. In RDF, the two functions (specifying type and referencing an identifier) are handled separately using _rdf:type_ declarations ([Section 2.3.1](./index.htm#2.3.1_Declaring_the_type_of_the_resource)) and defined mechanisms for expressing the identifier of the subject resource ([Section 2.2](./index.htm#2.2_Subject_resources)). Because these mechanisms are well-known best practices outside TDWG, they should be used rather than using the Darwin Core ID terms when data are expressed as RDF. The following example shows an appropriate way to express the information in Example 21 as RDF:
In Example 21 and Table 3, the "ID" terms are used to specify both the identifier of a resource which is the subject of the record itself (using the term ```dwc:identificationID```) and to specify an object resource related to the subject resource by a foreign key (using the term ```dwc:taxonID```). Because the ID terms are not designated to be used with subjects or objects specifically, the resource they identify must be made clear by the context in which they are used. In the case of the database table, a pre-existing understanding between the data provider and consumer would indicate that the rows of the table represent ```dwc:Identification``` instances and therefore the ```dwc:identificationID``` property would provide the identifier of the subject and any other ID terms would refer to object resources that are related to that particular identification instance. In the XML example, the type of the subject resource is made clear through the record's container element and hence a consumer would know that the ```dwc:identificationID``` property referred to the subject resource. In RDF, the two functions (specifying type and referencing an identifier) are handled separately using ```rdf:type``` declarations ([Section 2.3.1](./index.htm#2.3.1_Declaring_the_type_of_the_resource)) and defined mechanisms for expressing the identifier of the subject resource ([Section 2.2](./index.htm#2.2_Subject_resources)). Because these mechanisms are well-known best practices outside TDWG, they should be used rather than using the Darwin Core ID terms when data are expressed as RDF. The following example shows an appropriate way to express the information in Example 21 as RDF:
**Example 22:**
@ -860,8 +860,8 @@ Turtle:
The following points about the Example 22 should be noted:
1. In RDF/XML use the _rdf:about_ attribute of an _rdf:Description_ element to specify an IRI identifier used with the subject ID term, i.e., the value of _dwc:identificationID_ is an HTTP IRI and can therefore be used with the _rdf:about_ attribute. The _dcterms:identifier_ property can also be used to express the primary identifier for the subject resource as a literal. In Example 22, the HTTP IRI is considered the primary identifier for the Identification instance so it is included as a string value of _dcterms:identifier_ as well as the IRI of the subject resource. Refer to [Section 2.2.1](./index.htm#2.2.1_Identifying_subject_resources_using_IRIs) and [2.2.2](./index.htm#2.2.2_Associating_a_string_identifier_with_a_subject_resource) for more details.
2. Data providers who want to relate a subject resource to related non-literal resources should use object properties (i.e., properties which relate IRI-identified instances to other IRI-identified instances) [[OWL-PRIMER](http://www.w3.org/TR/owl-primer/#Object_Properties)] from a well-known vocabulary or ontology. Darwin Core does not generally define object properties that connect its core classes and in those cases users will have to find object properties outside of Darwin Core (see the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://code.google.com/p/tdwg-rdf/wiki/DwCAncillary)] for examples). In this example, the term _dwciri:toTaxon_ (see [Section 2.7.4](./index.htm#2.7.4_Description_of_a_taxonomic_entity)) is used to relate the _dwc:Identification_ instance to a taxon instance. (Please note that this is for illustration purposes only and this guide takes no position on the nature of taxa or taxon concepts or whether the resource used in this example is actually a taxon or not.)
1. In RDF/XML use the ```rdf:about``` attribute of an ```rdf:Description``` element to specify an IRI identifier used with the subject ID term, i.e., the value of ```dwc:identificationID``` is an HTTP IRI and can therefore be used with the ```rdf:about``` attribute. The ```dcterms:identifier``` property can also be used to express the primary identifier for the subject resource as a literal. In Example 22, the HTTP IRI is considered the primary identifier for the Identification instance so it is included as a string value of ```dcterms:identifier``` as well as the IRI of the subject resource. Refer to [Section 2.2.1](./index.htm#2.2.1_Identifying_subject_resources_using_IRIs) and [2.2.2](./index.htm#2.2.2_Associating_a_string_identifier_with_a_subject_resource) for more details.
2. Data providers who want to relate a subject resource to related non-literal resources should use object properties (i.e., properties which relate IRI-identified instances to other IRI-identified instances) [[OWL-PRIMER](http://www.w3.org/TR/owl-primer/#Object_Properties)] from a well-known vocabulary or ontology. Darwin Core does not generally define object properties that connect its core classes and in those cases users will have to find object properties outside of Darwin Core (see the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://github.com/tdwg/rdf/blob/master/DwCAncillary.md)] for examples). In this example, the term ```dwciri:toTaxon``` (see [Section 2.7.4](./index.htm#2.7.4_Description_of_a_taxonomic_entity)) is used to relate the ```dwc:Identification``` instance to a taxon instance. (Please note that this is for illustration purposes only and this guide takes no position on the nature of taxa or taxon concepts or whether the resource used in this example is actually a taxon or not.)
3. If an identified object of a triple is a non-literal resource ([Section 2.4.2](./index.htm#2.4.2_Non-literal_object_resources)), RDF requires that it be referenced by an IRI. Although the UUID "d79c11aa-29c1-102b-9a4a-00304854f820:col20120721" is a globally unique and hopefully persistent identifier for the taxon, it is not an IRI. Catalog of Life has created an IRI from the UUID in the form of an LSID:
```rdf
@ -876,11 +876,11 @@ so expressing the object reference as
would be valid RDF. However, best practices ([Section 2.4.2.1.1](./index.htm#2.4.2.1.1_Objects_identified_by_LSIDs)) specify that when LSIDs are the objects of triples, they should be in HTTP-proxied form. In Example 22, the LSID is proxied using the TDWG LSID resolver.
4. The class of the subject identification instance (_dwc:Identification_) is asserted explicitly using _rdf:type_. The type of the object taxon instance is not stated directly - a client would need to dereference the IRI to discover it.
4. The class of the subject identification instance (```dwc:Identification```) is asserted explicitly using ```rdf:type```. The type of the object taxon instance is not stated directly - a client would need to dereference the IRI to discover it.
#### 2.6.1 Unintended consequences of using Darwin Core ID terms in RDF (non-normative)
The previous section showed that using a Darwin Core ID term to indicate the identifier associated with the subject resource is not necessary because there are well-known means in RDF (the _rdf:about_ attribute and the _dcterms:identifier_ property) for exposing the subjects identifier. However, as shown below, using a Darwin Core ID term to identify an object resource (as shown in the non-RDF XML Example 21) would actually be problematic. In its normative definition, each Darwin Core ID term is declared to be _rdfs:subPropertyOf_ _dcterms:identifier_. In RDF, the purpose of a subproperty declaration is to allow a client with reasoning capability to infer a triple containing a broader (and presumably more well-known) property. In the terminology of Dublin Core, the "ID" term is a qualifier which "refines" a basic Dublin Core term [[DC-QUALIFIER](http://dublincore.org/documents/usageguide/qualifiers.shtml)] and the process of inferring a broader meaning from a more specific term is called a "dumb-down" operation. If a provider attempting to expose the data of Table 3 as RDF used the _dwc:taxonID_ term as a property of the identification as shown in the (incorrect) Example 23:
The previous section showed that using a Darwin Core ID term to indicate the identifier associated with the subject resource is not necessary because there are well-known means in RDF (the ```rdf:about``` attribute and the ```dcterms:identifier``` property) for exposing the subjects identifier. However, as shown below, using a Darwin Core ID term to identify an object resource (as shown in the non-RDF XML Example 21) would actually be problematic. In its normative definition, each Darwin Core ID term is declared to be ```rdfs:subPropertyOf``` ```dcterms:identifier```. In RDF, the purpose of a subproperty declaration is to allow a client with reasoning capability to infer a triple containing a broader (and presumably more well-known) property. In the terminology of Dublin Core, the "ID" term is a qualifier which "refines" a basic Dublin Core term [[DC-QUALIFIER](http://dublincore.org/documents/usageguide/qualifiers.shtml)] and the process of inferring a broader meaning from a more specific term is called a "dumb-down" operation. If a provider attempting to expose the data of Table 3 as RDF used the ```dwc:taxonID``` term as a property of the identification as shown in the (incorrect) Example 23:
**Example 23:**
@ -905,7 +905,7 @@ Turtle (incorrect usage)
     dwc:taxonID "http://lsid.tdwg.org/urn:lsid:catalogueoflife.org:taxon:d79c11aa-29c1-102b-9a4a-00304854f820:col20120721".
```
there would be an undesired effect if a client unfamiliar with Darwin Core performed a "dumb-down" operation (i.e., fell back to the broader meaning of the _dwc:taxonID_ term as _dcterms:identifier_). The client would infer the triple:
there would be an undesired effect if a client unfamiliar with Darwin Core performed a "dumb-down" operation (i.e., fell back to the broader meaning of the ```dwc:taxonID``` term as ```dcterms:identifier```). The client would infer the triple:
**Table 4**
@ -913,7 +913,7 @@ Subject | Predicate | Object
--- | --- | ---
<http://guid.mvz.org/identifications/23459> | dcterms:identifier | "http://lsid.tdwg.org/urn:lsid:catalogueoflife.org:taxon:d79c11aa-29c1-102b-9a4a-00304854f820:col20120721"
where the value of the _dwc:taxonID_ term was the identifier of the subject resource rather than of the object resource as intended by the data provider. This is why data providers will generally need to look outside Darwin Core for object properties that can be used to relate instances of one class to instances of another instead of using the Darwin Core ID terms.
where the value of the ```dwc:taxonID``` term was the identifier of the subject resource rather than of the object resource as intended by the data provider. This is why data providers will generally need to look outside Darwin Core for object properties that can be used to relate instances of one class to instances of another instead of using the Darwin Core ID terms.
### 2.7 Darwin Core convenience terms (non-normative)
@ -929,7 +929,7 @@ The data unambiguously specifies the lowest level political subdivision (Roberts
#### 2.7.1 What purpose do convenience terms serve? (non-normative)
When expressing the data about resources collected in Robertson County in RDF, it really isnt necessary to indicate in every record that North America is a parent feature of the United States, that the United States is a parent feature of Tennessee, and that Tennessee is a parent feature of Robertson County. It is only necessary to link the record to an IRI for Robertson County such as <http://sws.geonames.org/4653638/> and a semantic client can discover the parent features by traversing the _gn:parentFeature_ property of features included in the hierarchy. Once a client has discovered the higher level parts of the hierarchy in which it is interested, no additional retrieval of data about the hierarchy is required.
When expressing the data about resources collected in Robertson County in RDF, it really isnt necessary to indicate in every record that North America is a parent feature of the United States, that the United States is a parent feature of Tennessee, and that Tennessee is a parent feature of Robertson County. It is only necessary to link the record to an IRI for Robertson County such as <http://sws.geonames.org/4653638/> and a semantic client can discover the parent features by traversing the ```gn:parentFeature``` property of features included in the hierarchy. Once a client has discovered the higher level parts of the hierarchy in which it is interested, no additional retrieval of data about the hierarchy is required.
In general, it should not be necessary for a data provider to recreate hierarchical RDF relationships that have already been expressed by a centralized service. For that reason, this guide does not describe best-practices for expressing such relationships in RDF. Nevertheless, there are several reasons why it may be convenient for a data provider to expose literal values from existing text-based data:
@ -939,7 +939,7 @@ In general, it should not be necessary for a data provider to recreate hierarchi
#### 2.7.2 Literal convenience terms versus a single object property reference (normative)
There are several groups of convenience terms in the _dwc:_ namespace which may be used to provide literal values for the purposes listed above ([Section 3.6](./index.htm#3.6_dwciri:_terms_having_local_names_that_don%E2%80%99t_correspond_to)). In the case of each of these groups, it is not expected that a provider will link to IRI references for each level in the hierarchy. Therefore, _dwciri:_ analogues are not defined for those convenience terms from the _dwc:_ namespace. Rather, for each category of convenience terms, there is a single _dwciri:_ namespace term (having no analogue in the _dwc:_ namespace; [Section 3.7](./index.htm#3.7_dwc:_namespace_terms_that_have_analogues_in_the_dwciri:_name)) that can be used to link to the lowest available level in the hierarchy with the understanding that the RDF of the object resource will provide links to other IRIs for higher levels of the hierarchy. Such _dwciri:_ terms can refer to any level in the hierarchy if there is uncertainty about the identity of lower levels, or if lower levels do not exist.
There are several groups of convenience terms in the ```dwc:``` namespace which may be used to provide literal values for the purposes listed above ([Section 3.6](./index.htm#3.6_dwciri:_terms_having_local_names_that_don%E2%80%99t_correspond_to)). In the case of each of these groups, it is not expected that a provider will link to IRI references for each level in the hierarchy. Therefore, ```dwciri:``` analogues are not defined for those convenience terms from the ```dwc:``` namespace. Rather, for each category of convenience terms, there is a single ```dwciri:``` namespace term (having no analogue in the ```dwc:``` namespace; [Section 3.7](./index.htm#3.7_dwc:_namespace_terms_that_have_analogues_in_the_dwciri:_name)) that can be used to link to the lowest available level in the hierarchy with the understanding that the RDF of the object resource will provide links to other IRIs for higher levels of the hierarchy. Such ```dwciri:``` terms can refer to any level in the hierarchy if there is uncertainty about the identity of lower levels, or if lower levels do not exist.
**Table 6**
@ -953,7 +953,7 @@ lithostratigraphy descriptors (Section 2.7.7) | dwciri:fromLithostratigraphicUni
#### 2.7.3 Ownership of a collection item (normative)
Historically, the set of values for _dwc:institutionCode_, _dwc:collectionCode_, and _dwc:catalogNumber_ (a “Darwin Core triplet”) has been used to identify a collection item and to indicate the owning institution and collection within that institution as shown in Table 7.
Historically, the set of values for ```dwc:institutionCode```, ```dwc:collectionCode```, and ```dwc:catalogNumber``` (a “Darwin Core triplet”) has been used to identify a collection item and to indicate the owning institution and collection within that institution as shown in Table 7.
**Table 7** (non-normative)
@ -961,7 +961,7 @@ dwc:basisOfRecord | dwc:institutionCode | dwc:collectionCode | dwc:catalogNumber
--- | --- | --- | --- | ---
"PreservedSpecimen" | "MVZ" | "Mamm" | "115956" | "urn:lsid:biocol.org:col:34904"
In RDF, unique identification of collection items is done through the IRI which acts as a globally unique identifier for that item. The Darwin Core triplet properties may still be provided as literal values, but ownership/control of the collection item should be indicated using _dwciri:inCollection_ with an HTTP IRI as the IRI-reference object. For physical specimens, the recommended best practice is to use a collection IRI from a collections registry such as an HTTP-proxied LSID from the Global Registry of Biorepositories [[GRBIO](http://grbio.org/)]. Example 24 illustrates this for the data from Table 7.
In RDF, unique identification of collection items is done through the IRI which acts as a globally unique identifier for that item. The Darwin Core triplet properties may still be provided as literal values, but ownership/control of the collection item should be indicated using ```dwciri:inCollection``` with an HTTP IRI as the IRI-reference object. For physical specimens, the recommended best practice is to use a collection IRI from a collections registry such as an HTTP-proxied LSID from the Global Registry of Biorepositories [[GRBIO](http://grbio.org/)]. Example 24 illustrates this for the data from Table 7.
**Example 24:**
@ -989,9 +989,9 @@ Turtle
#### 2.7.4 Description of a taxonomic entity (normative)
The consensus embodied in the TDWG Taxon Concept Transfer Schema (TCS) standard [[TCS-STANDARD](http://www.tdwg.org/standards/117/)] is that identification instances refer to taxon concept instances. Therefore it would be a best practice to describe taxonomic entities in RDF as taxon concepts sensu TCS. However, because the TCS standard is an XML schema, it is not directly translatable to RDF. It is considered to be out of the scope of this document to specify how taxon concepts should be rendered as RDF. Nevertheless, Darwin Core does define many convenience terms listed under the _dwc:Taxon_ class that can be used as properties of _dwc:Identification_ instances ([Section 3.5](./index.htm#3.5_Darwin_Core_convenience_terms_that_are_expected_to_be_used_o)).
The consensus embodied in the TDWG Taxon Concept Transfer Schema (TCS) standard [[TCS-STANDARD](http://www.tdwg.org/standards/117/)] is that identification instances refer to taxon concept instances. Therefore it would be a best practice to describe taxonomic entities in RDF as taxon concepts sensu TCS. However, because the TCS standard is an XML schema, it is not directly translatable to RDF. It is considered to be out of the scope of this document to specify how taxon concepts should be rendered as RDF. Nevertheless, Darwin Core does define many convenience terms listed under the ```dwc:Taxon``` class that can be used as properties of ```dwc:Identification``` instances ([Section 3.5](./index.htm#3.5_Darwin_Core_convenience_terms_that_are_expected_to_be_used_o)).
It might be argued that these convenience terms would more appropriately be properties of a _dwc:Taxon_ instance. However, the object properties necessary to relate _dwc:Taxon_ instances to name entities, references, parent taxa, and child taxa do not exist and the exact relationship between taxonomic entities such as taxon concepts, protonyms, taxon name uses, etc. has not been established using RDF. So the creation of functional _dwc:Taxon_ instances described using RDF is not possible at the present time. Therefore this document establishes the convention that convenience terms for taxonomic entities should be properties of _dwc:Identification_. The task of describing taxonomic entities using RDF must be an effort outside of Darwin Core. This guide does establish the object property _dwciri:toTaxon_ for use in relating a Darwin Core identification instance to a taxonomic entity as defined elsewhere.
It might be argued that these convenience terms would more appropriately be properties of a ```dwc:Taxon``` instance. However, the object properties necessary to relate ```dwc:Taxon``` instances to name entities, references, parent taxa, and child taxa do not exist and the exact relationship between taxonomic entities such as taxon concepts, protonyms, taxon name uses, etc. has not been established using RDF. So the creation of functional ```dwc:Taxon``` instances described using RDF is not possible at the present time. Therefore this document establishes the convention that convenience terms for taxonomic entities should be properties of ```dwc:Identification```. The task of describing taxonomic entities using RDF must be an effort outside of Darwin Core. This guide does establish the object property ```dwciri:toTaxon``` for use in relating a Darwin Core identification instance to a taxonomic entity as defined elsewhere.
Consider the following example where Takuma Yun identified a spider to the species _Hersilia yaeyamaensis_ using information in Tanikawa (1999). The data about this identification was listed in a database as shown in Table 8.
@ -1001,7 +1001,7 @@ dwc:identificationID | dwc:identifiedBy | dwc:order | dwc:family | dwc:genus | d
--- | --- | --- | --- | --- | --- | ---
"75C9EA16-72B1-44C9-AD40-3C3A41323A09" | "Takuma Yun" | "Araneae" | "Hersiliidae" | "Hersilia" | "yaeyamaensis" | "75C9EA16-72B1-44C9-AD40-3C3D41323AB9"
In this example, a best practice would be to link the identification instance to a taxon instance of _Hersilia yaeyamaensis_ sec. Tanikawa 1999 using the object property _dwciri:toTaxon_ as shown in Example 22. However, the data provider may be uninterested, or unable to mint or discover a taxon instance to which the identification instance can be linked. The provider may simply wish to make it easier to discover the identification instance and be unconcerned about the taxonomic relationships that might be asserted for concepts that may be defined for the listed name components. In that case the provider can use the following RDF:
In this example, a best practice would be to link the identification instance to a taxon instance of _Hersilia yaeyamaensis_ sec. Tanikawa 1999 using the object property ```dwciri:toTaxon``` as shown in Example 22. However, the data provider may be uninterested, or unable to mint or discover a taxon instance to which the identification instance can be linked. The provider may simply wish to make it easier to discover the identification instance and be unconcerned about the taxonomic relationships that might be asserted for concepts that may be defined for the listed name components. In that case the provider can use the following RDF:
**Example 25:**
@ -1038,7 +1038,7 @@ In the example, providing the triple
<http://museum.or.jp/9AC9BD26-8B41-458A-AA35-503A4527D009> dwc:order  “Araneae”
```
should not be taken to imply that Takuma Yun asserted that the spider he identified was classified within the order Araneae, nor should the RDF be assumed to imply that Takuma Yun asserted that Aranaeae is the name of a parent taxon of the genus _Hersilia_. Those sorts of assertions would need to be made using more complex RDF and a more expressive vocabulary outside of Darwin Core. The RDF simply makes it easier for users who are looking for spider identifications to search for them by looking for identifications having _dwc:order_ of “Araneae”, _dcw:genus_ of “Hersilia”, and a specific epithet of “yaeyamaensis”. If it can be determined (perhaps at a later time) that the taxon described by the convenience terms corresponds to a particular IRI-identified instance, the identification instance can be linked to it using an object property, e.g.,
should not be taken to imply that Takuma Yun asserted that the spider he identified was classified within the order Araneae, nor should the RDF be assumed to imply that Takuma Yun asserted that Aranaeae is the name of a parent taxon of the genus _Hersilia_. Those sorts of assertions would need to be made using more complex RDF and a more expressive vocabulary outside of Darwin Core. The RDF simply makes it easier for users who are looking for spider identifications to search for them by looking for identifications having ```dwc:order``` of “Araneae”, ```dcw:genus``` of “Hersilia”, and a specific epithet of “yaeyamaensis”. If it can be determined (perhaps at a later time) that the taxon described by the convenience terms corresponds to a particular IRI-identified instance, the identification instance can be linked to it using an object property, e.g.,
```rdf
<http://muse.or.jp/9AC9BD26-8B41-458A-AA35-503A4527D009> dwciri:toTaxon <http://zoobank.org/75C9EA16-72B1-44C9-AD40-3C3D41323AB9>
@ -1046,7 +1046,7 @@ should not be taken to imply that Takuma Yun asserted that the spider he identif
#### 2.7.5 Names of geographic subdivisions (normative)
The data from Table 5 can be expressed as shown in Example 26. In the example, the term _dwciri:inDescribedPlace_ is used as an object property to link the _dcterms:Location_ instance to an IRI for the lowest known geographic subdivision which applies to the locality. _dwc:locality_ could also be used to provide a string literal description of the specific description of the place.
The data from Table 5 can be expressed as shown in Example 26. In the example, the term ```dwciri:inDescribedPlace``` is used as an object property to link the ```dcterms:Location``` instance to an IRI for the lowest known geographic subdivision which applies to the locality. ```dwc:locality``` could also be used to provide a string literal description of the specific description of the place.
**Example 26:**
@ -1080,11 +1080,11 @@ Turtle
     dwciri:inDescribedPlace <http://sws.geonames.org/4653638/>.
```
Because generic RDF places no restrictions on repeating properties, a _dcterms:Location_ instance could have multiple _dwciri:inDescribedPlace_ properties if the location is included within several described geographic subdivisions. For example, a particular location could be included within <http://sws.geonames.org/4626068/> (The Great Smoky Mountains National Park which straddles two states) and <http://sws.geonames.org/4656568/> (Sevier County, Tennessee, US, which is the lowest level political subdivision).
Because generic RDF places no restrictions on repeating properties, a ```dcterms:Location``` instance could have multiple ```dwciri:inDescribedPlace``` properties if the location is included within several described geographic subdivisions. For example, a particular location could be included within <http://sws.geonames.org/4626068/> (The Great Smoky Mountains National Park which straddles two states) and <http://sws.geonames.org/4656568/> (Sevier County, Tennessee, US, which is the lowest level political subdivision).
#### 2.7.6 Chronostratographic (geological timescale) descriptors (normative)
The following example is taken from [http://dx.doi.org/10.1098/rsbl.2011.0228](http://dx.doi.org/10.1098/rsbl.2011.0228), which involves the geological context of a fossil serving as a holotype for a species description. In this example (Table 9), there is a single value given for the Epoch (Middle Jurassic), so the values for each of the _earliest.../latest..._ stratigraphic timescale term pairs are the same.
The following example is taken from [http://dx.doi.org/10.1098/rsbl.2011.0228](http://dx.doi.org/10.1098/rsbl.2011.0228), which involves the geological context of a fossil serving as a holotype for a species description. In this example (Table 9), there is a single value given for the Epoch (Middle Jurassic), so the values for each of the ```earliest.../latest...``` stratigraphic timescale term pairs are the same.
**Table 9** (non-normative)
@ -1120,15 +1120,15 @@ Turtle
     dwciri:latestGeochronologicalEra <http://resource.geosciml.org/classifier/ics/ischart/MiddleJurassic>.
```
In this example, the object properties _dwciri:earliestGeochronologicalEra_ and _dwciri:latestGeochronologicalEra_ link to an IRI that identifies an instance of the _gsml:GeochronologicEra_ class which uses SKOS to relate the Middle Jurassic epoch to higher levels in the geochronological hierarchy.
In this example, the object properties ```dwciri:earliestGeochronologicalEra``` and ```dwciri:latestGeochronologicalEra``` link to an IRI that identifies an instance of the ```gsml:GeochronologicEra``` class which uses SKOS to relate the Middle Jurassic epoch to higher levels in the geochronological hierarchy.
#### 2.7.7 Lithostratigraphy descriptors (normative)
Since lithostratigraphic units are hierarchical, the pattern followed with the other hierarchical convenience terms applies to the Darwin Core lithostratigraphic terms categorized under the _dwc:GeologicalContext_ class (_dwc:group_, _dwc:formation_, _dwc:member_, and _dwc:bed_). The object property _dwciri:fromLithostratigraphicUnit_ can be used to link the IRI for a lithostratigraphic unit at the lowest appropriate level.
Since lithostratigraphic units are hierarchical, the pattern followed with the other hierarchical convenience terms applies to the Darwin Core lithostratigraphic terms categorized under the ```dwc:GeologicalContext``` class (```dwc:group```, ```dwc:formation```, ```dwc:member```, and ```dwc:bed```). The object property ```dwciri:fromLithostratigraphicUnit``` can be used to link the IRI for a lithostratigraphic unit at the lowest appropriate level.
### 2.8 Darwin Core association terms (non-normative)
Darwin Core contains a number of terms whose local name begins with "associated" (_dwc:associatedMedia_, _dwc:associatedOccurrences_, etc.), which are referred to as "association terms" in this guide. Because these terms were designed to link the subject resource to one or more related resources within a flat, text-based data system, they need special handling to represent their values as IRI-reference objects.
Darwin Core contains a number of terms whose local name begins with "associated" (```dwc:associatedMedia```, ```dwc:associatedOccurrences```, etc.), which are referred to as "association terms" in this guide. Because these terms were designed to link the subject resource to one or more related resources within a flat, text-based data system, they need special handling to represent their values as IRI-reference objects.
#### 2.8.1 What is the purpose of association terms? (non-normative)
@ -1138,7 +1138,7 @@ The information encoded by a Darwin Core association term property/value pair ca
- a designation of the type of the related resource
- (for some terms) a description of the nature of the relationship including its direction
The related resource is designated by some sort of identifier present in the literal value. The type of the related resource is implied by the second part of the local name (e.g., "Media", "Occurrences", etc.). The definitions of some of the terms (_dwc:associatedTaxa_, _dwc:associatedOccurrences_, and _dwc:associatedOrganisms_) also specify that the nature of the association with the subject resource should also be included in the literal value ("sibling of", "predator of ", etc.).
The related resource is designated by some sort of identifier present in the literal value. The type of the related resource is implied by the second part of the local name (e.g., "Media", "Occurrences", etc.). The definitions of some of the terms (```dwc:associatedTaxa```, ```dwc:associatedOccurrences```, and ```dwc:associatedOrganisms```) also specify that the nature of the association with the subject resource should also be included in the literal value ("sibling of", "predator of ", etc.).
#### 2.8.2 Expressing Darwin Core association terms as RDF with literal values (normative)
@ -1150,7 +1150,7 @@ dwc:organismID | dwc:associatedOrganisms | dwc:associatedMedia
--- | --- | ---
"http://bioimages.vanderbilt.edu/ind-durandp/dd343" | "sibling of AX3467" | "http://bioimages.vanderbilt.edu/durandp/dd343 &#124; http://bioimages.vanderbilt.edu/durandp/dd344"
These data can be serialized as RDF using the _dwc:_ namespace literal value terms _dwc:associatedOrganisms_ and _dwc:associatedMedia_ as shown in Example 28.
These data can be serialized as RDF using the ```dwc:``` namespace literal value terms ```dwc:associatedOrganisms``` and ```dwc:associatedMedia``` as shown in Example 28.
**Example 28:**
@ -1172,7 +1172,7 @@ Turtle:
     dwc:associatedMedia "http://bioimages.vanderbilt.edu/durandp/dd343 | http://bioimages.vanderbilt.edu/durandp/dd344".
```
Because the values of the association terms are literals, a consuming client would need to carry out additional processing to determine the identity of the associated resources referenced in the literals. In the case of the value for _dwc:associatedOrgansims_, the client would have to determine that the substring "AX3467" was an identifier for the organism and determine the nature of the relationship represented by the substring "sibling of". In the case of the value for _dwc:associatedMedia_, the client would need to parse the identifiers included in the value string, then determine that those substrings were IRIs.
Because the values of the association terms are literals, a consuming client would need to carry out additional processing to determine the identity of the associated resources referenced in the literals. In the case of the value for ```dwc:associatedOrgansims```, the client would have to determine that the substring "AX3467" was an identifier for the organism and determine the nature of the relationship represented by the substring "sibling of". In the case of the value for ```dwc:associatedMedia```, the client would need to parse the identifiers included in the value string, then determine that those substrings were IRIs.
The advantage of presenting the literal values of Darwin Core association properties via RDF as in Example 28 is that a provider could easily expose existing data with little effort. The disadvantage is that there would be a significant processing burden on consuming clients. It is possible that some literal values would be uninterpretable without additional information from another source. For example, how can the organism identified by "AX3467" be distinguished globally from other organisms that might have also been assigned the identifier "AX3467" ?
@ -1180,11 +1180,11 @@ The advantage of presenting the literal values of Darwin Core association proper
Because a Darwin Core association term property/value pair actually encodes two or more discrete "facts", it is probably better to represent the information contained in that property/value pair by more than a single triple.
The well-known Dublin Core term _dcterms:relation_ (http://purl.org/dc/terms/relation) can be used to link related resources. _dcterms:relation_ does not specify the exact nature of the relationship, although it has a number of declared subproperties that more precisely specify kinds and directions of the relationships (for example: _dcterms:hasPart_, _dcterms:isPartOf_, _dcterms:hasFormat_, _dcterms:isFormatOf_, _dcterms:references_, _dcterms:isVersionOf_, etc.). So _dcterms:relation_ is a generic term that may be used to indicate that a resource has an unspecified association with some other resource.
The well-known Dublin Core term ```dcterms:relation``` (http://purl.org/dc/terms/relation) can be used to link related resources. ```dcterms:relation``` does not specify the exact nature of the relationship, although it has a number of declared subproperties that more precisely specify kinds and directions of the relationships (for example: ```dcterms:hasPart```, ```dcterms:isPartOf```, ```dcterms:hasFormat```, ```dcterms:isFormatOf```, ```dcterms:references```, ```dcterms:isVersionOf```, etc.). So ```dcterms:relation``` is a generic term that may be used to indicate that a resource has an unspecified association with some other resource.
The term _rdf:type_ ([Section 2.3.1](./index.htm#2.3.1_Declaring_the_type_of_the_resource)) is the standard property for indicating the type of a resource in RDF. So it should be used to declare the type of the object resource of a Darwin Core association term property/value pair.
The term ```rdf:type``` ([Section 2.3.1](./index.htm#2.3.1_Declaring_the_type_of_the_resource)) is the standard property for indicating the type of a resource in RDF. So it should be used to declare the type of the object resource of a Darwin Core association term property/value pair.
The nature and direction of the association between the subject and object resource can be described more precisely if an appropriate term exists for that purpose. For example, in many cases, the relationship between a subject and object resource that are linked by _dwc:associatedMedia_ is depiction. Thus the well known term _foaf:depiction_ can be used to link two resources in lieu of, or in addition to _dcterms:relation_.
The nature and direction of the association between the subject and object resource can be described more precisely if an appropriate term exists for that purpose. For example, in many cases, the relationship between a subject and object resource that are linked by ```dwc:associatedMedia``` is depiction. Thus the well known term ```foaf:depiction``` can be used to link two resources in lieu of, or in addition to ```dcterms:relation```.
Example 29 shows how the data presented in Table 10 may be expressed as RDF using URI-reference properties instead of Darwin Core association properties.
@ -1234,11 +1234,11 @@ Turtle:
Notes:
1. Because there is no well-known term for expressing the relationship "sibling of", the nature of the relation between the two associated organisms was not represented in the triples.
2. In this example, both of the associated media items were depictions of the subject organism, so _foaf:depiction_ was used to indicate that. However, it is likely that many associated media items will not depict the subject resource. For example, specimen labels do not depict specimens with which they are associated nor do still images of habitats depict organisms with which they are associated. Therefore, there is a need for more expressive terms to describe these types of relations more precisely. However, creating such terms is beyond the scope of this guide.
2. In this example, both of the associated media items were depictions of the subject organism, so ```foaf:depiction``` was used to indicate that. However, it is likely that many associated media items will not depict the subject resource. For example, specimen labels do not depict specimens with which they are associated nor do still images of habitats depict organisms with which they are associated. Therefore, there is a need for more expressive terms to describe these types of relations more precisely. However, creating such terms is beyond the scope of this guide.
#### 2.8.4 Querying for associated resources (non-normative)
If the strategy outlined in [Section 2.8.3](./index.htm#2.8.3_Expressing_Darwin_Core_association_terms_as_RDF_with_URI_r) were used, resources associated with a subject resource could be discovered using a SPARQL query [[SPARQL](http://www.w3.org/TR/sparql11-query/)] similar to Example 30. In that example, <iri1> is the IRI of a subject resource, and _dcmitype:StillImage_ is the type of associated media that would be discovered.
If the strategy outlined in [Section 2.8.3](./index.htm#2.8.3_Expressing_Darwin_Core_association_terms_as_RDF_with_URI_r) were used, resources associated with a subject resource could be discovered using a SPARQL query [[SPARQL](http://www.w3.org/TR/sparql11-query/)] similar to Example 30. In that example, <iri1> is the IRI of a subject resource, and ```dcmitype:StillImage``` is the type of associated media that would be discovered.
**Example 30:**
@ -1254,9 +1254,9 @@ PREFIX dcmitype: <http://purl.org/dc/dcmitype/>SELECT ?resource WHERE {
### 2.9 MeasurementOrFact instances (normative)
Darwin Core provides a mechanism for expressing measurements and factual information associated with resources that are described using Darwin Core. Terms from the _dwc:_ namespace that are organized in the _dwc:MeasurementOrFact_ class were designed to express this information using string values in "flat" files. The information can be also expressed as RDF using a combination of literal value _dwc:_ namespace terms and IRI value _dwciri:_ terms. It is likely that this information could also be mapped to more expressive terms. However, that sort of translation is beyond the scope of this guide.
Darwin Core provides a mechanism for expressing measurements and factual information associated with resources that are described using Darwin Core. Terms from the ```dwc:``` namespace that are organized in the ```dwc:MeasurementOrFact``` class were designed to express this information using string values in "flat" files. The information can be also expressed as RDF using a combination of literal value ```dwc:``` namespace terms and IRI value ```dwciri:``` terms. It is likely that this information could also be mapped to more expressive terms. However, that sort of translation is beyond the scope of this guide.
Measurement properties can be grouped as part of a _dwc:MeasurementOrFact_ instance as shown in Example 31. In order for that instance to have meaning, it must be linked to some other resource that is the measured entity. In Example 31, the measurement took place when the occurrence of an organism was documented by its collection as a preserved specimen. The measurement was of a part of the documented organism. Given that the organism itself was preserved, the measurement also applies to the corresponding part of the specimen. Darwin Core does not provide the object properties that would be required to describe precisely how the _dwc:MeasurementOrFact_ instance was related to the _dwc:Occurrence_ instance, the _dwc:Organism_ whose occurrence was recorded, or the _dwc:PreservedSpecimen_ that was collected. In the example, _dcterms:relation_ was used to link the _dwc:MeasurementOrFact_ instance to the _dwc:Occurrence_ instance that was the subject of the database record that served as the source of the data serialized as RDF in Example 31. It is possible for providers to link _dwc:MeasurementOrFact_ instances using more expressive object properties outside of Darwin Core. See the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://code.google.com/p/tdwg-rdf/wiki/DwCAncillary)] for more information.
Measurement properties can be grouped as part of a ```dwc:MeasurementOrFact``` instance as shown in Example 31. In order for that instance to have meaning, it must be linked to some other resource that is the measured entity. In Example 31, the measurement took place when the occurrence of an organism was documented by its collection as a preserved specimen. The measurement was of a part of the documented organism. Given that the organism itself was preserved, the measurement also applies to the corresponding part of the specimen. Darwin Core does not provide the object properties that would be required to describe precisely how the ```dwc:MeasurementOrFact``` instance was related to the ```dwc:Occurrence``` instance, the ```dwc:Organism``` whose occurrence was recorded, or the ```dwc:PreservedSpecimen``` that was collected. In the example, ```dcterms:relation``` was used to link the ```dwc:MeasurementOrFact``` instance to the ```dwc:Occurrence``` instance that was the subject of the database record that served as the source of the data serialized as RDF in Example 31. It is possible for providers to link ```dwc:MeasurementOrFact``` instances using more expressive object properties outside of Darwin Core. See the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://github.com/tdwg/rdf/blob/master/DwCAncillary.md)] for more information.
**Example 31**
@ -1317,15 +1317,15 @@ dcterms:rightsHolder | dcterms:Agent | IRI for the agent owning or managing the
dcterms:accessRights | dcterms:RightsStatement | A custom RDF rights statement could be created describing who can access the resource or an indication of its security status. | No literal object analogue exists for this term. The string value can be expressed as a property of a blank node.[^7]
dcterms:references | --- | IRI for a publication (preferably an HTTP-proxied DOI) related to the subject resource. | Use dwc:identificationReferences for a reference consulted in making an taxonomic identification and dwc:associatedReferences for references related to occurrences.
[^2]: None of these _dcterms:_ namespace terms have domain declarations.
[^2]: None of these ```dcterms:``` namespace terms have domain declarations.
[^3]: For recommended controlled values, see the document "Sources of well-known controlled value IRIs", accessible from the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://code.google.com/p/tdwg-rdf/wiki/DwCAncillary)]
[^3]: For recommended controlled values, see the document "Sources of well-known controlled value IRIs", accessible from the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://github.com/tdwg/rdf/blob/master/DwCAncillary.md)]
[^4]: For more information about linking a creative work to its license, see the document "Sources of well-known controlled value IRIs", accessible from the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://code.google.com/p/tdwg-rdf/wiki/DwCAncillary)]
[^4]: For more information about linking a creative work to its license, see the document "Sources of well-known controlled value IRIs", accessible from the Darwin Core informative ancillary web pages [[DWC-RDF-ANCILLARY](https://github.com/tdwg/rdf/blob/master/DwCAncillary.md)]
[^5]: DCMI does not provide a literal object analogue of _dcterms:license_. Audubon Core [[AUDUBON-CORE](http://terms.tdwg.org/wiki/Audubon_Core)] recommends _xmpRights:UsageTerms_ for literals.
[^5]: DCMI does not provide a literal object analogue of ```dcterms:license```. Audubon Core [[AUDUBON-CORE](http://terms.tdwg.org/wiki/Audubon_Core)] recommends ```xmpRights:UsageTerms``` for literals.
[^6]: DCMI does not provide a literal object analogue of _dcterms:rightsHolder_. Audubon Core [[AUDUBON-CORE](http://terms.tdwg.org/wiki/Audubon_Core)] recommends _xmpRights:Owner_ for literals. However, since _xmpRights:Owner_ is defined as "a list of legal owners of the resource" [[XMP-SPECIFICATION](http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/XMPSpecificationPart1.pdf)], it can only be used to specify the rights owner, not an agent managing the rights.
[^6]: DCMI does not provide a literal object analogue of ```dcterms:rightsHolder```. Audubon Core [[AUDUBON-CORE](http://terms.tdwg.org/wiki/Audubon_Core)] recommends ```xmpRights:Owner``` for literals. However, since ```xmpRights:Owner``` is defined as "a list of legal owners of the resource" [[XMP-SPECIFICATION](http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/XMPSpecificationPart1.pdf)], it can only be used to specify the rights owner, not an agent managing the rights.
[^7]: See the DCMI accessRights guidelines [[DC-ACCESSRIGHTS](http://wiki.dublincore.org/index.php/User_Guide/Publishing_Metadata#dcterms:accessRights)] for an example.
@ -1342,7 +1342,7 @@ dwc:otherCatalogNumbers | There is no simple mapping because of the kinds of ide
dwc:basisOfRecord | Use only with literal value strings consisting of the local name component of Darwin Core class IRIs. Use rdf:type to refer to IRIs that describe the type of the resource.
dwc:dynamicProperties | Expected to contain JSON as a literal. Communities of practice might choose to use other vocabularies or develop their own vocabularies to express this sort of content directly as RDF.
[^8]: No Darwin Core terms defined by Darwin Core (as opposed to those imported from Dublin Core) have domain or range declarations as a part of their definitions. However, the five terms in the _dwc:_ namespace listed in the table above are defined to be _rdfs:subPropertyOf_ of _dcterms:date_, which has the range _rdfs:Literal_. Under the extensional entailment rule ext4 listed in section 7.3.1 of the RDF Semantics 2004 W3C Recommendation [[RDF-SEMANTICS-2004](http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#RDFSExtRules)], these terms can be inferred to have the range _rdfs:Literal_. However, the RDF 1.1 Semantics W3C Recommendation [[RDF-SEMANTICS-1.1](http://www.w3.org/TR/rdf11-mt/)] does not include these extensional entailment rules. Nevertheless, it is reasonable to expect that date properties should have literal values, with datatype attributes whenever possible.
[^8]: No Darwin Core terms defined by Darwin Core (as opposed to those imported from Dublin Core) have domain or range declarations as a part of their definitions. However, the five terms in the ```dwc:``` namespace listed in the table above are defined to be ```rdfs:subPropertyOf``` of ```dcterms:date```, which has the range ```rdfs:Literal```. Under the extensional entailment rule ext4 listed in section 7.3.1 of the RDF Semantics 2004 W3C Recommendation [[RDF-SEMANTICS-2004](http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#RDFSExtRules)], these terms can be inferred to have the range ```rdfs:Literal```. However, the RDF 1.1 Semantics W3C Recommendation [[RDF-SEMANTICS-1.1](http://www.w3.org/TR/rdf11-mt/)] does not include these extensional entailment rules. Nevertheless, it is reasonable to expect that date properties should have literal values, with datatype attributes whenever possible.
### 3.5 Darwin Core convenience terms that are expected to be used only with literal values (normative)
@ -1404,7 +1404,7 @@ Resource | Link | Description
[DCAM] | http://dublincore.org/documents/abstract-model/ | Dublin Core abstract model.
[DWC] | http://rs.tdwg.org/dwc/ | An introduction to the Darwin Core Standard.
[DWC-GUIDE] | http://rs.tdwg.org/dwc/terms/index.htm | Darwin Core Quick Reference Guide.
[DWC-RDF-ANCILLARY] | https://code.google.com/p/tdwg-rdf/wiki/DwCAncillary | Ancillary documents related to the Darwin Core RDF Guide.
[DWC-RDF-ANCILLARY] | https://github.com/tdwg/rdf/blob/master/DwCAncillary.md | Ancillary documents related to the Darwin Core RDF Guide.
[DWC-XML] | http://rs.tdwg.org/dwc/terms/guides/xml/index.htm | Darwin Core XML Guide.
[FOAF] | http://xmlns.com/foaf/spec/ | Friend of a Friend (FOAF) Vocabulary Specification.
[GEONAMES] | http://www.geonames.org/ | GeoNames geographical database.