Incorrect Prefix Mapping in context.json

[tekrajchhetri]

I noticed that the current context file (context.json) is generating an incorrect mapping for the Activity class. Specifically, it maps Activity to dandi:Activity, while it should instead reference the prov:Activity from the PROV ontology.

Interestingly, the prov prefix is already defined in the context, but it is not being utilized.

Expected Behavior:

The context should reference:

"Activity": "prov:Activity"

Why This Matters:
Using the incorrect prefix implies that Activity is a custom DANDI-defined term rather than a standard term from the PROV ontology. This breaks semantic alignment with existing ontologies/schemas and hinders interoperability, which is critical for downstream applications and FAIR compliance.

Suggested Fix: Use the correct prefix.

Note: Since I am familiar with PROV ontology so I observe the issue but there might be issues with other classes/properties. It is advisable that we do check all classes/properties to ensure that they're using the correct prefix.

@yarikoptic @candleindark @kabilar

[candleindark]

This is mostly caused by the value of the "nskey" field at

https://github.com/dandi/dandi-schema/blob/6d6c7b18addc40bbbbe8311d4a3f8a37e832cc3d/dandischema/models.py#L1235C80-L1235C85

[satra]

@tekrajchhetri - as noted in the line @candleindark shared this is technically dandi:Activity, which is a subclass of prov:Activity.

[tekrajchhetri]

@satra I see in the context that it is marked as the subclass of but in the generated YAML file I do not see it reflected. Shouldn't the yaml file have is_a pointing to prov:Activity? I should have been clear about it earlier.

[candleindark]

@tekrajchhetri By YAML file, are you talking about the generated LinkML schema file? If that's the one, it is not complete.

@satra I can't find any use of "rdfs:subClassOf": ["schema:Person", "prov:Person"] in generating the context at context.json and https://github.com/dandi/schema/tree/master/terms doesn't contain a YAML file for Activity either.

[tekrajchhetri]

@candleindark Yes, I am referring to the LinkML schema file.

[yarikoptic]

I wonder where/how we should address this, i.e.

• where to encode such knowledge (of subclassing) within our pydantic models so they are taking into account while producing linkml models?
• could it be anyhow exported/represented in current produced context.json ?

[satra]

the solution i had proposed originally was linkml as the form which can represent both the context and also what's needed to generate owl or other semweb components. we were not generating term/class docs in jsonld (similar to schema.org), which is what would be needed otherwise.

unless we shift to a data model that can represent the various components, we will be writing translators based on pydantic and create our own other list of transformers. hence the linkml suggestion as the common point. also in linkml we can make a proposal for custom code to be associated as a property of a class or a slot. chris mungall and i had a bit of a discussion on that topic.