Skip to content
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

Open
osma opened this issue May 24, 2017 · 7 comments
Open

Remodel representation of Series #52

osma opened this issue May 24, 2017 · 7 comments

Comments

@osma
Copy link
Member

osma commented May 24, 2017

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.

@osma osma changed the title Remodel representation Series Remodel representation of Series May 24, 2017
@osma
Copy link
Member Author

osma commented May 24, 2017

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...

@osma
Copy link
Member Author

osma commented Jun 6, 2017

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.

osma added a commit that referenced this issue Jun 6, 2017
@osma
Copy link
Member Author

osma commented Sep 27, 2017

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.

@sfolsom
Copy link

sfolsom commented Sep 27, 2017

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.

@osma
Copy link
Member Author

osma commented Sep 27, 2017

@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.

@osma
Copy link
Member Author

osma commented Nov 14, 2017

There are two quite different cases to consider:

  1. When the record represents a Work that is itself a series
  2. When the record represents a Work that is part of a series

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.

@osma osma added this to the Short term milestone Nov 16, 2017
@osma
Copy link
Member Author

osma commented Nov 16, 2017

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.

osma added a commit that referenced this issue Nov 16, 2017
… the more generic CreativeWorkSeries which nowadays can accommodate schema:issn properties. Part of #52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants