ISO metadata is expressed as properties of (usually) a dataset, but can be used to express the metadata for a feature or an attribute, or a service or series of datasets. Whatever it is you want to give metadata for will be need a linked data identifier - probably a document identifier.
The metadata then becomes a series of relationships between the identified document (or thing) and other things.
ISO 19115 metadata has a reasonable overlap with Dublin Core; noting that linked data already makes use of the dc namespace, that will be our first place to look (except for dc:coverage)
We reckon that in the linked data world you could create these relationships from each thing, or create a document identifier (akin to the ISO dataset), link that to the metadata things, and have the original things link to the "metadata" document.
First mint a linked data URI for the thing you are describing; if you are linking the metadata directly from each thing, then they would need their own URIs. These ISO elements (if available) would be good sources for creating a "dataset" identifier:
- MD_Identification.citation.CI_Citation.identifier (code, codespace)
- if neither is available, you may be able to make something from the title
ISO 19115 describes a relational structure; when encoded in XML (ISO 19139) it usually becomes tree-like, that is I haven't seen much use of linking by reference in ISO 19139 instances. Fortunately, many of the ISO 19139 classes should become linked data things in their own right.
Multiple Languages ISO 19139 takes a complex approach, involving CharacterString or "FreeText". This page (so far) only really thinks about a single language. If you are encoding your RDF in XML, look at xml:lang (even though ISO TC211 explicitly rejected it). Note that xml:lang seems to expect the 'shortest ISO 639 code' (IETF RFC4646), whereas ISO 19139 may have free text, but often has two or three letter ISO 639 codes.
ISO Mandatory Core
|ISO 19115||RDF Predicate||Remarks|
|Dataset title||dcterms:title (or foaf:name/rdfs:label/skos:prefLabel?)||For one language, e.g. English|
|Dataset reference date (creation)||dcterms:created||ISO 8601 date or date time (Use URI date if really need to)|
|Dataset reference date (publication)||dcterms:issued||as above|
|Dataset reference date (revision)||dcterms:modified||as above|
|Dataset language||dcterms:language||Current practice is ISO 639 two or three letter codes. Linked Data URIs for languages may be useful. But perhaps the things being described will express their language more directly, so this becomes unnecessary.|
|Dataset topic category||dcterms:subject||Someone should make linked data concept URIs for ISO MD_TopicCategoryCode values|
|Abstract describing the dataset||dcterms:abstract||It is easy if there is any one language|
|Metadata point of contact (originator) MD_Metadata.identificationInfo.MD_Identification.pointOfContact where CI_ResponsibleParty.role.CI_RoleCode[codeValue=’originator’]||dcterms:creator||Link to a URI for the person/organisation who created the original metadata|
|Metadata point of contact (publisher) MD_Metadata.identificationInfo.MD_Identification.pointOfContact where CI_ResponsibleParty.role.CI_RoleCode[codeValue=’publisher’]||dcterms:publisher||as above|
|Metadata point of contact (contributor) MD_Metadata.identificationInfo.MD_Identification.pointOfContact where CI_ResponsibleParty.role.CI_RoleCode[role=’author’]||dcterms:contributor (can be a predicate off each of the other predicates, e.g. ISO role "author"->dc:creator!).||as above|
|Metadata date stamp||dcterms:modified (a predicate off each of the other predicates)||ISO 8601 date or date time (Use URI date if really need to)|
Useful Optional elements
|ISO 19115||RDF Predicate||Remarks|
|Alternate Title||dcterms:alternative||Easy if only one language, might require more thinking in case of more languages|
|Distribution format||dc:format||as above|
|Geographic location||dcterms:spatial||(bounding box)|
|Geographic description||dcterms:spatial||extent in words - preferably by referring to a controlled list, which should then be exposed as URIs for those locations, e.g. OS gazetteer|
|Quality (INSPIRE conformity)||dcterms:conformsTo||Works well if the specification you conform to has its own (document) URI|
|Quality (Lineage)||dcterms:provenance, or||Even if just a text description|
|Use Constraints (License)||dcterms:license (in some cases, see dcterms:accessRights)||Works best if the licence has its own (document) URI|
|Temporal extent||dcterms:temporal||See also the work being done on expressing temporal extents|
|Keywords||dcterms:subject||As with topic category, each keyword should be a linked data concept, with its own 'ontology' URI. This is OK if the keywords come from a controlled list - which good keywords should:)|
|distributionInfo -> Distributor.distributor||(could be dcterms:publisher, if the distributor is in fact the publisher)||Link to a URI for the distributor|
|Metadata Standard Name||dct:conformsTo||Conforming to the standard metadata XML is written|
Things not mapped yet
- MD_Metadata.fileIdentifier: Identifier for the Metadata file; this may not make much sense, as with this approach we don't have a metadata file to identify
- MD_Metadata.parentIdentifier: Identifier for the parent Metadata file; as above
- MD_Metadata.language: If your RDF is in XML, can map it to xml:lang on relevant objects (see above for comment on mapping the language)
- MD_Metadata.characterSet: How does RDF handles this? Presumably, if the RDF is in XML it is handled by the XML character encoding.
- MD_Metadata.referenceSystemInfo: Despite its place in the MD_Metadata structure, this describes the reference system of the data. How you handle this depends on the choice you make for geometry in RDF.
Welcome people at the camp to contribute to this page