-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create list of identifiers and their canonical forms #51
Comments
I've made a lot of good progress on this but could use (1) some more work to track down information on some of the remaining identifiers and (2) some input on my current set of recommendations. See https://github.com/ec-geolink/design/blob/master/data/dataone/canonical-identifiers.md My current recommended form for each identifier is preceded by the text 'Recommend:' |
Thanks @amoeba! Regarding issue #61, do you think it is appropriate if on the base ontology, we create an |
Remind me .. since DataCite has already published URIs for these terms (Apologies if this has already been answered.) On Mon, Sep 14, 2015 at 03:01:33PM -0700, krisnadhi wrote:
|
@robertarko You responded just as I was typing this up: Interesting idea. Could you maybe explain what doing that would add to our efforts? I think I like the idea. The identifiers I'm researching the serializations for are all in the DataCite ontology as NamedIndividuals. For identifiers in our graphs that have schemes that already exist as NI's in DataCite, I would prefer to use DataCite. But I expect we will have identifiers not in DataCite and possibly not in another ontology so we will need to do something like you've suggested to accommodate them. |
Right, I see your point. I was assuming the DataCite vocabulary Out of curiosity , what are some ID types you need, that On Mon, Sep 14, 2015 at 03:14:08PM -0700, Bryce Mecum wrote:
|
I don't think there are any in the DataOne network. @mbjones might know otherwise, but I think identifiers in DataOne will always map directly to DataCite. Many of ours are DataCite local-resource-identifiers. |
Okay. On Mon, Sep 14, 2015 at 03:43:26PM -0700, Bryce Mecum wrote:
|
I have yet to find one that we've needed in DataONE that isn't already in the DataCite vocabulary (especially since they support url and urn identifiers as types). |
I didn't know the extent of DataCite vocabulary for identifier schemes, hence my earlier comment. If an appropriate one to use is available from DataCite already, I am also in favor of using it, instead of inventing our own URI. @robertarko, are IMA identifier schemes covered by anything from DataCite other than the generic fallback options? Referring to #61, |
@krisnadhi Sounds good to me. @amoeba and I just discussed being careful about the definitions of our properties. For example, we should clarify that there are two use cases for |
Why can't we use the value pointed by |
@krisnadhi We could, and that's how I originally thought of it. But, will everyone be using it that way? Would we be happy with the definition of the hasIdentifierValue property as "Provides a string literal value that represents the proper form of the identifier for display purposes."? So, for a DOI, this would be of the form "doi:10.xxxx/foo42". |
Hi Bryce, Could you also add 'GVP', 'SCAR', 'InterRige', 'IMA' and 'IGSN' to GVP Source: http://volcano.si.edu/list_volcano_holocene.cfm Examples: GVP:210010 SCAR https://www1.data.antarctica.gov.au/aadc/gaz/scar/information.cfm Examples: SCAR:883 Notes: It does not publish URIs that speak RDF InterRidge Source: http://vents-data.interridge.org/about_the_database Examples: InterRidge:13-n-ridge-site Notes: It speaks RDF from version 3, and provide sparkql endpoint IMA http://www.ima-mineralogy.org/Minlist.htm On Mon, Sep 14, 2015 at 2:13 PM, Bryce Mecum notifications@github.com
|
Hi Bryce, Could you also add 'GVP', 'SCAR', 'InterRige', 'IMA' and 'IGSN' to GVP Source: http://volcano.si.edu/list_volcano_holocene.cfm Examples: GVP:210010 SCAR https://www1.data.antarctica.gov.au/aadc/gaz/scar/information.cfm Examples: SCAR:883 Notes: It does not publish URIs that speak RDF InterRidge Source: http://vents-data.interridge.org/about_the_database Examples: InterRidge:13-n-ridge-site Notes: It speaks RDF from version 3, and provide sparkql endpoint IMA http://www.ima-mineralogy.org/Minlist.htm Examples: IMA:2014-028 Notes: It does not publish the URIs that speak RDF IGSN http://www.geosamples.org/igsnabout Examples: IGSN:HRV003M16 On Mon, Sep 14, 2015 at 2:13 PM, Bryce Mecum notifications@github.com
|
@sparkji I'll add those to the list today. Thanks for providing all that information too -- it helps a lot! |
Would that be the only purpose of the value pointed to by One way to avoid confusion regarding how to display the identifier value is to augment the corresponding instance of |
If we represent DOIs as doi:10.xxxx/foo, then will we follow that On Mon, Sep 14, 2015 at 10:55:03PM -0700, Matt Jones wrote:
|
PS. Coincidentally we're discussing similar issues in One thing that worries me, is how Publishers will implement doi:doi:10.xxxx/foo42 On Mon, Sep 14, 2015 at 10:55:03PM -0700, Matt Jones wrote:
|
Actually, @amoeba's note already indicates that this style is not necessarily appropriate for some identifier scheme.
Is this business logic more on the data publishing or data consumption? |
I agree with @krisnadhi that the consumers need to intelligently consume the identifiers because there are so many ways of representing things, and the recommended best practice for how to reference identifiers is a moving target. Plus, some groups like the DOI foundation make both a display recomendation (DOI:10.xxxx/foo) and a machine-readable link recommendation (e.g., http://dx.doi.org/10.xxxx/foo, http://doi.org/10.xxxx/foo over time). I think the issue here is that we need to know where these two types of information (display and link) will be recorded in glbase, and which is which. I'm not enamored of rdfs:label because it is used so loosely, and sometimes contains garbage text. I would prefer targeted properties for identifierDisplayForm and identifierLinkForm, regardless of the naming we end up with. |
Just checking in on this issue as I don't think we've resolved it just yet. From the comments, it looks like we need to decide between whether we want the display form, machine-readable form, or a web-resolvable form (or some combination of the three) to be stored in our graphs and how we want to do that. We could use Identifiers can have (1) a value, (2) a display form, and/or (3) an HTTP resolvable form, with some of these forms being the same for some identifiers. What should we be storing in our graphs? |
As per our 2015/11/18 telecon, I will complete a first-draft of the identifier recommendations for the group to review. I'll have this done for the next telecon on 2015/12/2. |
This issue stems from discussion on the Sep 2 2015 teleconference.
The literal representation of identifiers can come into our graphs in multiple forms, e.g.
We would like to have a canonical form to simplify lives for both producers and consumers.
The text was updated successfully, but these errors were encountered: