Marsupium

Babel user information
de-N Dieser Benutzer spricht Deutsch als Muttersprache. en-3 This user has advanced knowledge of English. fr-2 Cet utilisateur dispose de connaissances intermédiaires en français. it-1 Quest'utente può contribuire con un livello elementare in italiano. es-1 Esta persona tiene un conocimiento básico del español. la-1 Hic usor/Haec ustrix simplici lingua Latina conferre potest. grc-1 Ὅδでるたεいぷしろん ὁ χρώμενος στοιχειώδη γがんまνにゅーῶσしぐまιいおたνにゅー τたうῆς ἀρχαίας ἑλληνικῆς ἔχει. tr-1 Bu kullanıcı temel düzeyde Türkçe bilir. arz-1 اليوزر ده عنده معرفه اساسيه باللغه المصرى. ar-0 هذا المستخدم ليس لديه معرفة بالعربية (أو يفهمها بصعوبة بالغة). nl-0 Deze gebruiker heeft geen kennis van het Nederlands (of begrijpt het met grote moeite). he-0 משתמש זה אינו מבין עברית (או מבין אותה בקשיים ניכרים). mul-0 This user has no knowledge of multiple languages (or understands it with considerable difficulty). This user loves OpenRefine. This user uses Mix'n'match. This user uses QuickStatements. ȹThis user uses quickpresets, with custom settings. This user shares their books on inventaire.io (Q32193244).
Users by language

Accounts: w:de | w:en | w:fr | wiktionary:de | commons | wikidata | osm | osmwiki

I'm mostly active on WD:WikiProject Visual arts and Commons.

User:Marsupium/Notes

Useful Tools

Also obvious ones … (see also WD:Tools)

• QuickStatements 2
• Mix'n'match
• User:Magnus Manske/Mix'n'match report (ULAN ID (27))
• Wikidata History Query Service
• Crotos IIIF Image Cropper for Wikimedia Commons and Wikidata
• IIPImage Server, here File:Godward Idleness 1900.jpg: s. a. Wikidata:Property proposal/Creative work#relative position within image
• PLtools
• classes: Wikidata generic tree, WGB, Wikidata ontology explorer
• edits: Navel Gazer, WD todo edits, …

• c:User:Multichill/Same image without Wikidata (see also c:User:Multichill/Unable to add Wikidata link)
• c:Commons:WikiProject sum of all paintings/To upload/Duplicates
• WD:WPSOAP/Image suggestions/Creator, institution and inventory number match
• WD:WPSOAP/Wiki monitor/dewiki
• WD:WPSOAP/Missing collection
• WD:WPSOAP/RKD to match (/Alte Pinakothek)
• WD:WPSOAP/Duplicate paintings
• WD:WPSOAP/Duplicate Commons category
• WD:WPSOAP/Possible paintings
• WD:WPSOAP/Location/Germany/Missing inventory number
• WD:WPSOAP/Creator inception mismatch

• WD:WPSOAP/Collection/Bavarian State Painting Collections to fix
• WD:WPSOAP/Bad descriptions
• WD:WPSOAP/Recent incomplete creator
• User:Multichill/RKD redirects
• WD:WPSOAP/Creator no authority control
• WD:WPSOAP/Creator missing collection authority control
• User:Multichill/Zandbak: formerly authority control missing for painters
• Multichill's missing painters from descriptions (BStGS)
• Commons <-> WD maintenance
  • c:Category:Creator template maintenance (c:Category:Creator templates without Wikidata link)
  • c:Category:Institution template maintenance
  • c:Category:Artwork template maintenance
• WD:WPSOAP/Duplicate paintings
• WP:WPVA/Artists same name, WD:WPSOAP/Creators same name
• Wikidata:Database reports/Same humans
• User:Nurni/DuplikatyULAN (limited used, last update 2019)
• https://mix-n-match.toolforge.org/#/issues/WD_DUPLICATE
• Wikidata:Interwiki conflicts/Unresolved
• User:ValterVB/ConflittiDipintoDi

• (DEAD) Source MetaData: creating/adding from PMID/DOI/PMCID
• (DEAD) Resolve authors with ORCID
• Magnus' Wikidata file candidates currently (2019-07-09) not working tho intro

• Wikidata Lexeme Forms
• Ordia
• graves.wiki (down? 2020-12-04, still 2024-05-22)

To try:

• toolforge:dicare
  • toolforge:dicare/bnf
  • toolforge:dicare/idref

Properties to remember: narrative motif (P6962), review of (P6977)

