Provide abstracted API for data access by clients

[sdruskat]

Implement as follows:

model/__init__.py

Use the Schema.org names SoftwareSourceCode and SoftwareApplication and provide classes for both (here still called SoftwareMetadata), or (perhaps better) add a flag software_application: bool = False to auto-add @type to the returned data.

from .types.software_metadata import SoftwareMetadata

• Create SoftwareMetadata class in .types.software_metadata similar to the following, but taking either:
  • a single schema or a list of schemas, or
  • a list of schemas (as below)

class SoftwareMetadata(ld_dict):
    def __init__(self, extra_contexts=[]):
        super().__init__([{}], context=[*ld_context.HERMES_BASE_CONTEXT, *extra_contexts])

Now, clients can access data (and inject new schemas to be used) by doing:

from hermes.model import SoftwareMetadata

data = SoftwareMetadata(extra_contexts=[{"my_schema": "https://my_schema.tld", "other_schema": "https://other_schema.tld"}])
data["my_schema:field"] = "foo"
data["other_schema:field"] = "bar"
data["funding"] = "nope"  # from CodeMeta

return data

[led02]

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

[sdruskat]

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

In #377 (comment), we decided that it should be possible to describe both source code and applications, specifically to support non-source code publications, e.g., for closed source software.

Hence, the API needs to provide a way to retrieve the specific @type.

Our preferred way of doing this is:

class SoftwareMetadata(ld_dict):
    def __init__(self, extra_contexts=[], software_application: bool = False):
        super().__init__([{}], context=[*ld_context.HERMES_BASE_CONTEXT, *extra_contexts], software_application=software_application)

This also means that ld_dict may need to be changed to accept a bool kw software_application with default False (see third code line above).

Question: Arguably, @types are only relevant for harvest plugins, right? Both curation and deposition should work with what they are passed...

[sdruskat]

Question: Arguably, @types are only relevant for harvest plugins, right? Both curation and deposition should work with what they are passed...

Probably not even that! The type should come from configuration, and the sensible default should be @type: SoftwareSourceCode. As far as I can see, this means that the API needs access to runtime configuration to be able to determine the @type to pass back.

Options to enable this that come to mind are:

• Pass config to SoftwareMetadata (which would be overkill, I think?)
• Implement SoftwareMetadata in a plugin base class (harvest, most likely?), where it can access runtime config to check for values and set defaults.

The second option sounds sensible to me, especially as this API is primarily intended for use in plugins.

Any thought, @led02?

[sdruskat]

Related to #383 (comment), this also means that in practice, SoftwareMetadata implements what #403 and #421 started to assume for ld_context.__getitem__, namely via ld_dict, right? (To be tested in #410...)

from hermes.model import SoftwareMetadata

def my_plugin_logic():
    data = SoftwareMetadata(extra_contexts=[{"my_schema": "https://my_schema.tld", "
                                              other_schema": "https://other_schema.tld"}])
    data["my_schema:field"] = "foo"
    data["other_schema:field"] = "bar"
    data["funding"] = "nope"  # from CodeMeta
    # Alternatively: data["https://codemeta.github.io/terms/funding"] = "nope"
    data["schema:award"] = "CampusSOURCE Award 2021"  # from Schema.org
    # Or full IRI
    data["hermes:gitBranch"] = "develop"  # from hermes schema
    # Or full IRI
    return data

(I'm starting to believe that giving users the option to pass in full IRIs would be useful.)

[led02]

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

[led02]

Options to enable this that come to mind are:

• Pass config to SoftwareMetadata (which would be overkill, I think?)
• Implement SoftwareMetadata in a plugin base class (harvest, most likely?), where it can access runtime config to check for values and set defaults.

The second option sounds sensible to me, especially as this API is primarily intended for use in plugins.

Any thought, @led02?

Now I see you drifting into over-engineering... ;)

In fact, it is relevant whether we have SoftwareSourceCode or SoftwareApplication.
However, the actual content or applied vocabulary does not differ...
I'm a bit hesitant to obstruct those complex implementation details upon pool litte developers.

In the end, it's also just a question of applying the appropriate "merging strategy", so this could be handled by the merger...

[sdruskat]

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

Yes, that's how I understood it, asked in my comment above to be safe ;).

In fact, it is relevant whether we have SoftwareSourceCode or SoftwareApplication. However, the actual content or applied vocabulary does not differ... I'm a bit hesitant to obstruct those complex implementation details upon pool litte developers.

In the end, it's also just a question of applying the appropriate "merging strategy", so this could be handled by the merger...

Sure. In the end, the end user needs to provide the info if they're using hermes for code or app, so doing this in configuration is necessary anyway. Can then be picked up by a merging strategy.

No need to provide API, I agree.

So to summarize, the only model API that's being exposed to developers is:

from hermes.model.types import ld_dict

DEFAULT_CONTEXT = {
    None: "https://codemeta.github.io/terms/", 
    "schema": "http://schema.org/", 
    "hermes": "https://hermes.software-metadata.pub/schema/software-metadata/"
    }

class SoftwareMetadata(ld_dict):
    
    def __init__(self, extra_contexts: dict[str] = dict()):
        super().__init__([{}], context=[{**DEFAULT_CONTEXT, **extra_contexts}]) 

[led02]

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 comment (softwarepub/hermes#376) 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 Yes, that's how I understood it, asked in my comment above to be safe ;). In fact, it is relevant whether we have SoftwareSourceCode or SoftwareApplication. However, the actual content or applied vocabulary does not differ... I'm a bit hesitant to obstruct those complex implementation details upon pool litte developers. In the end, it's also just a question of applying the appropriate "merging strategy", so this could be handled by the merger... Sure. In the end, the end user needs to provide the info if they're using hermes for code or app, so doing this in configuration is necessary anyway. Can then be picked up by a merging strategy. No need to provide API, I agree. So to summarize, the only model API that's being exposed to developers is: from hermes.model.types import ld_dict DEFAULT_CONTEXT = { None: "https://codemeta.github.io/terms/", "schema": "http://schema.org/", "hermes": "https://hermes.software-metadata.pub/schema/software-metadata/" } class SoftwareMetadata(ld_dict): def __init__(self, extra_contexts: dict[str] = dict()): super().__init__([{}], context=[{**DEFAULT_CONTEXT, **extra_contexts}]) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>