<div dir="ltr">Hi all, <div>This a very interesting discussion. Thanks for your answers about the choice of Dublin Core, Darren. I also like the fact that it is widely used outside of the geospatial realm. </div><div><br></div>
<div>One further question/comment: In looking at the semantic definition of dc:source, I wonder if dc:provenance might be a better fit for the source institution? In the DC definitions, dc:source is "<span style="color:rgb(0,0,0);font-family:Verdana,Arial,'Arial Unicode MS',Helvetica,sans-serif">A Reference to a resource from which the present resource is derived," which could be stretched to include an institution, but does seem like a bit of a stretch. Provenance, on the other hand, is more about the chain of custody, and seems to me like perhaps a better fit.</span></div>
<div><span style="color:rgb(0,0,0);font-family:Verdana,Arial,'Arial Unicode MS',Helvetica,sans-serif"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Verdana,Arial,'Arial Unicode MS',Helvetica,sans-serif">Best,</span></div>
<div><font color="#000000" face="Verdana, Arial, Arial Unicode MS, Helvetica, sans-serif">Susan</font></div><div><font color="#000000" face="Verdana, Arial, Arial Unicode MS, Helvetica, sans-serif"><br></font></div><div>
<font color="#000000" face="Verdana, Arial, Arial Unicode MS, Helvetica, sans-serif">Susan Powell</font></div>
<div><font color="#000000" face="Verdana, Arial, Arial Unicode MS, Helvetica, sans-serif">GIS & Map Librarian</font></div><div><font color="#000000" face="Verdana, Arial, Arial Unicode MS, Helvetica, sans-serif">UC Berkeley</font></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 14, 2014 at 10:30 AM, Steve Richard <span dir="ltr"><<a href="mailto:steve.richard@azgs.az.gov" target="_blank">steve.richard@azgs.az.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am looking through Chris's comments sent to Kim and Darren, and the discussion about how to put distribution information in metadata for service-based access to datasets is one I've wrestled with as well. There's a current activity at <a href="http://github/cat-interop" target="_blank">http://github/cat-interop</a> , and a related discussion in the <a href="http://data.gov" target="_blank">data.gov</a> projectOpenData (<a href="https://github.com/project-open-data/project-open-data.github.io/issues/291" target="_blank">https://github.com/project-open-data/project-open-data.github.io/issues/291</a>).<br>
<br>
My own thinking about this is summarized in a discussion paper on gitHub (<a href="https://github.com/usgin/usginspecs/raw/master/MetadataAsHypermediaApp.docx" target="_blank">https://github.com/usgin/usginspecs/raw/master/MetadataAsHypermediaApp.docx</a> , MS Word doc... :( )<br>
<br>
I think the best course of action for putting links to resources in Dublin Core XML (should they be in dct:references or in dc:relation???) is to make the dc element content a JSON blob that provides a machine-actionable description of the link<br>
<br>
<br>
Here's a few examples:<br>
Here's some examples of what the content of a dct:references (or dc:relation) element would look like if a JSON representation of this link representation was used as the encoding for a machine actionable link:<br>
<br>
{ "link":"<a href="http://mirador.gsfc.nasa.gov/mirador-plugin-search.xml" target="_blank">http://mirador.gsfc.nasa.gov/mirador-plugin-search.xml</a>",<br>
"rel":"documentation",<br>
"title":"OpenSearch description for accessing this collection",<br>
"type":"application/opensearchdescription+xml",<br>
"profile":"<a href="http://commons.esipfed.org/ns/discovery/1.2/collectionCast#" target="_blank">http://commons.esipfed.org/ns/discovery/1.2/collectionCast#</a>",<br>
"description":"point to a search service from a ESIP collection cast entry" }<br>
<br>
{ "link":"<a href="http://kgs.uky.edu/arcgis/services/aasggeothermal/ARSeismicHypocenters/MapServer/WFSServer?request=GetFeature&service=WFS&TypeName=Hypocenter&MaxFeatures=10" target="_blank">http://kgs.uky.edu/arcgis/services/aasggeothermal/ARSeismicHypocenters/MapServer/WFSServer?request=GetFeature&service=WFS&TypeName=Hypocenter&MaxFeatures=10</a>",<br>
"rel":"download",<br>
"title":"Example WFS getFeature request for NGDS seismic event hypocenters",<br>
"type":"application/gml+xml",<br>
"overlayAPI":"OGC:WFS",<br>
"profile":"<a href="http://stategeothermaldata.org/uri-gin/aasg/xmlschema/hypocenter/1.7" target="_blank">http://stategeothermaldata.org/uri-gin/aasg/xmlschema/hypocenter/1.7</a>",<br>
"parameter":"typeName=Hypocenter" }<br>
<br>
{ "link":"<a href="http://kgs.uky.edu/arcgis/services/aasggeothermal/ARSeismicHypocenters/MapServer/WFSServer?request=GetCapabilities" target="_blank">http://kgs.uky.edu/arcgis/services/aasggeothermal/ARSeismicHypocenters/MapServer/WFSServer?request=GetCapabilities</a>",<br>
"rel":"documentation",<br>
"title":"Get the capabilities document for seismic event hypocenter WFS service",<br>
"type":"application/xml",<br>
"overlayAPI":"OGC:WFS" }<br>
<br>
/* OpenSearch link in ESIP discovery/data cast<br>
<br>
{ "link":"http:// <a href="http://mirador.gsfc.nasa.gov/cgi-bin/mirador/collectionlist.pl?keyword={searchTerms}" target="_blank">http://mirador.gsfc.nasa.gov/cgi-bin/mirador/collectionlist.pl?keyword={searchTerms}</a>",<br>
"rel":"search",<br>
"title":"Search template for Mirador keyword search",<br>
"type":"application/atom+xml",<br>
"template":"<a href="http://a9.com/-/spec/opensearch/1.1" target="_blank">http://a9.com/-/spec/opensearch/1.1</a>",<br>
"profile":"<a href="http://commons.esipfed.org/ns/discovery/1.2/collectionCast#" target="_blank">http://commons.esipfed.org/ns/discovery/1.2/collectionCast#</a>",<br>
"description":"Search service for a collection cast entry" }<br>
<br>
Stephen M Richard<br>
Arizona Geological Survey<br>
416 W. Congress #100<br>
Tucson, AZ<br>
AZGS: 520-770-3500<br>
Office: 520-209-4127<br>
FAX: 520-770-3505<br>
<div class=""><br>
> -----Original Message-----<br>
> From: <a href="mailto:opengeoportal-request@elist.tufts.edu">opengeoportal-request@elist.tufts.edu</a> [mailto:<a href="mailto:opengeoportal-">opengeoportal-</a><br>
> <a href="mailto:request@elist.tufts.edu">request@elist.tufts.edu</a>] On Behalf Of Darren Hardy<br>
> Sent: Thursday, March 13, 2014 1:43 PM<br>
> To: <a href="mailto:opengeoportal@elist.tufts.edu">opengeoportal@elist.tufts.edu</a><br>
> Subject: Re: GeoBlacklight Solr schema<br>
><br>
</div><div><div class="h5">> Hi Chris,<br>
><br>
> Thanks so much for the great feedback. I've attempted to address your feedback<br>
> below...<br>
><br>
> On Mar 13, 2014, at 11:38 AM, Barnett, Christopher S<br>
> <<a href="mailto:Christopher.Barnett@tufts.edu">Christopher.Barnett@tufts.edu</a>> wrote:<br>
><br>
> > Hi Kim and Darren,<br>
> ><br>
> > I think this looks great! In particular I'm happy to see the use of Dublin Core,<br>
> as it seems like a good fit for the terms we're hoping to search. It also has good<br>
> mappings with CSW core queryables, which might become important. Building<br>
> on an existing standard also has the potential to aid in compatibility with other<br>
> similar projects.<br>
> ><br>
> > I have a few specific questions, most of which have to do with the layer<br>
> specific portions. Some of these are questions that I've also been asking myself<br>
> about the current OGP schema, as I've thought about ways in which it may be<br>
> improved.<br>
> ><br>
> >> dc_relation_url: URL to related item: Multiple values allowed. Example:<br>
> >> "<a href="http://purl.stanford.edu/vr593vj7147" target="_blank">http://purl.stanford.edu/vr593vj7147</a>"<br>
> ><br>
> > In the example you've given, the url is to the (ISO) metadata for the data<br>
> object? Is this common convention in Dublin Core? I'm wondering if there is<br>
> room in the schema for semantics to define what type of object is being linked<br>
> to.<br>
> ><br>
><br>
> Kim elaborated on this point in an earlier email. The semantics of DC.Relation is<br>
> quite vague unfortunately. I like the idea of looking at the INSPIRE profile for<br>
> discovery. Perhaps they have a solution for links to additional resources.<br>
><br>
><br>
> ><br>
> ><br>
> >> layer_geom: Shape of the layer as a Point, LineString, or Polygon WKT.<br>
> >> Example: "POLYGON((76.76 19.91705, 84.76618 19.91705, 84.76618<br>
> 12.62309, 76.76 12.62309, 76.76 19.91705))"<br>
> ><br>
> > Is this the actual geometry for the layer? A generalized representation? If the<br>
> former, how are you handling layers with millions of multipart features? If the<br>
> latter, how are you generalizing?<br>
> ><br>
> ><br>
><br>
> My example is just the bounding box. If you wanted to represent the actual<br>
> geometry, you could generalize it at indexing time, or compute a convex hull.<br>
> This field is more experimental in my evaluation document. When you use Solr4<br>
> + JTS you can represent (more or less) arbirary geometry WKTs and issue spatial<br>
> predicates on them. Solr 4.7, however, upgraded to Spatial4J 0.4 which has<br>
> some initial support for geometry WKTs, so this avenue may be promising as far<br>
> as the core Solr implementation goes.<br>
><br>
><br>
> ><br>
> >> layer_id_s. The complete identifier for the WMS/WFS/WCS layer.<br>
> >> Example: "druid:vr593vj7147",<br>
> ><br>
> > This makes the assumption that the layer name will be the same for all OGC<br>
> services (as OGP does). It's probably a reasonable assumption, but worth<br>
> thinking about. I'm glad to see WorkspaceName go away.<br>
> ><br>
><br>
> Yes, we're assuming the layer name is the same across all WxS services.<br>
><br>
><br>
> ><br>
> >> layer_srs_s: The spatial reference system for the layer. Example: EPSG:4326.<br>
> ><br>
> > Do you get this from the web service or use a library to translate WKT from the<br>
> metadata to EPSG, or something else? I wouldn't be surprised to hear that ISO<br>
> has a place to put EPSG codes, since ISO can represent virtually anything, but<br>
> I've also seen a lot of ISO metadata that does not have this info. Also, is this the<br>
> native EPSG for the original object or the web service? The web service of<br>
> course, can have many available projections. The end user may want to know<br>
> about the layer's projection, but the front end also needs to know what<br>
> projections are available for display. I've been dismayed to find services that<br>
> don't support web mercator or 4326.<br>
> ><br>
><br>
> We've found this to be a nasty problem. In our "data wrangling" phase, we<br>
> manually normalize the data into a 4326 projection, so in our case, the SRS for<br>
> the web services is always 4326. If they want the original projection, we have<br>
> another page outside the scope of the discovery service where they can<br>
> download that. But overall, my assumption is that layer_srs_s is the projection<br>
> used by the web service.<br>
><br>
> >> layer_geom_type_s. Valid values are: "Point", "Line", "Polygon", and<br>
> "Raster".<br>
> ><br>
> > Is there room in the schema for other "data types"? Something like "Scanned<br>
</div></div>> Map" is easy enough (maybe not... how do you differentiate between a<br>
<div class="HOEnZb"><div class="h5">> georeferenced and ungeoreferenced map? Are these distinct data types?), since<br>
> it could be classified as a geometry type. What about documents or data sets<br>
> with clear geospatial extents, but nothing that could rightly be called<br>
> "geometry"? A lot of folks in the scientific community use what we would call<br>
> geospatial metadata to document such things. You are also likely to run into<br>
> metadata that won't specify more than "raster" or "vector".<br>
> ><br>
><br>
> I was hoping to use the OGC simple feature types for these geometry types. The<br>
> extensions to GML provide for all sorts of coverage types which might be<br>
> suitable to handle a non-georectified scanned map. We do, however, want to<br>
> use a controlled vocabulary for the geometry type.<br>
><br>
> Part of our initial assumption for the discovery service was that if the record<br>
> does not have a WMS service, then it's not cataloged in the discovery service.<br>
> We're revisiting that to require only a bounding box and not both a bounding<br>
> box and WMS service.<br>
><br>
> For the "vector" data sets, we look at the actual data to determine the<br>
> geometry type during our "data wrangling" phase.<br>
><br>
><br>
> ><br>
> >> layer_wcs_url: Service root for the WCS service that holds this layer. If<br>
> applicable. Example:<br>
> >> "<a href="http://geowebservices-restricted.stanford.edu/geoserver/wcs" target="_blank">http://geowebservices-restricted.stanford.edu/geoserver/wcs</a>"<br>
> >> layer_wfs_url: Service root for the WFS service that holds this layer. If<br>
> applicable. Example:<br>
> >> "<a href="http://geowebservices-restricted.stanford.edu/geoserver/wfs" target="_blank">http://geowebservices-restricted.stanford.edu/geoserver/wfs</a>"<br>
> >> layer_wms_url: Service root for the WMS service that holds this layer<br>
> "<a href="http://geowebservices-restricted.stanford.edu/geoserver/wms" target="_blank">http://geowebservices-restricted.stanford.edu/geoserver/wms</a>"<br>
> ><br>
> > If there are non-ogc services (ArcGIS Server REST services, HGL's Open Delivery<br>
> for scanned maps, Berkeley's service for ungeoreferenced maps, etc.), links to<br>
> zip files, browse graphics, or other resources would those be represented here<br>
> (with additional elements like "layer_arcgisrest_url" ) or in the repeatable<br>
> "dc_relation_url" element? One could also imagine a multipart/multilayer object<br>
> more properly represented by an OGC WMC or (upcoming) OWS Context. I<br>
> wonder if there is a more generic way to define service url as a schema element<br>
> that would at least pair a url with a descriptor. It may be that there is not a<br>
> good way to do this in Solr and "layer_${service_type}_url" is the best current<br>
> approach. Is there a way of crafting a Solr query that would return all<br>
> "layer_${service_type}_url" fields, but not, say "layer_geom"?<br>
> ><br>
><br>
> As Kim mentioned, we're revisiting this issue and I'm hoping to use DC.Relation<br>
> plus a verb to manage these links. A preview image, for example. I'm not sure<br>
> about using other non-WxS services for our web map -- we haven't thought<br>
> about that frankly.<br>
><br>
><br>
> > Two last non-field specific questions:<br>
> ><br>
> > CSW supports "anytext" queries. It seems like that would require an indexed<br>
> field in Solr with the entire text of the metadata record (ISO or FGDC, etc.),<br>
> minus the xml entities. it's not something that tools like OGP or GeoBlacklight<br>
> must support as a matter of course, but I'm interested in thinking through what<br>
> possibilities/problems might emerge. I'm just curious if this came up in<br>
> discussions, and if so, what were the key decision points?<br>
><br>
> I'm not familiar with the semantics of the CSW anytext queries, but what we do<br>
> is copy various fields into our generic "text" field -- akin to an any text query<br>
> perhaps. We copy about a dozen fields into the text field. If you look at the<br>
> bottom of the Solr schema.xml you will see the specific copyField directives.<br>
><br>
> <a href="https://github.com/sul-dlss/geohydra/blob/master/solr/kurma-app-" target="_blank">https://github.com/sul-dlss/geohydra/blob/master/solr/kurma-app-</a><br>
> test/conf/schema.xml<br>
><br>
><br>
> ><br>
> > Mike Graves has talked some in the past about separating the OGP schema<br>
> from its Solr implementation. Think ISO 19115-1 vs. its implementation in ISO<br>
> 19139; at least that's my read on what I've heard Mike say. Did you guys have<br>
> any thoughts about having a more conceptual schema that's an information<br>
> model of sorts vs. concrete implementation as a Solr XML schema? I don't<br>
> anticipate OGP moving away from Solr anytime soon, but there may be other<br>
> potential partners using different search technologies.<br>
> ><br>
><br>
> This was part of my thinking behind using Dublin Core as they do have a<br>
> conceptual schema, plus they have various extensions and profiles, etc. Perhaps<br>
> that INSPIRE discovery profile might have some of this information model-level<br>
> work. But it would be a great asset to have a conceptual model for what<br>
> information is required for geospatial discovery services.<br>
><br>
> Thanks,<br>
> -Darren<br>
><br>
><br>
> --<br>
> Darren Hardy, Ph.D.<br>
> GIS Software Engineer<br>
> Digital Library Systems & Services<br>
> Stanford University<br>
> <a href="mailto:drh@stanford.edu">drh@stanford.edu</a><br>
> <a href="http://www.stanford.edu/~drh" target="_blank">www.stanford.edu/~drh</a><br>
><br>
><br>
> > Thanks for this! There are a lot of great things here. I understand that there<br>
> are many intractable problems that won't be solved in one iteration, or many! I<br>
> look forward to exploring the spatial search components in more detail.<br>
> ><br>
> > Just as a side-note, I was at a meeting last week for an NSF initiative with<br>
> some ISO luminaries and there was a lot of talk about discovery profiles for ISO.<br>
> Unfortunately, I can't contribute much more than to say that it's a thing that<br>
> exists or may/will exist. Anyone on the list know anything about ISO discovery<br>
> profiles?<br>
> ><br>
> > Chris<br>
> ><br>
> > --<br>
> > Christopher Barnett<br>
> > Geospatial Analyst, Research & Geospatial Technology Services Tufts<br>
> > Technology Services (TTS)<br>
> > 16 Dearborn Rd.<br>
> > Somerville, MA 02144<br>
> > <a href="http://gis.tufts.edu" target="_blank">http://gis.tufts.edu</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Mar 12, 2014, at 3:05 PM, Kimberly A Durante <<a href="mailto:kdurante@stanford.edu">kdurante@stanford.edu</a>><br>
> wrote:<br>
> ><br>
> >> Hello OGP,<br>
> >><br>
> >> Stanford Libraries is in the process of developing GeoBlacklight- a geospatial<br>
> data discovery application, and a plugin to Blacklight.<br>
> >><br>
> >> As part of this development our GIS developer, Darren Hardy, has created a<br>
> Solr metadata schema which we would like to share with the larger OGP<br>
> community in the hopes of gathering feeedback on the schema design and the<br>
> proposed elements.<br>
> >> The schema is based on elements from Dublin Core for the descriptive<br>
> >> metadata and also contains a set of layer-specific fields (prefixed<br>
> >> with 'layer_'.)<br>
> >><br>
> >> The current version of the schema can be found here:<br>
> >> <a href="http://goo.gl/UTIzRl" target="_blank">http://goo.gl/UTIzRl</a><br>
> >><br>
> >> Comments regarding the proposed GeoBlacklight schema are welcome from<br>
> members of entire OGP community. We are interested in any feedback or insight<br>
> into the elements, their definitions, as well as the possibilities for future use by<br>
> other institutions. Please feel free to review the schema and add your comments<br>
> to directly to the Google doc using the comment feature.<br>
> >> You can also send comments to this list, or directly to us us by email<br>
> (<a href="mailto:kdurante@stanford.edu">kdurante@stanford.edu</a>, <a href="mailto:drh@stanford.edu">drh@stanford.edu</a>).<br>
> >><br>
> >> In order to promote metadata exchange, this schema is intended to<br>
> crosswalk with the OGP schema. We are also developing an FGDC to MODS<br>
> crosswalk to manage the source metadata transformation.<br>
> >><br>
> >> Any comments or feedback are appreciated. Thanks for your time.<br>
> >><br>
> >> Kim Durante<br>
> >> Metadata Librarian for Geographic and Scientific Data Stanford<br>
> >> University Libraries<br>
> >> 650.724.5686<br>
> >><br>
> >><br>
> >><br>
> >><br>
> ><br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><br></div>