Wikidata talk:Item classification/Archive 2

Nuclide subclass of changed from Atom to Class

@Emw, Micru, Zolo, Succu, GerardM: User:TomT0m changed the subclass of-property of "nuclide" from "atom" to "class" [1]. That means all nuclides are now out of the physical object tree. en:Nuclide says "A nuclide (from nucleus) is an atomic species". I understand "is an atomic species" to mean "is a subclass of atom". Tamawashi (talk) 16:18, 26 July 2014 (UTC)

The statement "nuclide subclass of class" is essentially meaningless. Statements with relevant information for the given domain, e.g. "nuclide subclass of atom", are clearly preferable. I would support restoring the original statement. Let's see what others think before making any changes. Emw (talk) 17:08, 26 July 2014 (UTC)

@Emw: It's not a matter of opinion. If <the hydrogen atom in my teacup> is an instance of <hydrogen atom>, and <hydrogen atom> is a subclass of nuclide, which I understand is a statement you could make, then <the hydrogen atom in my teacup> is an instance of nuclide. Translating A nuclide (from nucleus) is an atomic species An (instance of) nuclide (from nucleus) is an atomic species, this becomes <the hydrogen atom in my teacup> is an atomic species.. Meaningless.

Once more this would make nuclide an equivalent class of atom, like Emw claims isotope is also, which seems meaningless as well to me. Emw, any answer of CheBi yet ? TomT0m ^(talk) 10:17, 27 July 2014 (UTC)

Isotope of hydrogen disconnected from hydrogen

@Emw, Micru, Zolo: User:TomT0m disconnected the class "isotope of hydrogen" from "hydrogen" [2]. Now one cannot derive the number of protons, the period, the main group, the chemical symbol etc. anymore. Tamawashi (talk) 04:58, 27 July 2014 (UTC)

Your statement don't make any sense at all. Derive how ? I did not disconnect anything. TomT0m ^(talk) 10:10, 27 July 2014 (UTC)

@"Derive how ?" Do you at all understand classification? "I did not disconnect anything." - you mean this page is illusion and does not show that you disconnected "hydrogen" and "isotope of hydrogen". Tamawashi (talk) 14:52, 27 July 2014 (UTC)

Luminous blue variable star and P881

@Izno, Emw, Paperoastro, Micru: luminous blue variable (Q742741) is a class but has no instances nor subclasses, the WDQ is:

claim[31:(tree[742741][][279])] or claim[279:(tree[742741][][279])]

The item AE Andromedae (Q2819147) via type of variable star (P881) links to luminous blue variable (Q742741). Izno suggested on the talk page of P881 that P881 could be replaced with P31.

Paperoastro wrote at that talk: "It is a question of semantic: where do we stop P31? We can classify all with P31! Brad Pitt (Q35332) "is a" -> person, not "is a" -> actor" plus "is a" person with light hair" without use properties for job or colour of hair."

One difference is: "person with light hair" is not a class in Wikidata, while luminous blue variable (Q742741) is. What do you think? Tamawashi (talk) 15:09, 27 July 2014 (UTC)

