-
Notifications
You must be signed in to change notification settings - Fork 5
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
Remodel representation of Series #52
Comments
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 series-work level... |
The CreativeWorkSeries type is a bit unnecessary in the current model. According to the Schema.org definition, it "serves largely just to organize these more specific and practical subtypes". I think we could just use Periodical everywhere and skip CreativeWorkSeries entirely. |
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 and it could be linked to the Linked Data that the ISSN Centre is going to publish very soon. |
Last year LD4L worked on a Series/Serial model that didn't reach approval status, and thus not shared publicly.We've considered how to get <www.loc.gov/aba/pcc/conser/> more involved, but capacity issues keep us from picking this up right now. That said, I'd love to compare notes. |
@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 that they're going to publish a few weeks from now. There is a little bit of information in a slide deck ("ISSN Register as Linked Data") linked from this European BIBFRAME Workshop wiki page. In my understanding they consider each ISSN as a single resource, that is both a bf:Work and a bf:Instance at the same time. |
There are two quite different cases to consider:
In case 1 we currently create both a Work and an Instance, since that's what marc2bibframe2 does. In case 2 we only create a Work (although marc2bibframe2 also creates an instance we ignore it). I think that in both cases we should create just the Work (actually a subtype that is a CreativeWorkSeries). Obviously it should have the name and ISSN, but in case 1 we probably also need to assert all the Instance-related properties that come from the MARC record. |
It's the Instance that should belong to a Series (just like in BIBFRAME after the conversion from MARC), not the Work. There may be multiple Instances of a Work and some of them may belong to different series, but the Work itself is series-agnostic. |
… the more generic CreativeWorkSeries which nowadays can accommodate schema:issn properties. Part of #52
I'm still not happy with the way series are modelled. Currently, it's the Work that is part of a Series (which is also a Work). I think that the Instance should instead be the entity that's part of a Series Work, but I need to check first with RDA modelling experts about their views.
The text was updated successfully, but these errors were encountered: