Wikidata talk:WikiProject Periodicals/Archive 2

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Update

Do we have a property to indicate update? --Juandev (talk) 23:22, 5 September 2019 (UTC)

Frequently missing properties on items for journals

An article from Q27712969 came up on WikiProject Random. It seems that title (P1476), inception (P571) (and if applicable dissolved, abolished or demolished date (P576)), short name (P1813) are frequently missing from similar items. It would be good if there was a way to complete that. --- Jura 09:57, 7 September 2019 (UTC)

That wouldnt be a big problem no? You can list those items and once you list them, you may add it, or what is the problem? --Juandev (talk) 15:54, 7 September 2019 (UTC)

No problem indeed. If someone already has the data, that might be easier. --- Jura 16:14, 7 September 2019 (UTC)

BTW I just re-did a query and added it at Wikidata:WikiProject_Periodicals#Numbers. P1476 is more frequent than in the first one, but still corresponding items could use some improvements. --- Jura 16:19, 8 September 2019 (UTC)

Issues

Please see User:Research_Bot/issues --- Jura 10:04, 7 September 2019 (UTC)

Received date ?

What property is suggested for the received date (date the article was received by the journal, months before the actual publication)? I started using production date (P2754) for that, but maybe a dedicated property is needed. --- Jura 10:04, 7 September 2019 (UTC)

Keywords

I am wondering whether to propose a property called keywords. Yes, we have main subject (P921), but in many cases the string which you need as a keyword does not have an item and is even nonlogic to create an item for it. --Juandev (talk) 01:47, 9 September 2019 (UTC)

@Juandev: take a look at Wikidata:Property proposal/subject facet which did not pass. If you do propose a new “keyword” property, you should probably address the issues raised here. - PKM (talk) 22:59, 4 October 2019 (UTC)

I have seen that and I think my proposal is different as the dataset is string. What issues were rised there? --Juandev (talk) 16:59, 6 October 2019 (UTC)

Magazine

Hello,

I’m looking into sorting out a bunch of video game magazine (Q69662460) a bit, and before I start, I want to make sure the following model is good :)

Jean-Fred (talk) 16:18, 4 October 2019 (UTC)

(I ask in particular because genre (P136) and country of origin (P495) are not mentioned on Wikidata:WikiProject Periodicals Jean-Fred (talk) 16:20, 4 October 2019 (UTC))

@Jean-Frédéric:Don't use country of origin (P495), use place of publication (P291) instead. Don't use -instance of (P31)magazine (Q41298)+-genre (P136)video game magazine (Q69662460) but rather -instance of (P31)magazine (Q41298)+-instance of (P31)video game magazine (Q69662460). Also, maybe you have an ISSN (P236) for these magazines ?. Tfrancart (talk) 07:32, 18 October 2019 (UTC)

I have also seen field of work (P101) used on some magazines-items − does not feel right to me but has some usage (although way less than main subject (P921) Jean-Fred (talk) 16:37, 4 October 2019 (UTC)

And also, there is plenty of usage of start time (P580) and end time (P582) − just double-confirming that they are not to use in this case. Jean-Fred (talk) 17:23, 4 October 2019 (UTC)

SELECT ?item ?itemLabel ?field_of_work ?field_of_workLabel WHERE {
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  ?item (wdt:P31/(wdt:P279*)) wd:Q1002697;
    wdt:P101 ?field_of_work.
}

Try it!

@Tfrancart: not sure to understand your propositions. Of course place of publication (P291) is better country of origin (P495) in general but here, if the value is a country, country of origin (P495) could work too, not sure here maybe both is the best heere? And for video game magazine (Q69662460),I disagree, it's definitely a value for {{P|136} and not for instance of (P31). Cheers, VIGNERON (talk) 08:29, 18 October 2019 (UTC)

@VIGNERON: country of origin (P495) is not wrong, place of publication (P291) is just more precise, and is actually a recommended property for periodicals, see the first table in this very same page. My suggestion for -instance of (P31)video game magazine (Q69662460) is based on the fact that video game magazine (Q69662460) is actually a class, subclass of magazine (Q41298), hence should be referenced through instance of (P31) too; one could see this as a matter of taste; personnally I would stick to using instance of (P31) everytime I refer to a class. Is there some commonly agreed rule for this ? Cheers Tfrancart (talk) 08:58, 18 October 2019 (UTC)

@Tfrancart: Sure, will add P291 (with the mutual-understanding that ideally it should be more precise than country level) but rather on top of P136 − it’s handy to quickly request the country without having to climb up the class tree.

Regarding video game magazine (Q69662460): I see what you mean, but I don’t think the implication is necessarily true: for example, we do have Citizen Kane (Q24815)instance of (P31)film (Q11424) and Citizen Kane (Q24815)genre (P136)drama film (Q130232), even though drama film (Q130232) is a subclass of film (Q11424).

@Jean-Frédéric: I wouldn't take the existing practices on this subject as the definite or the good practice. I am interested in this question, and I will probably escalate it to the Ontology Wikidata project. I would like to see reference to past discussions and agreement on this matter. Of course this is in no way related to your magazine project, and this should not prevent you to proceed with your upload of magazine descriptions. As a side note : if "video game magazine" was to be referenced as a "genre", it would be named "video game", not "video game magazine"; maybe both point of views can co-exist : the "video game magazines" could be defined as the "set of magazines for which genre = video game", or something like that. Tfrancart (talk) 13:37, 28 October 2019 (UTC)

@Tfrancart: Well, sure, data modeling practices are not set in stone never to be revisited :-) ; however, to the best of my knowledge, the use of genre (P136) I described is the currently agreed-upon best practice, as documented in Wikidata:WikiProject_Video_games/Properties, Wikidata:WikiProject_Movies/Properties and Wikidata:WikiProject_Music. Jean-Fred (talk) 22:16, 4 November 2019 (UTC)

@Jean-Frédéric: I am not saying that the use of genre (P136) in itself is bad. I am saying that if you use genre (P136), it should reference a genre, not a class. Take the example of genre (P136) given in Wikidata:WikiProject_Music : Night Train (Q7033524)genre (P136)blues (Q9759). blues (Q9759) is not a class; it is an instance of music genre (Q188451), and this makes all the difference. Tfrancart (talk) 09:24, 5 November 2019 (UTC)

And wait, I see that video game magazine (Q69662460) is both a class and a genre, so I think we're fine and I'm happy :-) Tfrancart (talk) 16:08, 5 November 2019 (UTC)

(Also, the outcome is at Wikidata:WikiProject Video games/Magazines − most have ISSNs).

Jean-Fred (talk) 14:36, 23 October 2019 (UTC)

Distribution format values ? (from MARC)

Notified participants of WikiProject Periodicals

Hello,

I am working on pushing part of the ISSN Portal (Q70460099) to Wikidata (teaser - more on this later). As you may know, an ISSN is assigned to a specific format of a periodical, and typically the paper version and the electronic version of the same periodical receive 2 different ISSNs. I plan on capturing these with a distribution format (P437) qualifier on the ISSN (P236) statement on these magazines.

My question is which values should I use for these distribution formats ? Here is the list, sorted by reverse number of usage in the ISSN register, with my mapping proposal for some values. I am not looking for a 100% perfect mapping, simplifications for rarely used values are welcomed.

