[cat-interop] Metadata link types vocabulary proposal

Tom Kralidis tomkralidis at gmail.com
Sat Mar 1 04:07:53 PST 2014


On Fri, Feb 28, 2014 at 4:17 PM, Paul van Genuchten
<paul.vangenuchten at geocat.net> wrote:
> Hi Tom, such a vocabulary using urn's is that still commonly used?
> My impression is that vocabularies these days use url's as identifiers.
>

We were initially inspired by the OGC URN Policy
(http://www.opengeospatial.org/ogcUrnPolicy).

For me I like the object type token of the URN notation as I can
depend on knowing it's some sort of service, or data format, for
example.  And I can tokenize the URN with more apriori knowledge given
its structure.

Having said this, how would using URLs be better? Now is a good time
to discuss this.

> I noticed you've also added some formats in the list (GML).
> Should we extend the list to have all known (geo)-formats, or maybe only
> W3C/OGC/OKFN-standard formats that are commonly used for data exchange?

IMHO we should start small, with known, in-use common formats.  The
initial list was based on a sift of Richard's initial list and the
GeoNetwork link type enumerations.

> And/Or create a separate list for formats
> (we might use an OGR-capabilities document here).
>
> Such as:
> - geojson
> - topojson
> - esri shapefile/filegeodatabase/e00
> - dxf/mapinfo tab
> - postgis/oracle/msql(-dumps)
> - mbtiles/spatialite/geoPackage
> - geoTiff/geoJpeg/mrsid/...
> - geoCSV/dbf/xls
>

I was thinking exactly this too (by first looking at ogrinfo --formats).

urn:x-osgeo:dataFormat:$FORMAT[:version]

where $FORMAT is a slugified string based on the value in
gdalinfo|ogrinfo --formats.

I would suggest keeping this small based on what people really have as
links in their metadata documents.

> Some additional servicetypes to consider
> - TMS/WMSc/WMTS
> - atom/rss/opensearch
> - geosparql/rdf/json-ld/rdfa
> - odata
> - geoGit
> - geoRestConf (a to be developed spec to configure servers remotely,
> like https://github.com/neogeo-technologies/mra)
>
> I'd suggest to use w3c as namespace for the www-link type
>

Good point.  How about urn:x-w3c:link:simpleLink ?

> For www-thumbnail we might also use the schema.org thumbnailUrl-property
> from CreativeWork, does this make sence?
>

Example?

> Cheers, Paul
>
> cat-interop-request at lists.osgeo.org schreef op 28-2-2014 21:00:
>> Send cat-interop mailing list submissions to
>>       cat-interop at lists.osgeo.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>       http://lists.osgeo.org/cgi-bin/mailman/listinfo/cat-interop
>> or, via email, send a message with subject or body 'help' to
>>       cat-interop-request at lists.osgeo.org
>>
>> You can reach the person managing the list at
>>       cat-interop-owner at lists.osgeo.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of cat-interop digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Metadata link types vocabulary proposal (Tom Kralidis)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 28 Feb 2014 11:43:36 -0500
>> From: Tom Kralidis <tomkralidis at gmail.com>
>> To: "<cat-interop at lists.osgeo.org>" <cat-interop at lists.osgeo.org>
>> Subject: [cat-interop] Metadata link types vocabulary proposal
>> Message-ID:
>>       <CAFWXLWUJxpwOUZYafuKo7o+avuqXnR+TPjVTz6CWMGDWDMt5AQ at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hi all: update on this activity. We've crafted an initial,
>> short/simple/extensible list at:
>>
>> https://github.com/OSGeo/Cat-Interop/blob/master/link_types.csv
>>
>> Associated ticket: https://github.com/OSGeo/Cat-Interop/issues/1
>>
>> The goal here is to have consensus among content providers and
>> implementations so something like this can be implemented.
>> Eventually, the list will be versioned and titled something like "Link
>> Type Vocabulary" with the author being "OSGeo Catalogue
>> Interoperability Working Group".
>>
>> Here, it would be great for deegree2, GeoNetwork, pycsw and others to
>> support this, and it is a great time for finally harmonizing such an
>> important piece of interoperability in a pragmatic manner.
>>
>> This also bring s us closer to realizing a better "add to map"
>> workflow/use case, a core driver of this WG.
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> cat-interop mailing list
>> cat-interop at lists.osgeo.org
>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/cat-interop
>>
>>
>> End of cat-interop Digest, Vol 3, Issue 6
>> *****************************************
>>
>
> _______________________________________________
> cat-interop mailing list
> cat-interop at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/cat-interop


More information about the cat-interop mailing list