Conversation
|
Curvenote Preview
|
There was a problem hiding this comment.
This looks good. I particularly like the "Principles" section.
My main confusion is around the need to introduce identifier and the @ prefix in addition to the existing id and # prefix. I can understand that reduces the potential for id clashes, but the potential for those still exits within the two namespaces. So I'm not sure of the benefit relative to introducing more complexity.
As a certified schema.org fanboy, I am also nervous about the risk of redoing the substantial work already done there around creative work metadata. It already covers so much of this. But maybe that is a conversation for future RFCs.
| Proposes a reserved `metadata` property on every OXA node that carries structured information about the node's content — title, authors, affiliations, funding, licenses, identifiers, and other descriptive data. Metadata is modular, referenceable, and composable: it propagates from parent to child, can be overridden at any level of the tree, and supports cross-references between metadata entries. This RFC establishes the principles and structural conventions for metadata; the specific field definitions are deferred to future RFCs. | ||
| --- | ||
|
|
||
| This RFC introduces a `metadata` property available on every OXA content node. The property provides a structured place for descriptive information — authorship, licensing, identifiers, titles, affiliations, funding, and similar concerns — that applies to the node and, by default, to all of its descendants. |
There was a problem hiding this comment.
The following paragraph is a little confusing when this one ends with "that applies to the node and, by default, to all of its descendants". The phrase "by default" is there, but still, i don't think this is necessary up front.
| This RFC introduces a `metadata` property available on every OXA content node. The property provides a structured place for descriptive information — authorship, licensing, identifiers, titles, affiliations, funding, and similar concerns — that applies to the node and, by default, to all of its descendants. | |
| This RFC introduces a `metadata` property available on every OXA content node. The property provides a structured place for descriptive information such as authorship, licensing, identifiers, titles, affiliations, funding, and similar concerns. |
| authors?: (AuthorData | MetadataReference)[]; | ||
| license?: LicenseData | MetadataReference; | ||
| identifiers?: Record<string, string>; | ||
| affiliations?: (AffiliationData | MetadataReference)[]; |
There was a problem hiding this comment.
I feel like having affiliations at the root of the metadata is a carry over from how they are normally presented (i.e. a list of authors, followed by a list of their affiliations). This can also be a nicer way to author affiliations e.g. in YAML metadata because it saves repetition. But I don't think it is a great canonical data representation.
In Stencila Schema we follow schema.org and make affiliations a property of a Person: https://stencila.io/docs/schema/person/#properties.
OpenAlex is similar in that it has affilations as a property of an Author: https://developers.openalex.org/api-reference/authors/get-a-single-author#response-affiliations
| license?: LicenseData | MetadataReference; | ||
| identifiers?: Record<string, string>; | ||
| affiliations?: (AffiliationData | MetadataReference)[]; | ||
| funding?: (FundingData | MetadataReference)[]; |
There was a problem hiding this comment.
For reference, in Schema Schema, again following from schema.org, we use funders (Person or Organization) and fundedBy (Grant or MonetgaryGrant) instead of funding: https://stencila.io/docs/schema/article/#properties.
| value: ' conceived the study and wrote the initial draft.' | ||
| ``` | ||
|
|
||
| The `@` prefix distinguishes metadata references from content references (e.g. `#fig1` for a figure, `@rowan` for a metadata reference, like authors). The exact cross-reference mechanics will be defined in a future RFC on cross-references. |
There was a problem hiding this comment.
I don't immediately see the need for this dichotomy, or the for the id vs identifier dichotomy. Maybe the reasoning is below and I'll get to it, but if it is, it might be useful to move up to here.
| - Software | ||
| ``` | ||
|
|
||
| The image does not redefine Rowan's name, ORCID, or affiliations — it references the canonical entry and layers on context-specific roles. This composition pattern means that updating the author's ORCID in the document metadata automatically propagates to all references. |
|
|
||
| ### Metadata Identifiers | ||
|
|
||
| All identifiable entries within metadata (authors, affiliations, funders, grants, venues, etc.) carry an `identifier` field. These identifiers: |
There was a problem hiding this comment.
As mentioned above, I don't understand why we need to add a identifier field when all OXA nodes already have an id node.
This is coming off some of the recommendations in the the Modular Incentives working group (Creative Commons & Continuous Science Foundation):
https://articles.continuousfoundation.org/articles/reuse-incentives/recommendations
I think there are certainly a lot of places to improve the general plan for metadata, looking to others for help in shaping this and additional authorship. We can then move to specific metadata proposals (licensing, attribution, etc.).