1. Why not? We can create classes for colour of hair as for jobs, sex, religion, and so on for people.
2. I try to follow suggestions that [[User:Emw|] gave here, i.e. avoid a lot of statements of P31 in the same item.
3. To avoid confusion, we can rename P881 as variability: the meaning is the same.

--Paperoastro (talk) 16:37, 27 July 2014 (UTC)

@Paperoastro: To go further and rely less or just feelings like bad smell, I think we need a more robust foundation for instance of (P31) uses : the notion of class expression. A class expression in OWL, is an intensional definition (Q1026899)    . I think that, when some class is defined by a function on some other basic properties, there is no reason to create a new properties and more rely on robust foundations like the one of OWL languages. For example if some class of stars is defined with respect to the sze of the star and its color spectra, if we have a property spectra, a property size, we can define the class giant red starstar by a class expression stating a giant red star is a star with a range of spectra beetween X and Y and size>value. That way we have all but an abuse of instance of (P31) use : we got a class, used by astronomer hypothetically, whose membership is verifiable, we can detect an inconsistency if someone say a star is a giant red star to a small star, with well and regular foudation, by doing an actual use of properties. This means we give more sense to classes and actually use the properties values and our datas using a well defined mechanism.

In a word, a use of instance of (P31) can be justified if we have a class expression, like big town =def town > 10 000 inhabitants, we got a class expression combining two properties of the item. Imho this is also an opportunity to find out bad edits as someone who do not care could change a property and cause an inconsistency : if someone change the number of inhabitants of a city to 10 000 people where the town is actually a big town while not removing the instance of (P31) < big town > statement, this could raise a constraint report error (assuming we got a bot who knows the class expression and checks consistency of the values of the properties of the claimed instances of this class with the class expression.) Hence an opportunity of constraint report if you see the class expression as a constraint.

We chose the generic path for classification : this is imho justified by the fact we can build generic mechanisms that benefits any field. This is an example of why this choice is meaningful, otherwise it is not : use generic mechanism to class, but not actually use them to build tools, it is like making learn something to community for no outcome but headeachs. TomT0m ^(talk) 09:45, 28 July 2014 (UTC)

Hi TomT0m, I forgot to put luminous blue variable (Q742741) in the right classification scheme (see discussion page of type of variable star (P881)). Your arguments concerning constraint can be applied (if I understood correctly) also to P881. My idea is to avoid items likes Betelgeuse (Q12124): the P31 have three statements: one redundant (star), but I can add also P31 -> M-type star (Q14745304). All of these are not overlapped each other. What of these Wikipedia will use? How Wikipedia templates (as Template:Starbox character) can recover variability type for the right field? How we can query through items characteristics so different all together in one property? --Paperoastro (talk) 12:04, 28 July 2014 (UTC)

I don't see any problem with adding type M star : it is a legitimate class of stars usable by astronomers, well defined and so on. Our classification system is OK to express this using very few concepts and only two properties, this is a good thing imho. I don't understand the template you linked but I think it would be interesting to work on this to see how it can really be simplified creating a Lua infobox. Soon we will be able to access other item datas using luas, which will allow to do more elaborate code for those kind of complex infobox : to know the variability type, for example, we will be able to access the datas of all instance of (P31) values of the star, and go up the subclass tree, the way we already shows superclasses tree in {{Classification}} using {{Tree}}. We can already know easily know if an item is a star (is instance of (P31) <star>) checking this tree just checking if <star> is in this superclass tree, this is a simple test. If one of those class is known to be a star variability type, then we will know which one it is (and the infobox will even be able to put inconsistencies in hidden categories like star with inconsistent claims). You say what is doable with a generic classification property is doable with a specific one is possible, that's mostly true, but still, is not the specific classification property actually a burden in the end ? It's just not needed. We got something that is powerful enough to release the burden of creating and maintaining tons of typing properties, and there could be quitillions of those, using generic mechanisms.

The other tool I propose to use is class classification. For example if luminous blue variable (Q742741)    is a type of variable star, I propose to put a

⟨ luminous blue variable (Q742741)    ⟩ instance of (P31) ⟨ variable star type ⟩

statement to this class. Then we know this class is used to class stars using their variability criteria. Actually the variable star type property is actually kind of weird, it adds an information just by beeing present : if we know this statement is present, then we know the star is a variable star, which could be stated easily using instance of (P31). Worse : imagine we have a type of star property, a type of variable weird star, a type of variable star, which is the kind of things we will have if we multiply typing properties, we will end up having weird unformal rules like "if we got a type of variable star statement, then we don't need a type of star statement" that look very close to "if the item is an instance of a A-class star, then the instance of (P31) is redundant because A-class star is a subclass of star", except the subclass relation is well defined and makes that rule implicit : we just have to put a subclass of (P279) statement, and the definition of subclass of (P279) makes the rest : we can handle this using generic rules and a statement, and not creating some weird specific rules more or less well and informally beetween specific typing properties. It's simpler and works in every fields.

The infoboxes, with this tools, have enough informations to sort things out : if a star belongs to several classes, the infobox can choose the one that is of interest for it : let's say

⟨ luminous blue variable (Q742741)    ⟩ instance of (P31) ⟨ Variable star type ⟩

, and the infobox wants to show how the information both that it is a variable star and whose kind of variale star it is.

The first step is to know if it is a variable star. Assuming we use a {{Infobox star}} template and that the item is a star, then the infobox can check if <variable star> is in the set of superclasses of the star (possible, {{Superclass Tree}} already does show the superclass tree). Then it may want to show a more specific classification information for this star : then it can search to know if, amongst the superclass tree item set, there is a class who is an instance of <Variable star type>, and only those classes which we know belongs to the standard classes used by astronomers to class variable stars. And it's enough.

This way of choosing the information is generic : it can be used as is for other infoboxes, just replacing the <variable star> and <type of variable star> items with new ones, which means they can be parameters of some lua module function reusable in any other infobox just like that. TomT0m ^(talk) 18:59, 28 July 2014 (UTC)

Ok, "it is one way as another" to organize informations. I like the items <"something" type>: it can be used to choose the correct items for the hierarchies. I have a doubt: this type of organizations will replace also sex or gender (P21) and occupation (P106)? The hierarchy is ready... --Paperoastro (talk) 20:55, 28 July 2014 (UTC)

Why would they replace those properties ? I gave by the notion of class expression how classes and those properties are related, for example the class expression of younger sister (Q15634710)    could very well be defined as the set of items As who are instance of (P31) <human> AND sex or gender (P21) = woman/female AND there exists a B such that

⟨ A ⟩ is brother or sister of Search ⟨ B ⟩

. This is not a substitution. But this expression is very similar to a query, so we may have to wait a little for Wikibase to be fully implemented to see how queries will work before taking final decisions :) TomT0m ^(talk) 21:23, 28 July 2014 (UTC)

