journals, volumes, issues

[kcoyle]

I am seeing volumes and issues as parts of manifestations:

(edit this at: https://docs.google.com/drawings/d/1Fyknx-uqJJdwsmATHABUSzHHkkShE7BP__6thG5dLpY/edit)

[kcoyle]

Articles are works in their own right, but also parts of issues.

(file at: https://docs.google.com/drawings/d/11VpZ_Jw2DXyP2uRrtv1MJwN8xIDmypQ1NzzNWvDUa_0/edit)

[kcoyle]

Daniel brought up the "special issue" problem. Here's one possibility:

(here: https://docs.google.com/drawings/d/15v1yP-17g8C1t4k0mnfXhtLyQ4ND21Bcx3H7AS2mkS8/edit)

[schlawiner]

Since you already marked it with a squiggly arrow and a question mark: I'm also not sure if the Article's Work should really be "part of" the Journal's work:

The same content (article work) probably appears in both the online version of the journal and the print version (and might in fact be republished with a different layout in a repository, which is also a kind of continuing publication) - however, these two journal formats are actually two different works according to LRM (each with their own wem-locked expression and manifestation) (see pages 8-12 in this presentation, for example https://loc.gov/catworkshop/RDA2020/What-Is-IFLA-LRM/Module%2012%20Serials%20in%20LRM.pptx or this whole presentation http://www.rda-rsc.org/sites/all/files/modeling%20of%20serials.pdf). Therefore, I'd say that the article's manifestation (or rather, one of it's manifestation, like the pdf) should be part of the (online) journal's manifestation (and also part of the issue manifestation). I generally think such component parts should be "part of" at the manifestation level. If you only connected a component work to its aggregate/whole work - how would you be able to say, for example for a book of conference proceedings and its chapters, that the online version of a chapter is part of the ebook version and the print manifestation is part of the print book?

flowchart LR
classDef Works fill:lightblue;
classDef Manifestations fill:lightyellow;
subgraph article
direction TB
WA((Article<br/>Work)):::Works -->|has manifestation| MAO((Article<br/>Manifestation<br/>PDF/Online)):::Manifestations
WA((Article<br/>Work)) -->|has manifestation| MAP((Article<br/>Manifestation<br/>Print)):::Manifestations
end
subgraph onlinejournal
direction TB
WJO((Journal<br/>Work<br/>Online)):::Works -->|has manifestation| MJO((Journal<br/>Manifestation<br/>Online)):::Manifestations
end
subgraph printjournal
WJP((Journal<br/>Work<br/>Print)):::Works -->|has manifestation| MJP((Journal<br/>Manifestation<br/>Print)):::Manifestations
end
MAO-->|part Of|MJO
MAP-->|part Of|MJP

[kcoyle]

Thanks, @schlawiner. If you showed a relationship between the online journal and the print journal, (maybe skipping the article question for now), what would that be? I'm presuming they are the same work in different manifestations, so there would not be an online work and a paper work. Is that how you see it?

[schlawiner]

Alas, no, print and online versions of the "same" journal are not electronic and print/paper manifestations of the same work (this is why we can't have nice things!), but really two completely independent Work-Expression-Manfestion bundles.

The Works of the different journal formats are viewed as "plans" or intentions, which may and often do diverge at some point. (Some journals used to have microfiche and CD-ROM versions which are probably not being continued anymore, for example; others merge or are split, or the print version is discontinued while the online one moves to another publisher...).

Bibframe uses bf:Hub (a subclass of bf:Work) as a kind of "glue" or bridge connect the works of different journal formats. A Hub for the online and print version would have relationships "bf:hasExpression" to the two works. Here's a good example on the Library of Congress' LoD service: https://id.loc.gov/resources/hubs/871be26c-85e5-7c06-0c81-8d877b527130.html

One could relate the different journal formats themselves using bf:otherPhysicalFormat (between manifestations/instances or works, as loc does above), and the Works do share the same L-ISSN (which is also what the issn.org's model does - page 8/9 - although they simplify things by saying each format is both a Work and an Instance, which is alright, considering the WEM-lock that happens anyway).

therefore, the collocation, i.e. the grouping of different manifestations or different expressions under a same work is not possible for continuing resources. The IFLA-LRM states therefore that each new manifestation (i.e. each entity identified by an ISSN) should correspond to a new expression and a new work. In Bibframe terms, it means that each continuing resource identified by an ISSN correspond to only one Instance and one Work. Therefore, each ISSN resource is systematically declared at the same time as a Bibframe Instance and a Bibframe Work.

Here's the same journal bundle from above at https://portal.issn.org/resource/ISSN-L/0022-1015 - both work/instance sets are collected on one page and connected with the same L-ISSN which acts as a kind of hub here (-> "display linked data" button).

Here's an example and diagram in Bibframe I made for a presentation at SWIB 22: Turtle example of Journal Hub acting as bridge between two Journal Works, with works and hub sharing an L-ISSN and instances connected with bf:otherPhysicalFormat.

[kcoyle]

OK, so for someone following RDA this would be a situation where you would want to define the relationship between these two works. BF:hub is interesting because it doesn't specify the relationship, but just brings them together (if I have understood it). There is nothing here that contradicts openWEMI, in that you can define other entities and other relationships. You could define a Work/Work relationship that does what bf:Hub does here. The question that remains for me is whether openWEMI:Endeavor can function like bf:Hub and link two works. As we've so far conceived of openWEMI:Endeavor it exists to provide an umbrella over a WEMI shape with one Work. Maybe we need to rethink that. We did talk about the fact that we are not clear on the difference between openWEMI:Endeavor and openWEMI:Work. I can diagram the difference that I see but I'm not sure it works out in practice. I'll add an issue.