tipo_media - media_type

[HansUwe52]

At the moment, under ‘Physical details’, you can choose from the following media types:
Book, Record, Audiobook, DVD and Other
It would be nice if you could add other media types, such as newspaper articles or magazine articles.

[fabiodalez-dev]

Since v0.7.77 Pinakes ships a bundled Emeroteca plugin that was built precisely for newspapers and magazines, so before extending tipo_media I'd like to make sure you've seen it — it may already cover your case, or change what the right fix is.

What the Emeroteca plugin does

It's inactive by default: activate it from Admin → Plugins (it creates its own tables on activation, no migration needed). It adds an admin section under Periodicals and a public /emeroteca area, structured the way periodicals actually work:

• Mastheads (testate): the publication itself — ISSN, type (newspaper, magazine, journal, bulletin, fanzine), frequency, publisher (shared with the book publisher registry), publication history.
• Volume years (annate): bound or loose, per year/volume.
• Issues (fascicoli): numbered, each with its own state (owned, missing, damaged, in restoration), cover, shelf location and an optional PDF (public or admin-only). A Kardex workflow generates the expected issues from the frequency and lets you mark them received or missing — the holdings statement, gaps included, is derived automatically.
• Articles: each issue can carry an article-level table of contents (title, authors, pages, type) with full-text search — so "that article about X in some 1998 issue" is findable.

From v0.7.78 the whole thing is also browsable in the Android app (release 1.5.0+): the Emeroteca section appears automatically when the server has the plugin active.

One deliberate design choice: the emeroteca does not circulate — issues and articles are for consultation, not lending, and articles there are index entries inside an issue you own, not standalone catalogue items.

Where a new media type would still make sense

If what you catalogue is the article as a physical object of its own — a clipping, an offprint, a bound photocopy kept in a folder with its own shelf mark, possibly lendable — then the emeroteca is the wrong home and extending tipo_media is the right move. In that case I'd add a single type named after the object rather than the content (something like "offprint/clipping" — Sonderdruck / Zeitungsausschnitt), deliberately not "newspaper" or "magazine": whole issues you own belong in the emeroteca, and two parallel homes for the same physical object is exactly what I want to avoid.

So, which is your workflow?

• Do you own the issues and want their articles findable? → the plugin should already cover it, and I'd love to hear if anything is missing there.
• Do you own standalone articles/clippings as individual pieces? → I'll add the new media type in an upcoming release.
• Both? → there's a possible future bridge (promoting an article from an issue's table of contents to a catalogue item, linked so nothing gets entered twice) that I'd consider if the mixed case is real.

Let me know which one matches your collection and I'll take it from there.

[HansUwe52]

I have this article: Marc J. Schweissinger: Intertextuality in Daniel Kehlmann's Novel Tyll, from International Journal of Language and Literature, June 2019, Vol. 7, No. 1, pp. 138-148, which I want to catalog in my Pinakes system.

When asking Gemini, I get this answer:

To catalog Marc J. Schweissinger’s article "Intertextuality in Daniel Kehlmann's Novel Tyll" in a library system, you should structure the metadata to clearly identify it as a journal article (periodical component) rather than a standalone book.
Recommended Metadata Entry

Author: Schweissinger, Marc J.
Article Title: Intertextuality in Daniel Kehlmann's Novel Tyll
Container Title (Journal): International Journal of Language and Literature
Publication Date: June 2019
Volume: 7
Issue: 1
Pages: 138–148
Document Type: Journal Article / Academic Paper
Subject/Genre Tags: German Literature, Daniel Kehlmann, Tyll, Intertextuality, Modern Fiction

Step-by-Step Cataloging Guide

Select Item Type: Choose Article or Serial Component (avoid selecting "Book" or "Monograph", as this will misrepresent the container relationship).
Input Author Information: Enter Schweissinger, Marc J. in the author/creator field.
Enter Titles Correctly:
    Title field: Intertextuality in Daniel Kehlmann's Novel Tyll
    Host/Container Title field: International Journal of Language and Literature
Add Enumeration and Chronology: Fill in the chronological details: June 2019, Volume 7, Number 1, with the page span 138–148.
Subject Indexing: Assign relevant genre or topical tags (e.g., German fiction, 21st-century literature, literary criticism) to make the article easily searchable.

As I - for the moment - only have this single article from this magazin using the Emeroteca plugin seems to be a bit complicated.

[fabiodalez-dev]

Released in v0.7.84, and your article is the one I used to check it.

Your objection was the right one: with a single article from a magazine you do not own, the Emeroteca was asking you to invent a masthead, a year and an issue first. It no longer does.

