Replies: 7 comments 3 replies
-
|
I voted for option 2 (no backward compatibility), because replacing a couple of terms seems simple enough not to warrant the extra complexity of three coexisting versions of the codemeta context. Either way, existing documents will not be affected because they use the v2.0 context URL ( |
Beta Was this translation helpful? Give feedback.
-
|
I voted for 2.2, but would be supportive of both paths. The reason that I voted for 2.2. is that it would introduce the new properties into the 2.x namespaces, and provide an opportunity for us to directly map old deprecated names to their new counterparts with equivalence relations. That way, when the deprecated term is removed in 3.0, there will be a direct machine-readable path for transformation between the 2.2 context and the 3.0 context. But I could also see just replacing the old term and skipping the deprecation step, going straight to 3.0. |
Beta Was this translation helpful? Give feedback.
-
Codemeta has a single namespace for both v1.0 and v2.0 (
What does that mean? Make the v2.2 context define this? if yes, then readers of documents with a v2.2 context will get |
Beta Was this translation helpful? Give feedback.
-
|
Oh, I see what you mean. The context identifier for CodeMeta was originally defined as:
That redirects to the actual context file (despite the problems with content negotiation for ld+json that we discussed elsewhere). We originally intended these as versioned namespaces, and I forgot that we mapped the terms to You can see this in operation in the example codemeta.json file for the repository itself. And yes, it is exactly that kind of equivalence mapping I was referring to, but I don't see why it is an error -- it means both terms can be used and will be mapped onto embargoEndDate. I'd have to look more carefully at the JSON-LD expansion to make sure its right, but my intention was that in 2.2 both terms would be usable (one documented as deprecated), and in 3.0 only the preferred term would remain. |
Beta Was this translation helpful? Give feedback.
-
|
So what you are saying is that writers of Codemeta documents will allowed to write either But readers of a Codemeta document should interpret it after expansion, so if they get this document as input: {
"@context": "<hypothetical context URL for v2.2>"
"embargoDate": "2023-07-01"
}then if {
"embargoDate": { "@id":"codemeta:embargoEndDate", "@type": "schema:Date" },
"embargoEndDate": { "@id":"codemeta:embargoEndDate", "@type": "schema:Date" }
}then readers of the document will interpret it like this: {
"https://codemeta.github.io/terms/embargoEndDate": "2023-07-01"
}whereas this document: {
"@context": "https://doi.org/10.5063/schema/codemeta-2.0"
"embargoDate": "2023-07-01"
}was interpreted like this: {
"https://codemeta.github.io/terms/embargoDate": "2023-07-01"
}So even if writers can use |
Beta Was this translation helpful? Give feedback.
-
|
I voted for the second option, because we are moving towards v3.0 in the end. I hope we can produce a proper changelog specifying the changes between versions (we can even have a separate machine-readable file for the replacements). |
Beta Was this translation helpful? Give feedback.
-
|
Given the difficulties we encountered with using DOIs with content negotiation, and our prior discussions on this issue, I think moving towards using the namespaces you prepared at w3id would be best and set us up well for having both human-readable and machine-readable endpoints for the context files. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @mbjones, If you do not object, we will go forward with this plan. |
Beta Was this translation helpful? Give feedback.
-
|
Last call for the version vote! |
Beta Was this translation helpful? Give feedback.
-
|
With 80% we will now move towards a V3.0 release without backward compatibility. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello CodeMeta community,
We would like you to vote between these two options below, as discussed in #258.
hasSourceCodeor adding natively a role to an author while at the same time using an old v2.1 property with the old name (e.gembargoDateandcontIntegration).Please vote before June 19th 2023.
Feel free to leave a comment with your take on the subject.
If you have a minute, go and introduce yourself in #304
5 votes ·
Beta Was this translation helpful? Give feedback.
All reactions