Some notes

Just now, I decided that I will testingly start a small series addressing small things connected to my activity at Wikidata. I always make notes for myself anyway. However, some of them might be more useful for me and maybe others if I note them understandable and written out. Feel free to correct the posts or to add comments. Thanks, --Marsupium (talk) 06:30, 13 April 2014 (UTC), changed 01:19, 19 April 2014 (UTC), 09:53, 15 August 2017 (UTC)

Ordering our triples

• (Inspired by Wikidata:Requests for comment/Sort identifier statements on items that are instances of human:) External IDs could get ordered by their classes, and in one class by English label with the existing MediaWiki:Wikibase-SortedProperties. A bad start for query to get such a list

  SELECT
  ?prop ?propLabel ?instanceOf ?instanceOfLabel ?subclassOf ?subclassOfLabel
  WHERE {
    ?prop a wikibase:Property ;
          wikibase:propertyType wikibase:ExternalId.
  #  OPTIONAL {
      ?prop wdt:P31 ?instanceOf.
      OPTIONAL { ?instanceOf wdt:P279 ?subclassOf. }
  #            }
    SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
    }
  ORDER BY ?subclassOf ?instanceOf
  

  this tree query ; this tree query. The question remains then how to order the classes!? …
• IMHO best would be to store all sort order settings in the database, also MediaWiki:Wikibase-SortedProperties. For an approach for this see http://vocab.getty.edu/doc/#Sort_Order.
• For statement claim ordering of course series ordinal (P1545), start time (P580) etc. should be evaluated!

--Marsupium (talk) 11:36, 20 June 2018 (UTC)

On quality

Wikidata is growing fast. That's great. The database it is it can't be without errors. Quality has to be traded off against quantity. IMHO less quantity and more quality would be preferable. I'd like to respond to Wikipedias of which many are sceptical about Wikidata's quality and its usefulness for them that their doubts are unfounded. I'm afraid that they are not.

There are manual editors' errors, and errors by scripts and bots, all lowering quality. I spend much of my time here with the correction of bot errors. Many of them are evitable, many even easily. I think higher standards for bots and their requests could help:

• Bots shouldn't get a flag for some task and afterwards use them for many others.
• Bots shouldn't continue with new additions if they've done harmful ones that are not yet corrected.
• Bots running with code that is not public should be a well-founded exception. It should be demanded that bot code is open source.

Rules can help with this. A culture of more effort to reduce bot errors is nicer. I appreciate all the work bot operators put into their contributions and I'd like to encourage everyone to take care, improve code, point out errors and help to eliminate them! --Marsupium (talk) 09:53, 15 August 2017 (UTC)

Collaboration on the Physical Objects Class Tree

Concerned with the progress of the Wikidata:WikiProject Visual arts I try to improve the interoperability of Wikidata with commons:Template:Artwork which was – if I remember correctly – more than 500.000 times transcluded (when [1] still showed this information). This occupation includes the mapping of commons:Template:I18n/objects to a physical object class tree on Wikidata with the help of the Art & Architecture Thesaurus (Q611299). In doing so I often enter the field of other disciplines and in the same time issues with the different language versions of Wikipedia. A great and perhaps the only possibility to create high value data will be the collaboration of projects with different domains and from different languages. The projects at WikiProject Archaeology (Q10801979) and Portal:Archaeology (Q7076022) or even de:Wikipedia:Wikidata trifft Archäologie 2013 might be those which can help the Wikidata:WikiProject Visual arts to determine if arrowhead (Q1643900) shall be a subclass of (P279) projectile point (Q2308299), and the projects at Portal:Fashion (Q13341443) might be able to help to distinguish the forms of headgear (Q14952) which caused me some trouble some weeks ago. --Marsupium (talk) 01:19, 19 April 2014 (UTC)

Some Critique of Iconclass

WARNING: This section was written some time ago. I'm afraid it contains errors I still plan to do some research on. If you think anything is not correct, I'm happy if you edit it or perhaps leave a remark. --Marsupium (talk) 09:53, 15 August 2017 (UTC)

