Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rights refinement for jurisdiction #104

Open
HughP opened this issue May 16, 2022 · 6 comments
Open

Rights refinement for jurisdiction #104

HughP opened this issue May 16, 2022 · 6 comments

Comments

@HughP
Copy link

HughP commented May 16, 2022

Is there a clear way to indicate which jurisdiction rights apply under? For example, US Government works may be in the public domain within the USA, but within copyright outside of the USA. Another case is terms of length of copyright. A described item may be within copyright, and the date created along with the copyright assertion can be recorded. But where this copyright is asserted (Canada, EU, USA, or any other Jurisdiction) is, as far as I can tell not able to be made clearly. This impacts the term of copyright application (and aldo the validity of licenses such as creative commons licenses which are dependent on the copyright applying to the item).

So an item may be copyright 1954... but one can't know if copyright still applies to that item unless one knows the legal framework under which copyright was asserted. dc.coverage.jurisdiction does not seem to apply. Is any clarification possible?

@kcoyle
Copy link
Collaborator

kcoyle commented May 16, 2022

The Open Digital Rights Language (ODRL) uses dct:coverage for the jurisdiction. I don't know if that fits your use case, but you might want to take a look at ODRL for how they put it all together. ODRL is ostensibly an RDF vocabulary but they do state that it can be used with any other data format.

@HughP
Copy link
Author

HughP commented May 16, 2022

That is an interesting framework.

Their use of dc.coverage.jurisdiction is directly enabled by the fact that it describes the policy rather than the object. My understanding is that dct.jurisdiction is in its bare from applied to aboutness situations, in much the same way that LCSH terms are. Which in some ways makes it redundant.

In a record-based approach to description using an OAI-pmh type xml syntax, it seems that this is not possible to describe the rights statement independently of the target object directly with Dublin Core. One could add it to the URI of a rights value but then one would need a URI for each permutation of Jurisdiction + 'right type'.

@tombaker
Copy link
Collaborator

@HughP I do not know about OAI-pmh syntax today but recall that OAI-pmh originally used flat records based on the fifteen-element Dublin Core. By "flat", I mean that the metadata recorded direct properties of the resource but could say nothing further about those properties, eg, the jurisdictional applicability of a rights statement.

Is there a clear way to indicate which jurisdiction rights apply under?

If I correctly understand your question: yes - but not if the description needs to be flat.

If flatness is abandoned, one can record "these rights go with this jurisdiction" and "those rights go with that jurisdiction" with nested elements in XML or additional nodes in RDF. Perhaps this could also be done with one URI that means "rights valid in jurisdiction X" and another URI for "rights valid in jurisdiction Y", and maybe that could even be used to keep the description flat, though at the cost of coining alot of extra URIs.

As an aside, I'm curious about dc.coverage.jurisdiction, which is written in a dot-style syntax first formalized in RFC 2731 of 1999 for use with metadata embedded in HTML tags but which fell a bit out of use as "jurisdiction" came to be seen not as a qualifier of coverage (in the manner of an adjective modifying the noun) but as a subproperty of coverage (in an RDF sense, a property in its own right). Do you work with metadata that uses dc.coverage.jurisdiction?

@kcoyle
Copy link
Collaborator

kcoyle commented May 21, 2022

@HughP

Their use of dc.coverage.jurisdiction is directly enabled by the fact that it describes the policy rather than the object. My understanding is that dct.jurisdiction is in its bare from applied to aboutness situations, in much the same way that LCSH terms are.

I agree that the ODRL use of coverage has as its "resource" the policy, not the object the policy is defining the rights for. I don't know what metadata format you are using, but as TomB stated, with RDF you can define more than one resource with DC Terms. So you can say:

(my book) has dct:rights X
X has dct:coverage

And you have then defined X as a resource that dct:coverage can refer to. That is, however, possible only if you have an IRI for X. (There may be another way around this, but I'm not thinking of one at the moment.)

If, however, your use of DC Terms is "flat" then, as you said, you cannot use dct:coverage to refer to the value of dct:rights because you are not able to define multiple resources for a single metadata "record."

@tombaker
Copy link
Collaborator

@HughP @kcoyle It looks like we have shed light on the issue. Without objection, will close the issue in a few days.

@HughP
Copy link
Author

HughP commented Aug 18, 2022

@tombaker

Do you work with metadata that uses dc.coverage.jurisdiction?

I don't necessarily use dc.coverage.jurisdiction, but I do use Dublin Core in scholarly websites for Google Scholar crawling, and that is how it would appear in DSpace if there were a field for it in DSpace?

RFC2731 is really interesting. I've been looking for this source for a while, thanks. The only crawler I know of which looks in HTML for Dublin Core is GoogleScholar, and in the Google situation the stage manager (entity making the aggregator) determines the script (dialect and syntax of metadata). Is there another crawler that you know of?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants