freeToRead parameter is difficult to interpret

[erinspace]

Background

When porting over harvesters to meet the new schema, we've run into issues using the freeToRead element in the schemas as a date range. Many of the providers simply provide the "isPublic" or "isOpenAccess" pieces of metadata as a boolean value of true or false, and so we have to interpret the start date on our freeToRead item by the publication date or date updated, not from information about the date period in the original source.

Proposed solution

Make the main required element of freeToRead a boolean value, with an optional date range if the provider has a coherent date range for freeToRead.

[anarchivist]

Hiya, you may be aware of this already, but there's probably a need to align this with the work on the NISO ALI schemas under development. See CrossRef/niso-ali#1 and CrossRef/niso-ali#7. Apologies if y'all have already made the connection.

[JeffSpies]

Our models may be able to help with this. Let's touch base in person.

On Tue, Apr 28, 2015 at 1:26 PM, Erin Braswell [email protected]
wrote:

Background

When porting over harvesters to meet the new schema, we've run into issues
using the freeToRead element in the schemas as a date range. Many of the
providers simply provide the "isPublic" or "isOpenAccess" pieces of
metadata as a boolean value of true or false, and so we have to interpret
the start date on our freeToRead item by the publication date or date
updated, not from information about the date period in the original source.
Proposed solution

Make the main required element of freeToRead a boolean value, with an
optional date range if the provider has a coherent date range for
freeToRead.

—
Reply to this email directly or view it on GitHub
#10.