Property talk:P486

Documentation

MeSH descriptor ID
identifier for Descriptor or Supplementary concept in the Medical Subject Headings controlled vocabulary

Description

MesH ID: NLM catalogue codes for diseases

Applicable "stated in" value

Medical Subject Headings (Q199897)

Data type

External identifier

Template parameter

en:Template:Infobox disease field MeshID

Domain

term: medical subjects, diseases, ... (note: this should be moved to the property statements)

Allowed values

^[CD]\w{6}(\w{3}|)$ (C or D, followed by 6 or 9 digits. Don't use M (see MESH Concept) nor T (see MESH Term))

Example

systemic lupus erythematosus (Q1485) → D008180 (RDF)
Uruguay (Q77) → D014583 (RDF)
DPPH (Q5205953) → C004931 (RDF)

Source

http://www.nlm.nih.gov
List of MeSH codes

Formatter URL

https://meshb.nlm.nih.gov/record/ui?ui=$1
https://id.nlm.nih.gov/mesh/$1.html

Tracking: same

no label (Q30463739)

Tracking: differences

no label (Q30463732)

Tracking: usage

Category:Pages using Wikidata property P486 (Q30463729)

Tracking: local yes, WD no

no label (Q30463735)

Distinct values for a cancer vs a neoplasm?[edit]

For many different types of cancer, both the cancer and the neoplasm are referring to a single MeshID. See neck cancer and neck neoplasm for example.

Yes, it's a serious issue. Many of the cases are introduced by bot edits, and I have had discussions on the topic. Charles Matthews (talk) 09:54, 8 September 2019 (UTC)[reply]

Allowable constraint violations[edit]

As far as I know, there are two cases where the constraints should, arguably, be ignored.

One is for the "single value" constraint. As on periodical (Q1002697), there is an artefact of the MeSH system meaning there are different identifiers for Periodical [Publication Type] and Periodicals as Topic. On PubMed, these are used in different sections of the MeSH term listing. But really there is no difference as object of a Wikidata statement.

The other is for the "distinct value" constraint. While the scope notes for a MeSH term are normally carefully drafted, they do not always allow one to read off the intended taxon range, which can be humans, primates, mammals or vertebrates, or all organisms. For instance, for lung the MeSH page does not give enough to decide between human lung (Q2640512) and lung (Q7886) which covers animals. Charles Matthews (talk) 10:05, 8 September 2019 (UTC)[reply]

#P486 identifiers starting with D, grouped by occurrence number on items
SELECT ?item ?itemLabel (COUNT(?mesh) as ?count)
  WHERE {?item wdt:P486 ?mesh.
         FILTER(strstarts(?mesh, 'D'))
         
         SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
         }
GROUP BY ?item ?itemLabel
ORDER BY DESC(?count)

LIMIT 50

Try it!

shows item with more than one P486 statement. At the time of posting there were 44, that seemed admissible. The number can vary. Charles Matthews (talk) 11:16, 30 September 2019 (UTC)[reply]

A fuller discussion of this topic is being posted at Wikidata:ScienceSource project/MeSH project 2020. Charles Matthews (talk) 12:31, 3 November 2020 (UTC)[reply]

How to Handle Entry Term(s)?[edit]

Should Wikidata consider the entry term(s) for MeSH Descriptor and Supplementary concepts? I would like to use Wikidata to get MeSH IDs for these amino acids, including 'Glutamate'. When I search for 'Glutamate' at the MeSH site, I get D018698, which is Glutamic Acid, but it also has these entry terms: 'Aluminum L-Glutamate', 'D-Glutamate', 'Glutamate', 'Glutamic Acid, (D)-Isomer', 'L-Glutamate', 'L-Glutamic Acid' and 'Potassium Glutamate'.

Should I be able to use Wikidata to map from the term 'Glutamate' to the MeSH ID D018698? The Wikidata item DL-glutamic acid (Q181136) has MeSH descriptor ID D018698, but Scidudebot said that 'glutamate' is not a valid alias for this item. Would this be a case where I should use MeSH term ID (P6680) to reference T055678? --Ariutta (talk) 19:55, 24 November 2020 (UTC)[reply]

I replied in Talk:Q181136, but please, ask a question in one place, as it is not easy to discuss one topic in different places. Wikidata is far more detailed than MeSH, because we do not reflect classification system of MeSH, but we try to link many different databases and point of views. MeSH is a medical database, so the level of detail reflects this; in medicine or biological sciences the difference between an acid and its anionic form is usually negligible. However, in chemistry it has to be taken into account. Statements using MeSH descriptor ID (P486) should always be qualified using mapping relation type (P4390), because there is many situations in which there is no 1:1 equivalency between WD entry and MeSH entry. Adding MeSH term ID (P6680) is always welcome – caution is needed however, because Glutamate can be applied only for a WD entry for a group of stereoisomeric ions and D-Glutamate for a specific anion; see DL-glutamate(1−) (Q27108980), L-glutamate(1−) (Q27104095) and D-glutamate(1−) (Q27104097); also, many entries in Wikidata is not manually curated yet and contain a lot of errors or missing data. Wostr (talk) 13:43, 25 November 2020 (UTC)[reply]

@Wostr: Thanks for the explanation. It makes sense regarding how to handle aliases on Wikidata entries for these cases. How about linking dioxygen (Q5203615) and hydron (Q506710) to MeSH? Is it possible to use MeSH descriptor ID (P486) qualified using mapping relation type (P4390), or do I need to just use MeSH term ID (P6680)? --Ariutta (talk) 19:00, 4 December 2020 (UTC)[reply]

Both I think. MeSH descriptor ID (P486) can be used in only one item, but it should be qualified with mapping relation type (P4390), even if there is 1:1 relationships between WD and MeSH. MeSH term ID (P6680) should be added as well if applicable. Wostr (talk) 04:04, 5 December 2020 (UTC)[reply]

MeSH descriptors + qualifiers[edit]

This is the URI for the MeSH string Violence--prevention & control: http://id.nlm.nih.gov/mesh/D014754Q000517. On the new item I just created for violence prevention (Q104733130), I want to include the MeSH identifier D014754Q000517. However when this property was set up, it appears no one took into account the fact that there are MeSH descriptor/qualifier strings that as a whole represent a topic that could have a Wikidata item. The regex for P486 needs to be revised to allow IDs such as D014754Q000517. Can someone please do that and then add this example to the property:

violence prevention (Q104733130)

MeSH descriptor ID (P486): D014754Q000517

Thanks. UWashPrincipalCataloger (talk) 17:57, 8 January 2021 (UTC)[reply]

This issue has now been resolved and the links work correctly. UWashPrincipalCataloger (talk) 18:41, 11 January 2021 (UTC)[reply]

Oppose http://id.nlm.nih.gov/mesh/D014754Q000517 is not a Descriptor but an AllowedDescriptorQualifierPair, so if you really want that, we need to add yet another prop. But I'm not a big fan of precoordinated (compound) concepts because:
- This approach leads to combinatorial explosion
- It also leads to redundant data: something needs to check that the values of Descriptor and Qualifier conform with DescriptorQualifierPair
Assuming that item violence prevention (Q104733130) is really needed, you can apply MESH Descriptor=D014754; qualifier MESH Qualifier=Q000517 to it. Then I believe a custom formatterURL function can be used (eg see https://www.wikidata.org/wiki/Property:P3608#P1630) to check whether both props are applied to an item, and if so to make the compound link --Vladimir Alexiev (talk) 19:37, 6 March 2021 (UTC)[reply]

MeSH RDF vs MeSH Browser links[edit]

Can we change the value of the instances of this property to always link out to MeSH RDF (https://id.nlm.nih.gov) instead of MeSH Browser (https://meshb.nlm.nih.gov)? If you look at the above issue the ID only works in MeSH RDF. Pullen255 (talk) 13:55, 11 January 2021 (UTC)[reply]

The problem has now been resolved and the link now goes to MeSH RDF. UWashPrincipalCataloger (talk) 18:40, 11 January 2021 (UTC)[reply]

Comment: I saw there had been some edit-warring on the property page, and I came here to find discussion.

First point: while I can see someone might want to have such links with qualifier on Wikidata, they are out of scope for the original purpose of the property. There have been some changes on the way, but this property is for the "Mesh Unique ID" and "Mesh Supplementary ID", i.e. the D- and C-numbers.

Second point: I work on the Mesh Unique IDs, and the page https://meshb.nlm.nih.gov/record/ui?ui=D014435 is a great deal more useful to me than https://id.nlm.nih.gov/mesh/D014435.html. The former has much more human-readable information.

Third point: I didn't find discussion here. Waiting a few hours is not adequate for serious changes.

Fourth point: Can we discuss the actual value of including qualified MeSH terms?

I think there is great value in including these terms, as they can have separate items in Wikidata and represent unique concepts. For example, there are separate items for COVID-19 (Q84263196), transmission of COVID-19 (Q98456223), COVID-19 disease in pregnancy (Q88058672), and COVID-19 mortality (Q104778232) and each of these concepts has its own identifier in MeSH RDF, the latter three constructed by combining a D number and a Q number. All valid combinations of main MeSH descriptor and qualifier have identifiers in the MeSH RDF service. UWashPrincipalCataloger (talk) 18:10, 21 January 2021 (UTC)[reply]

@Pullen255: @UWashPrincipalCataloger: I'd like to have this whole business hashed over. Charles Matthews (talk) 11:14, 18 January 2021 (UTC)[reply]

I consulted with National Library of Medicine before making the change to the property. They wanted the link to the MeSH RDF. UWashPrincipalCataloger (talk) 22:04, 18 January 2021 (UTC)[reply]

@UWashPrincipalCataloger: I think you'd agree that the decision lies with the community here, though.

It may be that there are use cases for the MeSH RDF. We can talk about that. Currently clicking the link gives me both types of external link, which is not great. Perhaps that is transient, but I don't actually know.

My reaction to the use of DQ-numbers within this property is that it is evidently mission creep. There are around 30K D-numbers. There are indeed quite a lot more C-numbers. But the DQ-numbers may be up to half a million in number. The proposed change would, in the normal way of thinking, allow the creation of items for each of those. I can see that you wish to have one of those available. But I'd call that a serious stretch.

The Mesh ID property was subdivided a little while back, to separate out the M-numbers and T-numbers. We don't yet have a property for the qualifier Q-numbers.

I think the right approach here is a property proposal for the DQ-numbers. I also do not accept the use that has been made of exceptions to the value constraint for MeSH descriptor ID (P486): it is particularly important for the purposes of reverse lookup from the D-number to the Wikidata item that there is no ambiguity. There is an ongoing WikiCite project for main subject (P921) statements that requires this, and I have worked to clarify the business (see Wikidata:ScienceSource project/MeSH and cleanup dashboard table column 1 and footnotes, for example).

For these reasons, I'm putting the property back to where it was in early January. There is a lot to go over here, and I think it is important that these MeSH issues are seen in context. Charles Matthews (talk) 10:57, 21 January 2021 (UTC)[reply]

Maybe we can propose a property to be added where we can add a Q number as a qualifier to this main property and that will link out to MeSH RDF (since MeSH browser doesn't have individual pages for qualifiers) rather than a whole new property for DQ-numbers? That way the item can also link out to the more human-friendly webpage to show the main heading. Pullen255 (talk) 12:00, 21 January 2021 (UTC)[reply]

@Pullen255: Currently I'm using subject named as (P1810) as qualifier to MeSH descriptor ID (P486) to write the actual MeSH vocabulary term into Wikidata (a property proposal to have a separate string-value property ran into some objections). MeSH descriptor ID (P486) can be used with other qualifiers, and with reference URL (P854) in the reference slot. For example, to get the MeSH RDF page into a place where machines could read it - and I can see that might be desirable - it could be used with P854.

A new MeSH Qualifier property could indeed be sought, and used in the fashion I use P1810; and indeed using P1810 as well, to store the term/qualifier string. The reverse lookup I mentioned ought to be respected. With the constraint taking into account the exclusion of strings with "/", then a SPARQL query would be able to pick out the unqualified value.

So, there are various options here. Charles Matthews (talk) 12:48, 21 January 2021 (UTC)[reply]

Based on this discussion, and with input from additional staff, the National Library of Medicine agrees with the suggestion of the community to leave this property as is. We hope it can become a best practice to include a reference URL that links out the MeSH RDF page so this information can be machine readable and in line with Linked Data ideals. We will also be looking into suggesting a new property for MeSH Qualifier ID that can be used as a qualifier to this property which would supply Q numbers. Pullen255 (talk) 13:35, 4 February 2021 (UTC)[reply]

Would the MeSH Qualifier ID be able to be used as a qualifier for the MeSH Descriptor ID or would it have to be included in its own separate statement? I think it might be useful to be able to use it as a qualifier, for example for item transmission of COVID-19 (Q98456223): MeSH descriptor ID (P486): D000086382, qualified by MeSH Qualifier ID: Q000635 UWashPrincipalCataloger (talk) 18:46, 4 February 2021 (UTC)[reply]

Yes, MeSH Qualifier ID should be usable both as main prop (eg for an item like Prevention), and as qualifier prop (eg for an item like Violence-Prevention). I'll give this example at your property proposal --Vladimir Alexiev (talk) 19:45, 6 March 2021 (UTC)[reply]

Another possibility, other than using described at URL (P973) might be a new property for MeSH strings that links to the MeSH RDF site, where both the descriptor ID and qualifier ID could be combined, so for item transmission of COVID-19 (Q98456223) you could have a new property MeSH String ID: D000086382Q000635, that is an external ID that links to http://id.nlm.nih.gov/mesh/D000086382Q000635. UWashPrincipalCataloger (talk) 18:50, 4 February 2021 (UTC)[reply]

This is not needed and will lead to redundant data and combinatorial explosion. See my comment in the previous section --Vladimir Alexiev (talk) 19:45, 6 March 2021 (UTC)[reply]

Property talk:P486

Contents

Documentation

Distinct values for a cancer vs a neoplasm?[edit]

Allowable constraint violations[edit]

How to Handle Entry Term(s)?[edit]

MeSH descriptors + qualifiers[edit]

MeSH RDF vs MeSH Browser links[edit]

Navigation menu

Property talk:P486

Documentation

Distinct values for a cancer vs a neoplasm?[edit]

Allowable constraint violations[edit]

How to Handle Entry Term(s)?[edit]

MeSH descriptors + qualifiers[edit]

MeSH RDF vs MeSH Browser links[edit]

Navigation menu

Search