Marc code	Value	Number of instances in ISSN register	Wikidata mapping
ta	(Print)	1868807	printed matter (Q1261026) (most used currently)
cr	(Online)	282934	online publication (Q1714118) (most used currently)
co	(Optical disk)	21255	optical disc (Q234870)
tu	(resource is a text (no specific material designation))	4764	text (Q234460) (proper equivalences with Bibframe and DCMI)
zm	(resource is in multiple physical forms)	2904	mixed material (Q96323758)
vd	(resource on videodisc)	1801	videodisc (Q764322)
t<pipe>	(Print)	1610	printed matter (Q1261026) (same value as ta above)
ou	(resource is a kit)	1096	kit (Q811844) (although the image is incorrect, I think this entry comes from bibliograph.net, bib extension to schema.org, so definitely from the bibliographic world)
vf	(resource on videocassette)	791	videotape (Q747779)
cz	(electronic resource : other)	563	electronic media (Q1209283) ?
cm	(electronic resource on magnetooptical disk)	513	magneto-optical disc (Q763745)
he	(resource on microfiche)	502	microfiche (Q2368076)
cj	(magnetic disk)	370	magnetic storage (Q1364527)
ss	(resource is a sound recording on cassette)	344	compact cassette (Q149757)
td	(resource is in a loose-leaf binder)	323	loose leaf (Q6676005)
tb	(resource is in large print)	253	large-print (Q1548123) seems correct
tz	(Print : other)	230	printed matter (Q1261026) (same value as ta above)
sd	(resource is a sound recording on disc)	217	disc vinyle ? to be clarified ?
tc	(resource is in printed Braille)	203	Braille (Q79894)
zz	(resource is in another form)	133	?

Here is the query to list the currently used distribution formats on property "ISSN" :

SELECT ?format (COUNT(?format) AS ?howMany) ?formatLabel
WHERE
{
  ?serial wdt:P31/wdt:P279* wd:Q2217301 .
  ?serial p:P236 [ ps:P236 ?issn; pq:P437 ?format ].
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE]". }
}
GROUP BY ?format ?formatLabel
ORDER BY DESC(?howMany)

Try it!

Also, I could not find a field to record the mapping of a Wikidata entry with a MARC code. Does that exists ?

Cheers Tfrancart (talk) 08:04, 18 October 2019 (UTC)

@Tfrancart: it sounds really interresting, I try to look into it in more details (and probably create the missing items). As a first remark, I see that you used CD-ROM (Q7982) twice, which doesn't seems right : if there is two value on the ISSN side, there should be two values on Wikidata two.

Thanks ! as I wrote, I am ready to accept simplifications here, but of course the more precise, the better. This is why I used CD-ROM twice.Tfrancart (talk) 09:03, 18 October 2019 (UTC)

Hello @VIGNERON: a friendly ping on that matter : did you had the time to review the list of distribution formats ? we would love to get some feedback. Thanks. Tfrancart (talk) 13:41, 28 October 2019 (UTC)

And for has been done already, you could take a look at wikimania:2019:Libraries/Converting MARC and EAD Creator Descriptions to Wikidata.

Cheers, VIGNERON (talk) 08:37, 18 October 2019 (UTC)

Data donation from ISSN Register - Feedback welcome

Notified participants of WikiProject Periodicals and The Source MetaData WikiProject does not exist. Please correct the name. and The Source MetaData/More WikiProject does not exist. Please correct the name.

The ISSN International Center (ISSN International Centre (Q12131129)), which maintains the ISSN Register (ISSN Portal (Q70460099)) (the most complete reference source in the world for the identification of serial publications) wishes to contribute a subset of its bibliographic database to Wikidata. This consists of (approximately) 1.100.000 entries (only current/not discontinued publications), with 10% having 2 or more ISSNs (typically, paper and electronic version). Currently, Wikidata contains approximately 94000 ISSN values.

Each serial notice is described with metadata from the set of metadata already freely available from the ISSN Portal :

ISSN identifier
ISSN-L identifier (the ISSN-L identifies the serial publication independantly of its medium, while distinct ISSNs are assigned to each medium)
Proper (original) title of the serial
Key (unambiguous) title of the serial
Country of publication
Distribution format (of a given ISSN)
URL (for online publications)
Language of the serial

(Note that the publisher is not part of the free data)

More facts and figures on ISSN and Wikidata can be found in this presentation.

The plan is to reconcile and send this data using OpenRefine.

Preliminary analysis has been conducted and this data is planned to be captured with the data model described in the following diagram. We are looking for feedback from the community before proceeding with the ingest. Although this is not a formal deadline, feedback is welcome until 4th of december (1 month).

A few notes / explanations :

the values for distribution formats are discussed here;
the language of the label (and title) will be derived from the language of the publication itself (this may not be an accurate assumption in 100% of the case)
the cancelled ISSNs are ISSNs that have been published, then cancelled; the plan is to store them as with a deprecated rank;
there is a single ISSN-L for each serial, but multiple ISSNs are possible (one for each medium)

Thanks for your comments

Tfrancart (talk) 21:39, 4 November 2019 (UTC)

--

Excellent news. Thanks for doing that. I think we should be able to gather feedback in less than a month. Just a few minor points:

I'm not entirely sure if OpenRefine is suitable for that many additions, but alternatively, you might want to look into QuickStatements.
I tend to agree about the suggestion made earlier of using country of origin (P495) for country of publication (if no city is available).

OK, we will consider that, thanks. Tfrancart (talk) 09:36, 5 November 2019 (UTC)

If there is a start date available, I think it would be good to include that.

ISSN has that in its registry, but it is not part of the free data. Tfrancart (talk) 09:36, 5 November 2019 (UTC)

