Handling of DOIs #16
Comments
|
So we're only allowing DOI, ISBN, and ISSN identifiers in citation? This means that "custom" identifiers are only supported where identifier of MD_Identifier occurs - see above. Is everyone OK with that restriction? FYI, from doi.org:
|
|
True, "custom" identifier related to the resource would only go in MD_Identifier (resourceIdentifier in adiwgJSON). The additionalIdentifier{} block just has identifiers than have common, well recognized names. We could add other identifiers later if we like. That saves space in the JSON and if they are common we can always create the MD_Identifier citation for them to meet ISO standards. But I don't think we are missing any opportunity to specify all the identifiers we need. |
|
To note a conversation Stan and I had, I had expressed concern about On Wed, Aug 13, 2014 at 4:11 PM, stansmith907 notifications@github.com
|
|
I think space saved in the JSON is negligible in the larger scheme of things. For me, the issue is whether we want to maintain a "codelist" of identifier types, encode the types directly in the JSON (done currently via additionalIdentifier), or allow any identifier via an identifier[ ] array(like ISO). Personally, I find the "codelist" more appealing than using the identifier type as a property name. It's much easier to extend since we don't have to change the json to account for a new type of identifier. In fact, this seems more appealing than the way we're currently handling resourceIdentifier, since, like MD_Identifier, there's no direct way to determine the type of identifier (I supposed you could try to infer from the authority). {
"additionalIdentifier": [
{
"code": "10.1000/182", <= any string, required
"type": "doi", <= from codelist, recommended but not required, if present could auto-generate authority in translator
"authority": { <= could be citation block or just a contactId, not required
"contactId": "1"
}
}
]
} |
|
I kind of like the codelist idea. This strikes me as similar to a contact's On Thu, Aug 14, 2014 at 9:57 AM, Josh Bradley notifications@github.com
|
|
Josh - If authority were a citation, think we could drop the resourceIdentifier section? "type": would need to be required but NOT restricted. The advantages are that it all fits in one place by combining additionalIdentifier and resourceIdentifier; and it becomes more clear that these identifiers all describe the main resource. {
"additionalIdentifier": [
{
"identifier": "10.1000/182", <= any string, required
"type": "doi", <= required, not restricted
"authority": { <= not required
"name": "Digital Object Identifier", <= required
"date": "2014-08-14", <= not required
"contact": "1" <= not required
}
}
]
}Note: additionalResources describe OTHER resources. |
|
If you want to use a citation, it should follow the base citation schema. I would not make title required in the JSON for identifiers, it generally contains redundant data in the context of an identifier - just auto-fill with the type or just "assigned identifier" to satisfy ISO if it's not present in the JSON. I also wouldn't require type, making it required doesn't seem to serve a purpose if it's not restricted. You either provide a value in the codelist and get the benefit(e.g. doi, isbn), or not, and get a generic identifier. Why would you not create a MD_Identifier ISO record if authority were missing? The only required element for MD_Identifier is the code. We could drop resourceIdentifier. {
"identifier": [
{
"identifier": "10.1000/182", <= any string, required
"type": "doi", <= not required, not restricted
"authority": { <= not required
"title": "Digital Object Identifier", <= not required
"date": [ <= not required
{
"date": "2013-03-13",
"dateType": "creation"
}
],
"responsibleParty": [ <= not required
{
"contactId": "1",
"role": "originator"
}
]
}
}
]
} |
|
I definitely agree that authority should follow the standard citation format, I was just posting too fast before my 11am conference call. The point I was trying to make was to include the ISO required fields plus contact but keep citation fields to a minimum. This field set makes it compatible with what we have for resourceIdentifier. I don't think we need to auto-fill citation:title with additionalIdentifier:type. If we don't want to say who the authority is, why have an authority at all? It's not required. Just don't include it for that identifier. Of course title was only required if we do specify an authority. Type not required, that's ok with me, it fits with the MD_Identifier standards. Type is really only used to extract the ISSN and ISBN for ISO, and otherwise enhance readability in adiwgJSON record. It does not transfer to ISO. But I think a pick list is too restrictive. If we go this direction is everyone comfortable with dropping the resourceIdentifier section? |
|
I think having the codelist identifies those types that have special significance and may receive special treatment by the translator. Otherwise, I'm good with dropping resourceIdentifier. |
|
Okay. Looking back at your example. I also like changing additionalIdentifier{} to identifier{}, since there is really no primary identifier anyway. The original meaning sort of got lost once the block expanded to handle all MD_Identifiers and we eliminated resourceIdentifier{}. This means we should also drop resourceIdentifier{} from associatedResource[]. And change out the old additionalIdentifier{} block to identifier{} is all its 7 locations. I'm still not clear on what you are suggesting we do with type:? On one hand it would be nice to control it with a codelist for known types (isbn, issn, doi). On the other it would be necessary to have it open for organization specific types (ascProject, nsfAward, nccwscProject, lccProject, "gntpId", etc.). And I don't think we can anticipate all these types. Another possible way to approach it would be set "type": to "string" or "other" for these types and add details to the authority. This would be less useful in searching adiwgJSON metadata. But unrestricted types make searching problematic as well. I think I lean toward just having type NOT restricted for now. |
|
If we want to codelist the type; maybe broad categories would work like [ projectId, awardNum, grant, ...] |
|
I'm not saying that we restrict entries to the codelist using an enum constraint. Like our other codelist supported properties, it's more of a recommendation, e.g. you should use the code doi, isbn, etc. and the translator or other ADIwg entities recognize them. Users would still be able to enter custom types for their own purposes. |
|
That sounds okay to me. But I was kind of warming to the idea of a broad category code list ... I'm open to either a controlled category list for type or a non-restricted type. Everything else good to go? Anything else before we change the schema and code? From anyone? |
|
The broad category code list sounds good, for our use. I just don't think we should enforce it in the schema. |
|
Agreed. Don't enforce it in the schema, but we could prompt it in the on-line editor. The writer would just look for items of interest specifically to it. Are we ready to code? |
|
After starting through implementation, one more thing: I think we need to include an onlineResource block for identifier>authority. If we do, we will able to provide a link to an authority page for lesser know authorities such as GTN-P http://www.gtnp.org/index_e.html; and have an identify block that will also function for our "assignedId" block in extent>geographicElement>properties>assignedId. "identifier": [
{
"identifier": "",
"type": "",
"authority": {
"title": "",
"date": [
{
"date": "0000-00-00",
"dateType": ""
}
],
"responsibleParty": [
{
"contactId": "",
"role": ""
}
],
"onlineResource": [
{
"url": "http://thisisanexample.com",
"protocol": "",
"name": "",
"description": "",
"function": ""
}
]
}
}
],We suggest use this same block in both citation and geographicElement>properties. |
onlineResource{} => removed doi
additionalIdentifiers{} => changed name to identifier[]:
-objects have identifier, type, authority{};
-authority has title, date[], responsibleParty[], and onlineResource[]
resourceIdentifier[] => removed sections
assignedId[] => replaced with identifier[]
Places where doi occurs:
onlineResource{} occurs in
additionalIdentifier{} occurs in
identifier of MD_Identifier occurs in
Rules:
Recommendations:
for onlineResource ...
[ ] change uri to url to match ISO requirement
[ ] drop doi - people can make the url a resolvable doi if that is the preferred method of accessing the resource
for additionalIdentifier ...
[ ] no change - specify doi as URN; ISO writer will publish doi as MD_Identifier
for resourceIdentifier ...
[ ] no change
The text was updated successfully, but these errors were encountered: