User talk:TomT0m

Jump to navigation Jump to search

About this board

Previous discussion was archived at User talk:TomT0m/Archive 1 on 2015-08-10.

Ghouston (talkcontribs)

Can you think of anything for this to be a subclass of? Otherwise, it can't have instances, without violating constraints at least.

TomT0m (talkcontribs)

It’s a subclass of « mathematical class » or something like this (as any complexity class is a mathematical class, in the sense of set theories)

Reply to "Q908207"

Reminder: Share your feedback in this Wikimedia survey

MediaWiki message delivery (talkcontribs)

WMF Surveys, 01:40, 13 April 2018 (UTC)

Reply to "Reminder: Share your feedback in this Wikimedia survey"
MediaWiki message delivery (talkcontribs)

You are receiving this message because you commented at the above RFC. There are additional proposals that have been made there that you are welcome to comment on. MediaWiki message delivery (talk) 03:50, 9 April 2018 (UTC) (for Rschen7754)

Reply to "Wikidata:Requests for comment/Privacy and Living People"

Share your experience and feedback as a Wikimedian in this global survey

MediaWiki message delivery (talkcontribs)

WMF Surveys, 18:57, 29 March 2018 (UTC)

Reply to "Share your experience and feedback as a Wikimedian in this global survey"
Malore (talkcontribs)

I sees "union of" as the sets of parts whose union is the item itself, so a particular case of "has part". Probably I'm wrong. What are your thoughts?

TomT0m (talkcontribs)