Is there any chance of making dates part of the free data, either on Wikidata or at the public ISSN portal? The problem is that without them, it can be very hard to precisely define the entity being described. Wikidata has dates for many of the serials in its database, but I think they often disagree with the dates in the ISSN portal (in particular because Wiki* tends to lump slightly changed prior versions of the serial (including title and publisher changes) with the current version more often that ISSN and many library catalogs tend to. It's hard to match up serial entities from multiple data sources (such as Wiki* and the ISSN database) unless it's clear on both sides where they start and end. Thanks for considering this! JohnMarkOckerbloom (talk) 21:09, 5 November 2019 (UTC)

What happens when a publication change its name?

AFAIK, kf the name changes significantly, it gets a new ISSN. Tfrancart (talk) 09:36, 5 November 2019 (UTC)

Could you do a test run of 10 or so items?

Yes, we will do that. Tfrancart (talk) 09:36, 5 November 2019 (UTC)

@GZWDer, Magnus Manske: who work frequently with journals.--- Jura 21:51, 4 November 2019 (UTC)

--

wonderful news! Just so you know that it's an option, you could also make the import using wikibase-cli, and I would be more than happy to give support if needed. -- Maxlath (talk) 23:39, 4 November 2019 (UTC)

Thanks ! we will see what the best option for the tool is. The nice thing with OpenRefine is 1/ the ability to reconcile with serials already in Wikidata and having already an ISSN and 2/ (if I understand properly) the ability to not duplicate statements that are already present. How does wikidabse-cli performs on these 2 aspects ?. Tfrancart (talk) 09:36, 5 November 2019 (UTC)

--

I have just used OpenRefine to add a few thousand ISSN statements for academic journals and I think it works perfectly. Many academic journals have ISSN statements but no ISSN-L. Having ISSN-L allows less tedious queries.

I have no experience on the best data model for the "distribution format".

Do I understand correctly that you don't plan to add information on the publisher? That could be useful, especially historical information for publications which have changed publisher (relevant to identify reverse flipped journals) or whose publisher went bankrupt (relevant for digital preservation projects).

Correct, the publisher is not part of the free data in the ISSN register. Tfrancart (talk) 15:33, 5 November 2019 (UTC)

As a suggestion, I recommend that you start by adding the information you described above to the existing entities about periodicals. We have no shortage of incomplete entities; having information on their language, publisher, identifiers and URL unquestionably makes them more useful. After you've tested your data model and precision of reconciliation with existing items, it will be easier to proceed with the creation of new items. Only after reconciliation you will know exactly how many new items you need to create. Nemo 10:07, 5 November 2019 (UTC)

I take good note of this. We will separate addition of statements on existing entity and creation of new entities. Tfrancart (talk) 15:33, 5 November 2019 (UTC)

--

This is great, thanks! The data model diagram makes sense to me. I am assuming that there will only be one item created/updated per ISSN-L, you will not be creating separate items for each ISSN (name or format change), right? ArthurPSmith (talk) 13:21, 5 November 2019 (UTC)

Correct : one item per ISSN-L. Tfrancart (talk) 15:33, 5 November 2019 (UTC)

--

I agree that this is fine news. Here are some issues you might consider:
1. ISSN number change when the title change. Wikidata follows, I believe, no overall scheme of determining when a serial should have a new item when there are name changes, splits or merges, so there might be issues around these things.

> This is one of the reason ISSN data will be limited to current publications only. Tfrancart (talk) 15:33, 5 November 2019 (UTC)

1. It is unclear to me whether the place of publication is stable. Doesn't large international publishing houses move the publishing site around? For instance, NeuroImage (Q1981225) was initially published from Academic Press, San Diego AFAIR, now Wikidata says The Netherlands (perhaps erroneously), while ISSN and NLM portal says Orlando. I see in old editions that the editorial office is in San Diego while the publisher is in Orlando.

> The place of publication is (I think) the country of the latest/current publisher of the serial. Tfrancart (talk) 15:33, 5 November 2019 (UTC)

1. Wikidata tend to merge the electronic version and the paper version in one item. As far as I read the model, that is also what the ISSN dump will do, and that a qualifier will be added to the two ISSNs that are typically associated with the serial Wikidata item.

> Correct, the plan is to have one item per ISSN-L (which is not as trivial as it seems on the ISSN Register side). Important Note : this means separate entries (with separate ISSN-L) will be created for the various regional editions of the same journal, or the different linguistic editions of the same journal; these entries will not be linked as these links are not part of what the ISSN will import. Tfrancart (talk) 15:33, 5 November 2019 (UTC)

— Finn Årup Nielsen (fnielsen) (talk) 14:55, 5 November 2019 (UTC)

--

Agree with everybody above that this is really exciting news. It's great to see the ISSN International Center taking this proactive step.
Also agree with cautions noted above, to be careful with journals where there have been name changes / series changes / publisher changes. Wikidata doesn't necessarily deal with these well. I see you're going to restrict to only current publications with ISSNs, which may be a pity, because it may be older journals that can be particularly likely to have copyright-expired or copyright-waived copies, that it can also be particularly useful to be able to match identifying ISSNs to. However I can see it may make sense to start with the most straightforward case first. But beware of items for older runs of the journal, or for the whole history of the journal, that may need to be distinguished when it comes to matching.
Props for really having done your homework untangling the data modelling that's evolved, and publishing it above -- you now appear to have a clearer take on it than many of us may well have done!
I'd echo also what User:JohnMarkOckerbloom wrote, that there may be more efficient ways of going about this at such a scale than OpenRefine. In particular, it may be more efficient to write a query for all live periodicals currently without ISSNs, with accompanying side-data, and then try to match as much of that as you can offline first, rather than going straight to OpenRefine.
But mostly I just want to say Thank You for what has the makings of being a hugely valuable contribution. Jheald (talk) 14:51, 6 November 2019 (UTC)

Former names

Quote "This is one of the reason ISSN data will be limited to current publications only. "

Seems my question about name changes isn't relevant as only current names are being added. Depending how it goes, I think importing data about former publications (and former names) would be most helpful as well. How many would this be? --- Jura 10:23, 9 November 2019 (UTC)

@Tfrancart: --- Jura 13:31, 13 November 2019 (UTC)

Start date

Quote (1) "If there is a start date available, I think it would be good to include that." (by Jura1)
Quote (2) "ISSN has that in its registry, but it is not part of the free data. Tfrancart (talk) 09:36, 5 November 2019 (UTC)"
Quote (3) "Is there any chance of making dates part of the free data, either on Wikidata or at the public ISSN portal? The problem is that without them, it can be very hard to precisely define the entity being described. Wikidata has dates for many of the serials in its database, but I think they often disagree with the dates in the ISSN portal (in particular because Wiki* tends to lump slightly changed prior versions of the serial (including title and publisher changes) with the current version more often that ISSN and many library catalogs tend to. It's hard to match up serial entities from multiple data sources (such as Wiki* and the ISSN database) unless it's clear on both sides where they start and end. Thanks for considering this! JohnMarkOckerbloom (talk) 21:09, 5 November 2019 (UTC)"

Agree with that. --- Jura 10:26, 9 November 2019 (UTC)

Upload

@Tfrancart: do you need help with this? --- Jura 13:25, 20 January 2020 (UTC)

@Jura1: we are getting back on track with this. For internal reasons this was delayed, and the suggestion to not use OpenRefine but some other tools has required more analysis. Besides OpenRefine does not allow to create statements with a Deprecated rank. I am now considering Wikidata toolkit.

Followup on ISSN data import : questions and help needed

Notified participants of WikiProject Periodicals and The Source MetaData WikiProject does not exist. Please correct the name. and The Source MetaData/More WikiProject does not exist. Please correct the name. and @Jura1: and @VIGNERON:

Hello

Followup on ISSN data import. I have manually entered 2 notices following the above proposed data model from ISSN register : Europa medicophysica (Q27720997) and Q84021148. This triggered some questions :

Should a reference be set on instance of (P31) too ? I amthinking about setting references only on title, place of publication, official website, and language;
I guess instance of (P31) serial (Q2217301) will be repeated if it does not exists, even if instance of (P31) exists on the entity and points to a subclass of serial (Q2217301). (e.g. Europa medicophysica (Q27720997)) Is this an issue ?
In case a publication has multiple ISSN, which one should be used in the references ? I am thinking about using the ISSN-L as a reference, but the target page on the ISSN portal is not really nice neither useful (https://portal.issn.org/resource/ISSN-L/2284-2993); but for the official website, the true reference is the ISSN corresponding to the digital copy;
The qualifier distribution format (P437) printed matter (Q1261026) generates a warning, as an instance of printed matter (Q1261026) is expected; see Europa medicophysica (Q27720997). Can someone fix that ?
I stuck to place of publication (P291) to indicate the country of publication, more precise than the country of origin, this value is _current_ country of publication, may be different than the original one
Can somebody fix the automatic URL for ISSN-L (P7363) ? it is currently https://issn.org/resource/issn-l/... but should be fixed to https://issn.org/resource/ISSN-L/... (capital "ISSN-L"). Thanks
As suggested, I am thinking about using wikidata-client in Java instead of OpenRefine to load notices;

Thanks and Best Regards Tfrancart (talk) 09:14, 30 January 2020 (UTC)

Just a partial feedback:

In these items, I don't see an advantage to add a reference to the P31 statement.
If a more specific value is already available (as at Q27720997), please don't add serial (Q2217301). You could just skip P31 for any existing item.
On labels/titles like Q84021148, can you suppress the trailing "." ?
I added the new formatter url for ISSN-L (P7363).
If you prefer to work with Open Refine, you could either first skip retired ISSNs or add these with normal rank, but ask another bot operator to adjust the ranks. If more information about the reason for their discontinuation is available, maybe normal rank with "end cause" or "end date" is appropriate. Deprecated rank is for values that were never really correct.

It might be worth doing 50 items as a more extended test. --- Jura 10:06, 30 January 2020 (UTC)

@Tfrancart: I suppose other things have come up since, but, if you don't plan to upload the data yourself, would you consider making it available? --- Jura 07:50, 3 May 2020 (UTC)

Tables with information on periodical copyright and free issue availability

I've been working at the Penn Libraries on compiling information on "deep backfiles" of periodicals, to help surface what is and what can be made freely available online from them. I've been using Wikidata and various publisher manifests to compile basic information on serials with free online content, or that were publishing prior to 1964 (when, at least in the US, rightsholders had to actively register and renew copyrights, and many periodical publishers and authors did not when required). This is the main page for the project, and here's its initial announcement.

I'm grateful to the Wiki* community for compiling much of the data in this project, and I invite folks to research and send me more data about serial copyrights and online availability. (Instructions for finding and contributing basic copyright information can be found in the announcement post.) I'm currently linking the data I'm compiling on periodicals with their corresponding Wikidata entries (using the P5396 property for the links from Wikidata, and links going the other way from our data pages). It may eventually make sense to copy or migrate some of the data I'm compiling directly into Wikidata. I haven't made steps to do that yet, but the data is CC0, so feel free to reuse it as you see fit.

My initial tables were built for the offerings of various publishers and aggregators (e.g. Elsevier, JSTOR, Taylor and Francis, etc.) I've recently built another table, though, based on the periodicals that have articles about them in English Wikipedia-- not just journals, but also other periodicals that Wikidata identifies as going back far enough to potentially be at least partly out of copyright, or that have free online issues that I know of. I plan to add that table to our Deep Backfile page soon, but here's an early look at it. It's quite large-- there are over 10,000 periodicals written about in English Wikipedia that are eligible for listing! Please let me know if you find it useful or if you have any suggestions for improving it. I'll also happily add any additional data you contribute via the "Contact us" links.

I'd also like to see if there's other data this community has already compiled that can be included in the knowledge base. There are links to each serial's Wikidata record already, but if there's a good way to automatically slurp up information on free issue availability based on Wikidata or other Wiki* information, I'd be happy to hear about it. (I'm looking to link to complete, copyright-cleared issues, volumes, and runs, rather than individual articles.)

Thanks! JohnMarkOckerbloom (talk) 14:08, 6 November 2019 (UTC)

Oh, thank you for posting here too! I just came to link your article. :) So, to clarify, an item will be added to your table only if it has both an English Wikipedia entry and a Wikidata entry? If your objective it to have a free text article you can link, you could also link non-English Wikipedia articles as well,

