Wikidata

Wikidata:Properties for deletion/Joconde

< Wikidata:Properties for deletion

Joconde IDs

edit

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus is to keep these properties — Martin (MSGJ · talk) 21:35, 15 February 2022 (UTC)[reply]

I propose to merge these properties to one single property for consistency. See User_talk:Vladimir_Alexiev/Archive_1#Joconde_IDs.--GZWDer (talk) 06:37, 4 April 2020 (UTC)[reply]

  Delete That's fine with me. But you should maybe propose a new property for this first, or pick one of them to be the main one? ArthurPSmith (talk) 17:32, 6 April 2020 (UTC)[reply]
I rescind my vote here given the discussion below - if there are cases where the same item would have identifiers from more than one of these properties, then keeping them separate seems the better choice. I really don't have a strong opinion on this either way though. ArthurPSmith (talk) 13:24, 8 April 2020 (UTC)[reply]
  Keep Those properties link to different and specific vocabularies. For reuse, we need this differentiation. For example on Nicolas Poussin (Q41554) with the value of Joconde author ID (P7711) we can make a link trough the structured data on data.culture.fr to make enable a specific search to the POP results on Jocond Artist field. --Shonagon (talk) 11:39, 7 April 2020 (UTC)[reply]
  Keep If we merge the Joconde properties it may lead to confusion between similar terms used in different vocabularies and lose their original meaning. For example Domaine : Afrique du Nord http://data.culture.fr/thesaurus/page/ark:/67717/T51-112 and Lieux : Afrique du Nord http://data.culture.fr/thesaurus/page/ark:/67717/T84-2. --Christelle Molinié (talk) 16:06, 7 April 2020 (UTC)[reply]