• A – depending on the use – more or less big issue with Iconclass (Q1502787) is that it is only formalised partially. (Maybe apart from some recurring annexes) Iconclass is a monohierarchical classification. Between the time Iconclass “took shape in the early 1950s“ and its digital publication this probably did not really matter. A multihierarchical classification published in the after all mostly linear form of books would be hard to use anyway. However, at the latest now when the classification is yet published as Linked Open Data this is a problem which reduces the value of Iconclass for Wikidata heavily. The problem gets evident through a passage of an official guide to Iconclass:

  ”This richness is not due to the fact that Iconclass linguistically differentiates between meanings of the word "praying". It is simply because Iconclass contains concepts that may be represented in various ways, like "public prayer" and "private prayer", but also concepts we can use to describe the visualization of prayer, like "hands folded"; and of course, many scenes of prayer from the bible, classical history and classical mythology. So, there is a fundamental difference between the word we use as a search term and the various concepts or groups of concepts that are linked to that word. This difference can be summarized in one word: context. Of course, the word "praying" has its own semantic richness, but that will never match the historical, thematic and narrative contexts which the Iconclass browser unfolds for us.“

• Classification: The classification is shaped by the formerly paper form of Iconclass. Unfortunately the classification is monohierarchical what is an annoying limitation. Moreover the number of subclasses in a level is quite arbitrarily limited due to the use of a digit for the first two levels, a letter for the third, and again digits for the further levels.
• Nonsense and redundancy of the classification: In consequence of the bad formalisation Iconclass lists redundant and nonsense notations and both together, there are "11F(+2) the Virgin Mary (+ Mary)" and "11F7(+2) specific aspects ~ Madonna-representations (N.B. secondary notations only) (+ Mary)".
• Formalisation: Another point where missing formalisation becomes evident are the so called "Structural Digits" that should better be expressed explicitly.
• Controlled vocabulary: Iconclass is a controlled vocabulary. This brings the advantage with it that no unexpected values appear. With semantic web technologies open systems that are still well formalised have become possible. Especially considering the structurally necessary incompleteness of Iconclass regarding non-European art for example open systems could probably facilitate more expressive powers.
• The system of labeling main and additional minor parts of an image might be improvable by expressing the precise relationship between these parts in a formalised manner.
• Nonsense and redundancy of the classification: In consequence of the bad formalisation Iconclass lists redundant and nonsense notations and both together, there are "11F(+2) the Virgin Mary (+ Mary)" and "11F7(+2) specific aspects ~ Madonna-representations (N.B. secondary notations only) (+ Mary)".
• Formalisation: Another point where missing formalisation becomes evident are the so called "Structural Digits" that should better be expressed explicitly.
• Controlled vocabulary: Iconclass is a controlled vocabulary. This brings the advantage with it that no unexpected values appear. With semantic web technologies open systems that are still well formalised have become possible. Especially considering the structurally necessary incompleteness of Iconclass regarding non-European art for example open systems could probably facilitate more expressive powers.
• The system of labeling main and additional minor parts of an image might be improvable by expressing the precise relationship between these parts in a formalised manner.
• More: Comments like in http://www.iconclass.org/rkd/46C11/ ("Comments: Jan. 6, 2011, 1:33 p.m. Hans Brandhorst says: 46C119 manoeuvering, navigating We don't have the concept for traffic on land as we do have for travel on water. Seems useful to have it: "coachman" could be: 46C1191...") may indicate more problems.

--Marsupium (talk), before 23:23, 20 July 2014 (UTC), 23:18, 10 September 2017 (UTC)

PS: Now the Getty Vocabulary Program provides the Getty Iconography Authority looking aspiring after at first glimpse. See Guidelines (2017-09-01 as of 2017-09-26), Slides by Patricia Harpring, revised June 2016, CONA and the Iconography Authority: Linking and Relationships Are Unique. International Terminology Working Group Meeting, 23 August 2016, Patricia Harpring (similar content). --Marsupium (talk) 14:49, 26 September 2017 (UTC)

PPS: It seems not to be intended that some "structural digits" after a bracket cannot be given without a definite content of the bracket, the need for this can be seen in Madonna with Canon Joris van der Paele (Q2480921)depicts Iconclass notation (P1257)61B2(...)12 from https://rkd.nl/en/explore/images/2149. --Marsupium (talk) 16:59, 21 January 2019 (UTC)

Property proposals

• off topic: interesting discussion about sources Wikidata:Project chat/Archive/2017/10#Redundant Wikipedia citations

