Open mejackreed opened 8 years ago
I like seeing this as JSON-LD. Thanks for getting this up @drh-stanford!
Yes thanks, looks good! One quick concern I have is increasing the complexity of indexing documents from their native format. Maybe we can use something from here: https://cwiki.apache.org/confluence/display/solr/Uploading+Data+with+Index+Handlers#UploadingDatawithIndexHandlers-TransformingandIndexingCustomJSON ?
Though it does seem like this might not fully meet our need, but the XML approach seems more amenable, as you can provide custom xslt's to transform your data. Sigh.
Also maybe the Data Import Handlers (DIH) are an option?
The layer:id
probably should move into the dct:references
since it's not really an "identifier" as much as it's a parameter to the WMS/WFS protocol.
Not to throw a wrench in things, but we should possible talk about DCAT as an alternative too! https://project-open-data.cio.gov/v1.1/schema/
Below is an example of a JSON-LD format for the GeoBlacklight schema that abstracts out the Solr specific details, and makes a couple other changes. Namely, this example uses
@id
in lieu oflayer_slug_s
, anddc:identifiers
for a set of alternate identifiers and dropsuuid
( #53 ). Note thatdct:references
becomes a proper JSON hash, and all derivative fields are dropped.To ingest the abstracted JSON-LD format into a Solr index would require a shim of harvesting code that derives the fields needed for the Solr implementation (such as
solr_geom
's ENVELOPE syntax from thegeorss:box
field). This harvesting code could also provide a conversion utility from the current version of the JSON schema and the 1.0 abstracted JSON-LD version.There's several other issues with various individual fields, such as moving
layer_id_s
intodct:references
#77, but the example below is meant to illustrate the JSON-LD file format and its implications as an interchange format.The example shows that the JSON-LD'ness is pretty straightforward. Namely, the use of
@context
for the prefixes, and@id
to identify the layer.