An interesting source to merge is the ISSN registry being discussed above, given your table shows many missing ISSN codes. To show availability, maybe we should link/import data from https://fatcat.wiki/ . BHL is collecting such information for many biology-related publications. For recent journals, Unpaywall has recently changed their detection of fully-OA journals and we could import that together with DOAJ data and others.

Isn't the country of (original) publication relevant too, if you want to establish public domain status? Copyright registration doesn't matter for non-USA periodicals, usually.

Finally, do you plan to provide help hosting copies of those serials if they're in the public domain but not hosted anywhere yet? The Internet Archive has thousands of journals and millions of articles but they don't necessarily want to host everything (yet). I'm sad to see your repository was bought by Elsevier, but it would be trivial to create a separate DSpace repository à la DeepBlue for public domain submissions, if you're interested. Nemo 17:08, 10 November 2019 (UTC)

Thanks Nemo for your comments and questions! My responses:

I'm focusing on English Wikipedia here because that's already plenty big (10,000 serials, as I mention), and because the copyright information I'm gathering is most relevant to American serials (for reasons you mention), and I expect English Wikipedia would be the Wiki most interested in those. Some older American serials are indeed covered in non-English WP but not English WP, but if anyone creates an English Wikipedia article for any of these and it meets the data criteria, it'll automatically show up in the table not long after.

The countries of publication are indeed important, and I'm noting in my copyright files when serials originate outside the US, for the reasons you indicate. (The notes are currently free text, but they're regular enough that I might make these structured data fields if that seems warranted.) In some cases, content of these journals is still subject to US notice and renewal requirements, so it's still worth listing them. The main such cases are (a) foreign serials that can still be considered "published" in the US for the purposes of US copyright law, which might include ones that (for instance) regularly marketed and distributed to US subscribers; and (b) contributions to foreign serials that were authored by Americans. And of course really old foreign serials can also be public domain in the US due to sheer age.

We're not currently set up at Penn to host large quantities of digitized serials, but I'll let you know if that changes in the future. We do have a digitization unit, but the output from it that we self-host is mostly from our rare books collections. We do, however, send digitizations of things from our general collection to places like HathiTrust and the Internet Archive. In my own listings, I'm happy to point to copyright-cleared issues at either of those places, or at Wikisource, or anywhere else that will provide stable, user-friendly hosting for them. JohnMarkOckerbloom (talk) 15:24, 11 November 2019 (UTC)

Advice on handling large journal with many series - creating items for the series?

Notified participants of WikiProject Periodicals Hi, I'm adding lots of articles relevant to biological taxonomy to Wikidata, with the ultimate goal of being able to link every species in Wikidata to its original description (or at least providing some of the raw material to make that possible). I also have a little website I wrote to help display articles and journals based on data in Wikidata, e.g. Transactions of the Royal Society of New Zealand. Zoology

One journal that I want to flesh out is Annals and Magazine of Natural History (Q19798858), which has over 21,000 articles(!). This journal was published in 13 series, in each series the first volume published was volume "1". Normally I follow what seems to be standard procedure when adding articles, an article is published in (P1433) in a journal, and volume (P478) and issue (P433) are simple strings. I'm tempted in this case to also add part of (P361) and create items for issues issue (Q28869365) as these have been dated Publication and dating of the journals forming the Annals and Magazine of Natural History and the Journal of Natural History (Q28938329) and exact publication dates matter to the taxonomic community.

If you're still reading here's my question. I'm tempted to create Wikidata items for each series, so that there is a way for people to easily distinguish between volumes with the same volume number. This might also make it easy for clients querying Wikidata (e.g., I just want "articles from volume 3 in series 6"). Each article would be linked to the series it belongs to (I'm thinking that each of the 13 series would be instances of series of creative works (Q7725310)). Each article would be part of (P361) a series, and each series would be part of (P361) the journal Annals and Magazine of Natural History (Q19798858). Each article would also be published in (P1433) the journal as usual.

