Osma Suominen

@antagomir Thanks, looks really useful! The whole point of this pipeline is to stitch together existing tools instead of reinventing the wheel. Probably I just need to implement some glue...

The proposed [materialExtent property](https://github.com/schemaorg/schemaorg/issues/1759) in Schema.org could be used to represent the original, structured page count. Still, the normalized page count is probably much more useful for most analysis purposes....

For instances, this could be based on the RDA carrier categories. Here is the current breakdown: ``` 889902 nide 48298 arkki 29237 verkkoaineisto 10226 äänikasetti 7246 Digitaalinen jäljenne 3725 äänilevy...

To start, we should avoid asserting schema:Book for non-books.

See also: * http://blog.schema.org/2014/09/schemaorg-support-for-bibliographic_2.html * http://schema.org/PublicationVolume * http://schema.org/PublicationIssue

See branch [cleanup-260c](https://github.com/NatLibFi/bib-rdf-pipeline/tree/cleanup-260c) for initial code

An additional complication is that ISSN is really an instance-level attribute for series (the same series published in print and electronically get different ISSNs), except for ISSN-L which is for...

The CreativeWorkSeries type is a bit unnecessary in the current model. According to the [Schema.org definition](http://schema.org/CreativeWorkSeries), it "serves largely just to organize these more specific and practical subtypes". I think...

After discussing this with Clément Oury (ISSN centre) I think that Series should just be a single entity, not split into a Work and Instance. The ISSN identifies this entity...

@sfolsom I don't have anything very specific in mind, except what I said above. I think it's worth waiting to see how the ISSN centre has modelled their linked data...