• Admin → Plugins → activate Emeroteca, then choose Simple on the Periodicals page. The section then opens straight onto Articles; years, issues, Kardex and subscriptions stay out of the way.
• Add article and save. Nine fields cover exactly the metadata you listed — author, article title, container title, publication date (free text, "June 2019" stays as written), volume, issue, page span (138–148 keeps its en dash), and subject keywords — with ISSN, DOI and shelf mark in a collapsed section. Only the title is required. No masthead, year or issue is created: I verified the count afterwards.
• If you later acquire the magazine, create the masthead and associate the articles you already catalogued, in bulk; citations and attached PDFs survive.
• The media-type list where you started — Book, Record, Audiobook, DVD, Other — now says where an article belongs, so the next person does not have to open an issue to find out.

The article is public at its own permanent URL with structured data declaring the periodical it came from, and a catalogue search for its title points readers at the Emeroteca. The companion Android app reads these articles from v1.5.2.

The upgrade is available from Admin → Updates.

[HansUwe52]

I have changed the settings of the Emeroteca Plugin to "Simple" and added to articles to my collection:

When adding the article I put a checkmarc in the box "Show the article in the public catalog"

But when I search for the title from the puclic frontpage:

the article is not found:

I can only display the article by going to the menu: Tidsskriftssamling (journal collection). Here the articles are displayed with title, author name, publication, date and number of pages. The title is a link to the article:

Here the author name is not an active link to other publications by this author. The sames goes for the publication name and the keywords.

The only active link is the button to open the attached pdf file.

I also would like to display a "thumbnail" of the article, something like the cover of a book.

[HansUwe52]

Hi Fabio.
Have you seen my comment?

[fabiodalez-dev]

Sorry for the silence — it has been a very full few weeks, I am working on other projects and Pinakes got very little of my time. Your comment did not get lost: I am taking it this weekend.

So you know exactly where each of your four points stands, here is what I found when I went back over them.

The article not showing up in the public search. That is current behaviour, not something broken in your install: the catalogue search reads the book index only, and Emeroteca articles live in their own tables. What 0.7.84 added is a pointer, not a result — on the results page there should be a line reading Search "…" also in: Emeroteca that takes you to the article search. If that line does not appear at all for you, tell me, because then something else is wrong on top. Either way the pointer is not what you asked for: an article you marked as public should be findable where you went looking for it, and that is what I intend to change.

Author, container title and keywords not being links. Correct, they are plain text today. On a standalone article those three are free-text fields, not rows in the author and publisher registries that books use, so turning them into links means first deciding what they point at. The answer I lean towards is a filtered article search — every article by that author, every article from that journal, every article carrying that keyword — because it gives you the navigation without forcing you to create an author record for someone you hold a single article from.

Only the PDF button being active. Same root as above: it is the one link on the article page because it was the only one with an obvious destination.

A thumbnail for the article. Mastheads and issues can carry an image, standalone articles cannot — there is no image column on them at all. So this one is a schema change plus a sensible fallback for the articles already entered without a picture.

All of it is on the list for this weekend. I will report back on this issue as the pieces land.

[HansUwe52]

Hi Fabio.
Thank you for your follow up.

Hans Uwe

[fabiodalez-dev]

All four points are in 0.7.86, which is out now. Taking them in the order you raised them.

The article now shows up where you went looking for it. A catalogue search that matches an article no longer answers with a line of prose: the hint carries the articles themselves and the mastheads that hold them, each entry a link to its record, with a "see all N results" line when there are more than fit. One detail worth knowing, because it was wrong before and you would have noticed: the count next to the mastheads and the page it opens are now built from the same predicate, so the number cannot disagree with what you get when you click it.

Author, publication and keyword are links. Each one opens the article search narrowed to that value — every article by that author, every article from that publication, every article carrying that keyword. On a standalone article those fields are free text rather than rows in the author and publisher registries, so a filtered search is the only honest destination: it gives you the navigation without making you create an author record for someone you hold a single article from. The active filters appear as chips you can remove one at a time.

Co-authored articles were the part that needed care. Names are split on the semicolon alone, never on the comma inside "Surname, Name", so a credit line reading "Rossi, Mario; Bianchi, Anna" links two people rather than one string that matches nothing. The separator is now stated on the form and in the plugin's README instead of being left to guesswork.

The PDF button is no longer the only link, which follows from the above.

Articles can carry a cover, on the cataloguing form, like a book. And an article that has none inherits the image of its masthead rather than falling back to the generic placeholder — so a collection catalogued without per-article pictures still looks like the periodical it came from, with no work on your part.

If anything here behaves differently on your install, say so on this issue.

[HansUwe52]

However, I still find that the way articles (from newspapers, journals, etc.) are handled is strangely separate from the cataloguing of books.
I would therefore like to outline the traditional method of cataloguing articles using the danMARC2 format:

