Since the First Public Working Draft, the main changes to the DCAT vocabulary have been:
-
-
- addition of a
dcat:Resourceclass for representing any resource than can be included in the catalog, this is - now the super-class ofdcat:Dataset
- - addition of
dcat:DataService, as a sub-class ofdcat:Resource, to support cataloguing service end-points providing access to resources
- - addition of
dcat:DataDistributionService, as a sub-class ofdcat:DataService, + - addition of a
dcat:Resourceclass for representing any resource than can be included in the catalog, this is + now the super-class ofdcat:Dataset
+ - addition of
dcat:DataService, as a sub-class ofdcat:Resource, to support cataloguing service end-points providing access to resources
+ - addition of
dcat:DataDistributionService, as a sub-class ofdcat:DataService, representing service end-points providing access to datasets through their distributions, respectively - addition of ways to representing loosely structured catalogs, where there is no distinction between a dataset and its distributions
- more details for the ways of representing dataset provenance and dataset quality @@ -214,39 +214,39 @@
-
-
dcat:Catalogrepresents a catalog, which is a dataset in which each individual item is a metadata record describing some resource; the scope ofdcat:catalogis collections of metadata about datasets or data services. +dcat:Catalogrepresents a catalog, which is a dataset in which each individual item is a metadata record describing some resource; the scope ofdcat:catalogis collections of metadata about datasets or data services. -
-
dcat:Resourcerepresents an individual item in a catalog. - This class is not intended to be used directly, but is the parent class ofdcat:Dataset,dcat:DataServiceanddcat:Catalog. - Member items in a catalog should be members of one of the sub-classes, or of a sub-class of these, or of a sub-class ofdcat:Resourcedefined in a DCAT application profile or other DCAT application. -dcat:Resourceis effectively an extension point for defining a catalog of any kind of resource. +dcat:Resourcerepresents an individual item in a catalog. + This class is not intended to be used directly, but is the parent class ofdcat:Dataset,dcat:DataServiceand dcat:Catalog. + Member items in a catalog should be members of one of the sub-classes, or of a sub-class of these, or of a sub-class ofdcat:Resourcedefined in a DCAT application profile or other DCAT application. +dcat:Resourceis effectively an extension point for defining a catalog of any kind of resource. -
-
dcat:Datasetrepresents a dataset in a catalog. +dcat:Datasetrepresents a dataset in a catalog. A dataset is a collection of data, published or curated by a single agent. Data comes in many forms, including numbers, words, pixels, imagery, sound and other multi-media, and potentially other types, any of which might be collected into a dataset. -
-
dcat:Distributionrepresents an accessible form or representation of a dataset, for example a downloadable file. +dcat:Distributionrepresents an accessible form of a dataset, for example a downloadable file. -
-
dcat:DataServicerepresents a data service in a catalog. +dcat:DataServicerepresents a data service in a catalog. A data service is a collection of operations, accessible through an interface (API) that provide access to one or more datasets or data processing functions. -
-
dcat:DataDistributionServicerepresents a kind of data service that provides access to distributions of one or more datasets or extracts of datasets. +dcat:DataDistributionServicerepresents a kind of data service that provides access to distributions of one or more datasets or extracts of datasets. -
-
dcat:CatalogRecordrepresents a metadata item in the catalog, primarily concerning the registration information, such as who added the item and when. +dcat:CatalogRecordrepresents a metadata item in the catalog, primarily concerning the registration information, such as who added the item and when. -
- Class: Catalogued resource: In DCAT 2014 [[?VOCAB-DCAT-20140116]] the scope of a
dcat:Catalogwas limited to Datasets. This has been generalized, and properties common to all catalogued resources are now associated with a super-classdcat:Resourcedcat:Catalogwas limited to Datasets. This has been generalized, and properties common to all catalogued resources are now associated with a super-classdcat:Resource- see Issue #172 and Issue #116. The wiki page on Cataloguing data services describes some proposals related to this requirement. -
diff --git a/dcat/rdf/dcat.ttl b/dcat/rdf/dcat.ttl
index 68a027060..2b2230af2 100644
--- a/dcat/rdf/dcat.ttl
+++ b/dcat/rdf/dcat.ttl
@@ -413,7 +413,6 @@ dcat:accessService
rdfs:comment "A site or end-point that gives access to the distribution of the dataset" ;
rdfs:label "data access service" ;
rdfs:range dcat:DataDistributionService ;
- rdfs:subPropertyOf dcat:accessURL ;
skos:changeNote "New property in this revision of DCAT" ;
skos:editorialNote "Status: Property accepted by DCAT revision team, but details of definition and constraints not yet resolved." ;
.
@@ -633,6 +632,7 @@ dcat:endpointURL
rdf:type owl:ObjectProperty ;
rdfs:comment "The URI of the service end-point" ;
rdfs:domain dcat:DataService ;
+ rdfs:range rdfs:Resource ;
rdfs:label "service end-point" ;
skos:changeNote "New property in this revision of DCAT" ;
skos:editorialNote "Status: Property accepted by DCAT revision team, but details of definition and constraints not yet resolved." ;
diff --git a/profiles/index.html b/profiles/index.html
index 0178a851d..67d3d9dba 100644
--- a/profiles/index.html
+++ b/profiles/index.html
@@ -49,30 +49,35 @@
Overview of DXWG documents on profiles
Introduction
This section is non-normative.
- A profile is generally understood as representing a point of view. In information technology, profiles may also + A profile can be understood as an outline of some "thing" when seen from a specific point of view. + Also, Profiling is the task of distilling the essential aspects or character of something, such as a person, + from a specific angle. In the craft domain, a profile is taken by a tool that matches itself in detail + to the contours of a 3-dimensional object and returns a 2-dimensional accurate representation from which other + formable materials can be constrained and fashioned to that profile, or matched with it to determine how accurately + it portrays the original 3-dimensional object from which the profile was taken. +
++ In the same sense then, information entities can be viewed from different perspectives and in order to prepare + them for specific uses they are frequently tested for their goodness of fit to some pattern, or the pattern + can be provided prior to the gathering of the information to provide some constraint to ensure adequacy and + appropriateness of that information asset to the job in hand. +
++ In information technology, profiles may also support the data needs of specific applications. Profiling is often the work of a community interested in interoperability and data exchange. We define a profile generally as named set of constraints on one or more identified base specifications.
- Communities create and use data standards to ensure interoperability for information exchange. Although members - of a community may use the same basic standard schema, it is very common for different subsets within the larger - community to need some further specification of the data they create to meet their own needs. To continue to - support interoperability of their data with others, these community members need to express the specifics of - their implementation of the data schema. Profiles serve this purpose. Profiles enumerate vocabulary terms, - cardinality, and validation rules, and can also include descriptions of the rules used by creators to make - decisions regarding their data elements. -
-- Good metadata practice begins with the builders of vocabularies and ontologies. Builders of vocabularies and - ontologies are encouraged to make their work as broadly applicable as possible so as to maximize future adoption. + Good data practice generally begins with vocabulary and ontology designers who + are encouraged to make their work as broadly applicable as possible so as to maximize future adoption. As a result, vocabularies and ontologies typically define a data model using minimal semantics. For example, DCAT [[vocab-dcat-2]] defines the concept of a dataset as an abstract entity with distributions and data services - as means of accessing data; it is silent on whether a distribution should be in a particular serialization, or - set of serializations. It is also silent on how data services should be configured. While it states that the + as means of accessing data; there is no mention of whether a distribution should be in a particular serialization, or + set of serializations, nor of how data services should be configured. While it states that the value of dcat:theme should be a SKOS [[skos-reference]] concept, it does not specify a particular SKOS concept - scheme, and so on. Other vocabularies, such as Dublin Core Terms [[DCTERMS]], are equally parsimonious in their - prescriptions of how they should be used. This means that data models and methods of working can be applied in + scheme, and so on. Other vocabularies, such as Dublin Core Terms [[DCTERMS]], are similarly for general use. + This means that data models and methods of working can be applied in different circumstances than those in which the original definition work was carried out and, in that sense, these promote broad interoperability.
@@ -87,21 +92,18 @@Introduction
this property MUST be from this specific code list".- This document is about how to formulate and communicate profiles. + This document is about how to formulate and communicate profiles and the ways in which profiles can be + identified and related to each other.
- -- (Antoine:) Nick suggested to reuse some elements of the F2F3 outline as a 'motivation' section. I believe the - following ones could be mentioned in intro: ---
-
- Communities, national identity on data standards, domains of activity -
- Functions: consensus; sharing; search; etc. -
- Profile Definition
++ - - + +Definitions
++ We recognise that the term 'profile' occurs in several domains, and that there are a range of definitions + available from different communities. We have taken this variability into account but for the purpose of this document we + are using the following definitions: +
- profile
-
@@ -117,57 +119,84 @@
Profile Definition
Source: deliberations of the DXWG. See ProfileContext wiki page.
+ - profiling +
-
+
+ The act of creating a profile - an activity that has been undertaken by many communities with a range of formalisms. +
+
-
+
See comment 408916364+Profiles defined
diff --git a/profilesont/ns.html b/profilesont/ns.html new file mode 100644 index 000000000..9ac49d88a --- /dev/null +++ b/profilesont/ns.html @@ -0,0 +1,25 @@ + + + +Profiles Ontology Namespace + + + + + + ++++
++
+ This is a namespace for use with the Profiles Ontology (PROF). + See the ontology itself in Turtle or RDF/XML.
+
+ + Webmaster
+ Last modified: $Id: ns.html,v 1.4 2019-02-13 16:37:18 ncar Exp $ + + +
DCAT scope
DCAT is based around eight main classes:DCAT scope
Descriptions of datasets and data services can be included in a catalog. A catalog is a kind of dataset whose member items are descriptions of datasets and data services. Other types of thing might also be catalogued, but the scope of DCAT is currently limited to datasets and data services. - To extend the scope of a catalog beyond datasets and data services it is recommended to define additional sub-classes ofdcat:Resource in a DCAT application profile or other DCAT application.
- To extend the scope of service descriptions beyond data distribution services it is recommended to define additional sub-classes of dcat:DataService in a DCAT application profile or other DCAT application.
+ To extend the scope of a catalog beyond datasets and data services it is recommended to define additional sub-classes of dcat:Resource in a DCAT application profile or other DCAT application.
+ To extend the scope of service descriptions beyond data distribution services it is recommended to define additional sub-classes of dcat:DataService in a DCAT application profile or other DCAT application.
DCAT scope
Catalogs of other kinds of things might be designed following the DCAT pattern, e.g. dealing with facilities, instruments, samples and specimens, other physical artefacts, events or activities.
- These are currently out of scope for DCAT, but might be defined through further sub-classes of dcat:Resource, which could be specified in a DCAT application profile or other DCAT application.
+ These are currently out of scope for DCAT, but might be defined through further sub-classes of dcat:Resource, which could be specified in a DCAT application profile or other DCAT application.
A CatalogRecord describes an entry in the catalog. Notice that while dcat:Resource represents the dataset or service itself, dcat:CatalogRecord is the record that describes the registration of an item in the catalog. The use of explicit dcat:CatalogRecord is considered optional. It is used to capture provenance information about entries in a catalog explicitly. If this is not necessary then dcat:CatalogRecord can be safely ignored.
A CatalogRecord describes an entry in the catalog. Notice that while dcat:Resource represents the dataset or service itself, dcat:CatalogRecord is the record that describes the registration of an item in the catalog. The use of explicit dcat:CatalogRecord is considered optional. It is used to capture provenance information about entries in a catalog explicitly. If this is not necessary then dcat:CatalogRecord can be safely ignored.
RDF considerations
@@ -586,7 +586,7 @@Vocabulary specification
RDF representation
-+
The DCAT RDF representation is modularized into several files or graphs to help users access a version of DCAT with only the alignments that they need. This mechanism can also be used to capture different levels of axiomatization, though the status of such proposals has not been finalized. See Issue #134 and the issues enumerated below. @@ -877,7 +877,7 @@
Class: Catalogued Resource
This class carries properties common to all catalogued resources, including datasets and data services. It is strongly recommended to use a more specific sub-class when available. -dcat:Resourcedcat:Resource is an extension point that enables the definition of any kind of catalog. Additional subclasses may be defined in a DCAT application profile or other DCAT application for catalogs of other kinds of resourcesProperty: conforms to
- dct:Standard is defined as "A basis for comparison; a reference point against which other things can be evaluated." The target resource is not restricted to formal standards issued by bodies like ISO and W3C. In this context, it is any resource that specifies one or more aspects of the catalogued resource content, for example schema, semantics, syntax, usage guidelines, file format, or specific serialization. The meaning of conformance is determined by provisions in the target standard.
+ dct:Standard is defined as "A basis for comparison; a reference point against which other things can be evaluated." The target resource is not restricted to formal standards issued by bodies like ISO and W3C. In this context, it is any resource that specifies one or more aspects of the catalogued resource content, for example schema, semantics, syntax, usage guidelines, file format, or specific serialization. The meaning of conformance is determined by provisions in the target standard.
Property: resource creator
New property added in this revision of DCAT, specifically added when considering the data citation requirement and
- added to the dcat:Resourcedcat:Resource class, as the Dataset superclass.
@@ -1828,7 +1828,7 @@
Property: access address
- dcat:accessURL generally matches the property-chain dcat:accessService/dcat:endpointURL. In the RDF representation of DCAT this is axiomatized as an OWL property-chain axiom.
+ dcat:accessURL matches the property-chain dcat:accessService/dcat:endpointURL. In the RDF representation of DCAT this is axiomatized as an OWL property-chain axiom.
Property: access service
dcat:accessURLdcat:DataDistributionServicedcat:accessService SHOULD be used to link to a description of a dcat:DataDistributionService that can provide access to this distribution.Property: endpoint address
| RDF Property: | dcat:endpointURL |
|---|---|
| Definition: | The IRI of the service end-point. |
| Definition: | The location of the service end-point (an IRI). |
| Domain: | dcat:DataService |
| Range: | xsd:anyURI |
| Range: | rdfs:Resource |
Property: endpoint description
rdfs:Resource Property: hadRole
prov:Attribution or dcat:Relationshipprov:Attribution or dcat:Relationshipdcat:RoleClass: Role
Dereferenceable identifiers
-The scientific and data provider communities use a number of different identifiers for publications, authors and data. DCAT primarily relies on persistent HTTP URIs as an effective way of making identifiers actionable. Notably, quite a few identifier schemes can be encoded as dereferenceable HTTP URIs, and some of them are also returning machine-readable metadata (e.g., DOIs, ORCIDs). Regardless, data providers still might need to refer to legacy identifiers, non-HTTP dereferenceable identifiers, locally minted or third-party-provided identifiers. In these cases, [[?DC11]] and [[?VOCAB-ADMS]] can be of use.
-The property dct:identifier explicitly indicates HTTP URIs as well as legacy identifiers. In the following examples, dct:identifier identifies a dataset, but it can similarly be used with any kind of resources.
The scientific and data provider communities use a number of different identifiers for publications, authors and data. DCAT primarily relies on persistent HTTP URIs as an effective way of making identifiers actionable. Notably, quite a few identifier schemes can be encoded as dereferenceable HTTP URIs, and some of them are also returning machine-readable metadata (e.g., DOIs [[?ISO-26324]] and ORCIDs). Regardless, data providers still might need to refer to legacy identifiers, non-HTTP dereferenceable identifiers, locally minted or third-party-provided identifiers. In these cases, [[?DCTERMS]] and [[?VOCAB-ADMS]] can be of use.
+The property dct:identifier explicitly indicates HTTP URIs as well as legacy identifiers. In the following examples, dct:identifier identifies a dataset, but it can similarly be used with any kind of resources.
<https://example.org/id> a dcat:Dataset; dct:identifier "https://example.org/id"^^xsd:anyURI .-
Proxy dereferenceable URIs can be used when resources have not HTTP dereferenceable IDs. For example, in the following, https://example.org/proxyid is a proxy for id.
Proxy dereferenceable URIs can be used when resources have not HTTP dereferenceable IDs. For example, in the following example, https://example.org/proxyid is a proxy for id.
<https://example.org/proxyid> a dcat:Dataset;
dct:identifier "id"^^xsd:string
.
- The property adms:identifier [[?VOCAB-ADMS]] can express other locally minted identifiers or external identifiers, like DOI [[?ISO-26324]], ELI etc., as long as they are globally unique and stable.
The following example uses adms:schemaAgency and dct:creator to represent the authority that defines the identifier scheme (e.g., the DOI foundation in the example), adms:schemaAgency is used when the authority has no URI associated.
+
The property adms:identifier [[?VOCAB-ADMS]] can express other locally minted identifiers or external identifiers, like DOI, ELI, arΧiv for creative works and ORCID, VIAF, ISNI for actors such as authors and publishers, as long as the identifiers are globally unique and stable.
The following example uses adms:schemaAgency and dct:creator to represent the authority that defines the identifier scheme (e.g., the DOI foundation in the example), adms:schemaAgency is used when the authority has no URI associated. The CrossRef and DataCite display guidelines recommend displaying DOIs as full URL link in the form https://doi.org/10.xxxx/xxxxx/.
<https://example.org/id> a dcat:Dataset;
- adms:identifier <https://example.org/iddoi> .
- .
+ adms:identifier <https://example.org/iddoi> ;
+ dct:publisher <https://example.org/PoelenJorritH>.
-<https://example.org/iddoi> rdf:type adms:Identifier ;
+<https://example.org/iddoi> a adms:Identifier ;
+ # reading https://www.w3.org/TR/skos-reference/#notations more than one skos:notation can be set
skos:notation "https://doi.org/10.5281/zenodo.1486279"^^xsd:anyURI;
- # reading https://www.w3.org/TR/skos-reference/#notations more than one skos:notation can be set
- skos:notation "info:doi/10.5281/zenodo.1486279"^^xsd:anyURI ;
# the authority/agency defining the identifier scheme, used if the agency has no URI
adms:schemaAgency "International DOI Foundation" ;
# the authority/agency defining the identifier scheme, used if the agency has URI
- dct:creator ex:InternationalDOIFundation.
+ dct:creator ex:InternationalDOIFundation .
-ex:InternationalDOIFundation a dct:Agent;
+ex:InternationalDOIFundation a foaf:Organization ;
rdfs:label "International DOI Foundation";
foaf:homepage <https://www.doi.org/> .
-
- The example does not represent the authority responsible for assigning and maintaining identifiers using that scheme (e.g., Zenodo) as naming the registrant goes against the philosophy of DOI, where the sub-spaces are abstracted from the organisation that registers them, with the advantage that DOIs don't change when the organisation changes or the responsibility for that sub-space is handed over to someone else.
+<https://example.org/PoelenJorritH> a foaf:Person; + foaf:name "Jorrit H. Poelen" ; + adms:identifier <https://example.org/PoelenJorritHID> . + +<https://example.org/PoelenJorritHID> a adms:Identifier; + skos:notation "https://orcid.org/0000-0003-3138-4118"^^xsd:anyURI ; + # the authority/agency defining the identifier scheme, used if the agency has no URI + adms:schemaAgency "ORCID" . + -When the HTTP dereferenceable ID returns an RDF/OWL description for the dataset, the use of owl:sameAs might be consider. For example,
The example does not represent the authority responsible for assigning and maintaining identifiers using that scheme (e.g., Zenodo) as naming the registrant goes against the philosophy of DOI, where the sub-spaces are abstracted from the organisation that registers them, with the advantage that DOIs do not change when the organization changes or the responsibility for that sub-space is handed over to someone else. The example shows a locally minted identifier for the creator of the dataset (e.g., https://example.org/PoelenJorritHID) and its correspondent ORCID identifier (e.g., https://orcid.org/0000-0003-3138-4118).
When the HTTP dereferenceable ID returns an RDF/OWL description for the dataset, the use of owl:sameAs might be considered. For example,
<https://example.org/id> a dcat:Dataset; @@ -2335,8 +2341,9 @@Dereferenceable identifiers
when dereferenced with media type text/turtle, https://doi.org/10.5281/zenodo.1486279 returns a [[?SCHEMA-ORG]] description for the dataset, which might dynamically enrich the description provided by https://example.org/id.
The need to distinguish between primary and alternative (or legacy) identifiers for a dataset within DCAT has been posed as a requirement. However, it is very much application-specific and would be better addressed in application profiles rather than mandating a general approach.
@@ -2345,7 +2352,7 @@Dereferenceable identifiers
Indicating common identifier types
- If identifiers are not HTTP dereferenceable, common identifier types can be served as RDF datatypes or custom OWL datatypes for the sake of interoperability, see ex:type in the following example.
If identifiers are not HTTP dereferenceable, common identifier types can be served as RDF datatypes or custom OWL datatypes for the sake of interoperability, see ex:type in the following example.
<https://example.org/id> a dcat:Dataset; @@ -2360,7 +2367,7 @@-Indicating common identifier types
dcterms:issued "2001-09-12"^^xsd:date .
If a registered URI type is used (following [[?RFC3986]], Section 3.1), the identifier scheme is part of the URI; thus indicating a separate identifier scheme in 'type' is redundant. For example, DOI is registered as a namespace in the info URI scheme (see DOI FAQ #11), so according to [[?RFC3986]] URI it should be encoded as in the following
If a registered URI type is used (following [[?RFC3986]], Section 3.1), the identifier scheme is part of the URI; thus indicating a separate identifier scheme in 'type' is redundant. For example, DOI is registered as a namespace in the info URI scheme [[IANA-URI-SCHEMES]] (see DOI FAQ #11), so according to [[?RFC3986]], it should be encoded as in the following
<https://example.org/sid> rdf:type adms:Identifier ; # the actual id @@ -2809,7 +2816,7 @@Relationships between datasets and other resources
- Note: The property dcat:qualifiedRelation and association-class dcat:Relationship follow the pattern established in W3C [[!PROV-O]] and described in the section Qualified Terms. + The property dcat:qualifiedRelation and association-class dcat:Relationship follow the pattern established in W3C [[!PROV-O]] and described in the section Qualified Terms. However, PROV-O is activity-centric, and does not support Entity-Entity relations except for the single case of 'was derived from', thus necessitating the new elements shown here to support the general case.
Relationships between datasets and other resources
Provenance patterns
-+
In this chapter it is planned to describe patterns for the use of the [[!PROV-O]] vocabulary to support the various provenance-related requirements. A number of requirements identify the need to provide better support for Dataset and Record provenance - see Issue #78, @@ -2834,7 +2841,7 @@
Provenance patterns
Many of the requirements can be satisfied by using capabilities from the [[?PROV-O]] ontology, - in particular by treatingdcat:Resource and/or dcat:CatalogRecord a sub-class of prov:Entity.
+ in particular by treating dcat:Resource and/or dcat:CatalogRecord a sub-class of prov:Entity.
See Issue #128 for the relevant discussion. A preliminary alignment of DCAT with PROV-O is available.
See the wiki page on Provenance Patterns for more discussion.
@@ -3614,17 +3621,17 @@ Loosely structured catalog
:d33937 -dct:description "A set of RDF graphs representing the International [Chrono]stratigraphic Chart, ..." ; -dct:identifier "https://doi.org/10.25919/5b4d2b83cbf2d"^^xsd:anyURI ; -dct:creator <https://orcid.org/0000-0002-3884-3420>; -dct:relation <https://vocabs.ands.org.au/viewById/196> ; -dct:relation :ChronostratChart2017-02.pdf ; -dct:relation :ChronostratChart2017-02.jpg ; -dct:relation :timescale.zip ; -dct:relation :isc2017.jsonld ; -dct:relation :isc2017.nt ; -dct:relation :isc2017.rdf ; -dct:relation :isc2017.ttl ; + dct:description "A set of RDF graphs representing the International [Chrono]stratigraphic Chart, ..." ; + dct:identifier "https://doi.org/10.25919/5b4d2b83cbf2d"^^xsd:anyURI ; + dct:creator <https://orcid.org/0000-0002-3884-3420>; + dct:relation <https://vocabs.ands.org.au/viewById/196> ; + dct:relation :ChronostratChart2017-02.pdf ; + dct:relation :ChronostratChart2017-02.jpg ; + dct:relation :timescale.zip ; + dct:relation :isc2017.jsonld ; + dct:relation :isc2017.nt ; + dct:relation :isc2017.rdf ; + dct:relation :isc2017.ttl ; .@@ -3634,43 +3641,150 @@
Loosely structured catalog
:d33937 -rdf:type dcat:Dataset ; -dct:description "A set of RDF graphs representing the International [Chrono]stratigraphic Chart, ..." ; -dct:identifier "https://doi.org/10.25919/5b4d2b83cbf2d"^^xsd:anyURI ; -dct:relation <https://vocabs.ands.org.au/viewById/196> ; -dct:relation :ChronostratChart2017-02.pdf ; -dct:relation :ChronostratChart2017-02.jpg ; -dct:relation :timescale.zip ; -dcat:distribution :d33937-jsonld ; -dcat:distribution :d33937-nt ; -dcat:distribution :d33937-rdf ; -dcat:distribution :d33937-ttl ; + rdf:type dcat:Dataset ; + dct:description "A set of RDF graphs representing the International [Chrono]stratigraphic Chart, ..." ; + dct:identifier "https://doi.org/10.25919/5b4d2b83cbf2d"^^xsd:anyURI ; + dct:relation <https://vocabs.ands.org.au/viewById/196> ; + dct:relation :ChronostratChart2017-02.pdf ; + dct:relation :ChronostratChart2017-02.jpg ; + dct:relation :timescale.zip ; + dcat:distribution :d33937-jsonld ; + dcat:distribution :d33937-nt ; + dcat:distribution :d33937-rdf ; + dcat:distribution :d33937-ttl ; . :d33937-jsonld rdf:type dcat:Distribution ; -dcat:downloadURL :isc2017.jsonld ; -dcat:byteSize "698039"^^xsd:decimal ; -dcat:mediaType <https://www.iana.org/assignments/media-types/application/ld+json> ; + dcat:downloadURL :isc2017.jsonld ; + dcat:byteSize "698039"^^xsd:decimal ; + dcat:mediaType <https://www.iana.org/assignments/media-types/application/ld+json> ; . :d33937-nt rdf:type dcat:Distribution ; -dcat:downloadURL :isc2017.nt ; -dcat:byteSize "2047874"^^xsd:decimal ; -dcat:mediaType <https://www.iana.org/assignments/media-types/application/n-triples> ; + dcat:downloadURL :isc2017.nt ; + dcat:byteSize "2047874"^^xsd:decimal ; + dcat:mediaType <https://www.iana.org/assignments/media-types/application/n-triples> ; . :d33937-rdf rdf:type dcat:Distribution ; -dcat:downloadURL :isc2017.rdf ; -dcat:byteSize "1600569"^^xsd:decimal ; -dcat:mediaType <https://www.iana.org/assignments/media-types/application/rdf+xml> ; + dcat:downloadURL :isc2017.rdf ; + dcat:byteSize "1600569"^^xsd:decimal ; + dcat:mediaType <https://www.iana.org/assignments/media-types/application/rdf+xml> ; . :d33937-ttl rdf:type dcat:Distribution ; -dcat:downloadURL :isc2017.ttl ; -dcat:byteSize "531703"^^xsd:decimal ; -dcat:mediaType <https://www.iana.org/assignments/media-types/text/turtle> ; + dcat:downloadURL :isc2017.ttl ; + dcat:byteSize "531703"^^xsd:decimal ; + dcat:mediaType <https://www.iana.org/assignments/media-types/text/turtle> ; .
This example is available from the DXWG code repository at csiro-dap-examples.ttl
+ ++ Additional detail about the nature of the related resources can be given using suitable elements from other RDF vocabularies, along with dataset descriptors from DCAT. For example, the example above might be more fully expressed as follows (embedded comments explain the different resources in the graph): +
+ ++dap:d33937 + rdf:type dcat:Dataset ; + rdfs:comment "The data" ; + dct:conformsTo <http://resource.geosciml.org/ontology/timescale/gts> ; + dct:description "A set of RDF graphs representing the International [Chrono]stratigraphic Chart [...]" ; + dct:identifier "https://doi.org/10.25919/5b4d2b83cbf2d" ; + dct:issued "2018-07-07"^^xsd:date ; + dct:license <https://creativecommons.org/licenses/by/4.0/> ; + dct:publisher <http://www.csiro.au> ; + dct:relation <http://stratigraphy.org/ICSchart/ChronostratChart2017-02.jpg> ; + dct:relation <http://stratigraphy.org/ICSchart/ChronostratChart2017-02.pdf> ; + dct:relation [ + rdf:type dcat:Dataset ; + dct:conformsTo <https://www.w3.org/TR/owl2-overview/> ; + rdfs:comment "The ontology used for the data" ; + dct:description "This is an RDF/OWL representation of the GeoSciML Geologic Timescale model ..." ; + dct:issued "2011-01-01"^^xsd:date ; + dct:modified "2017-04-28"^^xsd:date ; + dct:title "Geologic Timescale model" ; + dct:type <http://purl.org/adms/assettype/DomainModel> ; + dcat:distribution [ + rdf:type dcat:Distribution ; + rdfs:comment "RDF/XML representation of the ontology used for the data" ; + dcat:downloadURL <http://resource.geosciml.org/ontology/timescale/gts.rdf> ; + dcat:mediaType <https://www.iana.org/assignments/media-types/application/rdf+xml> ; + ] ; + dcat:distribution [ + rdf:type dcat:Distribution ; + rdfs:comment "TTL representation of the ontology used for the data" ; + dcat:downloadURL <http://resource.geosciml.org/ontology/timescale/gts.ttl> ; + dcat:mediaType <https://www.iana.org/assignments/media-types/text/turtle> ; + ] ; + dcat:distribution [ + rdf:type dcat:Distribution ; + rdfs:comment "Webpage describing the ontology used for the data" ; + dcat:downloadURL <http://resource.geosciml.org/ontology/timescale/gts.html> ; + dcat:mediaType <https://www.iana.org/assignments/media-types/text/html> ; + ] ; + dcat:landingPage <http://resource.geosciml.org/ontology/timescale/gts> ; + ] ; + dcat:distribution [ + rdf:type dcat:Distribution ; + dct:conformsTo <https://www.w3.org/TR/rdf-schema/> ; + rdfs:comment "RDF representation of the data" ; + dcat:accessService [ + rdf:type dcat:DataDistributionService ; + dct:conformsTo <https://www.w3.org/TR/sparql11-query/> ; + dct:title "International Chronostratigraphic Chart hosted at Research Vocabularies Australia" ; + rdfs:comment "Service that supports queries to obtain RDF representations of subsets of the data" ; + dcat:endpointURL <http://vocabs.ands.org.au/repository/api/sparql/csiro_international-chronostratigraphic-chart_2017> ; + dcat:landingPage <https://vocabs.ands.org.au/viewById/196> ; + ] ; + ] ; + dcat:distribution [ + rdf:type dcat:Distribution ; + dct:identifier "isc2017.jsonld" ; + rdfs:comment "JSON-LD serialization of the RDF representation of the entire dataset" ; + dcat:mediaType <https://www.iana.org/assignments/media-types/application/ld+json> ; + ] ; + dcat:distribution [ + rdf:type dcat:Distribution ; + dct:identifier "isc2017.nt" ; + rdfs:comment "N-Triples serialization of the RDF representation of the entire dataset" ; + dcat:mediaType <https://www.iana.org/assignments/media-types/application/n-triples> ; + ] ; + dcat:distribution [ + rdf:type dcat:Distribution ; + dct:identifier "isc2017.rdf" ; + rdfs:comment "RDF/XML serialization of the RDF representation of the entire dataset" ; + dcat:mediaType <https://www.iana.org/assignments/media-types/application/rdf+xml> ; + ] ; + dcat:distribution [ + rdf:type dcat:Distribution ; + dct:identifier "isc2017.ttl" ; + rdfs:comment "TTL serialization of the RDF representation of the entire dataset" ; + dcat:mediaType <https://www.iana.org/assignments/media-types/text/turtle> ; + ] ; + dcat:landingPage <https://data.csiro.au/dap/landingpage?pid=csiro:33937> ; +. + +<http://stratigraphy.org/ICSchart/ChronostratChart2017-02.jpg> + rdf:type foaf:Document ; + dct:type <http://purl.org/dc/dcmitype/Image> ; + dct:format <https://www.iana.org/assignments/media-types/img/jpeg> ; + dct:description "Coloured image representation of the International Chronostratigraphic Chart" ; + dct:issued "2017-02-01"^^xsd:date ; + dct:title "International Chronostratigraphic Chart" ; +. +<http://stratigraphy.org/ICSchart/ChronostratChart2017-02.pdf> + rdf:type foaf:Document ; + dct:type <http://purl.org/dc/dcmitype/Image> ; + dct:format <https://www.iana.org/assignments/media-types/application/pdf> ; + dct:description "Coloured image representation of the International Chronostratigraphic Chart" ; + dct:issued "2017-02-01"^^xsd:date ; + dct:title "International Chronostratigraphic Chart" ; +. ++
+ This example is available from the DXWG code repository at csiro-stratchart.ttl +
+Data services
More examples needed
-+
This section will contain more examples on the use of DCAT.
@@ -3898,7 +4012,7 @@