Any thoughts on this? Has anyone modelled a similar situation? --Rdmpage (talk) 09:58, 15 May 2020 (UTC)

@Rdmpage: Still reading ;-)

Your method would work; but alternatively, have you considered proposing a new property for "series"? Like choosing a side of the road to drive on, what we do is less important than agreeing to all do the same. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:35, 15 May 2020 (UTC)

@Pigsonthewing: I guess we could have series as a property, and that would be simplest (just a text string "1"), although we'd have to go through the process of proposing the property. Having series as items has the advantage that we can then talk about them (for example, add start dates, etc.). So I guess it ends up being the usual questions: do we want something that's easy to add? do we want something that could enable more details down the road? etc. I have no strong views, just trying to find out what people think before tackling this journal (although, of course, there's no reason the journal can't be added and series added later). --Rdmpage (talk) 14:35, 15 May 2020 (UTC)

@Rdmpage: See the discussion here some months ago. --Dick Bos (talk) 15:13, 17 May 2020 (UTC)

@Dick Bos: Thanks for bringing this to my attention, hadn't seen it (I find navigating Wikidata discussion threads to be a bit of a nightmare). So, my take on that is that that some people (e.g., @Ghouston: would favour having a simple text property for a journals series, partly to make forming citation strings easier. This seems sensible. Is it fair to say that there's no particular reason this hasn't been proposed, and that if I want a series property then I should just go ahead and propose it? --Rdmpage (talk) 16:01, 17 May 2020 (UTC)

Most likely a new property would be useful. There are some journals, like I think Physical Review (Q869847), where the various series have been set up in Wikidata as basically separate journals, such as Physical Review A (Q3382012), but for cases like Annals and Magazine of Natural History (Q19798858) that may not be the best way to do it. Ghouston (talk) 07:50, 18 May 2020 (UTC)

I quite agree that a new property would be useful! --Dick Bos (talk) 15:20, 18 May 2020 (UTC)

The type of a new property should be text. Unfortunately, the English label "series" is already taken by part of the series (P179), so I'd suggest naming it "journal series" with aliases "periodical series", "series of journal", "series of periodical". Ghouston (talk) 02:05, 19 May 2020 (UTC)

Hmm, the label on part of the series (P179) is "part of the series", I was looking at the Dutch "serie", but it's potentially confusing in multiple languages, so I'd include "journal" in the label. Ghouston (talk) 02:07, 19 May 2020 (UTC)

Because otherwise, it will look like the two are supposed to be inverses, but the data types will be different. Ghouston (talk) 02:09, 19 May 2020 (UTC)

duplicates

In preparation for a bot run I used a WD dump to get an index of article items with PMID. There are 6,177,391 such items of which 1,888 are duplicates (about 30 triplicates etc). Taking a small sample shows these were added by several bots, partly by the same bot in different runs. They don't appear to be different versions, however, slightly different sets of statements were added later by people.

This is just a heads up that I'll be merging them all automatically into the respectively oldest item. --SCIdude (talk) 17:23, 25 May 2020 (UTC)

Addendum: the actual numbers are 30,755,586 items with PMID, and 6,360 with duplicate PMID. I was only looking at items with main subject (P921) claims first. --SCIdude (talk) 07:40, 28 May 2020 (UTC)

Data donation from ISSN Register (Followup)

Notified participants of WikiProject Periodicals and The Source MetaData WikiProject does not exist. Please correct the name. and The Source MetaData/More WikiProject does not exist. Please correct the name.

Following previous announcement that the ISSN would upload some metadata from its ISSN Register to Wikidata, things have been moving slowly, of course also because of COVID, but now the development of a bot to do that job has started. Things have changed since the previous announcement :

ISSN will only upload data on entries that have an ISSN filled in in Wikidata with ISSN (P236). This :
- eases the reconciliation process, that will be conducted only based on ISSN (P236); we will not try to reconcile based on publication title;
- avoids the risk of creating duplicates if the match on the title does not work;
- avoids creating tons of very small entities in Wikidata;
This upload will be done by an automated Bot, not through OpenRefine, this will allow to have regular updates from ISSN Register;
Of course the bot will preserve existing values, and add qualifiers and references to them when they are the same as in the ISSN Register; e.g. if a different value for official website (P856) or place of publication (P291) exists in Wikidata, it will be preserved, and new values with references to ISSN Register will be added;
ISSN will only upload current ISSNs on serial entities, not ISSNs corresponding to ceased or dead resources or titles, since the start/end date for these is not part of the free data; so, to avoid confusion between current information and retired information, only current information will be uploaded;
If the value of official website (P856) or place of publication (P291) changes over time, the old value will be preserved, with an "end time" qualifier (end time (P582)), and set to "deprecated" rank;

Below is a slightly updated data model diagram that reflects these changes :

– The preceding unsigned comment was added by Tfrancart (talk • contribs) at 09:04, 9 June 2020‎ (UTC).

@Tfrancart: Good news. Just curious: how many current ISSNs are we missing (approximately)? Depending on the number, I could do some checks and create some or all missing items. --- Jura 09:46, 29 July 2020 (UTC)
- @Jura1: last time we checked there was ~ 164k wikidata items with an ISSN. The ISSN register at https://portal.issn.org/ says 2739477 (2.7 million) notices, but this includes different notices for print/electronic variants, plus discontinued periodicals; I don't know the number of current ISSNs in the database. Please review https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/ISSNBot and recast your vote if the changes are appropriate.
- @Tfrancart: I think the approval should go ahead. I ask a bureaucrat to look into it. Even if we (you) start with 164k, we could add more at a later stage. If we just look at print variants, how many could we potentially add? I don't mind creating the items if they can be completed and/or they are in use elsewhere. --- Jura 10:07, 29 July 2020 (UTC)
  - @Jura1: the idea is also to avoid creating useless items just for the sake of synching the ISSN register : let's simply wait for items with ISSNs to be created by people that need them, and the ISSNBot will enrich them; anyway yes, they can be added later as the bot will be run periodically.
  - @Tfrancart: np. I think most current ones were mass-created by Magnus to allow feeding from pubmed easily. Missing ones are currently just skipped. This is obviously suboptimal. The idea would be to make useful selection among the 2.5 million. Maybe anything with more than 10 years of print publication? --- Jura 10:36, 29 July 2020 (UTC)

Missing periodicals

When checking a few articles, I noticed they had volume/issue/page numbers, but lacked a "published in" statement.

It's a known problem as the item for the periodical (here: Central Europe (Q98342911)) hadn't been created. For that publication, I could find more articles from that periodical with the DOI.

this query finds a few more, but others timed-out. Maybe Krbot can generate a report with the constraint I added to issue (P433).

It's probably worth going through more of the scholarly articles to find them. --- Jura 08:45, 13 August 2020 (UTC)

@Jura1: See [1].--GZWDer (talk) 09:02, 13 August 2020 (UTC)

Good idea. Currently gives >300,000 articles. Maybe combining that with checks on DOI can get the journals fairly easily. BTW, some journals might have items in the meantime. I left a note on Wikidata:Bot requests--- Jura 09:16, 13 August 2020 (UTC)

