The dataset access information in Example 59 is of course technically valid, but would be problematic in an environment where most access information is represented as distributions. The distribution approach for this example would look like:
ga-courts:jc
rdf:type dcat:Dataset ;
rdfs:comment "lots of other stuff here...";
dcat:distribution [
a dcat:Distribution;
rdfs:comment "other properties here... blank node here for convienence";
dcat:accessService ga-courts:jc-esri, ga-courts:jc-wfs, ga-courts:jc-wms;
]
The sparql query to pull the access information with this encoding is completely different from the approach in the example. Clients harvesting or working with metadata that might take either approach would have to write a more complex query or do some other preprocessing. Both approaches work, but hopefully in a given catalog one or the other would be used consistently.
(also comment in #1435 about used of dcterms:conformsTo and dcterms:Type for dcat:DataServices applies here as well)
The dataset access information in Example 59 is of course technically valid, but would be problematic in an environment where most access information is represented as distributions. The distribution approach for this example would look like:
The sparql query to pull the access information with this encoding is completely different from the approach in the example. Clients harvesting or working with metadata that might take either approach would have to write a more complex query or do some other preprocessing. Both approaches work, but hopefully in a given catalog one or the other would be used consistently.
(also comment in #1435 about used of dcterms:conformsTo and dcterms:Type for dcat:DataServices applies here as well)