Address ISLANDORA-1643; Document how to handle discrepancies between … #4
Conversation
…the code base and published ontology.
|
Looks good to me as far as addressing the issue of conflicts and how to deal with them. Do we want/need a statement about which side of the conflict is presumed to win (allowing for corrections, as indicated by the JIRA wording you added).? This was the wording cited as an example at the Roadmap Meeting: "The English version of this specification is the only normative version. In case of conflicts, this ontology is the normative version. New changes can be submitted via JIRA tickets," following the example from WC3. Or maybe that should be a different ticket, since this directly addresses 1643. |
|
@manez I guess it depends on what the conflict is. If it is the code base, and the published ontology, that should be a case-by-case basis IMO. If somebody is translating it, then, I can see language like above useful. |
|
Everything looks good to me. |
|
I'm sorry if things got a little convoluted when discussing conflicts. The potential for discrepancy that I saw (and which that verbiage from the Roadmap meeting was intended to clarify) was between the ontology as defined at http://github.com/Islandora/islandora_ontology vs. at http://islandora.ca/ontology/relsext/. Since they're meant to be identical versions of each other, but in reality the github one is likely to evolve faster than the exported version at islandora.ca, I wonder if we should either The question of resolving conflicts between the ontology and existing/potential code in the codebase (as pointed out by @willtp87, and as described in JIRA ticket https://jira.duraspace.org/browse/ISLANDORA-1643), is a separate issue. Regardless I think it'll be an important part of every release cycle to resolve any discrepancies between the islandora.ca ontology, the github version, and the code base. |
|
@rosiel as for http://github.com/Islandora/islandora_ontology vs. http://islandora.ca/ontology/relsext/ discrepancies, I'd say that is just a deployment thing. We could set it up in such a way that when something is merged, it is auto-deployed. Whether that is some scripts, or just a Jekyll site, I believe that is a solved problem. Does that make sense? |
|
@rosiel ...and I should also mention, we'll be working on this type of deployment for PCDM very soon. We just had a conversation about it at LDCX. Once we do that we can crib from there, or we do it here, and I implement it there. |
|
It makes sense from a technical perspective. It doesn't do anything for the philosophical problem of having two URLs that canonically define the same thing. But it seems like I'm the only one who thinks that's a problem, so I'll let the community proceed. |
|
@rosiel well, what do we mean by the same thing? Here, in the GitHub repo, we have the RDFS representations of the ontologies (or are they vocabularies?). At http://islandora.ca/ontology/relsext# & http://islandora.ca/ontology/relsint# we have the human readable HTML representations. If that's the case, do you think adding some language to the README would address it? |
|
@ruebot I see that my concern was misfounded and I'm sorry. Please proceed. |
|
@willtp87 does this pull request resolve ISLANDORA-1643? |
|
As I mentioned in the Jira ticket I'm unsure on this and to be clearer here I defer judgment to consensus. Thanks! William Panting |
|
Merged as per 2016-04-01 roadmap dicussion. |
…the code base and published ontology.
See: https://jira.duraspace.org/browse/ISLANDORA-1643