Bulletin of the United States National Museum

So, we currently have four wikidata items named "Bulletin of the United States National Museum" in English as of writing:

Bulletin - United States National Museum (Q21385133): described as "version of volume 1 of a journal"
Bulletin of the United States National Museum (Q21385329): described as "journal"
Bulletin of the United States National Museum (Q56634273): described as "volume 1 of a publication"
Bulletin of the United States National Museum (Q56633969): described as "publicaton of the United States Museum"

The first two are linked to ISSN numbers 0362-9236 ("Bulletin - United States National Museum") and 0096-2961 ("Bulletin of the United States National Museum") respectively including the corresponding Wikispecies articles, and the last one is linked to "Category:Bulletins of the United States National Museum" on commons.

Can somebody make sense of these? I've been trying to do some fixes to wikidata items for periodicals recently, particularly those linked to Wikispecies, but I haven't a clue what to do with these ones. I'm not sure why there are items described as for volume 1 of either "Bulletin [of the] United States National Museum". I mean, the Internet Archive link in the first item probably is for the first volume only, but everything else linked to that item is the full series. But that doesn't explain the third item, which has no site links at all. Oh yeah, and the four items link to each other. Monster Iestyn (talk) 16:25, 24 September 2020 (UTC)

User:RaboKarbakian made the changes and additions. --Succu (talk) 17:54, 7 October 2020 (UTC)

Well then... @RaboKarbakian: can you explain what's going on here then? Monster Iestyn (talk) 16:33, 9 October 2020 (UTC)

First, my short answer is that this is how the Wikisourcers want it.

Each book has versions and editions and perhaps ISSN numbers describe version and edition differently, I wouldn't know. We deal with scans of old books. Books that were bought at various print lots for hundreds of years. If those are separate scans that is what they are. If you have an ISSN, then you probably have a cover image that is not too big to be on the language wikipedia and can via a link to there. You have to make it jump through more hoops to upload it to the commons.

If there is a problem and those are all the same three publications, then fix it. I don't think so, for one with an ISSN number because the scans are not so organized. --RaboKarbakian (talk) 20:26, 20 October 2020 (UTC)

Every scan might have one or more ISSN. I will look into this tomorrow.--RaboKarbakian (talk) 18:44, 22 October 2020 (UTC)

@RaboKarbakian: Apologies for not responding sooner, I forgot about this discussion until just now! Anyway, the problem I was actually having with these is how the volume items have identifiers that are actually supposed to apply to the whole periodical, such as the ISSN, BHL bibliography ID, ACNP journal ID, etc. That they are applied to an item purportedly for a single volume of a periodical seems inconsistent with how periodical-related wikidata items are normally set up from my experience, which confuses me a great deal. I would have fixed it myself but everything here seems to be rather a tangled web. Q21385133 in particular appears to be linked from many other items as if it was the item for the periodical itself rather than a volume, despite what the label says!

If it helps to know, the two ISSNs I mentioned initially are for the same periodical but for different runs of it. According to ACNP [2] [3], ISSN 0096-2961 ("Bulletin of the United States National Museum") ran between 1875-1905, and was continued by ISSN 0362-9236 ("Bulletin - United States National Museum", or just "Bulletin") which ran between 1907-1971. Monster Iestyn (talk) 06:37, 27 October 2020 (UTC)

Can we try to apply scientific journal (Q5633421) to just one of them or not have overlapping start/end dates if there are multiple items? --- Jura 09:57, 27 October 2020 (UTC)

Start and end date

Please see Wikidata:Project_chat#Periodicals'_start_and_end. --- Jura 09:30, 5 October 2020 (UTC)

Followed by = absorbed by?

I'm wondering whether P155/P156 is used for when one periodical is absorbed/taken over by another? - Kosboot (talk) 12:21, 30 October 2020 (UTC)

According to this query several journals have been merged from multiple other journals, so why not? -- JakobVoss (talk) 21:01, 30 October 2020 (UTC)

There is also merged into (P7888) Monster Iestyn (talk) 01:35, 31 October 2020 (UTC)

Welcome to the wonderful world of Wikidata data modeling where there are often multiple ways to do it. To me it looks like merged into (P7888) is better but then a lot of existing followed by (P156) statements need to be modified. -- JakobVoss (talk) 11:12, 2 November 2020 (UTC)

Sounds to me that followed by (P156) might possibly be in some cases used more for “spiritual successor” than take-over (for example, JV (Q20726050) is a sort-of successor to Joystick (Q3187262)). So I would agree that in case of actual take-over, merged into (P7888) is better. Jean-Fred (talk) 11:48, 25 November 2020 (UTC)

Thank you all for your thoughts. Related to this is when a periodical is NOT taken over or absorbed or merged with another, but just changes its name. There are a lot of issues with periodicals that I don't see adequately covered in most Wikidata items (like when a periodical retains the same name but has a number of sponsors and/or publishers). - Kosboot (talk) 13:53, 25 November 2020 (UTC)

Not sure what to do with this entity

Q29519433 appears to be either a collection of scans of historic newspapers, and/or some editorial commentary on them. It was published on CD-ROM. I added a description, and added "instance of CD-ROM" but that doesn't seem quite right. It's a publication whose format happens to be CD-ROM. Hoping somebody has a better sense of what to do with this item. -Pete F (talk) 19:27, 24 November 2020 (UTC)

Thanks for your efforts on this @Jheald: it looks much better, and helps me understand what to do in a case like this. Much appreciated! -Pete F (talk) 20:30, 25 November 2020 (UTC)

Preferred properties for periodical predecessors and successors?

Are "followed by" and "follows" now the preferred relators for periodical title successors and predecessors? I recall seeing "replaced by" and "replaces" earlier, but the documentation may have changed recently, and it's not clear now. Also, someone just constrained the "replaced by" property (but not yet the "replaces" property) so that it's only supposed to be a qualifier, not a main property, and I don't see any discussion of this change. What's going on?JohnMarkOckerbloom (talk) 21:36, 7 December 2020 (UTC)

Should instance of (P31) article (Q191067) really be used?

I see in the current examples: Our Fragile Intellect (Q7110639) instance of (P31) article (Q191067). Naively, I would think that it's better to use academic journal article (Q18918145). Is there a good reason to use the more general property or should we update the guidance?

Notified participants of WikiProject Periodicals ChristianKl ❪✉❫ 22:33, 2 December 2020 (UTC)

@ChristianKl:

There is two opposite tendancies: putting more general or more precise values. The is pros and cons for both, we should strive to be consistent though...