As Joconde is a French website:
  Notified participants of WikiProject France --Liuxinyu970226 (talk) 01:23, 8 April 2020 (UTC)[reply]
  •   Keep: same as for Shonagon. Nomen ad hoc (talk) 06:56, 8 April 2020 (UTC).[reply]
  •   Neutral both cases (unique property or separate properties) have advantages. For the records, there was a unique property P3905 (P3905) (created in 2017, Wikidata:Property proposal/Ginco id) but it has been deleted (in 2018) and split into these separate properties. I'm not keen to go back to the previous situation without a good reason. That said, to answer @ArthurPSmith: question, if we go back so a single property, the best would be to undelete P3905 (P3905). Cdlt, VIGNERON (talk) 08:13, 8 April 2020 (UTC)[reply]
  •   Keep Per Shonagon, Christelle Molinié and VIGNERON. There are edge cases that would be too far and wide to solve easily, seeing as some items can fall into two (or more ? ) categories, depending on the axis you want to reach them from, and it is actually sometimes interesting to search all items by one axis, which merging all properties would make a bit more complicated. As an aside, unlike what was said on Vladimir Alexiev's talk page, they aren't "UUIDs" as they're not 128-bit integers (even assuming the letters to be 8-bit) : unique identifiers aren't necessarily UUIDs… Alphos (talk) 09:14, 8 April 2020 (UTC)[reply]
  • I suggest you synthesis and maybe a unanimous exit will see the light of day. Above all, tell me if I write bullshit!
    1. I think ArthurPSmith votes {{Vd}} because he sees that it is technically possible. The identifiers of each property will always be linked to a part of http://data.culture.fr/, but in a different way (url_prefix) and will always point to the right page (for each property). I think he has in mind the example of IMDb ID (P345): IDs present for each part (tt, nm, etc.), but linked by a single property. But he expressed the reservation that a proposal be made. (Maybe he's even waiting for a "Pull request" for index.php ?)
    2. So the opinions of @Shonagon, Christelle Molinié, Alphos: can be guaranteed, whether it is Author, Location or Domain, and whether it is UUid or not.
    3. For P3905 (P3905) from VIGNERON, the return of this property should not be useful, but when I see that sword (Q12791) has not been carried over to Thésaurus de la désignation des objets mobiliers ID (P4979), it would be useful to recover the old forgotten IDs.
    4. According to the problems formulated above, single-value constraint (Q19474404) and distinct-values constraint (Q21502410) will no longer be used in the future Property and indicated in the proposal. Only the complexity of RegEx will allow proper use.
    5. For RegEx, I recommend a separation of a term designating one of the old Property by : and the IDs themselves. The old RegEx will be taken over to form the new RegEx. So the future Regex will have the following form: (thesaurus:(T69-[1-9]\d{0,6}|T96-[1-9]\d{0,6})|author:(T513-[1-9]\d{0,4}|[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12})|domain:(T51-[1-9]\d{0,2}|[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12})|epoch:[1-9]\d{0,5}|etc. I don't know how long a RegEx can take on WD. Current Ids will take a prefix: thesaurus, author, domain, epoch, etc. Example of ID provided by Shonagon: Nicolas Poussin (Q41554) → author:T513-25084. syntax clarification (P2916) should be used to refer contributors.
    6. Before deletion, the old IDs should be taken back. They are 363. This is why I agree with   Delete: some current properties have less than 10 entries. Maybe an Open Refine would take the IDs (fetch URL?). I would also like a proposal before deletion. Warmest regards —Eihel (talk) 12:30, 8 April 2020 (UTC)[reply]
  •   Neutral —Eihel (talk) 01:31, 19 February 2021 (UTC)[reply]
  • My first idea (before discussion with Vladimir Alexiev and this proposal) is to create a new property "Joconde UUID" and rename all other properties to "Joconde legacy xxx ID".--GZWDer (talk) 12:59, 8 April 2020 (UTC)[reply]
@Eihel: I'm sure I understand your position. You say « the return of this property should not be useful » and then « I agree with {{Vd}} », but deletion of the separate properties is exactly the same as return to P3905 (P3905).
Plus, the analogy with IMDb ID (P345) is only partially relevant as each part is separate and disjoint (it's tt or - exclusive or - nm, which make it easier to manage and maintain) while here there is a lot of overlap between the thesauri (it's T69- and T96- for example) which may cause some trouble (including but not limited to the "single value" constraint as you pointed out; the "unique distinct value" constraint is still true though).
Cheers, VIGNERON (talk) 13:45, 8 April 2020 (UTC)[reply]
@Eihel: Yes that could have been a solution except that unfortunately the prefix is not reliable. It is a remnant of an old system for ancient entries. All new entries use UUID and are intentionally opaque. Example of artist Joconde with UUID: MASCAUX Claude Léon. Best regards --Shonagon (talk) 14:33, 8 April 2020 (UTC)[reply]
  • I have another point for deletion: there seems to be much more thesauri than Wikidata properties we have. Creating an property for each of them does not seems scalable.--GZWDer (talk) 13:48, 8 April 2020 (UTC)[reply]
@GZWDer: These vocabularies are all those of the Joconde database and are particularly important in France, used for hundreds of museum collections. Best regards --Shonagon (talk) 14:33, 8 April 2020 (UTC)[reply]
  •   Comment This thus look rather un-coodinated. We also seem to have more properties than some of those properties have actual uses. How many more properties should there be created? --- Jura 08:13, 10 April 2020 (UTC)[reply]
  •   Keep See https://www.wikidata.org/wiki/Property_talk:P7844: @Christelle Molinié, Shonagon: had a phone call a few days ago with colleagues at the french Ministry of Culture. (@DannyS712, ArthurPSmith, 99of9, Nikola Tulechki, Crowjane7, GZWDer:). They said they'll keep separate thesauri, are very interested in linking to WD, and are working to link the thesauri to POP (the FR aggregation of artworks). I completely agree with Christelle that we have to respect the wish/organization of the thesaurus provider, despite some messiness in their organization. What we need to do is below. I hope culture.fr people, @Christelle Molinié, Shonagon: can help with the last 3 bullets (the last 2 are the big-effort part) --Vladimir Alexiev (talk) 10:28, 23 April 2020 (UTC)[reply]
    • Relax regexes to just [\w-]+
    • Edit formatterURL to remove T69- (and the like)
    • Migrate existing values to put T69- (and the like) inside the value
    • Create a central page to describe all FR thesauri, with description, links to home page and prop, MnM catalog. A good place is a sub-page of Wikidata:WikiProject Visual arts
    • Import more of the thesauri to Mix-n-Match catalogs so they can be coreferenced
    • (when there is interest) Create more props and catalogs for more thesauri
Yes I see a point for doing so. I withdrew the deletion request but this should not be closed yet until others agree Vladimir Alexiev's proposal.--GZWDer (talk) 12:15, 23 April 2020 (UTC)[reply]
Vladimir Alexiev's proposal sounds fine to me. ArthurPSmith (talk) 20:44, 30 April 2020 (UTC)[reply]
OTH, the format seems to be either "<database id><old id>" or "<uuid>" .. --- Jura 08:03, 2 May 2020 (UTC)[reply]

@Alphos, @ArthurPSmith, @Christelle Molinié, @Eihel, @GZWDer, @Jura, @Liuxinyu970226, @Nomen ad hoc, @VIGNERON, @Vladimir Alexiev
Hello,
Following the various suggestions:

IMHO, creating more props for more thesauri is a challenge depending on the interest of the thesaurus and the implication of wikidata editors. For information there is a script on Github that can help to convert a data.culture vocabulary (in RDF/XML syntax) to a CSV file for Mix'n'Match, using the SKOS poperties (altLabel, broader, narrower) for description.
Best regards --Shonagon (talk) 11:43, 12 May 2020 (UTC)[reply]

Thanks @Shonagon: that's great!

Hi @Vladimir Alexiev: I've started the translation here but haven't finished yet. Maybe a lot of things to correct...--Christelle Molinié (talk) 10:15, 27 May 2020 (UTC)[reply]
  Keep Okay, per Vladimir Alexiev, I don't think that deprecating it is good for us. --Liuxinyu970226 (talk) 22:41, 3 June 2020 (UTC)[reply]

  Delete How do I add http://data.culture.fr/thesaurus/page/ark:/67717/T1-1187 to telephone (Q11035)? There does not seem to be an applicable Joconde (Q809825) vocabulary property here even though these are now all managed under the same GINCO ("Gestion Informatisée de Nomenclatures Collaboratives et Ouvertes") software at the Ministry of Culture (Q384602). Also newer terms have UUID identifiers that do not specify a specific vocabulary. This and the fact that they all currently have the same valued for ARK formatter (P8054) and formatter URL (P1630) makes me think these various properties ought to be merged. If we are to keep the separate Joconde (Q809825) properties they should be restricted to the appropriate Archival Resource Key (Q2860403) subspace instead of attempting to share the same. Some method should be devised to support the newer UUID identifiers too. Thanks. 50.53.22.81 02:06, 13 September 2020 (UTC)[reply]

You cannot currently add it because "Thésaurus-matières pour l'indexation des archives locales" is not made into a WD property. Given that we now have many culture.fr people involved in this effort on WD, i think we should leave it up to them to decide which culture.fr thesauri are worth exposing on WD. --Vladimir Alexiev (talk) 11:38, 24 November 2021 (UTC)[reply]
@Christelle Molinié, Shonagon: Can't you take them under your wing as well? They have MnM catalogs, and the same problem (format regexes need to be changed, and the values migrated to include T69-, respectively T96- ). Please include them in your pages, thanks!! --Vladimir Alexiev (talk) 12:10, 27 November 2021 (UTC)[reply]
Hello @Vladimir Alexiev and @Shonagon I've just created a global page for the vocabularies of the french ministry of culture which includes the Joconde project. I hope that will be more understandable. Christelle Molinié (talk) 11:14, 4 December 2021 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Properties_for_deletion/Joconde&oldid=1577927509"