Dear colleagues,
I just came across this group and, reading the charter proposal, I think the best practices and guidelines developed for INSPIRE (the Infrastructure for Spatial Information in Europe) for registers (= vocabularies), registries (= vocabulary services) and register federation could be useful: https://inspire.ec.europa.eu/id/document/tg/registers-and-register-feder...
This document describes best practices for setting up registers for INSPIRE, including for code list extensions. It also includes technical guidance for sharing national or community registers in the INSPIRE register federation and for using the federation’s access point (the “register of registers”) to search and browse through the registers included in the federation.
If you have questions or comments, I would be happy to hear them.
Best regards,
Michael
Author: Simon Cox
Date: 13 Feb, 2018
Mike – RDA VSSIG discussions are mostly happening on Slack – I’ve just sent you an invitation. – Simon
- Show quoted text -From: michael.lutz=***@***.***-groups.org [mailto:***@***.***-groups.org] On Behalf Of michael.lutz
Sent: Wednesday, 14 February, 2018 02:08
To: Vocabulary Services Interest Group <***@***.***-groups.org>
Subject: [vocabulary_services] INSPIRE Best Practices / Guidelines for registers & register federation
Dear colleagues,
I just came across this group and, reading the charter proposal, I think the best practices and guidelines developed for INSPIRE (the Infrastructure for Spatial Information in Europe) for registers (= vocabularies), registries (= vocabulary services) and register federation could be useful: https://inspire.ec.europa.eu/id/document/tg/registers-and-register-feder...
This document describes best practices for setting up registers for INSPIRE, including for code list extensions. It also includes technical guidance for sharing national or community registers in the INSPIRE register federation and for using the federation’s access point (the “register of registers”) to search and browse through the registers included in the federation.
If you have questions or comments, I would be happy to hear them.
Best regards,
Michael
--
Full post: https://www.rd-alliance.org/group/vocabulary-services-interest-group/pos...
Manage my subscriptions: https://www.rd-alliance.org/mailinglist
Stop emails for this post: https://www.rd-alliance.org/mailinglist/unsubscribe/58903
Author: Rob Atkinson
Date: 14 Feb, 2018
I'd like to pull together a few threads here and fix on an appropriate
practice for the OGC Definitions Service.
We follow the broad principles outlined in this INSPIRE paper, which leaves
us withthe practical question of attaching appropriate metadata to the
artefacts we publish, particularly around Registry governance roles.
We are happy to use ISO 19135 as a basis - so we need a canonical form to
publish these definitions, so that can be included in the Linked Data
environment that exposes OGC knowledge moving forward.
The Australian Government Linked Data Working Group has raised similar
concerns.
We note the resource at:
https://github.com/ukgovld/registry-core/blob/master/src/main/vocabs/reg...
(and its resolvable canonical address at
http://purl.org/linked-data/registry#>
This is very close to what we want - but not quite ideal and reusable for
the following reasons:
1) Is not governed by an International Standards Development Organisation
OGC has a formal liasion with.
2) Does not provide a Linked Data resource using content negotiation as per
BP
3) does not provide resolution at the level of a specific term (# based
uris preclude servers responding directly)
4) does not fit the OGC model of delivering definitons via a SKOS view,
using governance (register management) for skos:ConceptSchemes
5) mixes class and instance - status codes are embedded, whereas OGC has a
set of status codes at http://www.opengis.net/def/status/ - and as per
INSPIRE BP is governed as its own register
alternatively the ISO model (possibly at
https://github.com/ISO-TC211/GOM/blob/master/isotc211_GOM_harmonizedOnto...
appropriate
priveleges?)
does not meet publication criteria.
So my best guess is to derive a SKOS representation from one of the
available OWL resources, and link it to these so that others could
potentially reason over it even if they cared more about the source model
than OGC :-)
the target namespace I am considering is
http://www.opengis.net/def/metamodel/registry/
so questions are:
1) have i missed a different resource we can use in-situ?
2) what equivalence predicates should i use (owl:sameAs, skos:exactMatch)
3) what definition properties (skos:definition) shoukld i entail from the
soruces
4) what citation properties should I entail?
5) what have I missed?
Cheers
Rob Atkinson