In the model we are currently discussing, the "contribution-class" pattern of description, aka "structured representation", description would look like this (see also Kalli's example from BIBFRAME):
:a rdf:type ex:Movie ;
bibo:hasContribution :b .
:b rdf:type bibo:Contribution .
bibo:hasAgent :c .
bibo:role marcrel:aut .
In @osma's diagram, the "simple representation" would be:
:a rdf:type ex:Movie;
dct:contributor :c # or dct:creator
In the SRAP review to date, we seem to be leaning towards approving the more structured contribution-class pattern. As @osma has pointed out, however, it would be awkward for DCMI to publish an application profile that did not also support the "simple representation".
I think we should approve both patterns, with appropriate explanation, and in addition we should explain how to derive the simple representation from the more structured. We could use the term "dumb down" for the process of simplifying the "contribution-class" pattern to the "simple DC" pattern. The term "dumb-down", which was used in the DCMI Data Model Working Group in the 1990s for the process of resolving qualified DC descriptions to simple and was later used to describe the resolution of SKOS-XL labels to "vanilla" SKOS lexical labels by inference.
If we approve the contribution-class pattern, we could take advantage of the way MARC relators are formally defined in RDF and used in RDF data. MARC relators began as simple three-letter codes (strings) for use in MARC records. In the early 2000s, the Usage Board helped Library of Congress prepare a selection of MARC Relator Terms as refinements of dc:contributor. To do this, LC assigned URIs such as https://www.loc.gov/loc.terms/relators/ACT -- URIs that were retired after the start of the id.loc.gov in 2009.
Today, http://id.loc.gov/vocabulary/relators/act is defined both as a subproperty of dc:contributor (as in 2005) -- ie, as an instance of rdf:Property -- and also as an instance of skos:Concept (and bf:Role). (I remember reading somewhere an explicit acknowledgement from Kevin Ford of the MARC Standards Office that this was a deliberate design choice. If anyone finds a link, please drop me a line.)
This pattern of punning a SKOS concept as an RDF property does not violate any formal rules and indeed, in the case of the structured and simple patterns for representing contributors in SRAP, it could provide a neat addition to the process of dumb-down, where:
:a rdf:type ex:Movie ;
bibo:hasContribution :b .
:b rdf:type bibo:Contribution .
bibo:hasAgent :c ;
bibo:role marcrel:aut . # as SKOS concept
could dumb down to:
:a rdf:type ex:Movie ;
dct:contributor :c ;
marcrel:aut :c . # as RDF property
In other words, we could embrace the double nature of marcrel:aut as concept as as property and put it to good use.
If we approve both patterns, we would need:
- a formal expression usable to transform the structured pattern into the simple. This could be something like the sub-property chain axioms used to dumb down SKOS-XL labels to vanilla SKOS labels. For example Axiom S55, which reads: "The property chain (
skosxl:prefLabel, skosxl:literalForm) is a sub-property of skos:prefLabel."
- some sort of additional triple to express whether the structured description dumbs down to the
dct:contributor relationship or to dct:creator
In the model we are currently discussing, the "contribution-class" pattern of description, aka "structured representation", description would look like this (see also Kalli's example from BIBFRAME):
In @osma's diagram, the "simple representation" would be:
In the SRAP review to date, we seem to be leaning towards approving the more structured contribution-class pattern. As @osma has pointed out, however, it would be awkward for DCMI to publish an application profile that did not also support the "simple representation".
I think we should approve both patterns, with appropriate explanation, and in addition we should explain how to derive the simple representation from the more structured. We could use the term "dumb down" for the process of simplifying the "contribution-class" pattern to the "simple DC" pattern. The term "dumb-down", which was used in the DCMI Data Model Working Group in the 1990s for the process of resolving qualified DC descriptions to simple and was later used to describe the resolution of SKOS-XL labels to "vanilla" SKOS lexical labels by inference.
If we approve the contribution-class pattern, we could take advantage of the way MARC relators are formally defined in RDF and used in RDF data. MARC relators began as simple three-letter codes (strings) for use in MARC records. In the early 2000s, the Usage Board helped Library of Congress prepare a selection of MARC Relator Terms as refinements of dc:contributor. To do this, LC assigned URIs such as https://www.loc.gov/loc.terms/relators/ACT -- URIs that were retired after the start of the id.loc.gov in 2009.
Today, http://id.loc.gov/vocabulary/relators/act is defined both as a subproperty of
dc:contributor(as in 2005) -- ie, as an instance ofrdf:Property-- and also as an instance ofskos:Concept(andbf:Role). (I remember reading somewhere an explicit acknowledgement from Kevin Ford of the MARC Standards Office that this was a deliberate design choice. If anyone finds a link, please drop me a line.)This pattern of punning a SKOS concept as an RDF property does not violate any formal rules and indeed, in the case of the structured and simple patterns for representing contributors in SRAP, it could provide a neat addition to the process of dumb-down, where:
could dumb down to:
In other words, we could embrace the double nature of
marcrel:autas concept as as property and put it to good use.If we approve both patterns, we would need:
skosxl:prefLabel,skosxl:literalForm)is a sub-property ofskos:prefLabel."dct:contributorrelationship or todct:creator