Our framework introduces 'basic' rights statements, which can be re-used as such in object metadata. It is also possible to create 'custom' statements tailored to specific objects (e.g., with a specific expiry date) that will be attached to these objects.
Earlier Europeana discussions raised the question, whether one should use a unique property to link objects to the attached rights in both cases, or if different properties should be used (i.e., edm:rights for all assertions, vs. edm:rights plus another property). @aisaac's recommendation was to use edm:rights for everyrthing.
Right now, Europeana uses one edm:rights. It is more economical from a data perspective, and feels conceptually right. Other frameworks like ODRL and CCrel have examples that use one property (linking to more-or-less complex instances of odrl:Policy or cc:License).
But ODRS makes a conceptual difference between object-level (dataset-level, for ODRS) statements and licenses, representing them as disjoint but related resources.
From a data consumer perspective, using a different property allows not to mix simple cases with more complex resources in one place, which can be interesting for data providers and data re-user. Those interested in more complex rights will know that they should get or produce their data using the specific property, these with simple needs could avoid too complex guidelines.
@escowles's examples have PREMIS copyright status (premis:hasCopyrightStatus) distinct from the statement with dcterms:rights. But these properties are meant to serve another purpose, i.e. documenting the decision to assign the rights statements to the object.
Suggested resolution: it's preferable to use the same property for when an object is related to a basic rights statement or a 'custom' one. Other rights-related properties may be used, but for different purposes, i.e. documenting the motivation for assigning a rights statement to an object.
Our framework introduces 'basic' rights statements, which can be re-used as such in object metadata. It is also possible to create 'custom' statements tailored to specific objects (e.g., with a specific expiry date) that will be attached to these objects.
Earlier Europeana discussions raised the question, whether one should use a unique property to link objects to the attached rights in both cases, or if different properties should be used (i.e.,
edm:rightsfor all assertions, vs.edm:rightsplus another property). @aisaac's recommendation was to useedm:rightsfor everyrthing.Right now, Europeana uses one edm:rights. It is more economical from a data perspective, and feels conceptually right. Other frameworks like ODRL and CCrel have examples that use one property (linking to more-or-less complex instances of
odrl:Policyorcc:License). But ODRS makes a conceptual difference between object-level (dataset-level, for ODRS) statements and licenses, representing them as disjoint but related resources.From a data consumer perspective, using a different property allows not to mix simple cases with more complex resources in one place, which can be interesting for data providers and data re-user. Those interested in more complex rights will know that they should get or produce their data using the specific property, these with simple needs could avoid too complex guidelines.
@escowles's examples have PREMIS copyright status (
premis:hasCopyrightStatus) distinct from the statement withdcterms:rights. But these properties are meant to serve another purpose, i.e. documenting the decision to assign the rights statements to the object.Suggested resolution: it's preferable to use the same property for when an object is related to a basic rights statement or a 'custom' one. Other rights-related properties may be used, but for different purposes, i.e. documenting the motivation for assigning a rights statement to an object.