Alternative to using DCAT Distribution in GeoBlacklight records

gbl-dcat-alternative.md

Alternative to using DCAT Distribution in GeoBlacklight records

DCAT is pretty complex, and I'm wondering if it perhaps is overkill for GeoBlacklight records. If we aren't planning to use the full DCAT standard (and, no, I'm not suggesting that we do), is it really that helpful to use just the DCAT distribution?

The following is an attempt to present metadata, webservices, and downloads as simply as possible, with a top-level property for each of those groupings. These groupings will make it easier to automatically render a list of metadata options, or download options, or webservices options, on the GeoBlacklight page.

Each grouping contains an array of objects which typically have just a type and a url. I've tried to keep the type values as simple as possible. The type value could be used as button or link labels in GeoBlacklight, but this could be overridden by the optional label value, which would be especially useful to distinguish multiple entries of the having the same basic type.

Using a simple url property name saves the trouble of trying to remember whether it should be "accessUrl" or "downloadUrl", etc.

Occasionally there is another property for certain types. WFS, WMS, etc. will have a layerId.

Note that I've avoided using URIs like http://www.opengis.net/cat/csw/csdgm to mean FGDC, since that would add an unnecessary layer of complexity and confusion. (What's the URI for "frustration"?) If someone really wants to convert GBL records to RDF or linked open data, they could write a translator...

Comments welcome! Especially if there is something missing from the representations below that we need to have for GeoBlacklight.

"metadata": [
  {
    "type": "FGDC",
    "url": "https://raw.githubusercontent.com/OpenGeoMetadata/edu.tufts/master/165/242/110/132/fgdc.xml"
  },
  {
    "type": "HTML",
    "url": "https://s3.amazonaws.com/cugir-data/00/77/41/fgdc.html"
  },
  {
    "type": "Data Dictionary",
    "url": "http://64.90.181.107/geonetwork/srv/api/records/1df126d9-a111-4cb3-9f87-d68735b2188e/formatters/xsl-view?root=div&output=html"
},
  {
    "type": "MODS",
    "url": "http://purl.stanford.edu/dp018hs9766.mods"
  },
  {
    "type": "ISO 19139",
    "url": "https://raw.githubusercontent.com/OpenGeoMetadata/edu.stanford.purl/master/cz/128/vq/0535/iso19139.xml"
  }
],

"webservices": [
  {
    "type": "WFS",
    "url": "http://geoserver01.uit.tufts.edu/wfs",
    "layerId": "sde:GISPORTAL.GISOWNER01.CAMBRIDGEGRID100_04"
  },
  {
    "type": "WMS",
    "url": "http://geoserver01.uit.tufts.edu/wms",
    "layerId": "sde:GISPORTAL.GISOWNER01.CAMBRIDGEGRID100_04"
  },
  {
    "type": "WCS",
    "url": "http://kurma-podd1.stanford.edu/geoserver/wcs",
    "layerId": "druid:dp018hs9766"
  },
  {
    "type": "ArcGIS Dynameic Map Layer",
    "url": "http://data.isgs.illinois.edu/arcgis/rest/services/Geology/Glacial_Boundaries/MapServer"
  },
  {
    "type": "ArcGIS Feature Layer",
    "url": "https://geodata.md.gov/imap/rest/services/Transportation/MD_Transit/FeatureServer/18"
  },
  {
    "type": "ArcGIS Image Map Layer",
    "url": "https://mapsweb.lib.purdue.edu/arcgis/rest/services/Purdue/wabashtopo/ImageServer"
  },
  {
    "type": "ArcGIS Tiled Map Layer",
    "url": "http://services.arcgisonline.com/arcgis/rest/services/Specialty/Soil_Survey_Map/MapServer"
  },
  {
    "type": "IIIF",
    "url": "http://libimages.princeton.edu/loris2/pudl0076%2Fmap_pownall%2F00000001.jp2/info.json"
  }
],
"downloads": [
  {
    "type": "Shapefile",
    "url": "https://clearinghouse.isgs.illinois.edu/sites/clearinghouse.isgs/files/Clearinghouse/data/ISGS/Geology/zips/IL_Glacial_Bndys_Py.zip"
  },
  {
    "type": "Shapefile",
    "label": "Generated Shapefile",
    "url": "https://cugir.library.cornell.edu/geoserver/cugir/wfs/?service=wfs&version=2.0.0&request=GetFeature&srsName=EPSG%3A4326&outputformat=SHAPE-ZIP&typeName=cugir007741"
  },
  {
    "type": "GeoTIFF",
    "url": "http://stacks.stanford.edu/file/druid:dp018hs9766/data.zip"
  },
  {
    "type": "HGL",
    "url": "http://hgl.harvard.edu:8080/HGL/HGLOpenDelivery",
    "layerId": "cite:SDE2.G7064_S2_1834_K3"
  },
  {
    "type": "GeoJSON",
    "url": "https://cugir.library.cornell.edu/geoserver/cugir/wfs/?service=wfs&version=2.0.0&request=GetFeature&srsName=EPSG%3A4326&outputformat=application%2Fjson&typeName=cugir007741"
  }
]

A few thoughts:

1. Unfortunately, I think is HGL more of a web service than a download. There is special logic in GBL to get at those files.
2. Thumbnail isn't really a piece of metadata. I would call it a download. Perhaps it's type could be "Thumbnail".
3. I wonder if format is more appropriate than type for downloads? I could see why leaving it as type would be good for consistency, though.

1. I was going to ask about that... (HGL)
2. For datasets, I'd consider thumbnail to be more metadata (it gives you an overview of what's in the data, or at least what it looks like) than download (at least for datasets, since a preview isn't a substitute for the data). But for images, you're right, it is more a download.
3. I went back and forth a few times before giving up and leaving it at type. Partly because format seems less flexible.

Eliot and I took "thumbnail" out of the metadata section, so that the remaining metadata links could all be rendered the same way -- a link or button with a label. The thumbnail requires special handling, so perhaps it should be a top-level property.