Michael Meinel

Some additinal *term*s that will be important: - *term* - a specific key that describes a well-defined concept within a context - *prefix* - a specific key that mapps an...

Looking promising. Where do we want to put this glossary? However, I think there is still a mis-conception related to the *term IRI*: For example, the *vocabulary IRI* is https://doi.org/10.5063/schema/codemeta-2.0....

I think we have to clarify things here. I initially wrote `ContextPrefix` to facilitate my development, being tired of writing full IRIs all the time. This does not fully align...

> My proposal is to get rid of `ContextPrefix` first by using full IRIs instead of this convenience utility. > This would also make the sources more explicit, which is...

To help us use appropriate vocabulary: https://www.w3.org/TR/json-ld11/#the-context

The `__call__` method is curcial, as it is the primary interface used by `pyld`. ```python def __call__(self, url, options=None): for schema in self.cache: if url.startswith(schema['documentUrl']): return schema entry = self.load_schema(url)...

If we force the `@type` to be / contain `SoftwareSourceCode`, wouldn't that be the better / less confusing name?

Well, that is exactly what ld_dicht does already. And as expansion of an expanded IRI is a no-op, you're fine to use them

> Options to enable this that come to mind are: > > * Pass `config` to `SoftwareMetadata` (which would be overkill, I think?) > * Implement `SoftwareMetadata` in a plugin...

Again, https://codemeta.github.io/terms/ is a prefix/base URL and not a vocabulary reference. And JSON-LD does not allow „anonymous prefixes“.Von meinem iPhone gesendetAm 08.08.2025 um 12:46 schrieb Stephan Druskat ***@***.***>:sdruskat left a...