No, « union of » is for classes of stuffs (instance of / subclass of) and not for whole/parts relationships (part of (P361) / has part (P527) ) (see Help:BMP for an introduction). Physical objects have parts (my arm bart of my body, mereology (Q1194916) type relation), classes (types) have instances (my arm is an arm). If a class (say « arm » has a statement that states it’s a part of another class, say « body » it means that an instance of the former is a part of an instance of a latter (like with my arm and my body, so arm is part of body).

We can’t really mix up both notions, as the logic is not the same at all behind these two. People are already confused with part/instance sometimes, this would make this worse. Even if we could, this would not fit as « union of » expects a list of values as qualifiers when « part of » expects a single main value, so this means we could not substitute « union of » with « part of » and still get a meaningful value, as it should be for subproperties. This is because we don’t expect that Wikidata has items for all the parts/kind of parts, while « union of » was created precisely to model some kind of completeness.

I proposed something that is an analog of « union of » for physical parthood with Wikidata:Property proposal/fully divised into but it was recently rejected for not enough support, we could reopen it, I guess one more could have been enough, if you want.

Malore (talkcontribs)

I understand, thank you for your explanation (though I think you confused "part of" with "has part").

As regards your proposal, since "union of" exists I don't see why "fully divised into" shouldn't exist. I have only a doubt: is it possible to reach the same result using "has part" with qualifier "expected completeness": "is complete"?

It brings up another question: which of the two is preferable between a subproperty and a property with a qualifier?

TomT0m (talkcontribs)

Actually a better option, I think, would be to use « has part of the type » qualified with a number :

such that if we have

<me> has part (P527) <my left arm>


<me> has part (P527) <my right arm>

we know there is enough statements for all my arms.

The « expected completeness » qualifier approach would be tricky. I don’t actually think this can work. You can have many other kind of parts than « arm », like « legs », and each arm or leg may have its own « has part » statement. To which would you attach the « expected completeness » statement ? Moreother, « arm » or « leg » are both « bodyparts ». Then bodypart completeness would entail arm completeness, for example …

I also don’t like an « expected completeness » because this seems to be like « pure » metadata, an information about the dataset itself and not about the object described by this dataset. We should avoid make these kind of statements if we can.

I think I’ll right an Completeness page at some point. Related : some queries about parts and instance completeness Wikidata:Project chat/Archive/2018/01#Instance completeness

Reply to ""union of" subproperty of "has part""
M11rtinb (talkcontribs)
TomT0m (talkcontribs)

It’s both a rimmed cartridge and centerfire ignition cartridge. It’s then enough to state that

subclass of (P279) means that any example of 11x58mmR (Q17560835) is an example of rimmed (Q29842212) and of 11x58mmR (Q17560835).

Now the key is to describe the different classes. For example centerfire (Q190476) is a type of cartridge, for sure, but in what way is it different from the cartridge that are not of this type ? The type of ignition they use.

This means using a class of class (metaclass see an introduction User:TomT0m/Classification) approach we can use a metaclass « « cartridge ignition type », whose instances are « centerfire cartridge » and « rimfire (Q1289462) »

I added a « item documentation » template to the talk page of the « cartridge » item to demonstrate how it’s useful. The part « Union and disjoint queries » is generated thanks to them. I did not expect this queries to get answor as I did not expect there was item about specific ammunitions on Wikidata instance on Wikidata, (almost only) only types of ammunitions, but the result of the query I copy paste from here types should only be specific object, it seem this is not the case. An instance of ammunition would be « the Bullet that killed JFK » for example. An instance of « Bomb » would be Little Boy (Q181013), « atomic bomb » is not an instance of bomb, just a subclass.

Now seing centerfire (Q190476) I see there is a mess : the frwiki article is about the cartridge type, while the statement states that it’s a percussion type … This should be sorted out by creating an item for the percussion type itself and one for the munition of that type, actually. Then we can think of a property to link both items. I’m thinking an existing property of another project fits perfectly well has disposition. I’ll try a proposal.

Reply to "Cartridge classification"
Yair rand (talkcontribs)

In September, you did a run of petscan adding instance of (P31) unincorporated community (Q17343829) to many items, including many about humans, assorted geographic features, roads, businesses, educational institutions, film studios, golf courses, timelines, etc. Could you take a look at this? Thanks.

TomT0m (talkcontribs)
TomT0m (talkcontribs)

I cleaned what I could, this leaves a lot of unknown however. I used the following queries to find all « unincorporated community » instances (including instances of the subclasses of « unincorporated community » that are instances of another class. I assumed the results may be items with problems.

Other class by other class, I used petscan to clean stuffs up (removed « instance of : unincorporated community » for humans, for example). This leaves a number of class I excluded because : either they seemed compatible with « unincorporated community », either the topic of the item is unclear or mixed up, or I was not sure what to do. This also leaves individual items that may be to cleanup and that are the result of the query.

select ?item ?itemLabel ?val2 {
  ?item wdt:P31/wdt:P279* wd:Q17343829 .
  ?item wdt:P31 ?val2 
        filter not exists { 
          ?val2 wdt:P279* wd:Q17343829 
        filter not exists { 
          # whitelisting some classes for some reason to exclude their instance from the candidates items to clean
          values ?val2 { 
            wd:Q515       # town, those one seems OK
            wd:Q532       # villages, seems OK
            wd:Q751708    # united state village
            wd:Q15127012  # town US municipality
            wd:Q5084      # hamlet, seems consistent
            wd:Q3957      # small town
            wd:Q269528    # seems consistent but may be somehow redundant.          
            wd:Q74047     # ghost city
            wd:Q123705    # neighborhood
            wd:Q486972    # human etsablishment
            wd:Q15642541  # human territorial geographical entity
            wd:Q1620797  # not sure : historical neighborhood in the US
            wd:Q15243209 # not sure  : what to do about that one, historic neighborhood
            wd:Q17362920 # duplicates, not sure either (4 or five articles, candidate for merging ?)
            wd:Q2373919  # not sure what to do, seems consistent however
            wd:Q738570   # business neighboorhood, not sure.
            wd:Q1248784  # military airports, not sure what to do
            wd:Q695850  wd:Q245016 # and air force bases, same     
            wd:Q23002039 # public universities are census designated place, do not know what to do with that
            wd:Q23397    # mixed topic article : both leh lake and its surrounding community. Ideally to split.
            wd:Q55488    # mixed topic, some former station that became populated places (?)
            wd:Q23442    # mixed topic, islands that incorporate communities 
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
} order by ?val2

Try it!

Items for which I added the statement but that had no « instance of » statement cannot be found by this process.

Please let me know if you have any question.

TomT0m (talkcontribs)
select ?item ?itemLabel {
  ?item wdt:P31/wdt:P279* wd:Q17343829 .
  filter not exists {
    ?item wdt:P31 ?val2 filter (?val2 != wd:Q17343829 )
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
} order by ?val2

Try it!

There is quite a few items which are instances of wd:Q17343829 and no other class, but a quick sampling did not reveal anything that seems like a problem in them.

Reply to "Instances of unincorporated community"
Thierry Caro (talkcontribs)

Bonjour. Tu as dit quelque chose dans une conversation récemment qui m'a marqué. Je n'y avais pas pensé, mais c'est très vrai : il faudrait discuter des propriétés à créer non pas une par une mais globalement en fonction des relations qu'il s'agit d'établir entre plusieurs entités. La question est : pouvons-nous faire quelque chose de cette idée ? Il va être difficile de bousculer tout un système de votes, modèles et autres procédures déjà en place. Pourtant c'est vrai que proposer une par une la propriété de A à B puis de B à C alors qu'il faudrait d'emblée regarder A, B, C et D pour savoir que faire de plus pertinent et économe.

TomT0m (talkcontribs)

Je l’ai dit un certain nombre de fois :) le pêché originel c’est qu’il y a un droit de « création de propriété » et que tout s’est organisé autours de ça, les admins demandant une approbation communautaire pour chaque création.

Sinon j’ai plus ou moins obtenu qu’on puisse faire une proposition groupée, mais ça ne fonctionne pas vraiment. Faudrait peut être revenir à un fonctionnement « aligné sur les infobox » mais j’aime pas trop non plus parce que ça aurait tendance à créer autant de propriété que de paramètres d’infobox, je pense, et à pas faciliter la réutilisation pour des sous classes d’objets qui ont des infoboites différentes mais qui sont essentiellement la même chose.

Thierry Caro (talkcontribs)

Ce genre de problème est particulièrement intéressant quand il existe des triptyques (ou même des complexes à quatre ou cinq pôles, plutôt que deux seulement) qu'il faut structurer, à l'exemple du barrage, du cours d'eau et du lac de barrage évoqués récemment dans plusieurs discussions. C'est alors qu'une procédure plus large serait nécessaire. Mais je ne sais pas si ce genre de configuration est fréquent, d'un autre côté.

Reply to "Création de propriétés"
Reseletti (talkcontribs)

At least some amount of statements you added back in October 2015 that claim that some software to be written in the C++ programming language seem to not be verifiable anywhere. (like e.g. TweetDeck and Lingoes) I removed some of them. Maybe you want to check.

TomT0m (talkcontribs) on the enwiki,s category « free software programmed in C++ on enwiki’s article. If this is not correct, the category needs to be clean as the datas probably comes from here.

Reseletti (talkcontribs)

That just goes to say that the problem is even bigger? Or that you are willing to take care of these erroneous edits of yours if I fix stuff over there?.. :-/

TomT0m (talkcontribs)

That goes to say that the mistakes have to be corrected also on Wikipedia to prevent this to happen again. And that we have a tool to spot mistakes on enwiki.

Suggestion : is there correspondings category on dewiki or frwiki ? We find them, if there is, and we find mistakes candidates by computing the differences with them and wikidata on petscan.

Reply to "wrong programming language?"
VIGNERON (talkcontribs)
TomT0m (talkcontribs)

Ben c’est une entité admissible, dans tous les cas. Je travaille à Module:Class et à Template:Implied_instances actuellement. L’idée c’est de générer une requête sparql automatiquement à partir des déclarations de la classe (et de ses parentes) gui permet de lister ses instances. J ete tiens au courant des progrès.

VIGNERON (talkcontribs)

D'accord. Pas entièrement convaincu mais pourquoi pas. À déployer sur toutes les capitales de région ?

Sinon, j'ai remplacé Loire-Atlantique par Pays de la Loire en qualificateur.

Reply to "Que faire de Q20899166 ?"