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.
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.
No consensus. There is consensus that the distinction between first-party and third-party links is not useful. However there is not a consensus to delete this property shown in this discussion! As the discussion has been open since 2020 I am closing it now. If there is a clear plan for this property in future, then please start a new request — Martin (MSGJ · talk) 12:06, 13 May 2022 (UTC)
Merge with formatter URL (P1630). The distinction between first-party and third-party URLs is rather arbitrary. And because Wikidata.org only creates external links for P1630 and not for P3303, third-party URLs are often placed in P1630 if no first-party URL exists (e.g. autonomous system number (P3797), Minecraft UUID (P8727)). We can use ranks to define the best URL(s), and use nature of statement (P5102) to mark URLs as 'official' or 'unofficial' if need be, but having two separate properties just seems unnecessary. —IagoQnsi (talk) 17:04, 23 October 2020 (UTC)
@IagoQnsi: Maybe the name should be modified, but I don't see the purpose of having multiple P1630's on a property. The Wikibase UI will only use one of them, and I'm not sure it currently correctly selects the preferred one (there's a delay in any case, so it's complex to check). The advantage of a separate P3303 is that it makes clear that the entity making use of it needs to do the formatting themselves, the Wikibase UI won't help. Merging with P1630 will confuse that. ArthurPSmith (talk) 22:26, 24 October 2020 (UTC)
Keep It is important to distinguish primary 'official' formatter and the third party formatters. But it would be nice to have a tool/gadget to display external links also from third-party formatters.--Jklamo (talk) 10:40, 27 October 2020 (UTC)
Delete We don't have a rule that formatter URL (P1630) can only be filled with official formatter urls. If we want to store information about some formatter urls being official we can do that better explicitely via qualifiers. In addition we can use the preferred rank to chose the formatter url that's used by default. ChristianKl ❪✉❫ 23:30, 1 December 2020 (UTC)
I thought deprecation is needed to avoid that a former P1630 value is being used, that is: one can't add a new value with preferred rank to have these selected (as we usually do). --- Jura19:42, 2 December 2020 (UTC)
FYI I added a preferred formatter URL a couple of days ago to Mapy.cz ID (P8988) and it DOES seem to have replaced the original one in the UI (after a few days to let it propagate). We might want to test some more, but it looks like maybe this issue is actually ok now. ArthurPSmith (talk) 19:06, 1 January 2021 (UTC)
I feel like there is something important missing in this discussion. There are multiple use cases at play: 1. The built-in functionality of linkifying the property value. 2. Secondary links to various more- or less- related websites/tools using the same identifier. I completely agree the current official distinction between #1 and #2 (#1 is “first-party/official”, #2 is “third-party/unofficial”) is wrong (and that distinction is not even important or interesting) and does not match the current usage. What we need is one linkifying URL template (OK, we could use the preferred rank for that), plus a potentially unbounded set of URL templates with an agreed-upon way to indicate where that URL leads. I mean, nature of statement (P5102)unofficial (Q29509080) is nice but in fact, I don’t really care. What I’d like to have is a drop-down menu next to each ISBN statement, showing me the links to various online book databases, libraries, e-shops, whatever (now, for the specific case of ISBNs, we outsourced this job to Special:Booksources which is the “official formatter” for ISBNs… funny, right?). Ditto for DOIs, OIDs, MeSH codes, … So, sure, we might merge P1630 and P3303 and use the rank to mark the primary linkifier. But I think it is not the greatest priority. For now, I’d say Keep and rename both to indicate the distinction is not first-party/third-party, but auto-linkifier/additional links (cf. ArthurPSmith above). Then, let’s use operator (P137) (or anything else) for each of these additional URLs, and then let’s build a gadget (or Wikibase core functionality) to use the data in the property. That would be useful. --Mormegil (talk) 13:24, 18 December 2020 (UTC)
It seems to me EE works “inversely” in a sense, doesn’t it? I.e. on any page on Internet, it displayes whether it matches any formatter of any Wikidata property. On the other hand, my gadget displays next to every external-id property on a Wikidata item page links to all corresponding formatter URLs. I added a screenshot. → --Mormegil (talk) 15:19, 18 February 2021 (UTC)
Demonstration of Entity Explosion when used from a Wikidata item
@Mormegil: It also works from WD items, and it does show multiple outlinks (e.g. to Twitter/Keybase/Scholia/Unavatar) if it rates them high enough (usually when they have a operator (P137) or a matching language). See this screenshot. I haven't advertised this feature much - perhaps I should! --99of9 (talk) 06:11, 19 February 2021 (UTC)
Placeholder Keep for now. I use this as part of the decision making in Entity Explosion, so have a preference for not doing extra work if there is a way of reconceiving of the difference between these two properties. --99of9 (talk) 01:13, 21 February 2021 (UTC)
Delete As others have pointed out, this property can be replaced with a qualifier at no loss of functionality, and probably should. Infrastruktur (talk) 23:10, 28 April 2022 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
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.
It's the same item but specified with two different ways, string and number. The numeric ID redirects to the string one, however I was unable to find the numeric ID on the specified website. I suggest to delete the Property:P8152 (only after a migration to the string property). --DnaX (talk) 09:30, 23 February 2021 (UTC)
I think that a numeric ID is more stable than a string ID, although it is not human-readable. I suggest to delete the other one and leave P8152 as main property. One can use P554 or something similar to indicate the string ID --★ → Airon 9007:31, 24 February 2021 (UTC)
Why not keep both, and use one as a qualifier on the other? Then people can match their data to our items, no matter which of the two identifiers they have got. Jheald (talk) 13:15, 7 March 2021 (UTC)
I see points for keeping both of them: one is easier to retrieve but not very "identifying" (for example, it is not clear how two persons with same name would be treated), the other one is a classic identifier but more difficult to retrieve. --Horcrux (talk) 14:09, 1 April 2021 (UTC)
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.
On balance the request to delete is weakly supported. Deletion will be delayed by 30 days in case anyone wants to use the data in any way — Martin (MSGJ · talk) 12:14, 13 May 2022 (UTC)
In short, the database has been replaced [1] and the new database does not use the old identifiers. Not only do our identifiers now link to the Wayback Machine but, because the database was not really functional for long (few months?), the archived pages do not show anything. --SCIdude (talk) 14:47, 29 March 2021 (UTC)
I was tending to agree with deletion on the basis of the Internet Archive and Trove neither having any saved pages from the old online database using the IDs of AICS Chemical ID (BEING DELETED) (P7049). Additionally the example links of [2], [3] and [4] are not saved correctly by the Internet Archive, which seems to think all these example IDs match up with a single chemical in the database. Then I stumbled across [5], which indicates at least some pages were being saved by the Internet Archive correctly up to 2 years prior to AICS Chemical ID (BEING DELETED) (P7049) existing in Wikidata. This property is used over 16,000 times on Wikidata items and who knows how many of these uses does result in an archived page off the old NICNAS inventory website. Given the lack of archiving observed and seemingly invalid archived pages when Internet Archive did make an attempt, I'm tending to Weak support the deletion of AICS Chemical ID (BEING DELETED) (P7049) instead of the usual case of leaving AICS Chemical ID (BEING DELETED) (P7049) in a deprecated state (for the purpose of Internet Archive etc linking). Mix'n'Match seems to contain the full catalogue of previous IDs but what is the point if there is no copy of the original page available? --Dhx1 (talk) 13:28, 30 March 2021 (UTC)
I updated the label, but given the number of uses and the importance of the database, I'm not really convinced by the deletion proposal. If the identifier was used elsewhere than on the website, I think that should be kept. If it wasn't used elsewhere, somehow our description of the identifier has a problem. @99of9: who worked on this mostly. --- Jura21:19, 30 March 2021 (UTC)
Grrrr... I hate when databases do this. I'm accepting of my wasted efforts, but can't quite bring myself to vote for deletion! MnM will still be there in the unlikely event that we want to restore the data. --99of9 (talk) 21:44, 30 March 2021 (UTC)
It looks to me that the reason the Wayback Machine only has a fraction of the pages is because they were only online for a few months, not because the links were defect. What does that tell about the creator's intention or the database's quality? Do we really need to keep something alive that had not much time to mature? --SCIdude (talk) 12:59, 1 April 2021 (UTC)
It seems the database has been around for years. Is it in web.archive.org.au (or is that the same)? --- Jura14:20, 1 April 2021 (UTC)
I wasn't going to bother creating a new property proposal for the new database https://www.industrialchemicals.gov.au/search-inventory because it seems it could be a waste of time again. The only use it'd theoretically be is determining whether a chemical can be manufactured or imported into Australia. For example, Chlorinated Biphenyls are listed as a restricted class of chemicals at present, but an Internet Archive copy from April 2021 states no restriction. According to [6] and [7], polychlorinated biphenyl (Q211171) substances have been banned from manufacture and import in Australia since the 1970s so this new website in April 2021 appears to have been wrong in a fairly significant way. The database doesn't provide useful information such as the date a chemical was listed as being able to be manufactured and/or imported, or the date it was restricted or banned. As another example, DDT (Q163648) isn't listed at all (which would be expected), meaning it is most likely banned from manufacture or import. However, more generally, there is no way of knowing for sure what the meaning of a missing chemical is as the register also contains "secret chemicals" that manufacturers or importers may want to hide knowledge of from competitors. --Dhx1 (talk) 15:56, 14 October 2021 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
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.
In combination with the soon to be available replace property it surely is. Maybe "rarely" described it better than "hardly". --- Jura15:31, 29 September 2021 (UTC)
I can confirm that the links to the PDFs still work and that I can add additional ones to items. Although the PDFs are no longer linked from the site, a simple Google search of the species name plus "PDF" brings them up at the top of the search results. UWashPrincipalCataloger (talk) 19:50, 28 September 2021 (UTC)
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.
Comment This is part of a series of properties for Roman nomen: Roman praenomen (P2358), Roman nomen gentilicium (P2359), Roman cognomen (P2365), Roman agnomen (P2366). Obviously, not all are used with equal frequency and they could all be seen as subproperties of a "Roman name part" property. Depending on the use, one can query one or several of these properties. That they are generally single valued allows to determine easily if they are present or not (or if others are missing, e.g. cognomen is present, but not praenomen). The question is if P2366 would misidentify names as agnomen or not. That the property could have the alias "additional Cognomina" or "Roman name part 4* doesn't require it to be merged with the other properties. As mentioned, one can query one or several properties together. That terminology varies isn't really a reason not to use any of it. --- Jura13:15, 8 January 2022 (UTC)
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.
KeepStrong oppose see the discussion Total mess! for all explanations refuting Vladimir Alexiev hypothesis. In a nutshell: there is a proper definition, this is not exactly equivalent to a list (so has list (P2354) is not a replacement) and not all have individual IDs, there is some "mess" (an exagerated and unneededly aggressive word) but it can be fixed, this is not a reason for deletion. Also pinging @Fierodelveneto: who built the Infobox de Bało and @Vladimir Alexiev: the local village pump can very very easily be found on Project:Village pump (Q16503). Cheers, VIGNERON (talk) 09:09, 9 January 2022 (UTC)
The definition is "status of an item that is designated as intangible heritage" but the values (see query https://w.wiki/4dAz) don't conform to it, eg:
Inventory of intangible cultural heritage in France
Intangible Cultural Heritage of Indonesia
intangible cultural heritage
Beijing Municipal Intangible Cultural Heritage
Please tell me what is the common theme between all these items.
"Inventory of intangible cultural heritage in France" says "instance of: list"
"intangible cultural heritage" is surely not designated by any institution, it's a class of all ICH
"Intangible Cultural Heritage of Indonesia" says "status awarded by the Indonesian Ministry of Education and Culture" but then the name should be "Designated Intangible Cultural Heritage of Indonesia" (because there may be extra ICH in Indonesia that are not designated)
The current prop "designated status" has a mix of values that include lists of designated and non-designated items
So let me ask again, how is that "not exactly equivalent to a list"
It makes more sense to have a property "designated by"
Keep When data is a mess we clean it. This proprerty is incompatible with heritage designation (P1435) so we can't merge it. If the goal is to broaden the name of the property, why proposing it to deletion? It's a waist of time. --Fralambert (talk) 13:49, 9 January 2022 (UTC)
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.
@Facenapalm: Comment. Unfortunately, ag.ru and RAWG are not quite the same databases. Yes, ag.ru uses the same API and interface as RAWG, but the new version of Absolute Games is different in that it has editorial reviews from the old version ([8], [9]), while RAWG does not ([10]).
I'm not sure about the old database either, because if the new one has reviews from the old version, then it makes no sense to create a new property. As for removing this particular property, I'm not sure if it's worth it as we can still use it as the old database by changing the formatter URL. By the way, maybe we should also ask the members of the respective project on ruwiki what they think of it, and which of these versions is preferable, the old one or the new one?
If we conclude that we don't need the new version, then we can delete it or rename Absolute Games ID to Absolute Games ID (old version)/Old.ag.ru ID and use RAWG database for the new games only. Regards Kirilloparma (talk) 19:04, 25 January 2022 (UTC)
@Kirilloparma: looks like there are only 5217 AG.ru reviews, while RAWG have over 625k games in database. If we'll keep P8279, there would be 620k pairs of identical links. I think deleting P8279 and creating property for old.ag.ru is more optimal solution. If we're considering those reviews important. Facenapalm (talk) 21:22, 25 January 2022 (UTC)
@Kirilloparma, I'm not sure if it's okay to change a property midway like that. And I'm also not sure wherther those reviews are important (we usually don't keep track of other review sources, like Polygon or PCGamesN, only databases with useful information). If you're sure it's okay, I don't mind. As I said before, keeping one property for RAWG and one property for old AG sounds reasonable for me. Facenapalm (talk) 00:20, 26 January 2022 (UTC)
@Kirilloparma, I'd probably reorganize it into RAWG.io property as well. As far as I see, some descriptions are translated to Russian (Gabe Newell: [11][12]), but most of them are completely identical (Jesper Kyd: [13][14]), no point in linking both.
Moreover, AG and RAWG IDs are identical as well, right? We usually keep only one property in that case as far as I'm concerned. For instance, we don't have a separate property for GameRankings because it's the same to GameFAQs. And we also don't have a property for SteamDB because it uses application ID from Steam. Please correct me if I'm wrong. Facenapalm (talk) 14:54, 26 January 2022 (UTC)
Yes please, do the merge. There is consensus for that part. I think perhaps the identifier for old.ag.ru should go through a new property proposal, if anyone thinks that would be worthwhile — Martin (MSGJ · talk) 11:46, 13 May 2022 (UTC)
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.
This is a duplicate of the older property Marine Regions Geographic ID (P3006). I have manually migrated all items that referenced P7322 to now reference P3006. In addition, I have migrated the updated formatter URL and URL match pattern properties for P3006 to match P7322 and ranked these as preferred. The only thing missing are the per-language labels, descriptions, and akas which have a uniqueness constraint. This property could either be merged or deprecated —Ozmorph (talk) 03:42, 17 April 2022 (UTC)
Delete How'd we miss that duplication? I guess proposers and reviewers should try a bit harder to spot this sort of thing?! ArthurPSmith (talk) 15:19, 18 April 2022 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
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.
Keep seems to be reasonably used and the change of hosting service shouldn't affect the ids. --- Jura11:17, 6 July 2021 (UTC)
Comment @Trade: Are they the same data/target or different. If they are separate sites still and not an exact duplication then I see no issue with both existing. If they are exact duplicates then we should look to migrate/merge. — billinghurstsDrewth12:13, 19 July 2021 (UTC)
migrate and Delete. We should keep our list of properties clean; many people already complain that Wikidata is difficult to query. Imagine now that, for example, 1/3 of the links to fandom.com is added as "Gamepedia ID", 1/3 is added as "Fandom ID", 1/3 is just added twice (maybe with different qualifiers) - it is a nightmare. --Lockal (talk) 08:25, 24 August 2021 (UTC)
Comment Please be careful when migrating, some Fandom sites existed with the same name as Gamepedia sites. Some of these Fandom sites were suffixed with "-archive" and locked, like minecraft -> minecraft-archive. AntisocialRyan (Talk) 01:08, 5 May 2022 (UTC)
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.
No matter which link you open, you get the message: "The page you were looking for does not exist." The error has been occurring for at least 6 weeks. HarryNº2 (talk) 18:48, 12 October 2021 (UTC)
Then all entries pointing to Property:P6150 must refer to archive.org via bot. Or another replacement has to be found. The user expects to find an entry and instead receives a 404 message. --HarryNº2 (talk) 23:14, 14 October 2021 (UTC)
For some reason it was necessary to mark the new formatter as preferred. I did this and the links appeared, but I can't test them properly yet — Martin (MSGJ · talk) 12:32, 14 February 2022 (UTC)
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.
There is no consensus to delete this property based on this discussion. However it is clear that a sizeable proportion of the Wikidata community feel that taxons are classes, and that these properties should be replaced by P31/P279. As this would be a major change and affects more than a single property, it would be best addressed in a request for comment (if anyone has the inclination to start such a discussion) — Martin (MSGJ · talk) 10:44, 24 May 2022 (UTC)
This property effectively replaces instance of (P31) for a narrow set of classes: taxons. It was discussed and proposed with fairly little activity, and only two support votes (including the proposer). Yet, Vojtěch Dostál is now using it to remove P31 statements at a large scale, leaving behind several items with no P31 statements at all, which of course results in many constraint violations (see K35 (Q72009266), permalink, for an example), as well as breaking queries (e.g. my moon trees map no longer has working colors/layers). I don’t think we have consensus for this migration yet, and furthermore I believe this property doesn’t make sense in the first place and should be deleted again.
My answers to the questions in the discussion and property proposal are, I think, fairly simple:
The property proposal doesn’t even explain how individual of taxon (P10241), once created, would be used to solve these issues, nor does it elaborate how this property is any different from instance of (P31) – in fact, one of the property’s aliases is “instance of taxon”.
Delete I agree that we should use instance of (P31). I don't think creating another subproperty is the solution to an issue caused by poor support for subproperties. I also don't think we should model non-human living things in a way which is the opposite of what we do with other data (a lot of the suggestions I've seen of what we should use for instance of (P31) instead of the species are things which would normally go in occupation (P106) or heritage designation (P1435)). - Nikki (talk) 01:44, 13 January 2022 (UTC)
1) The property has >11000 uses. If replaced by P31, this will lead to 11000 constraint violations in property P31. @Lucas Werkmeister: is suggesting to circumvent this by adding subclass of (P279) to all taxa which are used as P31, which seems completely unsystematic to me. Why would you want some taxa with P279 and some without it?
2) I leave it to local taxonomists to consider if it would even make semantic sense to use P31:Taxon to indicate that an individual animal is classified as a given taxon. To me it doesn't. Same with P279:taxon in taxa items as discussed above. @Succu: with whom I discussed the P31/P279 logic just yesterday.
3) This problem was discussed just recently in Project chat and then you had the opportunity to discuss this in the property proposal. By deleting it again, you'd be saboteering our work. Why should someone create a new property ever again if there is a simple way for opponents to just wait a week after its creation, then nominate it for deletion - effectively demotivating everyone to propose large-scale changes... Vojtěch Dostál (talk) 08:21, 13 January 2022 (UTC)
Why wouldn't it make semantic sense? Taxon is a class of organisms and individual organism or animal is a specimen (instance) of some taxon after all.
1) I think this is an overestimate: not all of the 11000 uses would have been a constraint violation in P31. For instance, you’ve edited some items I created, and I’m fairly confident those items’ P31 statements didn’t have constraint violations at the time. Furthermore, while I don’t think constraint violations should be the only criterion for the validity of this property, I’d like to reiterate that some of your edits introduced constraint violations, a point which AFAICT you haven’t yet responded to.
2) I don’t have much to say on this except that using P31 for taxons makes a lot of sense to me, and apparently to others too.
3) I’m sorry that the discussions turned out this way – I would also have preferred to object to this property before it was created – but sometimes it happens. Even if I had seen your project chat discussion (I don’t remember if I did or not), you never mentioned your property proposal there (you only wondered if a new property was warranted), so I probably wouldn’t have looked further into it. (The weekly summary where the property proposal was included happened to be the December 27 one – between the holidays and rC3 2021 (Q110157763), I did not spend much time looking at Wikidata then.) And while I sympathize with the demotivating effect of this deletion proposal (sorry), we can’t just let once-made decisions lock our data model forever in place, as you seem to suggest. (I also don’t really agree that this was proposed as a large-scale change – even the property proposal doesn’t mention that you intended to not only add statements of this property, but also remove thousands of existing P31 statements.) Lucas Werkmeister (talk) 01:03, 14 January 2022 (UTC)
Comment I also noticed these large scale changes to P31 values, and I find it a poor workaround to the problem that taxa items in the first place still don't make proper use of basic membership properties. Generally, taxa are classes, and so every taxa should have P279 statement, as other class items normally do. P279 value for taxa could be organism (Q7239), or something a little less generic. But ideally parent taxon (P171) could be phased out eventually and P279 could be used to model taxonomic hierarchy, so that it could be properly combined with other hierarchies (e.g. indicate that all species of a family are carnivore species by simply setting the parent taxon as a subclass of carnivore class). Not making proper use of P279 for taxa is a root of all sorts of deficiencies, e.g. see also comments here. 2001:7D0:81DA:F780:D95:8B9D:98C7:D69C12:48, 13 January 2022 (UTC)
Delete This is pretty clearly duplication of the semantic content of instance of (P31) → "some specific taxon, usually a species", which should itself eventually be subclass of organism (Q7239). P31/P279* is the absolutely standard and, IMO, logical membership idiom used for hundreds of millions of items. What is the actual need for this sub-property that cannot be achieved using that idiom?
If there's a good technical/ontological need for this sub-property, that's a pretty huge discovery, because it must also apply to most other "instance" items and would represent an end-to-end shake-up of the basic structure of Wikidata. Not that that's necessarily a bad thing, but consistency is absolutely critical, and so if that's where taxa go, everything else should follow (notably, occupation (P106) is also a deviation and starts getting metaphysical when you wonder what the difference is between "being" a writer and "doing writing"). Buildings should have their instance of (P31) claims pointing to subclasses of building (Q41176) stripped out and replaced with a "is a building of type" property. And so on. Specifically, there should be a very clear path to transitioning to a new, more consistent, status quo than introducing a sub-property and changing only a small domain of items. There's enough fragmentation, inconsistency and fuzzy modelling about as it is. Inductiveload (talk) 14:00, 13 January 2022 (UTC)
Comment I wasn't part of the original discussion of this (I was pinged but didn't participate - I don't really have strong opinions on taxon-related items or properties). However, can we fix the constraints on instance of (P31) so that the value can have a statement with either subclass of (P279) or *any subproperty* of P279? Lucas Werkmeister you have some familiarity with constraint logic, is this possible? That would eliminate the need for the workarounds mentioned above. ArthurPSmith (talk) 16:07, 13 January 2022 (UTC)
Comment No strong feelings about it, but I do feel P31 suffices. The ontological modelling of taxa is weird, though: it is a mix of people seeing it as a class and people seem it as a term.taxon synonym (P1420) treats taxa like terms, like lexemes, for example. IMO, if we agree on Delete we are also agreeing that taxa should be modeled as classes (what I support).TiagoLubiana (talk) 17:20, 13 January 2022 (UTC)
As I understand it, despite using the work "synonym", the property taxon synonym (P1420) is referring to a synonym (Q1040689), aka taxonomic synonym, which isn't a linguistic/lexical concept, but rather a specific statement that someone somewhere has said that two taxa are referring to the same organisms (taxonomy being a complete mess, historically, this happened quite a lot!). It's more like a special case of said to be the same as (P460) with very specific semantics (completely unlike P460).
Exactly this. “…weird, though: it is a mix of people seeing it as a class and people seem it as a term”. Taxa and nomina could be modeled separately. (Or maybe there is a more elegant solution to handle both taxonomic concepts and naming?) For example, the Pacific oyster has been classified as Crassostrea gigas (Q20857) or Magallana gigas (Q61695262). It's still the same species concept, the circumscription hasn't changed. But we don't have a single item for the concept of “pacific oyster”. What has changed is the concept of the genus it belongs to: Crassostrea in the broader sense (sensu lato) includes Crassostrea sensu stricto and Magallana (Q47463935). Those two senses of Crassostrea are distinct sets having different membership. But because they have the same name “Crassostrea”, we only have one item Crassostrea (Q542708). Stepping up above the genus level, pacific oysters are still a type of oyster; Crassostrea s.l., Crassostrea s.s., and Magallana are all sub-taxa of family Ostreidae (Q21154). This example isn't some weird edge case: lumping and splitting parent taxa is just one of the many ways that names can change, and happens in taxonomy and nomenclature (two separate but related disciplines) all the time. (In some ways, the distinction between taxa and nomina is akin to our separation of items and lexemes apple (Q89) / apple (L3257).) ⁓ Pelagic ( messages ) 20:00, 10 February 2022 (UTC)
This view that we model taxon names, not taxa, does not reflect reality really. In general, current taxon items are explicitly set as instances of taxon (Q16521), while taxon name (P225) is given as merely an attribute to a taxon, taxon (not its name) has parent taxon (P171) etc. Some dissonance to that also exist in some items, but then this just needs to be cleared up eventually, keeping in mind that Wikidata is an ontological database. Any taxon as class warrants some P279 statement as well. If you want to model taxon names in particular, then you should probably set up this project in Lexeme namespace (see Wikidata:Lexicographical data).
It isn't clear what are you trying to polemize about with this giraffe example. What you say applies to P171 as much as it applies to P279, and a class with one subclass in itself shouldn't be a problem. You also say that "examples have more than one issue", but your subsequent response doesn't explain in any way what the issues are, as far as I can see. Contrary to your claims, Sunny the dog in particular isn't a dog breed, one's an instance of some breed which in turn is of some taxon (its subclass), and Moja the gorilla is an individual organism (as well as a true instance of some taxon) not a Wikimedia list article nor a group of organisms (if that's what you thought Q21167458 was). 2001:7D0:81DA:F780:449B:6048:408E:76D110:34, 14 January 2022 (UTC)
It shows only that it is not necessary to randomly drop in subclass of (P279) statements at taxon items to resolve the constraints. A sperate property is allway a better solution. --Succu (talk) 16:41, 14 January 2022 (UTC)
Actually it would probably be doable too, using two independent statements. I'm taking it back. Your solution is an option, definitely better than using taxon names as values in P31 itself. Vojtěch Dostál (talk) 12:20, 14 January 2022 (UTC)
Comment Anyway, in case the decision to migrate back to P31 prevails, I would prefer if the current usage of taxa in P31 is cleaned up before migration, because most of them have nothing to do with individual organisms. See https://w.wiki/4gUi for items which currently include taxa among their P31 statements. Please don't create chaos where measures to introduce order were taken, even if you don't agree with the way it's been done.--Vojtěch Dostál (talk) 12:26, 14 January 2022 (UTC)
Keep i don't understand how you propose replacing this with instance of (P31)? Do you want to make every taxon also a subclass? That seems like a big change. Can't vote delete until this is answered. BrokenSegue (talk) 23:00, 15 January 2022 (UTC)
It's answered in the original post and in subsequent posts. The change that we currently face is/was to replace P31, not the other way around. Taxons are classes and the classification of classes on Wikidata normally relies on P279, so why wouldn't we add P279 statements to every taxon? In fact, this issue probably would have been fixed ages ago, if a few users (or maybe one user) weren't determined to remove P279 statements from taxons, like this, for unclear reason. 2001:7D0:81DA:F780:7D84:5196:57E3:FA9413:45, 16 January 2022 (UTC)
Well, in this example you could have removed only P31 misuse, but for an unclear reason you also removed valid P279 statement, which is the problem here. Given P31 misuse in taxon item is irrelevant here. Also, I don't know what "problem" exactly you have in mind that was fixed via P171, but it definitely wasn't the one we are facing here. Regardless of P171, taxons as classes, in general Wikidata item classification scheme, still warrant P279 statements as well.
Comment As Lucas noted, P31 wasn't working as he didn't notice before that "Methuselah (Q590039) isn't linked to Pinus longaeva (Q1116374) at all as far as I can see."
The property actually fixes items in a field that was poorly modeled with instance of (P31).
In general, if need to be a expert in a field to determine the correct P31, than it's probably not good modeling (IMHO). --- Jura11:12, 18 January 2022 (UTC)
Keep Yes the change was very poorly communicated. I understood about it after some people started complaining to me about broken queries and missing data. That said I support the new property. Adapting my broken queries to the change actually made them simpler and faster. I think that, given the universal character (and scale) of the Wikidata Knowledge Graph it makes sense to unload instance of (P31) as much as possible from specifics about a given field. Similar to human (Q5), I approve the prospect of being able to rely on something like individual organism (Q110224119) and a dedicated property instead of having to filter out which of the types I am looking for. --Nikola Tulechki (talk) 08:43, 19 January 2022 (UTC)
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.
Linked website has not been updated for several years and has now gone permanently offline / verlinkte Website wurde seit Jahren nicht mehr aktualisiert und ist jetzt offline gegangen —- HvW (talk) 14:29, 21 March 2022 (UTC)
Wait a minute. Can it be. . . I think snookerdatabase.co.uk is online again. The web.archive replacement in WD was misleading. Okay, if that's so the property may not be of much use, but we can keep it just the same. -- HvW (talk) 08:29, 17 May 2022 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
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.
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.
@עלי: being defunct is not alone a reason to delete. also you went through and removed all the links to this property which makes assessing whether we should keep it impossible. please undo that. BrokenSegue (talk) 01:28, 3 June 2021 (UTC)
@BrokenSegue: I will not do something as useless as that. Sorry. You may examine the Wikidata property example (P1855) of this property, so it's not impossible. When a property's sole purpose is linking to a website, I think the website being defunct is sufficient reason to delete the property. It was a sufficient reason to delete its template at hewiki. Having said that, tipping you for a useless property is enough. Accept or reject the request, I am not going to spend even one more second of my time regarding this property. Thanks. עלי (talk) 01:59, 3 June 2021 (UTC)
@עלי: wow... that was needlessly hostile. Deleting all usages of a property and then listing it for deletion is obviously the wrong order to do something in. It's like blanking an item and then listing it for deletion. What hewiki does has no bearing here. There is potential value in external identifier for defunct websites. BrokenSegue (talk) 03:20, 3 June 2021 (UTC)
@BrokenSegue: No, there isn't. At least not when we are talking about a private website, who holds a private nonofficial database. The website died and its identifiers died with him. Please elucidate what could be the potential value, regarding this specific property. Sorry for my previous impatient reply. עלי (talk) 03:56, 3 June 2021 (UTC)
@עלי: often websites are well archived by some third party e.g. http://web.archive.org In those cases these identifiers can still be used by looking at the archives. Additionally if a website's identifiers are used elsewhere on the Internet then having these identifiers remains valuable for joining between databases. BrokenSegue (talk) 04:11, 3 June 2021 (UTC)
Fine. I will not pursue this request any further. Wasted enough of my time, that's wikidata's maintenance administrators concern anyways. Thanks. עלי (talk) 04:16, 3 June 2021 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
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.
No consensus to delete at this time. Please consider a well framed RfC to look at the whole issue in more detail — Martin (MSGJ · talk) 20:58, 27 May 2022 (UTC)
We already have a property for ALA-LC romanisation - ALA-LC romanization (P8991) - and I don't see any need for this one to be separate. It has only been used 6 times so far, so migrating the statements would be easy and deleting it shouldn't break anything.
I just noticed on the property talk page that Mzajac thinks we should have specific properties for every romanisation table ALA-LC has. I don't think that's a good idea because it would require a lot of properties (making it much harder for people find the right one to use) for little benefit. On https://www.loc.gov/catdir/cpso/roman.html there are 75 different files (which sometimes have different variations for different languages, e.g. Non-Slavic Languages (in Cyrillic Script)) and the index of languages covers around 150 different languages. The tables can also change over time (e.g. the 1997 version for Korean would use "dijain" for "디자인", while the 2009 version would use "tijain").
For the most part, there is one ALA-LC romanisation system for each language and script. In the cases where it's ambiguous (e.g. Khakass in the non-Slavic languages file), I would suggest using determination method (P459) to specify the exact version.
Firstly, a romanization is precisely defined by a single table. For example, ALA-LC Romanization for Ukrainian and ALA-LC Romanization for Russian are two different tables, intended for alphabets that share many of the same letters, some of which are pronounced differently. They can be applied to a specific string of characters and yield different results. ALA-LC Romanization is a very large set of tables. For Slavic languages, there are also some simplified variations (“modified Library of Congress”) intended for use in text rather than for library cataloguing. It has tried to maintain some phonological consistency, so languages can be compared. In contrast, BGN/PCGN is a set of tables coming from different national authorities, so its schemes are diverse. Some systems are for only one language and have only one table. There are also “universal” transliteration systems like ISO 9-1995 that has one table for all Cyrillic-script text. Some have changed their standards, so, e.g., there’s a BGN/PCGN-1965 romanization for Ukrainian and a 2019 one. For unambiguous identification, and for automation, just “ALA-LC romanization” is not good enough.
Secondly, and more importantly, romanization as it is modelled in Wikidata is a hot mess, and solitary changes like this won’t fix it. We need to create an overall framework. I started proposing properties based on others already present. But even now I can’t hold in my head at once all of the ways to indicate romanization here: sometimes it’s a statement (for items representing names), sometimes a property on a statement, sometimes a determination method property, and I don’t even know anything about how lexemes work. It applies differently to monolingual text or generic strings that may contain multiple languages. So I have no idea whether deleting this property is an improvement or not.
In comparison, w:IETF language tagging is a flexible scheme for identifying romanized text with a variable amount of precision, and this might be a useful model to inform us going forward. I can construct a language tag that indicates language, writing system, or method of romanization referring to a general system or a specific version of it. —MichaelZ.17:26, 3 September 2021 (UTC)
Keep per above. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)
Delete @Jklamo: No need to "distinguish", we should be neutral on every URL schemes. --Liuxinyu970226 (talk) 08:32, 30 October 2020 (UTC)
Notified participants of WikiProject Italy for opinions. --Epìdosis 21:13, 22 February 2021 (UTC)
Weak support the deletion of AICS Chemical ID (BEING DELETED) (P7049) instead of the usual case of leaving AICS Chemical ID (BEING DELETED) (P7049) in a deprecated state (for the purpose of Internet Archive etc linking). Mix'n'Match seems to contain the full catalogue of previous IDs but what is the point if there is no copy of the original page available? --Dhx1 (talk) 13:28, 30 March 2021 (UTC)
Notified participants of WikiProject Ancient Rome. The agnomen is an element of the Roman nomenclature that is hardly used in specialized literature. It is only a particular case of cognomen. On this page that collects much of the prosopography of the Republican period, the term is not used: it only says Additional Cognomina. In this repository of academic works, it can be verified that cognomen appears in more than 5000 articles while agnomen in just 200. It would be enough to add a qualifier that indicates that the cognomen is being used as an agnomen if it was necessary to indicate it. —Romulanus (talk) 18:33, 23 October 2021 (UTC)
WikiProject Cultural heritage has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
@Fralambert, Jingkaimori, Ulumarifah, Nw520, Aiaiaiaiaia, VIGNERON:
Strong oppose see the discussion Total mess! for all explanations refuting Vladimir Alexiev hypothesis. In a nutshell: there is a proper definition, this is not exactly equivalent to a list (so has list (P2354) is not a replacement) and not all have individual IDs, there is some "mess" (an exagerated and unneededly aggressive word) but it can be fixed, this is not a reason for deletion. Also pinging @Fierodelveneto: who built the Infobox de Bało and @Vladimir Alexiev: the local village pump can very very easily be found on Project:Village pump (Q16503). Cheers, VIGNERON (talk) 09:09, 9 January 2022 (UTC)
Done, thanks for helping with this — Martin (MSGJ · talk) 11:29, 16 May 2022 (UTC)
Deleted — Martin (MSGJ · talk) 21:04, 23 May 2022 (UTC)