The keywords provide labels, but not resolvable URIs. I hope the long term
solution would include resolvable URIs, ideal with some semantic relations
between the properties in the vocabulary..
- Show quoted text -From: ***@***.***-groups.org <***@***.***-groups.org>
Sent: Tuesday, January 14, 2020 3:42 PM
To: ***@***.***-groups.org
Subject: [i-adopt] FW: [esip-semantictech] NASA GCMD Keywords Version 9.0
Released (2019-11-12)
--
Full post:
https://www.rd-alliance.org/group/interoperable-descriptions-observable-...
erty-terminology-wg-i-adopt-wg/post/fw-esip
Manage my subscriptions: https://www.rd-alliance.org/mailinglist
Stop emails for this post:
https://www.rd-alliance.org/mailinglist/unsubscribe/67470
Author: John Graybeal
Date: 15 Jan, 2020
On Jan 14, 2020, at 2:46 PM, srichardUSGIN via InteroperAble Descriptions of Observable Property Terminology WG (I-ADOPT WG) <***@***.***-groups.org> wrote:
> The keywords provide labels, but not resolvable URIs. I hope the long term solution would include resolvable URIs, ideal with some semantic relations between the properties in the vocabulary….
Amen. A long time ago I asked GCMD to do that, or to let my group do that on their behalf. I just could not win that argument. I'm hoping some of the recent semantic releases position it to do so more readily now.
I suspect the reason many are unsettled about GCMD content and solutions is that it's a communities-contributed resource (as opposed to community-developed or community-managed). So random parts of the community brought their ideas for terms forward and a very large percentage were accepted as is. Much of the initial content was not vetted per any guiding principles, so the result is, umm, idiosyncratic.
Whereas CF is extremely community-driven, plus it has been managed for a long time (probably always, but that's before I noticed) by expert vocabulary managers who insist on semantic and syntactic consistency across the resource. It was always a very high-quality resource and has improved steadily for the last dozen+ years, IMHO. But regarding Lewis' points, as many terms as CF has, it often is pretty skimpy when your domain is not one of the core CF domains, and it can take a big time investment to change that. So while CF can be a great starting point, I have found it difficult to adopt and run with to suit the needs of a particular project, if those needs do not align with the standards used for the vocabulary.
Just makes the point that one vocabulary to rule them all is an unlikely outcome, I guess.
John
Amen. A long time ago I asked GCMD to do that, or to let my group do that on their behalf. I just could not win that argument. I'm hoping some of the recent semantic releases position it to do so more readily now.
I suspect the reason many are unsettled about GCMD content and solutions is that it's a communities-contributed resource (as opposed to community-developed or community-managed). So random parts of the community brought their ideas for terms forward and a very large percentage were accepted as is. Much of the initial content was not vetted per any guiding principles, so the result is, umm, idiosyncratic.
Whereas CF is extremely community-driven, plus it has been managed for a long time (probably always, but that's before I noticed) by expert vocabulary managers who insist on semantic and syntactic consistency across the resource. It was always a very high-quality resource and has improved steadily for the last dozen+ years, IMHO. But regarding Lewis' points, as many terms as CF has, it often is pretty skimpy when your domain is not one of the core CF domains, and it can take a big time investment to change that. So while CF can be a great starting point, I have found it difficult to adopt and run with to suit the needs of a particular project, if those needs do not align with the standards used for the vocabulary.
Just makes the point that one vocabulary to rule them all is an unlikely outcome, I guess.
John