1. Record type and control fields (Fields 001, 004, 008)
• Field 004: Specified using the code for an analytical record (article).
• Field 008: Contains the year of publication (the article’s publication date/year), country code (e.g. dk) and language code (e.g. dan).
2. Author and Title (The article itself)
• Field 100 or 700 (Author): Specifies the author of the article (if there is a known journalist/author).
◦ *a Surname, First name
• Field 245 (Article title):
◦ *a Article headline / title
◦ *b Subtitle / subheading (if relevant)
3. Source citation and newspaper relation (Field 773 / Source field)
As the newspaper is not held in the collection, field 773 (Work relation / Source reference) is used to describe where the article appeared. The field functions as a ‘free-text or structured source’, specifying the newspaper in question, the date and the page number:
• Field 773:
◦ *t Name of the newspaper (e.g. Berlingske or Jyllands-Posten)
◦ *d Publication date / volume (e.g. 27 September 2026 or Vol. 178, No. 250)
◦ *g Page number and section (e.g. Part 1, p. 12)
Note: In many Danish library systems (and the DBC shared database), field 773 is organised into subfields for specific source citations for periodicals/newspapers, where the newspaper’s title is entered as a ‘deferred’ source because the newspaper does not exist as a separate record in the database.
4. Subject headings and classification (Fields 652 / 653)
• As newspapers and newspaper articles are often topical or deal with specific events, people or places, relevant subject headings are added to field 652 (DK5 / local subject headings) or field 653 (free-text subject headings), so that the article can be retrieved with a fair degree of precision.
5. Digital version of the file (Field 856)
Although the record is a bibliographic record for an article, information about the digital version (the PDF) can be added so that the system or users can access it.
• Field 856 (Electronic location and access): This field is used to refer to electronic resources, files or URLs. If the PDF has been uploaded to your own local server, a DMS (Document Management System) or an internal network, the path or web address should be specified here.
◦ *u URL or file path to the PDF file (e.g. a link to the local document repository)
◦ *y Link text (e.g. ‘Download the article as a PDF’ or ‘Digital edition’)
◦ *z Any access conditions (e.g. “For internal use only” or “Open access”)
Option 6:
• Upload or link to PDF:
• If your library system supports the direct upload of attached files (e.g. to a local digital archive), the PDF is uploaded directly to the item record so that it is linked at the copy or record level.

I’ll add an example of how an article appears in the Royal Library’s catalogue:

Article
På sporet af et internationalt samarbejde blandt kedel- og maskinpassere i den anti-fascistiske kamp : faglig solidaritet med Hitler-Fascismens ofre
Hans Uwe Petersen
1988
Arbejderhistorie Nr. 31 (1988)

Details
Title: På sporet af et internationalt samarbejde blandt kedel- og maskinpassere i den anti-fascistiske kamp : faglig solidaritet med Hitler-Fascismens ofre
Creator: Hans Uwe Petersen
View in: Arbejderhistorie Nr. 31 (1988)
Subject: Danmark, Dansk Kedel- og Maskinpasser Forbund, fagbevægelsen, fagforeninger, nazisme. fagbevægelsen, tyske flygtninge. fagbevægelsen,
Description: Ty. res. Dansk Artikelindeks
Related titles: Arbejderhistorie : tidsskrift for historie, kultur og politik
Creation Date: 1988
Identifier: LC : (DK-870971)73092019
Format: S. 18-38
Language: Danish
Source: Royal Danish Library
DK5: 33.129

Citation: APA, 7th edition:

Petersen, H. U. (1988). På sporet af et internationalt samarbejde blandt kedel- og maskinpassere i den anti-fascistiske kamp : faglig solidaritet med Hitler-Fascismens ofre. Arbejderhistorie, Nr. 31 (1988).

Citation: Harvard:

Petersen, H. U. (1988) På sporet af et internationalt samarbejde blandt kedel- og maskinpassere i den anti-fascistiske kamp : faglig solidaritet med Hitler-Fascismens ofre. Arbejderhistorie. Nr. 31 (1988).

RIS (Endnote, Mendeley):

TY - JOUR
JF - Arbejderhistorie
Y1 - 1988
VL - Nr. 31 (1988)
N1 - Med litteraturhenvisninger
ID - alma99124995074005763
N2 - Ty. res Dansk Artikelindeks
KW - Dansk Kedel- og Maskinpasser Forbund
KW - fagforeninger
KW - tyske flygtninge. fagbevægelsen
KW - nazisme. fagbevægelsen
KW - fagbevægelsen
KW - Danmark
AU - Petersen, Hans Uwe
T1 - På sporet af et internationalt samarbejde blandt kedel- og maskinpassere i den anti-fascistiske kamp : faglig solidaritet med Hitler-Fascismens ofre
ER -