Wikidata talk:WikiProject Ontology/Archive for 2024

Subclass cycle

Would some ontological expert like to solve the subclass cycle of knowledge (Q9081)subclass of (P279)memory (Q104127086)subclass of (P279)information (Q11028)subclass of (P279)knowledge (Q9081)? There are a few other triplet subclass cycles as well that come up in a query but this is probably the most serious one. All complex violations of P279 are listed here if someone wants to have a look. Samoasambia ✎ 01:41, 5 February 2024 (UTC)

Order of properties: P279 just after P31 or not

It has been proposed to move P10241 individual of taxon and P289 vessel class to directly after P31 instance of and before P279 subclass of. I would like your comments on the proposed new order; I will apply the change on March 9 if no objection is presented. Thanks, --Epìdosis 19:09, 1 March 2024 (UTC)

It was explained that the proposed change is not a change to ontology. Could you explain why without providing reasoning to the contrary, you bring this up here? CV213 (talk) 19:35, 1 March 2024 (UTC)

I am not the original proposer but let me explain why I both think this is a good idea and why it is relevant to the ontology project.

The main ontology properties are instance of (P31) and subclass of (P279) so any change to how they work or how they are presented is relevant to the ontology project. Both individual of taxon (P10241) and vessel class (P289) are subproperties of instance of (P31) so they are also relevant to the ontology project via their connection to instance of (P31). Both individual of taxon (P10241) and vessel class (P289) should be placed near their superproperty, which, in my view correctly, puts them in the area where ontology properties are displayed. Of course, this does not *change* the data related to the Wikidata ontology, just its presentation.

But this proposal does not, in my view, go far enough. There are other properties that are relevant to the ontology of Wikidata and thus should be placed near instance of (P31) and subclass of (P279), such as is metaclass for (P8225). Peter F. Patel-Schneider (talk) 19:56, 1 March 2024 (UTC)

You can make a different proposal for more changes. CV213 (talk) 20:00, 1 March 2024 (UTC)

Wikidata:WikiProject Ontology/BFO

Wikidata:WikiProject Ontology/BFO @Peter F. Patel-Schneider: fyi. CV213 (talk) 19:33, 1 March 2024 (UTC)

@Peter F. Patel-Schneider: it would be helpful to have a property BFO ID to easily find the BFO classes without using instance of BFO class or exact match "http://purl.obolibrary.org/obo/BFO_0000..." CV213 (talk) 20:01, 1 March 2024 (UTC)

Reasonable, I suppose, provided that Wikidata ID properties are supposed to be used for this kind of purpose. But then all similar relationships should use ID properties, like relationships to the Cyc ontology and many other ontologies. And this only works for strictly exact matches. Uniformity and flexibility is more important here than having the precise best kind of relationship. Peter F. Patel-Schneider (talk) 20:06, 1 March 2024 (UTC)

If something doesn't "strictly exact match" then a different item could be created. Not sure for how many ontologies this should be done, but BFO is a TLO and an ISO ontology, so to have the classes here "exactly" and to easily find them, should benefit interoperability. CV213 (talk) 20:14, 1 March 2024 (UTC)

Q124711104 was created to find them via Special:WhatLinksHere/Q124711104. A property would be better. CV213 (talk) 20:03, 1 March 2024 (UTC)

What is this item about? It lacks a definition and external references, but it is suddenly supposed to be used on important items of the ontology. —MisterSynergy (talk) 20:47, 1 March 2024 (UTC)

The item represents the metaclass of which all classes defined in BFO at some point in time are instances of. CV213 (talk) 22:05, 1 March 2024 (UTC)

@Peter F. Patel-Schneider: what is your opinion about having

1. items for each BFO class
2. an item of which the former are instances of
3. a project page listing them (currently at Wikidata:WikiProject Ontology/BFO)

in Wikidata? CV213 (talk) 22:09, 1 March 2024 (UTC)

Andrea Westerinen knows more about this, I think. Peter F. Patel-Schneider (talk) 22:30, 1 March 2024 (UTC)

@AWesterinen: is it you who Peter referred to and do you know more about his opinion regarding the questions above? CV213 (talk) 22:50, 1 March 2024 (UTC)

Wikidata:Property proposal/BFO class ID

Wikidata:Property proposal/BFO class ID fyi. CV213 (talk) 23:18, 1 March 2024 (UTC)

more facilities for disjointness in Wikidata?

I have put together a proposal for a new way of stating disjointness in Wikidata at https://www.wikidata.org/wiki/User:Peter_F._Patel-Schneider/disjoint. Please let me know whether you think that there should be more facilities for disjointness in Wikidata and whether the approach is reasonable. Peter F. Patel-Schneider (talk) 18:30, 22 December 2023 (UTC)

@Peter F. Patel-Schneider Hi Peter, I commented on the talk page, I proposed a way to do the exact same thing just with the current properties. I think it's not worth the effort to require new tooling. Did you see it ? If this is the case, do you agree and can we close the topic (it's been a few month now, maybe you just did not see the comment) author  TomT0m / talk page 10:23, 21 March 2024 (UTC)

Allow false claims due to storage space limitations and a claimed need to be pragmatic

Example: Talk:Q1402057 , a user seems to suggest to conflate a publication (identified by ISSN) and an organisation (identified by ISNI).

The user is aware of the disctinctions, claims it to be subtle: "The newspaper vs the organization can be a subtle distinction, yes, but it's important to consider that Wikidata's storage space is limited and that we need to be pragmatic re: the usefulness and maintainability of different items." CV213 (talk) 15:31, 3 March 2024 (UTC)

What is the point here?

There are indeed technical limitations that make a substantial growth of Wikidata based on today's size impossible. The Query Service operates in a difficult condition for years meanwhile, with no clear solution on the horizon. The reason is that graph databases do not scale particularly well horizontally, so all of Wikidata needs to fit into memory of a single machine for the Query Service.

Whether this should affect our editorial decisions is another question, though. —MisterSynergy (talk) 16:03, 3 March 2024 (UTC)

The point here is that someone insists on having false claims stored in Wikidata items. Real word entities form the domains:

1. publication (identified by ISSN) and
2. organisation (identified by ISNI)

are clearly disjoint, but user insists on conflating them into one item. @Epìdosis: admin help desired, while discussion is ongoing, the pro-conflation user merged the items. CV213 (talk) 21:25, 3 March 2024 (UTC)

Tired of wasting time. Block evasion: sock puppet of User:Tobias Conradi. Blocked CV213 like the previous sock (Ac2wd). Multichill (talk) 18:57, 4 March 2024 (UTC)

Disjointness

Currently uchiwa (Q1056134) has a disjointness violation due to widget (Q2467478) which a commercial concept, it's both a concrete and an abstract object.

The issue seems to be that a "widget" is a subclass of unit, so an abstract object, concept used in accounting. Maybe it should be an instance of unit ? author  TomT0m / talk page 10:28, 21 March 2024 (UTC)