The copyright/owner element shouldn't contain an array.

[andrew2net]

The biblio grammar allows only a single copyright/owner, copyright/from, & copyright/to element:

copyright =
  element copyright {
    from, to?, owner
}

but there are multiple in the data: https://github.com/relaton/relaton-data-iho/blob/3c8aceec1b80c44a8d2ef34381dff6f9bf71c420/data/b-11.yaml#L36-L46

[ronaldtse]

@andrew2net yes the data is correct. We need to update the grammar.

[opoudjis]

There can be multiple copyright owners; I dispute there are multiple copyright dates.

[andrew2net]

@andrew2net yes the data is correct. We need to update the grammar.

@ronaldtse should we repeat the from and to elements for each owner? Nick said "The data is stupid", "there is a single date for copyright", and "the yaml is wrong".

[ronaldtse]

You can have multiple copyright dates with a single copyright holder, or multiple copyright holders:

https://www.heerlaw.com/copyright-faq

Can the same work have multiple copyright dates? A work may have multiple copyright dates if it is a derivative work of another copyrighted work, or a work altered substantially but made based on a work to which it is giving attribution by citing its copyright.

The YAML is correct.

[opoudjis]

@ronaldtse Clearly those are not copyright dates applying to the same work, they are applying to different related works, in the same way that we have already distributed publication dates between different related works. If you naively apply multiple copyright dates to the same work, you have no means of differentiating what work each date applies to --- for example, the copyright on the original work vs the copyright on a translation.

And the solution to this is not to start peppering copyright fields with annotations, it is to model the different entities to which different copyright dates apply, and apply them atomically. See https://www.copyright.gov/circs/circ14.pdf for the detail of what copyright can be applied to.

There is one copyright event being modelled: there is no derivative work within the IHO standard. To model two dates here is misleading.

[opoudjis]

Modelling is now:

BibliographicItem = ..., copyright*, ...

copyright = from, to?, owner+, scope?`

We are insisting on a single date per copyright, but we are allowing multiple copyright statements per bibdata, which would be differentiated by the optional "scope" statement.

Best practice is to create a related bibitem , and attach the distinct copyright statement to that bibitem; so if the translation has a distinct copyright, we have a bibdata for the translation, a related bibitem for the original, and two copyright statements, one for each. If the introduction has a distinct copyright, we have a bibdata for the entire document, a related bibitem for the introduction (as partOf the original, even if it isn't published separately), and a separate copyright for each. They may not be published separately, but for them to have distinct copyright is unusual enough, that they might as well have.

The scope statement is when that is not expedient or practical. In that case, we will allow two copyright statements, with different years, for the same document, but we expect a scope string to say what the difference is between the two statements.

[opoudjis]

So the source YAML still needs to change: we cannot have multiple dates. If multiple dates are needed, though, we can have multiple copyright statements.

[opoudjis]

@ronaldtse Please dissent if this doesn't reflect our agreement. I've written it up for relaton.com as well.

[ronaldtse]

Thanks @opoudjis for the explanation. In the future we wish to be able to associate copyright statements via machine-readable locality (e.g. Figure X is copyright to/licensed from Y), but that's a separate story.

[opoudjis]

That can be done either by making the figure a partOf document related to the source (if you're claiming separate copyright on it, I'd argue you're already treating it as a separate document),

<bibdata>
...
<relation type="partOf">
<bibitem>
....
<copyright>
... 
<owner><organization><name>Y</name></organization></owner>
</copyright>
</bibitem>
<sourcelocality type="figure"><referenceFrom>X</referenceFrom></sourcelocality>
</relation>
....
</bibdata>

or by adding a field after <scope>, which I think is pointless given the alternative