Property talk:P5504

Documentation

RISM ID
identifier for a person, institution, or work in the Répertoire International des Sources Musicales database

Associated item

Répertoire International des Sources Musicales (Q2178828)

Applicable "stated in" value

Répertoire International des Sources Musicales (Q2178828)

Has quality

VIAF component (Q26921380)

Data type

External identifier

Allowed values

(people|institutions|sources)\/[1-9]\d*

Example

Cambise (Q48997177) → sources/850009078
Pompeo Natali (Q47507735) → people/30006410
University of Washington Music Library (Q106900826) → institutions/30002456

Source

https://rism.info

Formatter URL

https://rism.online/$1

Tracking: usage

Category:Pages using Wikidata property P5504 (Q55691564)

Change to RISM Online[edit]

I represent the RISM Digital Center (https://rism.digital). Since 2021, we are responsible for building and maintaining the tools for the global RISM project. We develop the cataloguing tool, Muscat, used by all the RISM cataloguers.

As part of our work we have developed RISM Online, a data-oriented tool for delivering the RISM data. This tool is built with Linked Data in mind, so we have a full JSON-LD API.

We have recently been looking to add better integration between RISM Online and Wikidata, and one point that stands out is that this property currently refers to the older, third-party resource for RISM data. In addition, there are a significant number of records that use this property that do not resolve to a RISM record. (For example, this record dies not use the correct identifier format: Q452685). Additionally, the RDF formatter URI is not functional.

We would like to update this property to point to RISM Online, and work towards fixing the problems in Wikidata with this property to make it work correctly.

We have explored some methods for doing this, but before proceeding would like to hear from others involved in the creation of this property.

Many thanks, -Andrew Hankinson Ahankins (talk) 09:42, 30 November 2023 (UTC)[reply]

Hi @Ahankins:, your help is welcome to improve the coverage and the quality of the RISM IDs in Wikidata! Thanks for updating the VIAF code of the property. The obsolete/wrong RISM IDs can be removed; could you give an overview of all the formats of RISM IDs presently existent? In this way we can easily find the IDs which don't fit this format and remove them massively. For the RDF formatter URI, probably I have fixed it now. I think updating the property to RISM Online is a good idea, of course; which things will need to be modified in the property in order to archive this update? I will be glad to collaborate to this update if I can do something. --Epìdosis 13:58, 30 November 2023 (UTC)[reply]

Thanks! I'll try to summarize / answer point-by-point.

could you give an overview of all the formats of RISM IDs presently existent

First, all RISM IDs are initially assigned in Muscat, our cataloguing application. We maintain public authority lists for people and insitutions, but also have internal authorities for places, subject headings, and a few others. We are also working on a new authority record for musical works that will be made public.

All RISM IDs published are based on the Muscat identifier assigned, but differ by the URL/URI when made public. So, person 72637 in RISM is Fanny Henschel (aka Fanny Mendelssohn), Q57286. In the RISM OPAC, this record is published with the identifier "pe72637". The prefix "pe" denotes a person record; "ks" denotes an organization record. No prefix denotes a source record. These are then published as query parameters to a "permalink" search setup on the RISM OPAC, e.g., https://opac.rism.info/search?id=pe72637&View=rism

RISM Online, on the other hand, publishes these identifiers as more traditional URIs. That is, the same record is published as https://rism.online/people/72637. This is much closer to the HTTP principles of a "resource" on the web. Sources are likewise published as https://rism.online/sources/462003500, and institutions as https://rism.online/institutions/30001581.

Notably, we also make RDF and Turtle representations of these same URIs available through content negotiation. We are still working out a few minor issues, but it works now -- you can request any of the above URIs with an Accept header of "text/turtle" or "application/n-triples" and it will return these formats for each record.

which things will need to be modified in the property in order to archive this update

The formatter URL would need to change, but here we risk breaking some things. There are roughly 30,000 links to the RISM OPAC, but most of those are for person records. This means that any person record with the "pe" prefix will no longer work. So we would need to bulk update those records to fix them.

Most of the institution records in Wikidata that point to the RISM OPAC are broken, primarily because they do not include the "ks" prefix. But rather than deleting them we would update them to match the RISM Online format, for those that exist in our authorities. (A side note: We recently deleted a bunch of institution authority records because they were unnecessary and only in our system as the result of a legacy database being imported wholesale. So we can produce a list of Wikidata institutions that have a RISM ID that are no longer in our system, and actually delete those identifiers from the Wikidata records.)

The URL Match Pattern would also change -- I'm not sure what the difference is between that and the formatter URL, TBH.

We could also look at what is needed to support the RDF URI Formatter property. As I said, we are preferring to use a single URI for all resources, with Content Negotiation to vary the response format. So I would be interested to know how that approach would work with the RDF formatter.

The regex would also need to change.

I will be glad to collaborate to this update if I can do something

Thanks! Since we're relatively new here, just having a response is helpful. We're also interested in using QuickStatements to help update, so we might ask for guidance in this, if that's OK? Ahankins (talk) 15:17, 30 November 2023 (UTC)[reply]

@Ahankins: thanks for the very complete explanations. So, basically we need to change the format of the IDs from "peNUMBER" to "person/NUMBER" and from "ksNUMBER" (or the wrong "NUMBER" without initial "ks") to "institution/NUMBER", and adapt consequently the regular expression and the formatter URL (and the URL match pattern, which is used I think mainly by Wikidata:Entity Explosion and maybe other applications based on Wikidata). For the RDF URI formatter and content negotiation, I'm honestly unsure about the answer since I don't remember previous cases - but I think we will find a solution. I have a question about the deleted institution IDs: have these IDs been deleted also from VIAF when the passage from DE663 to DE633 was done? This is relevant because, if they are still in VIAF, they could be reimported from VIAF to Wikidata after we delete them from Wikidata.

Anyway, since the biggest change needed is adapting the IDs presently in Wikidata to the new formats (and deleting the obsolete ones, especially that group of IDs regarding institutions which you mentioned), I think using the Autofix is more efficient than using QuickStatements (QS) for some reasons: QuickStatements cannot "change" the IDs used as main values, but it can just remove them and readd in the new format, an option which looses their references; moreover, QuickStatements cannot change the format of the IDs used as references. The Autofix can do both things; I can set up it in a few seconds when you think we can proceed with the change. --Epìdosis 07:12, 1 December 2023 (UTC)[reply]

This looks good. However, IDs should be "people/NUMBER" and "institutions/NUMBER".

I have one question regarding the import from VIAF to Wikidata. How and when is this happening? Is this an automatic process that runs regularly? Where is it controlled? Lpugin (talk) 08:33, 1 December 2023 (UTC)[reply]

@Lpugin: sure, "people/NUMBER" and "institutions/NUMBER"; my previous comment was obviously mistaken, I wrote it a bit too fastly.

For VIAF imports: as of now, no massive import of RISM IDs from VIAF has been done; but users can manually, through gadgets like User:Bargioni/moreIdentifiers, extract IDs from VIAF clusters, including RISM; this is done item per item, so is practically a manual import. In theory massive imports of IDs from VIAF would be possible, and sometimes they have been performed, but they require a lot of caution since VIAF clusterization has some mistakes for persons and is mostly unreliable for organizations. So my question, having in mind users adding IDs from VIAF using gadgets, was aimed to understand if, in the future months, we risk to import IDs which are already obsolete. --Epìdosis 12:07, 1 December 2023 (UTC) P.S. We can proceed with the change of "people/NUMBER" and "institutions/NUMBER" when you want[reply]

We're going to do a bit more work on our own internal processes for publishing to VIAF -- this is also a manual process, and we need to talk with them about the format of identifiers they use, since it's not clear whether they would accept a slash. We can also volunteer some time to fix the import script if that causes a problem.

In any case, I think we're clear to proceed with the changes to the Wikidata property. Let us know if there is anything (verification, coding, or other) we can do to help.

PS: You may also have noticed I added the Identifiers.org property to this record as well, where we have the registered prefix of "rism". Ahankins (talk) 13:42, 1 December 2023 (UTC)[reply]

OK. Ideally having the same ID format on RISM Online, VIAF and Wikidata would be the best possible situation, I hope we can reach it soon. Changing the format can technically be started now; before starting it I just

Notified participants of WikiProject Authority control for confirmation; if there is no objection in 1-2 days, I will proceed through Autofix (I prepare them above here in ; they can just be uncommented to start the process). --Epìdosis 14:08, 1 December 2023 (UTC)[reply]

Support Sounds good! - PKM (talk) 20:31, 1 December 2023 (UTC)[reply]

@Ahankins, Lpugin: I started the change of format of the values. I only have one question: the equivalences for people (https://opac.rism.info/search?id=30006410 = https://rism.online/people/30006410) and institutions (https://opac.rism.info/search?id=30002456 = https://rism.online/institutions/30002456) are clear, but which is the equivalence for works (e.g. https://opac.rism.info/search?id=850009078) in rism.online? Thanks! --Epìdosis 10:54, 4 December 2023 (UTC)[reply]

Thanks, this looks good. Works are actually sources. The URI is https://rism.online/sources/850009078 Lpugin (talk) 16:16, 4 December 2023 (UTC)[reply]

Haven't had time to read all the discussion above, but right now we have 11,000+ articles in Wikipedia with errors identified — Martin (MSGJ · talk) 19:35, 4 December 2023 (UTC)[reply]

We've been fixing up many of the articles using this list, but it seems that many have been fixed. How can we update this list of articles with errors? Thanks! Ahankins (talk) 13:21, 6 December 2023 (UTC)[reply]

Format conversion[edit]

Have checked a few and some are working but Roberto Abbado (Q667842) and Adela Maddison (Q4681600) have non-working RISM links — Martin (MSGJ · talk) 19:39, 4 December 2023 (UTC)[reply]

It looks like those are from VIAF and were deleted in 2020. I've marked them as withdrawn. Ahankins (talk) 08:38, 5 December 2023 (UTC)[reply]

Errors now clearing at English Wikipedia — Martin (MSGJ · talk) 20:21, 4 December 2023 (UTC)[reply]

Yes, it looks like it is clearing. This is excellent. I can see a list of entities pointing to RISM IDs that do not exist. I guess this comes from an old VIAF aggregation. https://w.wiki/8PER. What shall we do with these? Lpugin (talk) 08:39, 5 December 2023 (UTC)[reply]

If they can't be corrected then the recommended action is to mark them deprecated and add qualifier reason for deprecated rank (P2241) -> invalid identifier format (Q107631537) — Martin (MSGJ · talk) 09:06, 5 December 2023 (UTC)[reply]

@Ahankins, Lpugin: Format change completed; as of now, no IDs with wrong format are present in Wikidata. --Epìdosis 09:08, 5 December 2023 (UTC)[reply]

Have you looked at the query linked above? — Martin (MSGJ · talk) 09:30, 5 December 2023 (UTC)[reply]

Sure. 206 IDs (https://w.wiki/8PFn) remain not converted since they had no prefix, neither "pe" nor "ks"; they seem to be all obsolete and they should be deprecated. All the convertible IDs have been converted. BTW, 75 other IDs (https://w.wiki/8PFj) were converted from "ks" to "institutions" but seem obsolete too. The others should be OK. --Epìdosis 09:42, 5 December 2023 (UTC) Precisation: some of these 75 are working, e.g. https://rism.online/institutions/63534, but others not, e.g. https://rism.online/institutions/1044. --Epìdosis 09:54, 5 December 2023 (UTC)[reply]

I came across a few ones that would be valid with the "institutions/" prefix but that cannot be corrected because the property is locked.

https://www.wikidata.org/wiki/Q19675

https://www.wikidata.org/wiki/Q462039

https://www.wikidata.org/wiki/Q189441 Lpugin (talk) 18:26, 5 December 2023 (UTC)[reply]

@Lpugin: they have been corrected. These items are semiprotected, so can only be edited by users with at least 50 edits (you will reach 50 edits soon, as of now you have 42). --Epìdosis 09:20, 6 December 2023 (UTC)[reply]

We are left with about 93 articles in en:Category:Articles with faulty RISM identifiers and these seem to be genuinely incorrect. Can they be corrected, or should they all be marked as deprecated? — Martin (MSGJ · talk) 15:10, 7 December 2023 (UTC)[reply]

I don't think they can be corrected. Ideally they should be removed since most of them never resolved to anything valid. If that is not possible, then making them deprecated would be good. Lpugin (talk) 07:22, 8 December 2023 (UTC)[reply]

If they never resolve correctly, I think a simple mass-removal is the best solution. I can do it in two minutes if you agree. --Epìdosis 07:51, 8 December 2023 (UTC)[reply]

I agree, please remove them. Lpugin (talk) 07:58, 8 December 2023 (UTC)[reply]

Is sources/ a valid prefix, per Cambise (Q48997177)? What other prefixes are supported? — Martin (MSGJ · talk) 12:15, 8 December 2023 (UTC)[reply]

It's in the regex for this property, so I'm not sure why it's coming up as invalid. It also works fine: https://rism.online/sources/850009078 Ahankins (talk) 12:22, 8 December 2023 (UTC)[reply]

Right now, we're only doing people, institutions, and sources. There may be other prefixes later (works) but that's not public yet. Ahankins (talk) 12:23, 8 December 2023 (UTC)[reply]

I have removed all the IDs without prefix as agreed (https://quickstatements.toolforge.org/#/batch/218499). No format constraint violations remaining. --Epìdosis 12:25, 8 December 2023 (UTC)[reply]

In the authority control info box on the Wikipedia article for Cambise Cambise (Q48997177) the RISM identifier is showing as an orange triangle. Maybe it's just not up-to-date yet? Ahankins (talk) 12:30, 8 December 2023 (UTC)[reply]

Only people and institutions were mentioned above. This is the first time sources has been mentioned. I'll update authority control tomorrow. — Martin (MSGJ · talk) 23:45, 8 December 2023 (UTC)[reply]

VIAF Import[edit]

Now that the identifiers have been fixed, we're getting in touch with VIAF to see what process they use for importing RISM identifiers.

However, changes to this will probably take time.

In the meantime, do we need to adjust the "moreidentifiers" script to do the conversion, just so we don't get the "old style" identifiers added to new records from the VIAF import? I had a look at it and it looks like there are already some special cases for BNF, but couldn't really tell if this was the place this sort of conversion is done. Any hints? Ahankins (talk) 10:22, 8 December 2023 (UTC)[reply]

@Ahankins: I have already had it fixed, see User talk:Bargioni/moreIdentifiers system regex.js#RISM. Now it adds new IDs converting them in the current format. --Epìdosis 12:26, 8 December 2023 (UTC)[reply]

Nice! Thank you very much. Ahankins (talk) 16:43, 8 December 2023 (UTC)[reply]

Property talk:P5504

Contents

Documentation

Change to RISM Online[edit]

Format conversion[edit]

VIAF Import[edit]

Navigation menu

Property talk:P5504

Documentation

Change to RISM Online[edit]

Format conversion[edit]

VIAF Import[edit]

Navigation menu

Search