-
-
Save mjgiarlo/7096160 to your computer and use it in GitHub Desktop.
| <info:fedora/scholarsphere:g732d898n> <http://purl.org/dc/terms/accessRights> <info:fedora/scholarsphere:g732d898n/rightsMD> . | |
| <info:fedora/scholarsphere:g732d898n/rightsMD> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://purl.org/dc/terms/RightsStatement> . | |
| # This blank node can of course be a real URI | |
| <info:fedora/scholarsphere:g732d898n/rightsMD> <http://projecthydra.org/ns/rights/edit> _:editors . | |
| # These strings could be URIs | |
| _:editors <http://purl.org/dc/terms/rightsHolder> "mjg36@psu.edu" . | |
| _:editors <http://purl.org/dc/terms/rightsHolder> "dmc186@psu.edu" . | |
| <info:fedora/scholarsphere:g732d898n/rightsMD> <http://projecthydra.org/ns/rights/view> _:viewers . | |
| _:viewers <http://purl.org/dc/terms/rightsHolder> "public" . |
Is there any reason not to attach the rights directly to the object?
<info:fedora/scholarsphere:g732d898n> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://purl.org/dc/terms/RightsStatement> .
<info:fedora/scholarsphere:g732d898n> <http://projecthydra.org/ns/rights/edit> "mjg36@psu.edu" .
<info:fedora/scholarsphere:g732d898n> <http://projecthydra.org/ns/rights/edit> "dmc186@psu.edu" .
<info:fedora/scholarsphere:g732d898n> <http://projecthydra.org/ns/rights/view> "public" .
@no-reply: I like your alternative, and I have to admit that I'm not sure why I put that blank node in there.
Agree about rightsHolder, though dcterms offers fairly little information about what "owning or managing rights" means (this suggests that rightsHolder is NOT a good fit: http://dublincore.org/usage/meetings/2004/03/dc-rights-proposal.html ). Maybe it could work as a super-property unless there's something better in that permissions ontology.
As for how we express the identities of the rights holders themselves, I like the idea of using mailto URIs, though we may need to be agnostic to allow for the sort of variation that is seen across hydra apps -- though all probably will have usernames and email addresses.
@escowles: I like the simplicity in your suggestion. Is it OK to assert that the Fedora PID is a RightsStatement, or put otherwise, to assert multiple RDF types for that URI? Though I am usually a big dcterms proponent, I wonder if the rights stuff in there is too overloaded, or underdocumented/underused, to serve as a model for us. Perhaps the permissions ontology would be a better base, and make for a simple, interoperable example.
@mjgiarlo: I think this question about the type of a PID reflects a bigger identity issue we may want to resolve.
As for dc:rights and dc:RightsStatement, Oregon Digital is using both the property and class to manage rights to the public (licenses, and wishy-washy statements like "for educational use"). I think that's closer to the intended usage--and seems clearly compatible with the RDF published by Creative Commons, for example.
Coming back to this after a long time, thinking about simplifying our rights metadata and how it would work with Fedora 4...
@mjgiarlo: it's totally fine to have multiple RDF types on an object. There are some ontologies that try to model exclusively like XML schema, but it's more common for types to be additive, like adding a concern to a model in Ruby.
I agree with @no-reply that dc:RightsStatement is a reasonable vessel for both strong/actionable rights information and wishy-washy notes. Though it might make more sense to define a more precise type (hydra:RightsStatement or similar) for clarity.
The other set of predicates I was thinking could be used are a few from the new PREMIS ontology: hasCopyrightStatus, hasCopyrightJurisdiction, hasStatuteCitation, hasStatuteJurisdiction, hasLicenseTerms. Those fill out most of the content that is in the blocks of the current rightsMetadata schema. And including those should allow mapping to the full, deeply-nested PREMIS.
We also have two other fields in mind, but I'm not sure if other people would want to use these or not:
- otherRights (this is based on PREMIS, but not present as a class/predicate in the ontology. We use this mostly for fair use and other administrative overrides).
- advisory: a field for a click-through notice shown before accessing an object (we use this for a variety of cultural sensitivity issues).
Why not simply:
I'm not sure dc:rightsHolder is the right term, here. I think the statements in the initial straw-person say the users hold the rights to /rightsMD, as opposed to some specific rights over /scholarsphere:g732d898n.
I would also suggest mailto: URIs as a bridge between existing relational database user tables and RDF rights metadata.