I would prefer more general values (personnaly, mostly per Occam's razor and the atomic principle of normal form databases). I see more and more talk about that recently, see Wikidata_talk:WikiProject_Cultural_heritage#Data_modelling_conventions_of_nature_de_l'élément_(P31),_genre_(P136),_levels_of_specificity,_and_consistency_across_cultural_heritage_description_on_Wikidata and Wikidata_talk:WikiProject_Visual_arts#Prints:_subclasses_vs_attributes_for_genre/form,_technique,_materials for instance. I feel like the "more general" tendancies is gaining ground recently (an after-aftermath of the P107 (P107) deletion...).

Cheers, VIGNERON (talk) 08:27, 3 December 2020 (UTC)

The normal form database model is for relational databases, and a graph database / knowledge graph model is very different. Wikibase is not a relational database. author TomT0m / talk page 15:43, 19 February 2021 (UTC)

Example, the « scholarly article » class can really have different properties than the « article » in general. The peer review process is really specific to published process, and not relevant for magazines. And it’s in no case a « form » problem. There is several form for scientific articles, for example https://www.researchgate.net/post/What-is-the-difference-between-a-State-of-the-art-paper-and-a-review-paper state of the art papers, review papers … and maybe sub-genre / sub-forms in each, hierarchically … you can’t deal with this easily with a rigid relational database scheme. The information that a paper is a state of the art is useful to have. author TomT0m / talk page 16:17, 19 February 2021 (UTC)

I would prefer something rather general for instance of (P31), similar to what is current practice for human (Q5). For publications, publication (Q732577) would probably be worth considering as the default. The more fine-grained information — which I agree is needed — could then be handled by other properties, e.g. genre (P136). --Daniel Mietchen (talk) 21:47, 6 December 2020 (UTC)

literary work (Q7725634) is another option for a generic value. academic journal article (Q18918145) may also be a candidate for form of creative work (P7937). Ghouston (talk) 02:58, 7 December 2020 (UTC)

Not too long ago, we had a discussion about the label of "scholarly article" (Q13442814). Not sure what the conclusion was (other than someone restore the label). --- Jura 16:15, 7 December 2020 (UTC)
I'm not sure exactly what would come under publication (Q732577), since its really a verb, not a noun (see it's English Wikipedia article). If we mean a published document or book, then a journal issue may be a publication and an article in the journal is just part of that. Typical items in Wikidata for articles have fields like published in (P1433) and volume (P478), which are specific to a particular printing, i.e., an edition. If we don't want to create work and edition items for journal or magazine articles, then I'd say they should instead be a conflation of literary work (Q7725634) and version, edition or translation (Q3331189), perhaps with a new item created for this purpose, and making use of form of creative work (P7937) to indicate the specific type of article. Ghouston (talk) 07:03, 20 December 2020 (UTC)
The problem with that is that such conflations aren't a very good database model. Perhaps a better idea would be to accept that for many works it's only necessary to have an edition item. The "work" item would only be needed if you want either a) to link multiple edition items together b) include external links to "work" items in other databases. (Also copied to a similar discussion at Wikidata talk:WikiProject Books.) That would mean the instance of (P31) for the typical article published in a periodical, which has no other edition items, would be version, edition or translation (Q3331189). In some cases, preprints are also used as references, which would require a separate edition. Ghouston (talk) 08:43, 3 January 2021 (UTC)
- It seems that for papers, the model with a single item generally works out quite well. --- Jura 11:59, 19 February 2021 (UTC)
Currently, it seems like the usage of retracted paper (Q45182324) is problematic and related. I think we should decide on one model and then run a bot to bring our existing data in touch with our data model. The Source MetaData WikiProject does not exist. Please correct the name. The Source MetaData/More WikiProject does not exist. Please correct the name. ChristianKl ❪✉❫ 11:32, 19 February 2021 (UTC)
- Not sure if titles of papers should be edited to insert "retracted". Can we change property sorting to display is retracted by (P5824) just below P31? --- Jura 11:59, 19 February 2021 (UTC)
  - That's a UI issue, the Wikidata UI is for editing, not reading or other consumption if I understood correctly. You can always create a ticket, but I don't think it's gonna be implemented before a UI redesign.--So9q (talk) 12:31, 19 February 2021 (UTC)
    - - ChristianKl, can you change it for us? Or do you want a "ticket". --- Jura 12:41, 19 February 2021 (UTC)
- What exactly would be the problem of « retracted article », in preferred value ? If we put an end date with normal rank and/or deprecate the « article / scientific article » value, and if « retracted article » is not a subclass of any article class, then there is no risk at all to retrieve it in any query that queries scholarly articles. author TomT0m / talk page 15:47, 19 February 2021 (UTC) (as in other cases, I think it’s better that a user that search for published article should easily find valid article, and should have not to bother to exclude retracted articles from the results. They should be excluded by default, if someone wants them he has to write that query to include them). author TomT0m / talk page 15:51, 19 February 2021 (UTC)
  - Just to note, there's also a discussion about how best to model retracted papers at Wikidata_talk:WikiProject_Source_MetaData#Retracted_articles. T.Shafee(evo&evo) (talk) 11:51, 23 February 2021 (UTC)

Properties for periodicals tiers: work/series/volume/issue/article

I'm trying to work out how to construct data for periodicals at Wikisource. These are generally structured something like this:

Journal
- Series (optional) - for example s:en:Portal:The Electrical Engineer has a few volumes in an untitled original series, then rebooted for a "New Series".
  - Volume (generally one year, not always), usually this is how scans come "packaged", but sometimes the scans are two multiple volumes or issues comprising two incomplete volumes. Some works, particularly newspapers don't have a formal "volume" tier.
    - Issue (weekly/biweekly/monthly/quarterly, etc, can vary in a given periodical over time)
      - Articles, which might be split into multiple parts and spread across multiple issues, volumes and series, and occasionally split within a single issue.

The question is, how should a work like The Electrical Engineer be structured on Wikidata? I have started with

The Electrical Engineer (Q105221968) (the work, instance of trade magazine (Q685935), but other works could be magazine (Q41298), scientific journal (Q5633421) or similar)
- The Electrical Engineer, original series (Q105267777) (instance of series (Q3511132): unsure if this is right)
- The Electrical Engineer, New Series (Q105267505)
  - The Electrical Engineer, New Series, Volume 1 (Q105224809) (instance of volume (Q1238720), unsure of the "title", and the property for "start and end", is start of covered period (P7103) and end of covered period (P7104) right?)
    - The Electrical Engineer, New Series, Volume 1, Number 25 (Q105268413) (instance of issue (Q28869365), unsure of the "title")
      - The Tesla Alternate Current Motor (Q19100726) (instance of article (Q191067), this bit is fairly straightforward)

In particular, I am unsure of:

the correct properties for the "series" tier
whether or not items should be created for series and volumes
- if so, the titles for these tiers
should things like issue and volume be top-level properties or qualifiers on part of (I feel the latter may be more correct, but the former is more common?)

I eventually hope to be able to use QuickStatements or similar to make this easier, and the long term goal is to make a substantial about of labour at WS automated based on WD series/volume/issue properties. Therefore, I'd like to get it was correct as possible up front.Inductiveload (talk) 11:07, 3 February 2021 (UTC)

The Tesla Alternate Current Motor (Q19100726) shouldn't be much different from an item for an article that is not at Wikisource, e.g. Recent advances in the detection of respiratory virus infection in humans (Q82838328). --- Jura 12:15, 3 February 2021 (UTC)

@Jura1: right, the article and top tier are perhaps the most straightforward, but my questions remain for the other aspects, which are actually more critical for a hypothetical data-driven structure at Wikisource for things like volume listings.

I also take it that it is the right thing to place volume (P478), page(s) (P304) and issue (P433) as separate, top level properties, rather than as qualifiers of published in (P1433)? Inductiveload (talk) 12:32, 3 February 2021 (UTC)

