Hej! No to jest być może trochę akademicka dyskusja, czy w dokumentacji właściwości ważniejsze jest property constraint (P2302) czy raczej subject item of this property (P1629). Osobiście stoję na stanowisku, że ważniejsze jest zmieszczenie się w aktualnych ograniczeniach właściwości (zresztą tak też ustawione jest Harvest Templates) i w tym sensie moje edycje uważam za poprawne. Raczej nie zgadzam się z Tobą, że ograniczenia ustawia się po to, żeby nie wyświetlały się błędy. Moim zdaniem to jest patrzenie na problem od końca - komunikaty o błędach są tylko technicznym efektem dużo poważniejszych decyzji co do konstrukcji Wikidanych jako bazy danych, które znajdują swój wyraz w takim, a nie innym, ustawieniu ograniczeń. I nie zgadzam się też, że wcześniej nie było takich importów - sam już ze dwa lata temu tym samym narzędziem importowałem stopnie również policjantów w tej samej właściwości. Krótko mówiąc - jasne, jest to temat do jakichś dalszych dyskusji w szerszym gronie, ale na dziś nie uważam tych deklaracji za "ewidentnie nieprawidłowe". Natomiast pełna zgoda, że warto tu rozszerzyć P1629, żeby nie było bałaganu w ramach jednej strony P. Pozdrawiam!
User talk:Wostr
In this edit you wrote, "en.wiki does not want to use WD data". Once upon a time, I thought that the whole point of Wikidata was to be used by the 'pedias, and while it took a while for that linking to get off the ground, at one point it seemed like it was actually picking up. So I'm more than a little dismayed to hear that there are strong wishes not to use WD data at all, after all. Do you have any links to discussions or decisions formalizing this attitude?
(I'm not arguing with you or doubting you, though; as a matter of fact I just came across w:Wikipedia:Short description, which explains that "Initially short descriptions were drawn from the Description field in Wikidata entries, but because of concerns about including information directly from another project, the Wikimedia Foundation (WMF) made provision for these to be overwritten by short descriptions generated within Wikipedia", followed by the direction that "Eventually, all articles should have a short description template", i.e., according to that page there should be no descriptions drawn from Wikidata at all. Foo.)
I can't give you any links, because — as I'm not a regular en.wiki user — I don't know where such discussions were held and I'm not familiar with en.wiki discussion/archive page structure. However, I remember for example a RFC in en.wiki some two years ago(?) about use of WD in en.wiki infoboxes and the most popular option was to not use WD at all (the summary of this RFC was something like: WD could be used in en.wiki if there is some assurance that the data meets en.wiki rules /verifiability etc./). I think there were notifications in Project chat about several discussions in en.wiki about use of WD data and I never heard that en.wiki users are eager to use WD. Frankly, I can't blame them, I have many reservations about use of WD data in my home wiki (pl.wiki), because policies about verifiability and quality of data are much less restrictive here than in pl.wiki. However, I try to use WD data where I have a lot of confidence that articles will not lose quality or verifiability, but also to use article's (infoboxes) data in such a way as to verify the WD data or add sources to WD statements.
About 'Short description': this is how it should be done in every project. Wikidata 'description' wasn't meant to be a description for Wikipedia articles, but the WMF thought otherwise. This WMF mistake resulted in more people now opposing WD data at all, because they see that WD description can be vandalised from IP without any knowledge of Wikipedia users and sometimes such description remains unreverted for days, weeks or even months.
All fair points. Thanks.
Hmm… wydaje mi się, że jest ok – chodziło o wykonywany zawód, nie konkretną formację z naszego grajdołka – w tym wypadku dla Q11698741 i occupation (P106).
Ok, to już jak uważasz – ja dodając kierowałem się rozstrzałem w angielskich aliasach – cop, fed, constable czy bobby.
Thanks for your input. I was imitating what I saw with the imported NIOSH data (instances of occupational carcinogens). I can change the relationships from instances to 'subject has role'. On a partially related note, is this also the preferred method of relating drugs to drug classes? Is there a good database for drug-drug class relations that can be added to WD?
As I wrote – that is only what I think would be best. There is no guidelines in chemistry or medicine regarding this. Everyone is adding new statements based on their own judgement, so sometimes related statements are added using 'instance of' and more precise properties in the same item.
To be consistent with the NIOSH data which was added by a Wikimedian in residence at the time, I'm going to finish adding the CA Prop65 data in this manner. Once the chemistry or medicine communities arrive at a consensus about how to handle this, I'll write a script to make the necessary changes.
Dzięki za zwrócenie uwagi, musiało mi coś uciec, prawdopodobnie chciałem napisać "jest podklasą dla", albo coś podobnego. Pozdrawiam! ~~~~
this change - and similar broke down template working in ruwiki. Maybe, if you need url property for some reasons, you should duplicate the value for new one property, but not to remove old one? Def2010 (talk) 10:17, 6 February 2020 (UTC)
You should change the template then, check the constraints (and then probably modify all the statements using this incorrect property or allow both properties in your infobox). reference URL (P854) is for sources only and cannot be used as a qualifier, the proper qualifier is URL (P2699). I don't need this anywhere, I'm just correcting constraint violations.
The template is protected and there are not too much volunteers that has time to correct it accordingly wikidata changes due to it's complexity. Another one for NFPA 704 has not been updated for some years, despite my repeated requests, only recently one man had fixed it. But the template has an important feature - it is just working if the property is consistent, so I will have to duplicate to ensure it will continue to do so. Def2010 (talk) 10:57, 6 February 2020 (UTC)
What I'm saying is that sooner or later these incorrect qualifiers will be fixed, with a prior notification or without it (as it is just correcting incorrect statements – not changing the whole model – I don't think it is an obligation to inform anyone outside WD). I can refrain from correcting these particular issues, but other users may want to fix these statements either manually or (semi-)automatically in the future.
https://commons.wikimedia.org/wiki/File:Ethoxyethane_200.svg - in this picture is not diethyl ether, but methyl ether.
Sorry for my English.
No, this image shows diethyl ether, drawn according to IUPAC recommendations. This File:Dimethyl ether Structural Formulae.svg is dimethyl ether, this is File:Di-n-propylether Structural Formulae.svg dipropyl ether.
1) The chemical formula of diethyl ether is (C2H5)2O, but on this picture (CH3)2O.
2) https://commons.wikimedia.org/wiki/File:Ethoxyethane_200.svg and File:Dimethyl ether Structural Formulae.svg these two pictures depict the same substance - dimethyl ether.
No, you're not right. Check the IUPAC Recommendations (https://www.degruyter.com/view/j/pac.2008.80.issue-2/pac200880020277/pac200880020277.xml). Any unlabelled atom is assumed to be carbon atom with max. hydrogen atoms attached. Only terminal carbon atoms are labelled in the preferred style; acceptable is not labelling any carbon atoms like in File:Diethyl ether chemical structure.svg. And this File:Ethyl functional group.svg is ethyl group, which may be drawn like this File:Ethyl group.png, but this style is not preferred.
Ok. But Wikipedia readers may not be aware of this recommendation. Wikipedia readers need a complete formula. This is my humble opinion. I will not insist on my opinion. Regards, Jim Hokins.
This is not about some unknown recommendations. This is the way chemical structures are drawn in chemistry worldwide. It is well understood – or at least it should be — by anyone from secondary school upwards.
Hi! Regarding Special:Diff/1033545034: I have to admit that it's hard to tell with sufficent certainty which is the correct relation as currently the entire classification of chemical substances is rather messy. I may have just hidden parts of the confusion. Generally it would make sense that chemical compound (Q11173) is a subclass of substance, the latter in turn being a subclass of concrete object of which instances are not substance classes like germanium dioxide (Q419133) (as opposed, say, particular chunk of this substance displayed on a photo in that item). However for some reason chemical compound (Q11173) is currently also set a metaclass (through "chemical component" item), as if it was a group or class of chemical substances (Q17339814). This is certainly wrong as it should not be a class of concrete objects and class of classes at the same.
Indeed there are lots of items (about 164k) directly set as chemical compound instances. Lots of it seem to be set by bots. This might have been wrong in the first place as it's unclear if "chemical compound" was ever supposed to be a metaclass and not class of concrete objects.
However, there are also lots of class item that are set as subclass of (subclasses of) "chemical compound" item. I'm having trouble to get the exact counts without query timing out, but for instance there are currently about 54k items that are a subclass of subclass of subclass of chemical compound (Q11173). Probably many items are incorrently set as instance of and subclass of chemical compound at the same time, too. So I doubt that using chemical compound (Q11173) in either relation is established really.
For the sake of practicality and simplicity I'd suggest correcting root items like chemical compound (Q11173) so that they were explicitly set as classes of concrete objects. Otherwise, if it was a metaclass, then what were true instances of concrete objects with particular chemical composition (substances) instances of. (In long term it might be reasonable to have separate items from substances and relevant molecular entities.)
The problem we have in WD with chemical compounds classification is mainly on the specific chemical compounds level. We have a growing classification tree starting from chemical compound (Q11173) using subclass of (P279) relation. These classes have either instance of (P31) structural class of chemical compounds (Q47154513) or instance of (P31) group of chemical compounds (Q56256086) (or its subclasses), but still many classes or groups of chemical compounds are not properly classified.
On the chemical compounds level there are many problems, partially because all items imported by bots have instance of (P31) chemical compound (Q11173), also because we still lack a consensus whether chemical compounds should be instances or subclasses of chemical compound (Q11173). What's more:
- there are many items describing chemical compounds with undefined stereochemistry; these items we agreed to treat as group of compounds (i.e. usually instance of (P31) group of stereoisomers (Q59199015)) and should be placed in the classification tree using subclass of (P279)
- there are many items describing ions that should be placed under ion (Q36496) and not under chemical compound (Q11173)
- in some items there is instance of (P31) chemical compound (Q11173) and subclass of (P279) with a class being a subclass of chemical compound (Q11173)
- it is temporarily adopted that all chemical compounds should have instance of (P31) chemical compound (Q11173) so as to retrieving all chemical compounds using SPARQL be possible.
However, the main problem IMO is that there is not many people involved in Wikidata:WikiProject Chemistry discussions and we couldn't come to an agreement whether chemical compounds are instances or subclasses of classes like chemical compound (Q11173), amine (Q167198), pyridines (Q47317020) or salt (Q12370).
Coming from molbio where the inconsistencies are similar, e.g. specific proteins being instance of protein mostly but also many subclass-of protein. Then protein families of which the specific proteins are part-of but also some are subclass-of. Fortunately UniProt is the de-facto database for proteins (although it's not complete) so to get all available proteins queried the best way is to query for UniProt ID.
Obviously there is a hierarchy of things, expressed as a DAG (directed acyclic graph) where there are end nodes (substances, proteins) from which no subclasses or instances are made, and there are between-nodes or parents (substance groups, protein families) that are subclassed and instantialized. This is well known to object-oriented programmers, and I'm surprised there is no standard way of handling this across Wikidata. So, at least molbio and chem should aim for a consistent approach. Please ping me on pages where this is discussed.
Classification of chemical compounds was discussed on many WikiProject Chemistry subpages. You may want to check Wikidata:WikiProject Chemistry/Proposal:Models and its discussion page, maybe also Wikidata_talk:WikiProject_Chemistry/Archive/2018#Documenting_how_to_model_chemical_concepts_in_Wikidata, Wikidata_talk:WikiProject_Chemistry/Archive/2018#'Is_a'_=_'chemical_compound' and other archived discussion of Wikidata_talk:WikiProject_Chemistry.
What we were able to agree on is the classification of 'compounds without fully defined isomerism or isotopic composition', see Wikidata:WikiProject Chemistry/Guidelines. The classification that uses structural class of chemical compounds (Q47154513) and group of chemical compounds (Q56256086) (or its subclasses like group of stereoisomers (Q59199015)) is similar to the concept of open and closed classes/groups in ChEBI.
If the Wikiproject cannot agree on the design I think we should try to agree here. The problem is not that ions have their separate tree, or that compounds with undefined stereo-, cis/trans-isomery or tautomery are actually groups/sets. Of course these ions and sets need to be identified and changed to the specific instances. The real design problems are, as you say, if a compound class gets a has-part statement, does this statement apply to the class, or does it apply to each of its instances? If we want it to apply to every instance then indeed the compound class must be subclass of a class of all objects where this statement holds:
- Wrong: oxygen compound (Q5156940) has part (P527) oxygen (Q629), water (Q283) part of (P361) oxygen compound (Q5156940)
- Solution 1: oxygen compound (Q5156940) has part (P527) oxygen (Q629), water (Q283) subclass of (P279) oxygen compound (Q5156940)
- Solution 2: oxygen compound (Q5156940) subclass of (P279) oxygen molecular entity (Q76272846), oxygen molecular entity (Q76272846) has part (P527) oxygen (Q629), water (Q283) part of (P361) oxygen compound (Q5156940)
Solution 2 would resolve the dilemma you have with has-part/part-of by moving the has-part one level up. We just would need 100 molecular entity classes. If you agree this could be proposed on one of the project pages. If you disagree we can find another solution, but please do comment.
We cannot force a solution. If there is no agreement, the problem won't be fixed. The problem with solution 2 is that there would be too many P361-statements in some classes – and it was rejected once, when P361 was used as a obligatory inverse property for P527 (has part), because in items about carbon or oxygen there would be thousands of compounds listed and because P361/P527 is used for many other things (too broad properties). The problem with items like oxygen molecular entity (Q76272846) is also that in WD compounds are more substances than molecular entities (most physical properties, uses etc. describe substance, not a single molecule).
By the way, there's even no agreement that we should classify compounds using classes ;)
For me, the solution 1 would be the best and the simplest, but the main reason for not doing so was that it would be hard to retrieve all the compounds via SPARQL (cf. Wikidata:WikiProject Chemistry/Tools). That's why all chemical compounds have instance of (P31) chemical compound (Q11173) despite being also an instance of its subclass) and that's why I'm now trying to clean up all items being subclasses of chemical compound and being incorrectly described using instance of (P31) chemical compound (Q11173) (ions, group of compounds, sometimes minerals, etc.). and also trying to expand and fix the existing classification tree for compounds.
I was also thinking about creating some sort of a metaclass that could be used instead of instance of (P31) chemical compound (Q11173), so as to every chemical compound could be queried via SPARQL and it would not affect the classification or relations part of/has part. Then all existing instance of (P31) chemical compound (Q11173) could be switched to P279 or deleted if there is already a subclass of chemical compound (Q11173).
BTW there may be another problem with instance of (P31) chemical compound (Q11173) in the future – the situation in which we have an item about a specific substance, i.e. a sample of substance (in a museum or whereever). I think we already have a few items about minerals being a real instances (a rock in a museum with its number and everything). It is at least theoretically possible with compounds I think.
I don't understand why you say that there would be too many P361-statements in some classes. The only item that would have as part oxygen would be oxygen molecule, all other compound classes subclass from it. That is the reason why I support the idea, instead of having has-part oxygen in every class and instance. Don't you agree?
You say if there is no agreement, the problem won't be fixed. I think that if there is agreement between the active people then this can be documented, and comments requested. This is one thing and worthwhile. And secondly, as you have seen, I have no problems doing mass edits via QuickStatement, after no valid objections have been raised. Just talk to me.
There are more active people than just the two of us ;) I think this matter should be brought to the Wikiproject (again), because maybe there will be consensus now to do something about it. Both solutions may be described there with an information that, if needed, there may exists a metaclass for all chemical compounds to be able to query them easily (like structural class of chemical compounds (Q47154513) but for specific chemical compounds like water (Q283)); there is chemical species (Q899336) but it doesn't seem entirely correct for a metaclass).
Let me explain about the "inorganic" definition that was used there. It comes from https://www.ncbi.nlm.nih.gov/mesh/68007287, i.e. from the {{P|486}} system. The definition may not be standard in relation to its treatment of carbon compounds; but MeSH is a major system for searching the medical literature. I have used that, to add several thousand links to the item: see for example https://www.wikidata.org/w/index.php?title=Special:WhatLinksHere/Q73543107&limit=2000. where links to Q73543107 persist. I suppose those links will be updated soon.
The information in the corresponding {{P|921}} statements has an exact scope as defined by the MeSH page, and so with the given description. Because this information has value, I would like to undo the merge you did, and update Wikidata:Do not merge. I think where Help:Merge#Check to be sure talks about "subtle differences", that advice applies here.
I see no differences between these two items and in fact there is no difference. Inorganic compounds do not have only one definition and this class is defined usually as "any compound that is not organic" = "any compound that do not consist of carbon, with exception of carbonates, ..., ...". Keeping these two items separated is a mistake, because this is the same concept.
You may expand the definition in Q190065, because both definitions can be used interchangeably.
I think we are not understanding each other.
It does seem, from the English Wikipedia article "inorganic compound", that chemists are not very interested in the inorganic/organic boundary. They probably aren't concerned with it, in a practical way.
MeSH, Medical Subject Headings, is a "comprehensive controlled vocabulary for the purpose of indexing journal articles and books in the life sciences". The vocabulary is controlled by scope notes that define how it is properly used. In other words the index terms from the vocabulary carry the value of fairly precise definitions.
Here there are indeed multiple concepts. I work with a bot that imports these terms from the PubMed repository, where they are attributed by the MEDLINE indexing system. That indexation is carried out by human experts.
I certainly wish that in giving main subjects to biomedical papers, referencing PubMed, I'm able to attribute exact meanings.
I'm not interested at all what is written in any language version of Wikipedia. Sitelinks to other Wikimedia projects are only an addition to Wikidata and do not define the Wikidata content.
The definition of inorganic compound in chemistry may be written as follow: "any chemical compound that is not organic, i.e. does not contain carbon with exception of some compound classes traditionally defined as inorganic, e.g. carbon monoxide, carbon dioxide, carbon disulfide, carbon diselenide, carbides, hydrogen cyanide, carbonic acid, cyanic acid, isocyanic acid, fulminic acid and its salts like carbonates, hydrogen carbonates, cyanides, cyanates". This definition covers both English Wikipedia definition and MeSH definition.
OK, thank you for the description, which I shall add to the item. We shall have to agree to disagree on other matters.
Maybe there is some difference between these two concepts that I just can't see, but it must be something other than the definition from https://www.ncbi.nlm.nih.gov/mesh/68007287. MeSH definition is one that is widely used for inorganic compounds.
BTW I'm not sure about items describing compounds of a specific element. I've just noticed that all entries in MeSH like this one: https://meshb.nlm.nih.gov/#/record/ui?ui=D017610 are for inorganic compounds only. However, in WD we don't have items for inorganic compounds of a specific element yet. So Q12548019 has MeSH id (inorganic) matched to 'calcium compound' (both organic and inorganic), Q74819737 has description about inorganic compounds, but is matched to category for both organic and inorganic compounds.
Is it intentional (and narrow match (Q39893967) as a qualifier should be used) or maybe I should create items for 'inorganic compound of ...' and move MeSH id to such items?
For a very accurate analysis of the MeSH identifiers for compounds, one can look at the MeSH tree codes (P672). E.g https://www.ncbi.nlm.nih.gov/mesh/68058085 for iron compounds has two, D01.490 and D02.691.550, where D01 means inorganic, and D02 organic. https://www.ncbi.nlm.nih.gov/mesh/68017612 for gold compounds has only D01.379, because the scope is inorganic only. So, yes, it would be possible to make these distinctions, and check them with queries.
At present I'm working to complete the P486 dataset, and this is not my major concern. There are some thousands of statements still to add.
Dziękuję za Twój głos w Wikidata:Property proposal/SGJP Online ID, dzięki temu po długim oczekiwaniu ta właściwość wreszcie powstała. Byłbym bardzo wdzięczny gdybyś równie życzliwym okiem spojrzał na to głosowanie: Wikidata:Property proposal/Doroszewski Online ID. Z góry dziękuję i pozdrawiam, ~~~~
Jasne.Na SGJP trafiłem przypadkowo z Wikisłownika (z baru). Ale aż dziwne, że po jednym głosie została ta właściwość utworzona, tak się zazwyczaj nie dzieje ;)
Dziękuję. Dla mnie to też niezrozumiałe, że jednym głosem przesądza się o utworzeniu właściwości, ale może to wynika z tego, że na razie dane leksykograficzne nie mają wielu wielbicieli. Przeglądam wszystkie tworzone leksemy i jest raptem kilku stałych twórców. W ramach wdzięczności za głos mogę chętnie utworzę jakiś chemiczny leksem dla Ciebie :), jest może jakieś ciekawe chemiczne słowo? Hasła dla pierwiastków chemicznych już tworzę. Ostatnio zrobiłem całe drzewo etymologiczne berylu https://lucaswerkmeister.github.io/wikidata-lexeme-graph-builder/?subjects=L6291&predicates=P5191
Nie ma sprawy. Pierwiastki to chyba najważniejsze chemiczne słowa ;)
Nie mają wielu wielbicieli podobnie jak całe Wikidane na początku nie miały, a dopiero od pewnego czasu znacznie wzrósł ruch i są podejmowane kroki, aby włączać dane z WD do innych projektów. Jestem bardzo ciekaw, jak rozwiną się dane leksykograficzne, bo interesująco to wygląda. W razie potrzeby (podobnych propozycji właściwości) możesz pisać albo po prostu dać pinga.
No właśnie się pojawiła nowa właściwość, polecam ją Twojej uwadze :) Wikidata:Property proposal/Kopaliński Online ID ~~~~
Polecam Twojej uwadze kolejne głosowanie Wikidata:Property proposal/WSO Online ID Tym razem słownik ortograficzny :)
I ponownie zjawiam się tu z podobną prośbą :) Polecam twojej uwadze kolejne głosowanie Wikidata:Property proposal/WSJP ID Z góry dziękuję za głos.
Nie ma żadnego problemu. Dzięki temu dowiaduję się o stronach, o których nie miałem pojęcia — a często szukam różnych rzeczy w słownikach ;)
I znowu ja z prośbą o wsparcie głosem :) Tym razem tutaj: Wikidata:Property proposal/Dobry słownik ID Pozdrawiam
Tym razem przybywam z pytaniem czy byś nie poparł Wikidata:Property proposal/usage example . Nie jest to jednak kolejny słownik a właściwość (+2 kwalifikatory) przydatna przy przenoszeniu z Wikisłownika przykładów użycia więc możesz mieć wątpliwości. Nic na siłę, jeśli nie popierasz tej propozycji to w porządku :)
Dzięki, postaram się zerknąć w wolnej chwili ;)
Tym razem prośba o wsparcie przy dwóch słownikach historycznego polskiego: tego Wikidata:Property proposal/SPXVI ID i tego Wikidata:Property proposal/SJPXVII ID. Z góry dziękuję, dzięki Twoim głosom język polski ma najlepiej przygotowaną bazę słownikową we właściwościach. :)
Bardzo ciekawe słowniki swoją drogą :)