Skip to content
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

Genre aliasing #105

Open
NicolasCARPi opened this issue Nov 22, 2024 · 0 comments
Open

Genre aliasing #105

NicolasCARPi opened this issue Nov 22, 2024 · 0 comments

Comments

@NicolasCARPi
Copy link
Contributor

          Following @SteffenBrinckmann comment on #103, `@type` MUST be a single string value while additional types should go to `genre`.

I understand the point of limiting variances.
However, @type is rather central in any RDF/JSON-LD reasoning, validation and framing operation.
A workaround would be to alias genre as @type ìf required by an interpreter

{
  "@context": [
    "https://w3id.org/ro/crate/1.1/context",
    {
      "genre": "@type"
    },
    "type": "schema:Dataset",
    "genre": "ex:CustomType"
  ]
}

In this case it would be helpful to allow genre to by an array of IRIs. This would allow the TheELNConsortium to specify a list of common types while vendors can add more specific subtypes to persist internal classification.

{
  "@context": [
    "https://w3id.org/ro/crate/1.1/context",
    {
      "eln": "https://w3id.org/TheELNConsortium/",
      "elabftw": "...",
      "osw": "https://opensemantic.world/id/"
    }
  ],
  "genre": [
    "eln:Experiment",
    "osw:Category-3AOSW0e7fab2262fb4427ad0fa454bc868a0d"
  ]
}

Otherwise additionalType IRIs may be the right location for those IRIs

Originally posted by @simontaurus in #69 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant