[cat-interop] Metadata link types vocabulary proposal

Fri Mar 7 07:38:16 PST 2014

Jeroen,
Definitely agree about wanting to host this some place neutral.   So if not
osgeo, how about https://github.com/opengeospatial?
It just worries me that folks will wonder why we need another new
organization (metadata101).

-Rich
P.S.  Incidentally, I'm not sure about in other countries, but here in the
US the term "101" kind of implies "for beginners" and sometimes has a
negative connotation.

On Thu, Mar 6, 2014 at 12:31 AM, Steve Richard <steve.richard at azgs.az.gov>wrote:

>  Jeroen--what you say makes sense. What would a registered profile look
> like in the metadata101 repository?  To be useful, each profile should
> declare a URI that identifies instances conforming to the profile. Is this
> part of your profile specification?  Would there be any kind of curation of
> metadata101?
>
>
>
> steve
>
>
>
> 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:* Jeroen Ticheler [mailto:jeroen.ticheler at geocat.net]
> *Sent:* Wednesday, March 05, 2014 10:50 AM
> *To:* Steve Richard
> *Cc:* Rich Signell [via OSGeo.org]; cat-interop at lists.osgeo.org
>
> *Subject:* Re: [cat-interop] Metadata link types vocabulary proposal
>
>
>
> 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
>
> ____________________________________________________
>
>    *Geo**Cat*
>
>  *introduces* *Bridge**(c) *
>
> *An extension to ArcGIS**(c)** 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 <http://osgeo.org/>] [
> mailto:ml-node+s1560n5107725h56 at n6.nabble.com<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 under
> http://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<http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5079187&code=c3RldmUucmljaGFyZEBhemdzLmF6Lmdvdnw1MDc5MTg3fC0xMDkwNzA1OTU0>
> .
> NAML<http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
>
>
> _______________________________________________
> cat-interop mailing list
> cat-interop at lists.osgeo.org
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/cat-interop/attachments/20140307/7527043c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 837 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/cat-interop/attachments/20140307/7527043c/attachment-0001.png>