I don't think the P1433 value at Q19100726 is currently ideal (compare with Recent advances in the detection of respiratory virus infection in humans (Q82838328)). I suppose it's debatable if the periodical to use as value should be:

Not sure if

are actually needed. You could just query that with volume (P478), published in (P1433) and issue (P433) etc. --- Jura 16:12, 5 February 2021 (UTC)

@Jura1:, so volume/page/issue as top-level statements is best practice, and not as qualifiers of published in (P1433)?

I don't really have a preference, I'll do whatever is "right", but what that is is not quite clear to me.

I guess it can all be done with one big entity (and things like Handle ID (P1184), document file on Wikimedia Commons (P996), Wikisource index page URL (P1957), start of covered period (P7103), end of covered period (P7104), etc will have at least 'n' entries, each with a volume (P478) and maybe "series" qualifier plus another 'n times 26' entries relating to the issues). We can then dig the data out that we need to construct something about "Volume 1, Number 25" at Wikisource from one big item. However, that will a) result in thousands and thousands of values for the periodical item and b) it will prevent Wikisource having sitelinks for the individual volume and issue pages.

What to do about the series is also a concern. Many periodicals have multiple series, for example Once a Week (Q7091757) had four series. I notice United Nations Treaty Series Volume Number (P4222) exists, but a special property seems kind of overkill. Inductiveload (talk) 17:26, 5 February 2021 (UTC)

Reprint of a journal

The 4 volumes of The Journal of Classical and Sacred Philology (Q105103351) (1854–59) were reprinted in 1970 (original OCLC 1587511, reprint 17761803). How should this be captured? Inductiveload (talk) 10:07, 4 February 2021 (UTC)

Academic publisher preprint policies

The page on ENWP: w:List of academic publishers by preprint policy has a structured table of publisher policies. How would it be best to encode these into wikidata? A possible way of organising data on the item of a publisher (e.g. Wiley (Q1479654)):

Statement: permits (P8738) preprint (Q580922) (or possibly create item for "submission from / sharing of preprint")
- Qualifier: prohibits (P8739) create items for common restrictions e.g. "commercial preprint server" or "version after peer review"
- Qualifier: has characteristic (P1552) alternatively the inverse of the above e.g. "Non-commercial preprint server only" or "version before peer review only"
- Qualifier: Not sure how to encode conditions such as "If preprint is CCBY, then must pay APC"
- Qualifier: start time (P580) if people want to add in when different publishers/journals changed policy
- Reference: quotation (P1683) if people want to quote the policy txt (along with reference URL (P854), obv.)

Please reply at w:Talk:List_of_academic_publishers_by_preprint_policy#Draft_wikidata_encoding to keep discussion centralised. Thanks in advance!. T.Shafee(evo&evo) (talk) 05:06, 2 March 2021 (UTC)

Please centralize discussions about editing Wikidata in .. Wikidata, not Facebook or enwiki. --- Jura 09:58, 2 March 2021 (UTC)

Periodicals as organizations vs venues: Number of items to create

In looking at the properties for periodicals as venues and periodicals as organizations, I am confused about how many items should be created. Is the section with properties for periodicals as organizations meant to show all of the properties that would exist in an item that is separate from the item for the periodical as venue? Up until now I have combined the properties in these two lists and put them into a single item for the periodical. I am now wondering if that is incorrect (though I have not yet seen an item for a periodical as an organization--only items for periodicals as venues).Mgrenci (talk) 21:53, 10 March 2021 (UTC)

Examples of items that include both venue and organization properties: Q55627861 and Q94022449 include Founded by (P112). This is the organization property most likely to be relevant to the publication (venue) item.Mgrenci (talk) 01:06, 11 March 2021 (UTC)

An organization is a different thing to a periodical, so it'd seem natural to me to have separate items, especially since it's not unusual for a single organization to publish multiple things. However, in some cases, you may not care enough about the organization to make an item for it. Ghouston (talk) 01:17, 11 March 2021 (UTC)

In the case of newspapers, the two concepts have been conflated to the point that newspaper (Q11032) has been made a subclass of both business (Q4830453) and organization (Q43229), which is clearly in does not always apply (Q90177495) territory. Ghouston (talk) 01:20, 11 March 2021 (UTC)

So-called "botany" scientific journals

I've been noticing for a while that a lot of items for periodicals, or at least scientific journals, seem to have both field of work (P101) and main subject (P921) set to botany (Q441), the former typically imported from Spanish Wikipedia and the latter without any references at all. In fact, however, many of these actually have a wider scope than botany, like natural history, or even science overall: in fact for instance I just found earlier today that this was true of Journal of the Royal Society of New Zealand (Q2790617), even though the Taylor & Francis pages for it says it publishes "international research on the science and technology of New Zealand and the Pacific region". Not just botany!?!? (I've since corrected this myself, obviously)

This sounds like a botched mass of imported data from some plant journal database, or at least with no humans checking that the data is actually correct. I've been trying to correct this for some months now on and off, but the sheer volume of items to correct is presumably too much for one user to do without burning out at some point. Anyone else care to look over these items as well?

By the way, I've mostly been referring to species:ISSN for a list of these (since I'm mainly on Wikispecies currently), but there may be more items without Wikispecies pages currently with the same problem. Monster Iestyn (talk) 15:19, 19 May 2021 (UTC)

No response in nearly a week... is this WikiProject not very active lately or something? Or did I start this discussion in the wrong place? Monster Iestyn (talk) 18:50, 25 May 2021 (UTC)

Wikidata talk:WikiProject Periodicals/Archive 2

Contents

Update

Frequently missing properties on items for journals

Issues

Received date ?

Keywords

Magazine

Distribution format values ? (from MARC)

Data donation from ISSN Register - Feedback welcome

Former names

Start date

Upload

Followup on ISSN data import : questions and help needed

Tables with information on periodical copyright and free issue availability

Advice on handling large journal with many series - creating items for the series?

duplicates

Data donation from ISSN Register (Followup)

Missing periodicals

Bulletin of the United States National Museum

Start and end date

Followed by = absorbed by?

Not sure what to do with this entity

Preferred properties for periodical predecessors and successors?

Should instance of (P31) article (Q191067) really be used?

Properties for periodicals tiers: work/series/volume/issue/article

Reprint of a journal

Academic publisher preprint policies

Periodicals as organizations vs venues: Number of items to create

So-called "botany" scientific journals

Navigation menu

Wikidata talk:WikiProject Periodicals/Archive 2

Update

Frequently missing properties on items for journals

Issues

Received date ?

Keywords

Magazine

Distribution format values ? (from MARC)

Data donation from ISSN Register - Feedback welcome

Former names

Start date

Upload

Followup on ISSN data import : questions and help needed

Tables with information on periodical copyright and free issue availability

Advice on handling large journal with many series - creating items for the series?

duplicates

Data donation from ISSN Register (Followup)

Missing periodicals

Bulletin of the United States National Museum

Start and end date

Followed by = absorbed by?

Not sure what to do with this entity

Preferred properties for periodical predecessors and successors?

Should instance of (P31) article (Q191067) really be used?

Properties for periodicals tiers: work/series/volume/issue/article

Reprint of a journal

Academic publisher preprint policies

Periodicals as organizations vs venues: Number of items to create

So-called "botany" scientific journals

Navigation menu

Search