@TomT0m: You are forgetting that the female subject has to be the younger one :) It is a complex example, but you could also use "instance of:<little siter>" with qualifier "of". But, yep, for those cases would be better to wait and do it the proper way.

@Paperoastro: The tree of human that you posted has some serious mistakes. For instance scientist (Q901) is not a subclass of "human", at most you could say "role of:human", which is the inverse property of "has role".--Micru (talk) 10:04, 30 July 2014 (UTC)

Thanks Micru, I chose a wrong example! --Paperoastro (talk) 19:29, 30 July 2014 (UTC)

@Micru: It may be an interesting case. After all, there is a set of human who are actually professor. How do you define a "role", a patterns of behavior that someone as ? Someone who is supposed to have the pattern of behaviors "teaching" is defined as having the role "professor" ? But the tokens in the real world are the actual teaching events. So ... is not professor the class of all persons who exhibits the "teaching" pattern of behavior for a living, in the spirit of classification of tokens such as "person" and "teaching event" into class ? This work also if we call "professing" a pattern of teaching event by some person. TomT0m ^(talk) 19:52, 30 July 2014 (UTC)

@TomT0m: That is another property <lesson> has agent <professor>.--Micru (talk) 20:24, 30 July 2014 (UTC)

@Micru: I don't follow you, this seems to be independant from whether or not the <professor> item is a subclass of <human> or not. The agent in the case of a lesson is certainly humain. Or a living organism at least. Role does not seem to make sense in the class/token distinction principle, except for the class of real world organisms who plays it. Why can't we say "a professor is someone who teach for a living" ? Then it's obvious that that class is a subclass of <human>, as the set of person who teached in their life is a set of humans, obviously. TomT0m ^(talk) 21:29, 30 July 2014 (UTC)

@TomT0m: You are mixing occurrants with continuants. "To be a professor" is an event that happens on and off, there is nothing in the nature of a person that could tell you that the subject is a professor or not. A person can "start being a professor" and "stop being a professor", but that doesn't affect their human condition. Yes, in natural language we use "is a" because people might identify themselves with what they do, but that is just a social, linguistic, or mental construct, not reality.--Micru (talk) 22:09, 30 July 2014 (UTC)

@Micru: I'm not convinced. A person can born and die as well. The occurence of traching makes a person a teacher. It's an event in the life of a person that change its social status and make him part of the class of all persons who ever teached in their life. TomT0m ^(talk) 11:56, 31 July 2014 (UTC)

@TomT0m: Imagine that you say that "<person A> instance of <teacher>", and "<teacher> subclass of <human>. By those statements you are declaring that while <person A> is a teacher, then he or she is also a human, but when <person A> is NOT a teacher, or stops being a teacher, does <person A> stops being a human? And why to overuse that method when we have the occupation property?--Micru (talk) 13:29, 31 July 2014 (UTC)

