Wanted: sub-templates for grouping of properties (not instantiating a specific class)

[olufine]

We are experimenting with Sinopia creating templates based on RDA. Intuitively, we tried to define nested templates with groups of properties used in many main templates, for example a template called "subjects description", containing several properties like "agent as subject", "geographical coverage", "classification", etc.
I was allowed to do this as long as I dreamed up a class to instantiate (I chose rdf:resource).
However, this will of course create erroneous rdf, with a blank-node instance of rdf:resource having the properties specified in the nested template, like this :

<https://api.stage.sinopia.io/resource/cac79a92-2bec-4cc9-8f6b-14936190ef73> <http://sinopia.io/vocabulary/hasResourceTemplate> "NB-lab:RDA:Verk:Musikk:Oddrun"; a <http://www.rdaregistry.info/Elements/c/C10001>; <http://id.loc.gov/ontologies/bibframe/adminMetadata> _:b242; <http://rdaregistry.info/Elements/w/P10223> "Symfoni i D-dur for orkester"@nb; <http://rdaregistry.info/Elements/w/P10053> <http://hdl.handle.net/11250/1725092>; <https://schema.nb.no/Bibliographic/Properties/P1000> <https://schema.nb.no/Bibliographic/Values/V1001>; <http://rdaregistry.info/Elements/w/P10256> _:b243; <http://rdaregistry.info/Elements/w/P10398> "1867"^^<http://id.loc.gov/datatypes/edtf/>; <http://rdaregistry.info/Elements/w/P10079> "Opus 4"@nb; <http://rdaregistry.info/Elements/w/P10220> "Orkester"@nb; <http://rdaregistry.info/Elements/w/P10221> "D-dur"@nb. _:b242 a <http://id.loc.gov/ontologies/bibframe/AdminMetadata>; <http://id.loc.gov/ontologies/bflc/catalogerId> "Olufine"; <http://id.loc.gov/ontologies/bibframe/creationDate> "2022-05-09"; <http://id.loc.gov/ontologies/bibframe/source> <http://id.loc.gov/vocabulary/organizations/noosnb>; <http://id.loc.gov/ontologies/bibframe/descriptionConventions> <https://id.loc.gov/vocabulary/descriptionConventions/rda>; <http://id.loc.gov/ontologies/bibframe/descriptionAuthentication> <https://id.loc.gov/vocabulary/marcauthen/norbibl.html>; <http://id.loc.gov/ontologies/bibframe/descriptionLanguage> <https://id.loc.gov/vocabulary/languages/nob.html>. <http://id.loc.gov/vocabulary/organizations/noosnb> <http://www.w3.org/2000/01/rdf-schema#label> "Nasjonalbiblioteket (The National Library of Norway)"@en. <https://id.loc.gov/vocabulary/descriptionConventions/rda> <http://www.w3.org/2000/01/rdf-schema#label> "Resource Description and Access"@en. <https://id.loc.gov/vocabulary/marcauthen/norbibl.html> <http://www.w3.org/2000/01/rdf-schema#label> "National Library of Norway (Nasjonalbiblioteket)"@en. <https://id.loc.gov/vocabulary/languages/nob.html> <http://www.w3.org/2000/01/rdf-schema#label> "Norsk bokmål"@no. <http://hdl.handle.net/11250/1725092> <http://www.w3.org/2000/01/rdf-schema#label> "Svendsen, Johan"@nb. <https://schema.nb.no/Bibliographic/Values/V1001> <http://www.w3.org/2000/01/rdf-schema#label> "Musikkverk"@nb. _:b243 a <http://www.w3.org/2000/01/rdf-schema#Resource>; <http://rdaregistry.info/Elements/w/P10256> <http://fictive.com/symfonier>. <http://fictive.com/symfonier> <http://www.w3.org/2000/01/rdf-schema#label> "Symfonier"@nb.

Instead of http://fictive.com/symfonier being related (by rda:P10256 (has subject)) to _:b243, we want to connect it to the described resource (https://api.stage.sinopia.io/resource/cac79a92-2bec-4cc9-8f6b-14936190ef73).
As nested templates work today, they must instantiate some class that is included in the range of the property they are specified for. I realize this fits well with the way BIBFRAME is designed, with lots of somewhat specialized classes representing clusters of properties. However, for RDA, with practically all the semantics being expressed through a large number of different relationships between the standard bibliographic entities, nested templates are of limited use.
Hence, in addition to nested templates, it would be very helpful to be able to group properties into sub-templates in such a way that the properties are understood as direct properties of the resource described in the main template (the template "calling" the sub-template).

[michelleif]

Hi, could you say more about the need to group these properties? You could just set up a property template (field) for each property in a single template? Are you saying for example you have a set of properties x, y, z and you would like to reuse this set in several templates and save yourself the trouble of recreating each individual property in each template?

[NancyL]

hi Oddrun, While it does not resolve completely what you want by any means, you can group properties in a drop-down list fashion, though they would have to share the same lookup vocabulary or be literals. That might help in some places, though clearly not transferable from template to template

[olufine]

Hi, ...Are you saying for example you have a set of properties x, y, z and you would like to reuse this set in several templates and save yourself the trouble of recreating each individual property in each template?

Yes, that was the gist of my somewhat long-winded explanation above. Also because templates sometimes get very long, making them hard to navigate, so being able to cluster properties that "have to do with the same thing" although not representing any specific class (e.g. properties describing the subject(s) of a resource), and reusing such clusters in other templates would help a great deal.

[olufine]

hi Oddrun, While it does not resolve completely what you want by any means, you can group properties in a drop-down list fashion, though they would have to share the same lookup vocabulary or be literals. That might help in some places, though clearly not transferable from template to template

Hi Nancy, Thank you for this tip, that can certainly be useful in many situations, at least make some templates more compact. One has to evaluate the risk of erroneous metadata though: In my "subject description" example, in which properties with different ranges would be put into the property drop-down ( (e.g. ranges like rda:Agent, rda:Work, lc:SubjectHeadings), one would have to set up all the appropriate lookups for the property group. Then the cataloguer has to be relied upon to always choose the right lookup for each property in the group. Since they also share label, this might not always be easy. But still, it's a nice feature!