[cat-interop] Metadata link types vocabulary proposal
Jeroen Ticheler
jeroen.ticheler at geocat.net
Wed Mar 5 09:49:50 PST 2014
Hi Stephen and Richard,
Thanks for the feedback. I agree that name recognition is a good thing. However, I feel that choosing for a domain/name that is not related to proprietary nor to open source software is a good thing.
Within GeoNetwork opensource we've been developing metadata profile support in the form of plugins for several year now. Because these profiles are hosted on our GeoNetwork github, outsiders using other software for metadata management are less likely to use and contribute to those profile plugins. This is a pity, because only a small part of the plugin is GeoNetwork specific while most is generic and often developed by a community of practice (e.g. a country or region, a community of marine or soil experts). Hence we want to move the profiles outside of the GeoNetwork opensource projects so we attract a larger expert community.
The idea is that under metadata101.org these profiles are developed and maintained by the profile custodians. Doing so has many benefits:
- Custodians manage versions better than software developers from a specific software.
- Interaction between metadata experts dealing with profiles can lead to more interoperable profiles.
- Transformations between profiles can be developed in a consistent manner between expert groups.
- Software developers of different applications that depend on supporting metadata profiles in their software need not to care about the specifics of a profile that much. They have a single point of reference for the schemas and the schematron rules that come with such profile.
- Software developers can ensure end users have the option to select the metadata profile of interest to them instead of hardcoding profiles into the software.
- End users and developers have an easier task in finding relevant & existing profiles. Now these are spread all over the place. And hardly anytime they can be found in a collaborative environment like github. So contributing or discussing them is difficult right now.
- It becomes easy for new communities to add their own metadata profile that can then automatically become available in their software of choice.
There are for sure more reasons why it is useful to maintain metadata profiles in an independent location.
Since vocabularies are so closely related to the metadata profiles that often use them, it seems a fairly logical thing to me to maintain those in the same location. And as I said, not relating it to a specific software project or to an open source (or proprietary) foundation makes it easier for both worlds to participate in the development, maintenance and use of these vocabularies.
I hope this makes sense to you. Cheers,
Jeroen
____________________________________________________
GeoCat introduces Bridge©
An extension to ArcGIS© to instantly publish data and metadata on GeoServer and GeoNetwork.
See http://geocat.net for more details.
Jeroen Ticheler
GeoCat bv
Veenderweg 13
6721 WD Bennekom
The Netherlands
Tel: +31 (0)6 81286572
http://geocat.net
Please consider the environment before printing this email.
On 5 mrt. 2014, at 18:14, Steve Richard <steve.richard at azgs.az.gov> wrote:
> Good point. The name recognition is important. Jeroen, what can you tell us about metadata101—it looks pretty new.
>
> Stephen M Richard
> Arizona Geological Survey
> 416 W. Congress #100
> Tucson, AZ
> AZGS: 520-770-3500
> Office: 520-209-4127
> FAX: 520-770-3505
>
> From: Rich Signell [via OSGeo.org] [mailto:ml-node+s1560n5107725h56 at n6.nabble.com]
> Sent: Wednesday, March 05, 2014 10:13 AM
> To: Steve Richard
> Subject: Re: [cat-interop] Metadata link types vocabulary proposal
>
> I like the git idea, but would vote for osgeo github as a location, if
> only because it has more name recognition at this point.
>
> On Wed, Mar 5, 2014 at 8:54 AM, Jeroen Ticheler
> <[hidden email]> wrote:
>
> > Hi Tom and others,
> >
> > We are working on getting metadata profiles developed in a separate git repository https://github.com/metadata101 and published underhttp://metadata101.org . This allows people to work on a range of metadata profiles while maintaining a common basis, so that applications can use these profiles from a single source.
> >
> > Would you be open to the idea to also host the vocabularies under that same umbrella? It would not be related to a specific project or foundation, which could help to get wide acceptance across open source and proprietary applications. This would be a great benefit for interoperability in my opinion.
> >
> > A build process could ensure the vocabularies are kept up to date under http://metadata101.org while they are developed and versioned on Github.
> >
> > My 2 cents,
> > Jeroen
> >
> >
> > On 5 mrt. 2014, at 14:12, Tom Kralidis <[hidden email]> wrote:
> >
> >>
> >> Thinking this though more, I think the way forward here is for this
> >> to be an OSGeo vocabulary, which we can build and manage under
> >> http://osgeo.org/vocab like:
> >>
> >> http://osgeo.org/vocab/data/{provider}/{type}[/version]
> >> http://osgeo.org/vocab/service/{provider}/{type}[/version]
> >>
> >> Then providing a thin resolution layer, members of this vocabulary, when
> >> invoked via HTTP, would then dereference/resolve accordingly. Like:
> >>
> >> http://osgeo.org/vocab/service/ogc/sos/1.0
> >>
> >> would resolve to:
> >>
> >> http://www.opengis.net/sos/1.0 (which then resolves as per the
> >> authoritative provider's wishes).
> >>
> >> This provides the following benefits:
> >>
> >> 1./ metadata clients/servers can bind to the OSGeo vocabulary, thus
> >> realizing the core goal of a harmonized link type list
> >> 2./ anyone who really wants to invoke / resolve these can do so
> >> 3./ This keeps OSGeo as a just a gatekeeper / custodian of the list with
> >> redirects as appropriate, which gets us out of the complexity of
> >> managing these across standards orgs/etc.
> >>
> >> Comments? I've written a small Flask app to act as a high level
> >> resolver, based on our link types list and will resolve / redirect
> >> accordingly, which we can push forward for hosting, etc.
> >>
> >>
> >>
> >> On Mon, 3 Mar 2014, Tom Kralidis wrote:
> >>
> >>> Date: Mon, 3 Mar 2014 21:53:51 -0500
> >>> From: Tom Kralidis <[hidden email]>
> >>> To: Paul van Genuchten <[hidden email]>
> >>> Cc: "<[hidden email]>" <[hidden email]>
> >>> Subject: Re: [cat-interop] Metadata link types vocabulary proposal
> >>> On Mon, Mar 3, 2014 at 4:07 PM, Paul van Genuchten
> >>> <[hidden email]> wrote:
> >>>> I support Stephan at this point. The semantic web can be a big consumer
> >>>> of spatial data services, if we're able to optimally embed our data in
> >>>> it. Linking to controlled vocabularies by url is a big facilitator.
> >>>>
> >>>
> >>> Good points.
> >>>
> >>>> Sure i see the point of having a urn structure as
> >>>> {provider}:{type}:{identifier}:{version}. But this can also be managed
> >>>> in a (skos) vocabulary-identifier-as-url by using identifiers like:
> >>>>
> >>>> for example:
> >>>> http://osgeo.org/vocab/service/ogc/wms/1.1
> >>>> http://osgeo.org/vocab/service/opensearch/opensearch/2.0
> >>>>
> >>>> and
> >>>>
> >>>> http://osgeo.org/vocab/mediatype/esri/shapefile/1.0
> >>>> http://osgeo.org/vocab/mediatype/ogc/gml/2.0
> >>>> http://osgeo.org/vocab/mediatype/w3c/json-ld/1.0
> >>>>
> >>>> or
> >>>>
> >>>> http://osgeo.org/vocab/service#ogc_wms_1_1
> >>>> http://osgeo.org/vocab/mediatype#ogc_gml_2_0
> >>>>
> >>>> At this point we should consider if osgeo.org is the best place to set
> >>>> up such a service/vocab, as this is more a data-matter then a software
> >>>> matter. Should we connect with geovocab, w3c/ogc, dbpedia to have this
> >>>> set up?
> >>>>
> >>>
> >>> Based on the comments on HTTP URIs at
> >>> https://github.com/OSGeo/Cat-Interop/issues/3, the OGC has this at
> >>> www.opengis.net. However the structure is not SKOS-like. I guess one
> >>> factor is how deep version negotiation would go.
> >>>
> >>> Then again, we could implement this in OSGeo and have resolver back to
> >>> their authoritative resources (i.e.
> >>> http://osgeo.org/vocab/service/csw/2.0.2 could resolve to
> >>> http://www.opengis.net/cat/csw/2.0.2. Does this sound useful/make
> >>> sense?
> >>>
> >>>> If we feel osgeo.org is a good place, let's post about it in the
> >>>> request-list...
> >>>>
> >>>> _______________________________________________
> >>>> cat-interop mailing list
> >>>> [hidden email]
> >>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/cat-interop
> >>>
> >
> >
> > _______________________________________________
> > cat-interop mailing list
> > [hidden email]
> > http://lists.osgeo.org/cgi-bin/mailman/listinfo/cat-interop
> >
>
>
>
> --
> Dr. Richard P. Signell (508) 457-2229
> USGS, 384 Woods Hole Rd.
> Woods Hole, MA 02543-1598
> _______________________________________________
> cat-interop mailing list
> [hidden email]
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/cat-interop
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://osgeo-org.1560.x6.nabble.com/cat-interop-Metadata-link-types-vocabulary-proposal-tp5106675p5107725.html
> To unsubscribe from Cat-Interop, click here.
> NAML
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/cat-interop/attachments/20140305/35be6bf0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GeoCat_small.png
Type: image/png
Size: 837 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/cat-interop/attachments/20140305/35be6bf0/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.osgeo.org/pipermail/cat-interop/attachments/20140305/35be6bf0/attachment-0001.pgp>
More information about the cat-interop
mailing list