Generalize dynamic `skos:prefLabel` generation to `skos:note` (maybe more) #168

New issue

Open

opened 2025-08-06 12:04:31 +00:00 by mih · 3 comments

mih commented

2025-08-06 12:04:31 +00:00

(Migrated from github.com)

A use case would be to say to use a description property as a skos:note.

A use case would be to say to use a `description` property as a `skos:note`.

jsheunis commented

2025-08-18 21:20:05 +00:00

(Migrated from github.com)

So where we currently have e.g.

    "display_name_autogenerate": {
        "trr379cps:City": "{trr379cps:name}",
        "trr379cps:Country": "{trr379cps:name}",
        "trr379cps:ConsortiumParticipation": "{trr379cps:participation_start_date}-{trr379cps:participation_end_date} ({trr379cps:status_group})",
        "trr379cps:DSCOrganization": "{trr379cps:name}",
        "trr379cps:Contributor": "{trr379cps:given_name} {trr379cps:family_name}",
        "trr379cps:PromotionStatus": "{trr379cps:promotion_start_date}/{trr379cps:dissertation_submission_date}/{trr379cps:oral_exam_date}",
        "trr379cps:PromotionQualifyingDegree": "{trr379cps:degree_type}"
    },
    "display_name_autogenerate_placeholder": {
        "default": "?"
    },

we could generalize this to something like property_value_autogenerate. However, we should note that the display_name_autogenerate option works by generating a display name for a given record, which displays if that record does not have a skos:prefLabel associated. So it does not set a value of a known property of the record, i.e. it does nothing to the data. It is purely for display purposes. So property_value_autogenerate would be an ambiguous name for the option.

We could still generalize and then allow a set of known display options, one of which would be the skos:note. E.g.

{
    "display_value_autogenerate": {
        "name": {            
            "trr379cps:City": "{trr379cps:name}",
            "trr379cps:Country": "{trr379cps:name}",
            "trr379cps:ConsortiumParticipation": "{trr379cps:participation_start_date}-{trr379cps:participation_end_date} ({trr379cps:status_group})",
            "trr379cps:DSCOrganization": "{trr379cps:name}",
            "trr379cps:Contributor": "{trr379cps:given_name} {trr379cps:family_name}",
            "trr379cps:PromotionStatus": "{trr379cps:promotion_start_date}/{trr379cps:dissertation_submission_date}/{trr379cps:oral_exam_date}",
            "trr379cps:PromotionQualifyingDegree": "{trr379cps:degree_type}"
        },
        "note": {
            "trr379cps:City": "{dlthings:description}",
            "trr379cps:Country": "{dlthings:description}",
            ...
        }
    }
}

Having written this, I see that it would also be convenient to not have to rewrite the same rule for all classes if the rule is the same, i.e. being able to configure "always use dlthings:description for the skow:note display" would be great. That could also be added to this feature.

Thoughts?

So where we currently have e.g. ``` "display_name_autogenerate": { "trr379cps:City": "{trr379cps:name}", "trr379cps:Country": "{trr379cps:name}", "trr379cps:ConsortiumParticipation": "{trr379cps:participation_start_date}-{trr379cps:participation_end_date} ({trr379cps:status_group})", "trr379cps:DSCOrganization": "{trr379cps:name}", "trr379cps:Contributor": "{trr379cps:given_name} {trr379cps:family_name}", "trr379cps:PromotionStatus": "{trr379cps:promotion_start_date}/{trr379cps:dissertation_submission_date}/{trr379cps:oral_exam_date}", "trr379cps:PromotionQualifyingDegree": "{trr379cps:degree_type}" }, "display_name_autogenerate_placeholder": { "default": "?" }, ``` we could generalize this to something like `property_value_autogenerate`. However, we should note that the `display_name_autogenerate` option works by generating a _display name_ for a given record, which displays if that record does not have a `skos:prefLabel` associated. So it does not set a value of a known property of the record, i.e. it does nothing to the data. It is purely for display purposes. So `property_value_autogenerate` would be an ambiguous name for the option. We could still generalize and then allow a set of known display options, one of which would be the `skos:note`. E.g. ``` { "display_value_autogenerate": { "name": { "trr379cps:City": "{trr379cps:name}", "trr379cps:Country": "{trr379cps:name}", "trr379cps:ConsortiumParticipation": "{trr379cps:participation_start_date}-{trr379cps:participation_end_date} ({trr379cps:status_group})", "trr379cps:DSCOrganization": "{trr379cps:name}", "trr379cps:Contributor": "{trr379cps:given_name} {trr379cps:family_name}", "trr379cps:PromotionStatus": "{trr379cps:promotion_start_date}/{trr379cps:dissertation_submission_date}/{trr379cps:oral_exam_date}", "trr379cps:PromotionQualifyingDegree": "{trr379cps:degree_type}" }, "note": { "trr379cps:City": "{dlthings:description}", "trr379cps:Country": "{dlthings:description}", ... } } } ``` Having written this, I see that it would also be convenient to not have to rewrite the same rule for all classes if the rule is the same, i.e. being able to configure "always use `dlthings:description` for the `skow:note` display" would be great. That could also be added to this feature. Thoughts?

mih commented

2025-08-19 02:48:39 +00:00

(Migrated from github.com)

I do wonder, if all does do not duplicate linkml's ability to declare string serializations and structured patterns?

jsheunis commented

2025-08-19 18:47:02 +00:00

(Migrated from github.com)

I think pretty much yes. But the challenge is that we need those display values in the annotation tool, when the user is busy using it, while LinkML would only be able to do its magic after the data has been submitted and validated/processed on the server side.