• Sandrart.net artwork ID (P4380)  Done (proposed 2017-10-05, created 2017-10-16)
• AKL Online artist ID (P4432)  Done (proposed 2017-10-06, created 2017-10-28)
• archINFORM project ID (P5383)  Done (proposed 2018-06-19, created 2018-06-27)
• Getty Iconography Authority ID (P5986)  Done (proposed 2018-10-10, created 2018-10-23)
• Incunabula Short Title Catalogue ID (P6494)  Done (proposed 2019-02-06, created 2019-02-13)
• folio(s) (P7416)  Done (proposed by Jura1 2019-10-05, created 2019-10-13), cf. also c:Template:Folio
• room number (P7532)  Done (proposed by Gittenburg 2019-11-02, created 2019-11-09), cf. osmwiki:Key:ref; corresponds to (superclass of (doc says only number)) |1= of c:Template:Room: is sometimes script-dependent (e.g. Baituna al-Tahami Museum): then only use at the room item with writing system (P282) qualifier.
• SMB-digital ID (P8923)  Done (proposed 2020-10-18, created 2020-12-06)
• WBIS ID (P8081)  Done (proposed by Wetzdata 2020-03-11, created 2020-04-06), see former discussions on User talk:Magnus Manske and perhaps do: better then much other stuff we have! (03:58, 14 August 2018 (UTC)) WBIS: no! it's about documents. and it's good to find sources, but not really as a source itself
• ArchDaily architecture office ID (P12364)  Done (proposed by DoublePendulumAttractor 2024-01-12)
• Archnet authority ID (P12728)  Done (proposed 2024-05-13, created 2024-05-21)
• Global Egyptian Museum ID (P12732)  Done (proposed 2024-05-13, created 2024-05-21)
• Historic Synagogues of Europe ID (P12733)  Done (proposed 2024-05-13, created 2024-05-21)
• CamerounWeb person ID (proposed 2024-11-13)
• Arabic name classes probably should use specific properties, namely nasab (Q3870467), laqab (Q3827032) (use nickname (P1449)?), nisba (Q1054545). See also kunya (P8927). Maybe discuss before proposing at WT:WikiProject Names {{Ping WikiProject|Names}}

• logic:
  • "statement reference" qualifier (can be omitted for formulas with only one operator type), probably numbered values "1", "2" etc.
  • "statements logics"/"statements relations"(?): as qualifier somewhere? (in the formula the referral statement could be represented by e.g. "THIS" (stupid idea?)) easy to complex formulas like simple "AND" (could be added as a qualifier to several) to "((2 XOR 4) AND 3) OR (1 AND NOT 5)" (how many operators shall be accepted?): not well formalized, but I don't see an alternative; TODO: find good examples and further consider with them (a less powerful alternative would be qualifiers "or" and "and", but really not expressive, error-prone and bad with information in qualifiers, so: no!)
• museum etc. place identifiers (because new items are stressful, and currently probably partly less structured ("followed by" should be used more (also by me); and "shares border with")):
  • "showcase reference": see above; some differentiation for room specific vitrine references?
  • "department": a department property with item datatype instead of the current method with special solution for the Louvre and others at Commons??? see 2018-12-19's Wikidata:Property proposal/organizational unit
• "patrocinium": use patron saint (P417) use dedicated to (P825)? see Property talk:P825#Religious buildings! source e.g. "Patrozinium" in the Klosterdatenbank (LD)
• "AdBK München Matrikelnummer";
  http://matrikel.adbk.de/;
  digitale Edition der Matrikelbücher der Akademie der Bildenden Künste München;
  über 14.000 Stammdaten (http://matrikel.adbk.de/edition);
  Studierenden der Akademie der Bildenden Künste München in den Jahren 1809 bis 1935;
  GND IDs teils angegeben;
  URLs are difficult, containing years: 05317 Heinrich Mielenz, Matrikelbuch 1884-1920: http://matrikel.adbk.de/matrikel/mb_1884-1920/jahr_1913/matrikel-05317;
  here one in GND: http://d-nb.info/gnd/1077828012; the numbers are issued several times, see e.g. https://matrikel.adbk.de/suche/#b_start=0&c13=02879 -> another solution than a simple "Matrikelnummer" property is needed! One for each of the five books? also not so cool …; see also mixnmatch:3604
• "stated in official website of" (we often don't and also do not want to a have a separate item for the website I assume?) – Probably this can be simply solved by using "publisher" (or a similar property)?? (also: how to crosscheck with "official website"?) (03:58, 14 August 2018 (UTC))
• "signature statement", cf. https://collation.folger.edu/2016/05/signature-statements/, see also https://collation.folger.edu/2016/05/physical-description-book-cataloging/ for some input for number of pages (P1104)
• IDs for https://ome.dehio.org/de/start
• "baukunst-nrw ID", Baukunst-nrw (Q811434), 2414 objects as of 2023-11-06