Skip to content
This repository has been archived by the owner on Aug 11, 2020. It is now read-only.

!NEEDED! dm2e2edm: Implement Public Domain Cutoff date !NEEDED! #6

Open
d0rg0ld opened this issue Nov 12, 2014 · 8 comments
Open

!NEEDED! dm2e2edm: Implement Public Domain Cutoff date !NEEDED! #6

d0rg0ld opened this issue Nov 12, 2014 · 8 comments

Comments

@d0rg0ld
Copy link
Member

d0rg0ld commented Nov 12, 2014

For Europeana ingestion of datasets where parts are old enough to be in Public Domain and others are still under copyright, it would be good to be able to selectively apply the Public Domain mark to records that are older than some arbitrary date.

The proposal is therefore to implement the following mechanism:

The provider sets a chosen rights label and ingestes the data to dm2e. Upon edm export, the export routine checks for each CHO a number of properties for available dates:

dcterms:issued
dm2e:sentOn (will be available soon)

If these (and only these) properties contain dates before the cutoff date, the CHO's edm:rights statement is set to http://creativecommons.org/publicdomain/mark/1.0/ otherwise the CHO remains as set by the provider. The rights statement also stays untouched if no date can be identified in the record!

The edm export routine should contain a flag that allows to set the threshold date in form of YYYY-MM-DD .The whole procedure will only be applied if a threshold date is explicitely set this way, otherwise the dataset is exported as is.

This will be necessary for a number of providers and should be implemented as soon as possible.

Thx and best regards
Doron

@kba
@kaiec

@kba
Copy link
Member

kba commented Nov 14, 2014

I've implemented this experimentally.

Conversion now takes a parameter for public domain date0, by. default '0000-01-01'.

When the conversion is handling 'edm:rights' statements, it loads

  • date1 (dcterms:issued)
  • date2 (dm2e:sentOn)

If date1 < date0 or date2 < date0:

On the CLI, there is an option 'public_domain_date ' to set this as well.

Still needs to be integrated into dm2e-data.sh

@d0rg0ld
Copy link
Member Author

d0rg0ld commented Nov 14, 2014

Thx a lot! Are you sure that there are no dates before 0000 ? Wouldnt it be better to set no default and only change the rights statements when a date is explicitely given?

br
doron

@kba
Copy link
Member

kba commented Nov 14, 2014

Is dm2e:sentOn a property of the aggregation or the CHO? I assume the aggregation for now.

@kba
Copy link
Member

kba commented Nov 14, 2014

What about web resources for CHOs that are put in the Public Domain like that? Should their rights statement change as well?

@d0rg0ld
Copy link
Member Author

d0rg0ld commented Nov 14, 2014

dm2e:sentOn will be on CHO level, it means the sending date of a letter.

webresources: very good point. have not thought about it. I'd say: Yes of course

kba added a commit that referenced this issue Nov 15, 2014
@kba
Copy link
Member

kba commented Nov 15, 2014

Since Web resources are so tricky to get right because it is so easy to produce contradicting rights statements: Maybe we should omit all edm:rights statements for WebResources if a Public Domain cutoff date was set.

From the EDM Mapping Guidelines:

The rights statement specified at the level of the web resource will ‘override’ the statement specified at the level of the aggregation.

If we do omit the edm;rights statements for all edm:WebResource instances, they would use the edm:rights information in the aggregation, which is exactly what we're trying to achieve. @d0rg0ld

@d0rg0ld
Copy link
Member Author

d0rg0ld commented Nov 17, 2014

I think that's the way to go, although I'd only do this for Webressources attached to edm:Object as I dont think we will have duplicate cases for WebRessources attached through other props. Saying this I have the Linked Data consumer in mind where it would be better to explicitely state the rights whereever possible

@kba
Copy link
Member

kba commented Nov 17, 2014

I guess it is possible to omit the edm:rights statements for all edm:WebResource that appear in :cho edm:rights :webresource statements. But then, the other edm:webResources will not have the same license as those aggregations that refer to them. I.e. with a cutoff-date of 1875-01-01:

:agg1 edm:aggregatedCHO :cho1 .
:agg1 edm:rights :veryRestrictiveLicense .
:cho1 edm:object :wr1 .
:agg2 edm:aggregatedCHO :cho2 .
:agg2 edm:rights :veryRestrictiveLicense .
:cho2 edm:isShownBy :wr2 .
:wr1 edm:rights :veryRestrictiveLicense .
:wr2 edm:rights :veryRestrictiveLicense .
:cho1 dct:issued 1960 .
:cho2 dct:issued 1700 .

will result in

:agg1 edm:aggregatedCHO :cho1 .
:agg1 edm:rights :veryRestrictiveLicense .
:cho1 edm:object :wr1 .
:cho1 dct:issued 1960 .
:agg2 edm:aggregatedCHO :cho2 .
*:agg2 edm:rights :PublicDomain* .
:cho2 edm:isShownBy :wr2 .
*:wr2 edm:rights :veryRestrictiveLicense .*
:cho2 dct:issued 1700 .

If that is not a problem for you, I can implement the behavior.

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

No branches or pull requests

2 participants