By those statements you are declaring that while <person A> is a teacher, then he or she is also a human, but when <person A> is NOT a teacher, or stops being a teacher, does <person A> stops being a human? Absolutely not, why would this be that way ? This is a set inclusion, or a logical implication (logical implication (Q7881229)    )depending on the point of view, not an equivalence (see contraposition (Q1077442)    for the correct thing you're trying to do). Not beeing a professor do not imply not beeing a person by any logical reasoning standards, so certainly not in well defined logical systems like Description logics or OWL. And why to overuse that method when we have the occupation property? We have to better understand what is an overuse before claiming there is overuse :) Imho professor is a socially widely used class, whom, if there was admissibility criteria, would meet the criteria very easily :) TomT0m ^(talk) 14:21, 31 July 2014 (UTC)

But given that the profession is something that starts after the person is born, you would need back up statements. I mean, you are not saving any work, and you want to use a generic statement for something where a more specific property already exists (occupation (P106)). TBH I don't know what you want to accomplish...--Micru (talk) 14:32, 31 July 2014 (UTC)

Btw, those cases are called in BFO specializations in contraposition to universals.--Micru (talk) 15:12, 31 July 2014 (UTC)

@Micru:occupation (P106) is certainly not a specialization of instance of (P31), not it replaces it. But what could link them is the notion of class expresssion. Let define the professor class as the set of all person who have occupation (P106) <professor> as a statement. Here we go. But what puzzles me actually is, wrt. the class/token relationship, what is a profession, an occurence or a pattern of intended behaviors ? Clearly the act of teaching is an instance of teaching. The set of all this occurences is a school year. But for the <professor> concept, are there instances, below the different affectations a teacher can have ? TomT0m ^(talk) 17:11, 31 July 2014 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I'm sorry you are questioning... Micru expressed better than me what I wanted to say. All of you are talking about two (valid) different conventions. TomT0m, why not <person A> is a teacher with teacher subclass of human? When <person A> finishes to be a teacher, he became another subclass of human or simply an human. The same for star variability: stars became a variable in some moments of their life, so they start and stop variability as <person A> starts and stops to be a teacher. Conceptually, organize stars characteristics as TomT0m suggests and people in the same manner, for me it is the same:

• Betelgeuse is a -> 1) red supegiant; 2) semiregular variable star; 3) star of class M
• <person A> is a -> 1) male; 2) teacher.

So why we can use sex or gender (P21) and occupation (P106) and we cannot use type of variable star (P881) or other similar properties? --Paperoastro (talk) 17:15, 31 July 2014 (UTC) P.S.: TomT0m, you conflict me, I wrote without read your last comment.

In Wikidata we have qualifiers who can sort out some of the problem of intermittent class membership. Some object can be a member of a class, or said differently, satisfy the conditions to be a member of some class, for example the non relevant "person who lives in New-York and leaved in Los Angeles boefore", at some interval in their life. Similarly, a star can change its star class at some point. The we can qualify the membership of the class by the date of validity of the class membership property satisfiability period. It's not different from any other property imho. Last, as I seem to fail to be able to explain, class membership in systems like OWL can be an Special:ItemByTile/en/Intensional definition. This definition can use the other properties and their values on the statements. But what is important imho wrt. specific classification property is that specific properties are no more powerful than instance of (P31): any specific explicitly typing property is substituable with instance of (P31), so any tool using instance of will work to class everything using the same principles : division of objects into classes. In a nutshell : instance of (P31) is good enough for classification, so per Ockham rasor it's good enough for everything. BUT instance of (P31)/subclass of (P279) needs other properties to define the intensional definitions (the class expressions), for example if we know the luminance of every stars and that luminance is used to class star, we can use the luminance property to write class expressions to class stars. SO : to class star by lumincance, we mainly need their luminance value. No specific property is needed as the generic classification system can already be used to class star by luminance, and even a lot more complex expressions. Which means, from a toolset POV, that we just need one toolset to class everything. In these conditions, why should we create one toolset for every typing properties we could want to create ? TomT0m ^(talk) 19:05, 31 July 2014 (UTC)

@TomT0m: But what puzzles me actually is, wrt. the class/token relationship, what is a profession, an occurence or a pattern of intended behaviors ? According to this paper, a profession is clearly a role.

I'm in favor of intensional definitions for classes. I also think that we would have more expressivity by creating a property has_quality.--Micru (talk) 00:10, 1 August 2014 (UTC)

@Paperoastro:, good point with property examples! I see no difference between type of variable star (P881), sex or gender (P21) and occupation (P106). I believe that (technically) they all are replaceable with instance of (P31). But it can be inconvenient for some reasons. So we should derive common policies for such properties. Some consensus can be in using subproperties. --Infovarius (talk) 10:47, 10 August 2014 (UTC)

Thank you, Infovarius. I'm right with you. Do we know when (or if) subproperties will be available? --Paperoastro (talk) 13:42, 10 August 2014 (UTC)