Wikidata talk:Item classification/Archive 1

From Wikidata
Jump to navigation Jump to search

Subclasses and instances

@Emw: @Pasleim: @Magnus Manske: @Filceolaire: @GerardM: You took part in Talk:Q35120#Instances of something else than entity, I created Wikidata:Subclasses and instances to document relations between P31, P279 and Entity. Tamawashi (talk) 06:22, 9 July 2014 (UTC)

Class of classes

Sometime it's useful to regroup classes themselves in class of classes in ways that are not totally modeled imho with subclass of, who relates classes to classes.

For example in Wikidata we use biological taxonomy classes and other classes of animals like animal breeds. Every example of breed is a subclass of a species, though we might be more precise about the breed itself and say something about that class : a breed is usually defined by a breed club organization like AKC, who says which dog belongs to which breed according to its standards.

I think it's useful that we use instance of (P31) to class those classes. for example

⟨ Akita ⟩ instance of (P31) View with SQID ⟨ AKC Breed ⟩
. <AKC Breed> is itself a class of class, hence
⟨ AKC Breed ⟩ subclass of (P279) View with SQID ⟨ Class ⟩
.
Classification of the class dog (Q144)  View with Reasonator View with SQID
For help about classification, see Wikidata:Classification.
Parent classes (classes of items which contain this one item)
Subclasses (classes which contain special kinds of items of this class)
⟨dog⟩ on wikidata tree visualisation (external tool)(depth=1)
Generic queries for classes

Dog has currently about 80 subclasses, this is useful metadata to understand a subclass tree. Akita would then have both a instance of (P31) and a subclass of (P279) claims. See [31&mode=cat_no_wdq&run=Run&label_contains=&label_contains_not=&chunk_size=1000 this request] for a list of items who have both. And because we actually use several classification systems in Wikidata, defined by different organisms.

To be correct, items like <AKC breed> would probably have to be in the subclass tree of the <Class> item. TomT0m (talk) 12:40, 9 July 2014 (UTC)

PS: note that this way of doing subsumes the taxon rank properties (looking at the <dog> superclass tree it seems worth mentioning : each of dog superclass can be tagged instance of (P31) <taxon>, instance of (P31) <clade>, instance of <genera> and so on. <clade>, <genera> and <taxon> are essentially class of classes used by biological taxonomy. TomT0m (talk) 12:52, 9 July 2014 (UTC)

Rooting reverted

I rooted dog to entity (Q35120) but was reverted [1] by User:Succu. Tamawashi (talk) 15:54, 9 July 2014 (UTC)

Before starting to rearrange everything on a fundamental level, first discuss why you want to do the weird thing. - Brya (talk) 17:24, 9 July 2014 (UTC)
(re-insert comment [2] deleted by User:Succu): I don't want to rearrange everything on a fundamental level. I just did apply "subclass of" to dog. Is the class "dog" not a subclass of entity (Q35120)? Or of mammal? Tamawashi (talk) 17:37, 9 July 2014 (UTC)
Tamawashi, I simply removed a property. as you did per Widar a lot. No revert was involved. --Succu (talk) 18:46, 9 July 2014 (UTC)
I added a statement, you removed the statement. Correct, you didn't use the "revert"/"undo" option. So instead of "Rooting reverted" one could speak of "de-rooting" or "unrooting", OK? @Widar The property I mostly removed is GND main type, I do it when it can be inferred from the subclass tree. You didn't add another statement that could one let derive the removed one. When Tamawashi (talk) 10:32, 10 July 2014 (UTC)

Rooting of Craniata (Q84149) undone [3] Tamawashi (talk) 23:40, 10 July 2014 (UTC)

Rooting of Homo undone [6] Tamawashi (talk) 17:21, 11 July 2014 (UTC)

Taxon rooting

As of 2014-07-09 there are 848,643 items that have a claim parent taxon (P171) and are not rooted. [13]. They could be easily rooted by a bot. (by User:Tamawashi)

parent taxon (P171) and subclass of (P279) are not the same. A little bit more taxonomic understanding could help. I'm tired to repeat this again and again. BTW: around 1,000,000 items lacking parent taxon (P171). An what about the rest (around 13,000,000 items). --Succu (talk) 17:40, 9 July 2014 (UTC)

@Succu: Instead of repeating just create documentation or point to an existing one. Tamawashi (talk) 10:12, 10 July 2014 (UTC)
You'll find a description about how we are modeling taxa at WikiProject Taxonomy. There, at project chat and at the property proposal pages you'll find the discussions why we do not treat every taxon as a separate class. --Succu (talk) 15:22, 10 July 2014 (UTC)
That's running away from my suggestion. Nobody asked for what you do, but why "subclass of" could not be used. Tamawashi (talk) 17:18, 11 July 2014 (UTC)
Exactly what was your „suggestion”? --Succu (talk) 21:27, 16 July 2014 (UTC)
See the one and only sentence I posted here before the alleged run away happened; it starts with "Instead". Tamawashi (talk) 01:53, 22 July 2014 (UTC)

Subproperty relation

RDF schema defines a SubProperty relation between properties with the possibility to search across subproperties as well as the property.

This relation is not yet supported by Wikidata yet but there is a bugzilla item for it. Once this is available then we can mark 'parent taxon' as a subproperty of 'subclasss of'. This may take a while. Filceolaire (talk) 19:13, 10 July 2014 (UTC)

Doing this was discussed some months ago. ;) --Succu (talk) 19:20, 10 July 2014 (UTC)
instance of (P31) and subclass of (P279) highlight a unifying structure for human knowledge. Subproperties of instance of and subclass of would obscure that. Aside from 2 properties out of 1411, there are no such domain-specific subproperties. The trend has been to reject or delete such properties, e.g. type of structure (P168), type of election (P173), watercraft type (P288), mountain type (P302) and, just recently, type of astronomical object (P60).
There are several reasons for this approach to classification:
  • There should be one -- and preferably only one -- obvious way to do something. instance of (P31) should be used to classify all instances and subclass of (P279) to classify all classes. Having many, many different properties that specify the type of a class would be confusing for users. It would be better to have only one obvious way to specify the type of a class, not dozens or hundreds.
  • The criteria for domain-specific "type of" properties are arbitrary, laying the groundwork for a proliferation of them.
  • The conventional way to do classification in the Semantic Web is with instance of (P31) and subclass of (P279), and not domain-specific subproperties of them. No major Semantic Web ontologies use domain-specific subproperties of instance of or subclass of. They use only those two properties for classification: one for instantiation, and one for subsumption.
For reference, the most relevant discussion about the relation of instance of and subclass of in WikiProject Taxonomy is Wikidata_talk:WikiProject_Taxonomy/Archive/2013/12#Simple_proposal_of_classification_using_instance_of_and_subclass_of. The opposition to using subclass of in that discussion hinges on a misconception, that it is valid to declare subproperties of rdf:subClassOf (more on this below). It is standard practice in the Semantic Web to use rdfs:subClassOf to specify parent taxon, as can be seen in the NCBI taxonomy and the UniProt ontology. Note how UniProt uses precisely the approach to classification proposed in the linked WikiProject Taxonomy discussion -- subclass of, not parent taxon.
Beyond that, subproperties of instance of and subclass of are not valid in OWL 2 DL, the main language used by Semantic Web ontologies. Instance of and subclass of have the semantics of rdf:type and rdfs:subClassOf. These are terms from OWL's reserved vocabulary, and are thus not valid to use rdfs:subPropertyOf with in OWL 2 DL per the OWL 2 Structural Specification. Declaring subproperties of those two built-in pieces of vocabulary would make our ontology undecidable for reasons explained in this paper. As people like Markus Krötzsch will tell you, we really want the Wikidata ontology to be decidable.
Subproperties of instance of (P31) and subclass of (P279) are technically invalid, not used in any major Semantic Web ontologies, and make it more difficult to discover basic, unifying properties on Wikidata. We should avoid them. Emw (talk) 04:22, 11 July 2014 (UTC)
„It is standard practice in the Semantic Web to use rdfs:subClassOf to specify parent taxon, as can be seen in the NCBI taxonomy and the UniProt ontology.” Emw, the problem is NCBI and UniProt are taxonomic authorities of their own. They can determine which scientific names they accecpt and whats the relation to higher taxa is. Wikidata can not, because we have to reflect a bunch of those opinons. --Succu (talk) 19:52, 11 July 2014 (UTC)
Succu, the problem of multiple authorities is not addressed by parent taxon. It has the same handling as subclass of would. Your point is interesting, but seems independent of the question at hand. Emw (talk) 00:06, 12 July 2014 (UTC)
It is as you can see at Cactaceae (Q14560) and other plant families. --Succu (talk) 06:58, 12 July 2014 (UTC)
@Emw: "Aside from 2 properties out of 1411, there are no domain-specific subproperties" - could you name them? Tamawashi (talk) 11:58, 11 July 2014 (UTC)
Tamawashi, the only two domain-specific subproperties of instance of or subclass of are parent taxon (P171) and P132 (P132). The latter is the subject of a deletion discussion (permalink). It's stalled mostly because of a lack of interest in a migration plan, which could be achieved with a few new everyday properties and some work, perhaps using the roadmap for deletion of 'type of astronomical object' as an example. Emw (talk) 12:17, 11 July 2014 (UTC)
@Emw: P202 (P202), voice type (P412) found via Wikidata:List of properties/all in one table. There are more occurrences of the string "type" on that page. Tamawashi (talk) 12:51, 11 July 2014 (UTC)
@Emw: I found P133 (P133). I included the ones you mentioned and the others in the page. If you see more, I am happy you add them. Tamawashi (talk) 14:18, 11 July 2014 (UTC)
@Tamawashi: there is more on Help:Modeling. TomT0m (talk) 18:09, 11 July 2014 (UTC)

Relation between this page and the classification help page

Hi @Tamawashi:, what's the relation beetween this page and help:Classification ? I see you push the use of this page, but its scope and the purpose of this page is not really well defined. The terms like rooted are not explicited for examples, it looks like an introduction or an help page but started like a statistical page.

What are you aiming to do here ?? The help on classification in Wikidata has already at least two pages : Help:BMP and Help:Classification, is this really a good idea to duplicate some of the content and start new pages without guidelines ? Let's work together ...

TomT0m (talk) 14:46, 11 July 2014 (UTC)

Statistics should best go to Database reports. The help page looks as if being made for beginners to classification ("Me, the writer, you, the reader, and everybody who ever read this page"). The page Wikidata:Item classification could show more about the development, something not needed in the help page. Both help pages are linked from Wikidata:Item classification. Tamawashi (talk) 14:57, 11 July 2014 (UTC)
It's OK to link but should not we discuss a little bit to what belongs where than just assuming from pages that looks like something ? As the writer of Help:Classification I am open to discussion and contribution about its scope, it's not meant to stay as it is. I think that item classification here is a bad title : are we actually classifying entities, items, or real world objects mapping to items for example ? TomT0m (talk) 17:34, 11 July 2014 (UTC)
@TomT0m: - see the page, and follow the link for the first occurrence of the word "item" below the page title. There you find how "item" is defined. If that is not what the page is about, please tell me what it is about. Tamawashi (talk) 03:11, 12 July 2014 (UTC)

Terminology

@Tamawashi: @Emw:

I think unrooted entity is a bad terminology. First, a Wikidata entity can be a non item like a property, so it's confusing into a page named Item classification. Second, it refers to the fact that every instance is supposed to be an instance of the top class. Which is then the root, by definition. But in our pure wikipedia item like disambig items, assuming we really got such things as pure wikipedia or wikimedia items, then their classes can be rooted somewhere like in the wikipedia concept class. In short there can be several roots.

What's the purpose of the unrooted entity terminology exactly ? TomT0m (talk) 20:26, 11 July 2014 (UTC)

My bad, it's unrooted instance. But the terminology is still problematic in a project page. Are we referring to the class/instance relationship, the token/class relationship ? We should be top clear and think well on that. TomT0m (talk) 20:29, 11 July 2014 (UTC)

@TomT0m: no pinging to me? I'm desperately disappointed. --Succu (talk) 20:34, 11 July 2014 (UTC)
(edit conflict) The page is only about Wikidata:Glossary#Item not about Properties. The item that is called "Entity" is not the same as Wikidata:Glossary#Entity. The constraints of P279 and P31 enforce entity (Q35120) as the root item for every Wikidata:Glossary#Item except this item itself. Tamawashi (talk) 20:33, 11 July 2014 (UTC)
Is any class an entity in your sense ? what about class of classes, are they entities ? does entity in that sense means actually item ? TomT0m (talk) 20:38, 11 July 2014 (UTC)
My sense is irrelevant. I am only talking about what exists in Wikidata. If every item is properly rooted, i.e. constraint violations cured, then every item is either an instance or a subclass of entity (Q35120). So every item then would be an entity (Q35120). IIRC, W3C uses the name Thing instead of Entity. Tamawashi (talk) 22:10, 11 July 2014 (UTC)
Ist lustig wie vemeintlich zusammenhängendes zuammengekitiet wird. --Succu (talk) 22:19, 11 July 2014 (UTC)
 Comment For those that try to use Google translate with Succu's statement, with "zusammengekitiet" he maybe meant "zusammengekittet". Tamawashi (talk) 22:24, 11 July 2014 (UTC)
Mir fällt nur noch das Wort aberwitzig ein...Succu (talk) 22:32, 11 July 2014 (UTC)

Statements on difference between instance and class

  • instance = token and class = type
  • an instance is a physical object, and a class is an abstract object
  • an instance has a unique location in space and time, while a class does not

Taken from comments by User:Emw at Help talk:Basic membership properties#Proposition of definition. I would like to add them, but with reference to some online source. Tamawashi (talk) 16:36, 12 July 2014 (UTC)

More on en:type-token distinction. Thanks to User:Emw who mentioned this page somewhere. Tamawashi (talk) 00:29, 13 July 2014 (UTC)

The related items of these article have a distance of less than 10 nodes from the root:

What subclass of entity is not an object (Q488383)? Tamawashi (talk) 15:20, 13 July 2014 (UTC)

Difference between instance and class

When recently working on general classification and selecting items with autolist2 that are an instance and a class, I found that even chemical elements have been characterized as instances [14]. It had been an instance already in 2013

In 2014 the instance claim is recreated and several edits on P31 occurred, despite that a subclass claim existed:

When I made my changes from instance to class, I had not been aware of that edit history. I just thought about the many real world objects that would be called "hydrogen", or classified as hydrogen, which let me to think of the item as a class. One idea on a technical level that I have here, is to disallow that "instance of" and "subclass of" can exist on one item and that there should be the possibility to convert from one to the other, to prevent that one has to delete one set of claims before the claims under the other property can be "re-installed". In the meantime there could be a game that lets people work on those items that fall under "claim[31] and claim[279]". User:Emw said [22] that these cases are not forbidden, but I still didn't understand when it would allowed and when not. Maybe someone can add a section to the page explaining that. Tamawashi (talk) 16:37, 12 July 2014 (UTC)

@Tamawashi: I proposed the following model in this really long discussion on project chat, initiated by a user who seem to have disappeared since :
 – The preceding unsigned comment was added by TomT0m (talk • contribs).
I think all classes may be instances of class types (meta-classes): all professions use both instance of (P31) and subclass of (P279), every ship class is a submarine type, or ship type, or boat type, and so on. - LaddΩ chat ;) 18:59, 12 July 2014 (UTC)
@Laddo: I agree, but the <ship> example might not be the best one : Emw might object that it's enough to state that < U-boat class> is a submarine type, that
⟨  U-boat class ⟩ subclass of (P279) View with SQID ⟨ submarine ⟩
. Then we know every < U-boat class> instance is a submarine, by definition of subclass of (P279) in Help:BMP. A better example imho is breeds of animal subspecies : Let's take two dog classes : the class of all <dog in Paris> and the class of all <american eskimo dog>. Both of those classes are type of dogs. But the first one is defined by location and regroups dogs of any kind, and the second is an American Kennel Club defined breed. The relationship beetween <american eskimo dog> and <akc dog breed> cannot be expressed by a subclass of (P279) claim because, let's say <my dog> is an <american eskimo dog>, we would have
⟨ my dog ⟩ instance of (P31) View with SQID ⟨ american eskimo dog ⟩
and
⟨ american eskimo dog ⟩ subclass of (P279) View with SQID ⟨ akc dog breed ⟩
. By definition of subclass of (P279) it would imply that
⟨ my dog ⟩ instance of (P31) View with SQID ⟨ akc dog breed ⟩
, which is absurd, my dog is not a breed by himself : a breed is a group of animal, an individual dog belongs to it.
⟨ american eskimo dog ⟩ instance of (P31) View with SQID ⟨ akc dog breed ⟩
solves this problem, but we have to be careful because <american eskimo dog> is a class, and using instance of (P31) on classes migth lead to problems.
I might be possible to things in a different way: create a class <AKC classified Dog>. Imagine Every dog is then an instance of <AKC classified Dog>, or of <AKC bastards> if he does not meet any criteria of breeds according to AKC. As <my dog> belongs to an AKC breed, then he is an (instance of) <AKC classified dog>. <American eskimo dog> then is a subclass of this class : any <American eskimo dog> has an AKC breed, obviously. Then if we want to know the class attributed to SKC for my dog, we might query all the <AKC classified dog> subclasses of which my dog is an instance of (AKC classification might be a tree two).
Imho this is not an optimal solution though : clearly we can add arbitrary subclass to this tree like <AKC classified dog who lives in Paris> if we like, for example if it is a notable class, the intersection of both classes. This class is obviously a subclass of <AKC classified dog>, and an intelligent program who understands what subclasses are like protege will be able to know that. Then if we query all the subclasses of <AKC classified dog>, then <AKC classified dog who lives in Paris> will be shown in the results, which is probably not what we wanted in the first place if we want to know information on the breed of <my dog> according to the AKC.
Of course we can use both model in Wikidata : somebody interested in the second one only will just extract the second model's styles statement and ignore the first ones, then import them into Protege or another tool using a subset of the Wikidata:RDF export. He can even use the first model's statements to search for all AKC classes first, those who are instance of (P31) <AKC class> to be sure he will get a clean tree and won't catch classes such as <AKC classified dog who lives in Paris> which might be interesting for us in Wikidata but not really part of the AKC standard classes.
In short the first model is friendly to Wikidatans as it allows to model things correctly while giving us additional flexibility in handling and creating classes and querying them, imho.
To be complete I must talk of another (compatible) solution here : create a specialized AKC breed typing property. We can also do this, but it looks like we tried to avoid the typing properties number explosion, so it might not be what we want. Besides if we do this, would have a Template:Constraint:Range constraint, which says that any value of this property should be an instance of <AKC breed>. So imho this does not really settle the class of classes problem as <AKC Breed> looks damn well to me like a class of classes.(@Emw: I can't find when I write this line a class expression in OWL which states that all values of a property are the class of all subclasses of some class. Any idea ? I can find a class expression to say that the values of some properties are instances of some class, but not a subclass of eg. <AKC classified dog>). This is not a problem if you imagine breeds are just identifiers or definitions without an extension of all the dogs that corresponds to the definition, but this looks like doing punning ourselves to me.
(side note)
The proposed layered instance/class/class of classes model is compatible with Wikidata and with other reasoning tools : a little review of what can be done with it.
On Wikidata
I just exposed why I think the class of class model is useful. Now I will elaborate on how to manage this in Wikidata :
We discussed on this page about subclass tree roots. This is a tricky part. to be crystal clear on logical consistency and avoid logical paradoxes who could dissolve Universe (Q1)  View with Reasonator View with SQID per strange logical principles like principle of explosion (Q60190)  View with Reasonator View with SQID (not our one. [Hopefully http://xkcd.com/704/]) like {{subst:Q|Q33401}) (or its understandable version barber paradox (Q807853)  View with Reasonator View with SQID ) we could have too classes : <entity>, which regroups all instances like <my dog>, and <class>, which regroups classes of instances like <AKC classified dog>:
⟨ my dog ⟩ instance of (P31) View with SQID ⟨ entity ⟩
and
⟨ American eskimo dog ⟩ instance of (P31) View with SQID ⟨ class ⟩
Then as
⟨ American eskimo dog ⟩ instance of (P31) View with SQID ⟨ AKC class ⟩
it become obvious that
⟨ AKC class ⟩ subclass of (P279) View with SQID ⟨ Class ⟩
and that it does not breaks the definitions we gave about instance of (P31) and subclass of (P279) : if
⟨ item A ⟩ instance of (P31) View with SQID ⟨ class A ⟩
and
⟨ class A ⟩ subclass of (P279) View with SQID ⟨ class B ⟩
then
⟨ class A ⟩ subclass of (P279) View with SQID ⟨ class B ⟩
. The only things we have to be careful about is not to break the line:
⟨ my dog ⟩ instance of (P31) View with SQID ⟨ AKC class ⟩
 is incorrect, because <my dog> is an instance of <entity> and <AKC class> is not an instance of <class> but a subclass of it. But a query will show these errors.
We can also discuss about whether or not we need, on top of these entity classes, have a top root item, of which instances and classes would be instances both. I don't really now if it is interesting or possible, I think we can ignore this question atm. I think the important thing is to be sure that <class> and <entities> are disjoint.
On (standards) OWL reasoners
through a kind of punning, can handle this in a suboptimal way because they creates two (equivalent of our) items and avoids possible Russel's paradoxes like problems by treating them as totally unconnected as if they were two different real world instances.
On (standards) OWL reasoners (bis)
the standard punning feature made some reasearchers in knowledge representation and engineering sad, so they tried to find better ways to do. They actually did and there is more advanced use of this feature of class of classes, called metaclass, in a OWL reasoner compatible way [have also been proposed http:www.cs.ox.ac.uk/files/3129/paper.pdf] (a sample paper), involving more advanced transformations of the statements than just taking the instance of (P31) and subclass of (P279) statements an exporting them in RDF. They found interesting feature using this that looks like maintenance categories in Wikipedia : if you make an error using a template into a page, for example, the page can be put in a category pages with template error. They use a similar feature to handle some kind of errors and make them instance of (P31) if I'm not too wrong about the paper /o\ This can be compared to the results of the queries listed on this page.
(personnal comment) we could also maybe add a third layer <class of class of class>, but I'm not sure I have any usecase yet ^^. And sorry for the long post /o\ Hope this is understandable. TomT0m (talk) 21:39, 12 July 2014 (UTC)

@TomT0m: maybe you could use an example from a domain that is more widely known than chemistry. I myself would have to read about atoms and isotopes. How about human (Q5)? Tamawashi (talk) 00:16, 13 July 2014 (UTC)

Class name -X- changed to -type of X-

@TomT0m: Why this? Would you rename all classes like that? "type of apples" instead of "apple"? Tamawashi (talk) 00:19, 13 July 2014 (UTC)

@Tamawashi: I don't remember why this particular edit, but a discussion about Administrative entities can be found here Wikidata_talk:Country_subdivision_task_force#layers. It actually contains another example :

Examples

Note : in those tables, going from one cell to the immediate left cell reads instance of (P31) ; going from one cell to one of its upper cell in the same column read subclass of (P279).

Administrative territorial entities classification

Administrative division classifications: Horizontal: instance of, Vertical : Subclass of
instance level class level class of classes level
- entity class
- administrative territorial entities type of administrative territorial divisions
- administrative territorial entity of France (Q192498)  View with Reasonator View with SQID table of administrative divisions by country (Q1423994)  View with Reasonator View with SQID (probably should have a better label : the class of all aministrative territorial divions defined by some unique state X). ,If every administrative division has a defined by state <X> statement, then if <Y> is the class of all administative divisions which have a <defined by state X> for some state X, then <Y> belongs to this class.)
Paris (Q90)  View with Reasonator View with SQID  ; Nantes (Q12191)  View with Reasonator View with SQID commune of France (Q484170)  View with Reasonator View with SQID french administrative division type as defined by french administration

(some of the items used in the table were deleted by someone for some reason, it did not ease things)

Two similar tables for the biological and breeds classification.

Administrative division classifications: Horizontal: instance of, Vertical : Subclass of
instance level class level class of classes level
- entity class
- living entities class used in biological taxonomy
- animal reign
my dog dog species
Administrative division classifications: Horizontal: instance of, Vertical : Subclass of
instance class class of classes
- entity class
- AKC classified dog AKC dog breed classification class
- american eskimo dog AKC breed
my dog american eskimo dog who lives in Paris -

comments

But you are right, the disagreement on WD:PC's discussion about the chemical element term shows it's maybe not the best introduction example to my POV :) I think the breeds / biological taxonomy is a better example. (if we take chemical element to be a synonym for atom, like it is done is some ontologies, you end up with something different than if you take chemical elements to be the classes of atoms with identical atomic numbers. Both definitions are used irl, which is confusing).

What's interesting in those table is that they show how several classification can be used with this three layer model by classing classes. The classification and definition of territorial administrative entities used by each country is different, yet we can use class of classes to regroup the classes they use. We can keep the flexibility to define our own subclasses like <French cities with more than 1 000 000 inhabitants> by subclassing <French cities> without this to imply that the <French cities with more than 1 000 000 inhabitants> is a part of the french administrative official type of administrative divisions. Classification made by scientists and breeds club is different for the same entities, yet class classification let us define our own Wikidata (or external) subclasses like <american eskimo dog who lives in Paris> with maintaining a clear separation.


Why ???

I was motivated to pull that string by several intuitions

  • subclass of on instances is powerful, but maybe a little too much for some purposes : its formal definition is basically a class if a subclass of another in one of the class iff they have the same instances. Which can lead to a really big number of subclass if we explicit everything. Of course we do not explicit subclass relationship, only some of them. But, why do we choose these ones ???? there should be some more things we can say about classes than just the subclass relationship.
  • there is some administrative divisions by country categories in Wikidata, which looks damn well to me like a class of categories : it countains classes, and it is not a subclass of relationship use of subcategories, of course Paris city is not a administrative divisions by country, although it is a french administrative division.
  • lots of people use different ways to class the same objects. For example states class territories according to criteria related to somewhat arbitrary boundaries, decision making and local politics criteria, historical criteria, and so on, it is very complex. In contrast statistical organisms uses different concepts often defined with objective criteria, they divide the territory in urban units for example. This is some different point of view and classification of the same object essentially : the territory. Then if urban unit as defined by french statistical organism INSEE is roughly an analog of the commune concept used by state french administration, there is things to be said and made explicit about the relationship beetween this statistical units that are probably deep and are better to be said at the classification system level (the class of classes level in my model) than at the instance level.

In summary using a class of classes level allows us to make explicit the choices we make about subclassing statements we put in Wikidata : obviously it make sense to subclass french administrative unit and french city because those classes are defined by french administration definitions. The class of class level allows us to say something like who defined those classes, make explicit the choices we made about which subclass of statement we put (why did INSEE defined rural unit like this and not like that ? Go check the Wikipedia article about INSEE classification of territorial entities). It also gives a convenient way to retrieve only the INSEE classes for my queries, or only the biological taxonomy animal classification classes and not the human made breeds with different criteria, where subclass of might give a very large tree and would imply to compute class intersections like all subclasses of dogs minus the subclasses of dogs who are subclasses of <AKC classified dog> which could become very tricky in a totally open world and if we add breeds definitions by other organisms by AKC ... TomT0m (talk) 08:00, 13 July 2014 (UTC)

TomT0m (talk) 08:00, 13 July 2014 (UTC)

Atom kind class

nuclide (Q15730548) What is that? Will there be for every class Foo a Foo kind class? Tamawashi (talk) 10:20, 15 July 2014 (UTC)

"Atom kind class" is the best example of TomT0m's worst idea for modeling classes. As he mentions above, we discussed this at length in Wikidata:Project_chat/Archive/2014/05#chemical_element. TomT0m's proposal is used nowhere else on the Semantic Web in modeling atoms or chemicals.
Virtually everyone that encounters the concept of "atom kind class" is (rightfully) confused or disapproving of the idea. If you think the confusion over classes and instances is bad today, wait until more people see commons:File:Atom_classes.svg, the graphic TomT0m uses to explain this idea. Users will be categorically bewildered. Constructs like "atom kind class" are extraneous and unhelpful. We should avoid them. Emw (talk) 04:23, 16 July 2014 (UTC)
This is just your opinion. Imho it HELPS a lot to conceptualize thing (at list the metaclass level), limiting modeling levels to class/instance is a burden who confuses things a lot. Take our discussion on the nature of the Isotope concept. We really agree a lot on the class/token relationship topic : Oxygen-18 and Oxygen are classes (subclasses of atoms). But there is a lot of problems into putting the <isotope> concept, for which we have a wikipedia item, into that scheme. Ontologically you noted it is not in CheBI ontology, I think you did not think enough on the <why> it is not. making <isotope> a superclass of all isotope class do not make sense and is not useful: we just have a second name for the <atom> class. So why do we have IRL a (general) isotope concept ? Not using a metaclass for that is using a screwdriver to go into space. TomT0m (talk) 10:09, 16 July 2014 (UTC)
@Tamawashi: It is a [meta]metaclass look around this query to see "metaclass" it is not an invention of mine. Classes of atoms like Oxygen or Hydrogen shares a lot in their definitions : <Hydrogen> is the class of all atoms with 1 as an atomic number, <Helium> is the class of all atoms with 1 as an atomic number. I proposed to regroup those classes into a <chemical element> class, of whose instances I are classes with the property I is the class of all atoms with 1 as an atomic number N]. This was the metaclass level. But if we dig a little bit more we find there is another useful atom metaclass : the <isotope> metaclass. Then we may add another model the [meta-meta] class atom type class, whe regroups all the metaclasses who sort out atoms with properties of the instances.
To answer Emw opinion is the best example of TomT0m's worst idea for modeling classes, I admit the meta-meta class level is a little extreme and very abstract, so it might not be very important. But the metaclass level IS imho really really important. So please Emw don't take this as an infinite meta abstract model to ridiculize the idea :) (plus there is the metamodeling field of computer science proving it's useless to go upper the meta-meta level or something :) ). TomT0m (talk) 10:09, 16 July 2014 (UTC)

@TomT0m: You didn't answer my second question. I found another edit of you related to chemical element: Chemical element has part "isotope"[23]. Do you have any source for that claim? Tamawashi (talk) 22:08, 17 July 2014 (UTC)

@Tamawashi: Good question. part of (P361) / has part(s) (P527) are indeed not the good relations. The thing I wanted to express is that if we union all the instances of all the isotope subclass of some element class, then we get the element class, ie that for all element class like <Oxygen>, [24] [<Oxygen-18> <Oxygen-16> <Oxygen-17>]. This can be thought as a class expression pattern at the meta level. But properties like disjoint union have a bad history in property proposal if I remember well (people thought better not do this to figure out how to do this well). But I think we got an interwiki conflict with this item : there is two definitions : Emw's one, used in an ontology and on the english WIkipedia article : a chemical element is some kind of pure chemical substance, and the one used for example in the french wikipedia : a chemical element is a class of atoms with identical atomic numbers. Those two definitions are not equivalent so we need two items and not only one, this is a hard to solve propertly interwiki conflict. TomT0m (talk) 15:35, 18 July 2014 (UTC)
Will there be for every class Foo a Foo kind class Nope it's probably not useful for every class. I think it's useful for chemistry as atom is a fundamental object. TomT0m (talk) 15:35, 18 July 2014 (UTC)
@Tamawashi, Emw: What do you think of the idea of a property inspired by part of (P361), but that would work for classes, partitioned in
For example, we would have
⟨ Oxygen ⟩ partitioned in Search ⟨ [Oxygen-17 ⟩
Oxygen-18 Search ⟨ Oxygen-16 ⟩
at the class level, and
⟨ Element (metaclass) ⟩ partitioned in Search ⟨ Isotope (metaclass) ⟩
at the metaclass level, like part of (P361) works at the instance and class level both ?
TomT0m, innovating new foundational properties is not a good idea. For example, most users familiar with instance of, subclass of and part of would notice that the statement "oxygen partitioned in oxygen-17, oxygen-18, oxygen-19" would be representable much more conventionally by the statement "oxygen has subclass oxygen-17, oxygen-18, oxygen-19". (Has subclass is supported in some technologies, e.g. as a Boolean method in Jena, but having an inverse property of subclass of, i.e. rdfs:subClassOf, would be invalid in OWL 2 DL.)
Precisely what would "element partitioned in isotope" mean? Would the statement "isotope partitioned in element" be correct? If so, that property would have the some modeling conundrum as subclass of. Emw (talk) 13:52, 19 July 2014 (UTC)
@Emw: ??? I gave the foundation in OWL, it is disjoint union. This OWL property states that some classes are, in the math sense, a mathematical partition of the class : an atom belongs in an element class, let's say <Oxygen>. It belongs also for sure to one, and only one, isotope class. This is a definition of a mathematical partition : some subset S1 .. Sn of a set of a set S who are all pairwise disjoints, and such no element belongs to both S1 and S2 nor any other pair. Isotope-classes are a partition are partition classes of an element class. This is different from beeing a subclass as an element of a class can belong to any number of its subclasses without restrictions. It's not really an innovation on the foundations :) cmtTomT0m (talk) 14:22, 19 July 2014 (UTC)
TomT0m, the statement "oxygen owl:disjointUnionOf oxygen-17, oxygen-18, oxygen-19" is incorrect, as is "element owl:disjointUnionOf isotope" insofar as your interpretation is concerned. Note the examples in http://www.w3.org/TR/owl2-new-features/#F1:_DisjointUnion. The OWL 2 Structural Specification gives a more precise definition of owl:disjointUnionOf:
A disjoint union axiom DisjointUnion( C CE1 ... CEn ) states that a class C is a disjoint union of the class expressions CEi, 1 ≤ i ≤ n, all of which are pairwise disjoint. Such axioms are sometimes referred to as covering axioms, as they state that the extensions of all CEi exactly cover the extension of C. Thus, each instance of C is an instance of exactly one CEi, and each instance of CEi is an instance of C.
—OWL 2 Structural Specification: Disjoint Union of Class Expressions
So we see that disjoint union expresses a covering axiom, i.e. an exhaustive list of subclasses. It is an unusually strong type of property, essentially a way to make statements characteristic of the Closed World Assumption (CWA) in OWL. Thus the statement "oxygen owl:disjointUnionOf oxygen-17, oxygen-18, oxygen-19" is trivially incorrect because there are more isotopes of oxygen than that (see Isotopes_of_oxygen#Table).
The only difference between has subclass and partitioned in is that the latter would also entail that the listed subjects were an exhaustive list of subclasses of the subject. A property has subclass would let us do the same thing, without being unnecessarily strong.
Also, importantly, note that owl:disjointWithOf refers to its subjects and objects as classes -- not instances -- and is a macro for subclass of, not instance of. If owl:disjointUnionOf is the foundation of partitioned in in OWL, then the statement "oxygen partitioned in oxygen-17, oxygen-18, oxygen-19, ..." entails "oxygen-17 subclass of (P279) oxygen", not "oxygen-17 instance of (P31) oxygen".
The statement "element owl:disjointUnionOf isotope" is incorrect insofar as your interpretation is concerned because it does not entail that any instance of an element is an instance of only one isotope. The statement entails that any instance of element is an instance of isotope, and nothing else. It does not entail that the statement "Foo subclass of oxygen-17, oxygen-18" is false, as you would have it. Formally, the statement "element owl:disjointUnionOf isotope" is identical to saying "element owl:equivalentClass isotope, which is identical to saying "element subclass of isotope", "isotope subclass of element". Emw (talk) 18:16, 20 July 2014 (UTC)

@TomT0m: Nuclides have different characteristics. Classes can be created by number of protons, of protons and neutrons, of neutrons and many more. What makes any of these classes a metaclass? Tamawashi (talk) 19:02, 18 July 2014 (UTC)

@Tamawashi: <Oxygen> or <Oxygen-18> are not metaclasses, they are classes of atoms. <Chemical element> or <isotope>, although, are not classes of atom. <Oxygen-18> is not a subclass of <isotope>, otherwise it would make the class <isotope> analog to <atom>, so pretty useless. <isotope> in my model is the class of all <Oxygen-18> like classes, and as such it is a class of class, hence a metaclass. But we are circling around, I'll not repeat this to you another time. TomT0m (talk) 00:44, 19 July 2014 (UTC)
@Tamawashi: I see you uniterally fix things that are not broken. In the name of what are you doing that ? TomT0m (talk) 00:52, 19 July 2014 (UTC)
@TomT0m: Could you please abstain from commenting about users and focus on content? Did anything happen that you don't agree with? If so, start a discussion next to the item or a relevant page inside Wikidata: related to that item. Tamawashi (talk) 16:22, 21 July 2014 (UTC)

A instance of B, B part of C, A part of C

Troll allegation by User:TomT0m at AN. Venus is an instance of an inner planet. An inner planet is a planet of the Solar System. So, why state, that Venus is part of the Solar System [25]? @Emw, Micru: - could one of you help? Tamawashi (talk) 01:31, 21 July 2014 (UTC)

The issue of so-called "claim redundancy" is interesting. What are the background discussions on this? How does the rest of the Semantic Web deal with it? Let's keep allegations of trolling and vandalism elsewhere, and keep this discussion civil, friendly, and focused on content. Emw (talk) 02:56, 21 July 2014 (UTC)
@Emw: Let's test the FMA-model:
  • Venus
    • instance of inner planet
    • instance of Solar System planet
  • inner planet
    • is a planet
    • part of Solar System
    • has part Mercury, Venus, Earth, and Mars
    • embodiment of complete set (see below)
  • Solar System planet
    • part of Solar System
    • is a planet
    • embodiment of complete set (see below)
@Tamawashi: you have to understand that here we work by consensus, no one has the right to impose their view to others if there is no agreement on what is right. You might be partially right in your corrections, but your actions diminish the value of your wholesome intentions. I recommend that you take the Admin warning as a time to meditate about what happened. Remember that here we are to collaborate and to help each other.--Micru (talk) 08:51, 21 July 2014 (UTC)
@Micru: some people claim that here editors work by consensus, and that no one has the right to impose their view to others if there is no agreement on what is right. These people might be partially right in their claims, but their actions diminish the trust in what they say. You may take the Admin warning as a time to meditate about what happened. Remember that here some people claim that we are to collaborate and to help each other. Tamawashi (talk) 16:15, 21 July 2014 (UTC)
I have added "subclass of:complete class""is a:complete set" to indicate that all instances of the class are known, and as such there is an equivalency between "part of"/"instancee of".--Micru (talk) 09:36, 21 July 2014 (UTC)
@Micru: Mmmm interesting, so if I follow you well, as
⟨ Earth ⟩ instance of (P31) View with SQID ⟨ solar system planet ⟩
and
⟨ Earth ⟩ subclass of (P279) View with SQID ⟨ complete class ⟩
, then by transitivity of instance of (P31) wrt. subclasses,
⟨ earth ⟩ instance of (P31) View with SQID ⟨ complete class ⟩
 ? That's a perfect semantical nonsense :) TomT0m (talk) 09:48, 21 July 2014 (UTC)
@TomT0m: You are right! Corrected.--Micru (talk) 10:22, 21 July 2014 (UTC)
Removed "subclassOf", as it is equivalent to is_a.--Micru (talk) 14:29, 23 July 2014 (UTC)
@TomT0m: Now it is corrected. The right property was not is_a, but embodiment_of (or materialization_of). It is similar to instance_of, but by having a distinct property we avoid A instance of B, B instance of C, because that would be wrong. Or is it allowed?--Micru (talk) 14:58, 23 July 2014 (UTC)
Certainly adding "instance of inner planet" is not a valid reason to remove "part of the Solar system" at the moment, as it means we should use p279 to know the implied p361 values of something. Such multi-property inferrence is not very legible and do not sound like a good idea, at the very least until we have better-structured data and more data analysis/visualization tools.
Does it make sense to add "instance of inner planet" ? As I understand it, this is just a compression for "instance of rocky planet" and "part of the Solar system". Mixing information about "instance of" and "part of" in the same place may not be a thing we want to do without a good reason.
"Inner planet" appears to be more of a terminological shorthand than a scientifical concept. If for some practical reason, we want to state that a planet is an instance of inner planet, I would sooner give such a statement a "normal rank" and use the "preferred" for cleaner classes like "rocky planet". --Zolo (talk) 18:51, 29 July 2014 (UTC)
@Zolo: I can't say I fully disagree with you but I can't say I'm totally convinced you got a good criteria for clean classes. Rocky planet might also be a compression for something more complex like low temperature spherical celestial body primarily composed with rocks and metals. And we have properties to say of what a celestial body is composed of. So can we apply also your reasoning, as soon as a class is expressable as a function or predicate of properties and values of its instances, it does not deserves to be explicitely stated ? I don't think so. But I agree we need more advanced tools, it's just that more advanced tools could be able to extract the best of our datas whatever how they are expressed. I say for example for a human it's more interesting to put one statement about the specific class of something and let a computer then suggest the good property/value pairs. Less human work. TomT0m (talk) 19:42, 29 July 2014 (UTC)
@tomT0m: Yes, I realize I did not really phrase it the right way.
I do not think mixing "part of" and "subclass of" is a good idea, perhaps because "part of" is transitive. You would expect to be able to find what the item is part of simply looking up p361 chains, not chains that can be created using combinations of p361 and p279. That calls for "Earth: part of the Solar system", not "Earth: instance of Solar System inner planet.
For the more general idea of "clean classes", this is probably not as clear as I would like to. I'll try to figure if I have more convicing things to say about one dat :) For now, just a note, partly for myself:
  • vehicle: mobile object used for transportation
  • good subclass: truck: motorized object used for good's transportation
  • bad subclass: black vehicle made in Germany
  • planet: spherical accretion of matter orbiting around a star
  • good subclass: accretion of solid matter
  • bad subclass (?) accretion of matter orbiting around the Sun.
--Zolo (talk) 20:54, 29 July 2014 (UTC)
subclass of (P279) and part of (P361) are very different, you can't really mix them : from the classification point of view I think part of (P361) plays no role at all in OWL's classification system, whereas subclass of (P279) is of course really important (It's also transitive :) ). I don't think the transitivity of part of (P361) is a real problem because it seems easy to filter the part-of hood relationship through the classes of things that are interesting : if we are interested in planets, whether or not oceans are part of planets is not really relevant because they are obviously not planets ... part of (P361) seems to me like any other property with respect to classification of elements, not really more interesting than brother or sister of, who is also a transitive property.
For the good/bad classification, quite some thinking to do to be convincing yet :) I guess if we search publications or persons who are interested in black vehicle made in Germany it probably will be quite difficult to find anything. It's different for accretion of matter orbiting around the Sun. because it will probably be really easy to find documentation about rocky planets of the solar system, we learn this class in school if I remember well ...
accretion of solid matter is unquestionable as it is a class of planet used by astronomer quite officially, rocky planets. Classes actually used in scientific classification, like taxonomy or astronomy, are probably an easy case : it's easy to cite textbooks or papers about scientific classifications that shows classes of first interest, pretty much the basis of an admissibility criteria. There is already plenty of items that maps to those classes, with a scientific definition that may map more or less into an OWL class expression. Those items are themselves classifiable as class of interest for science or class of modern taxonomy, for example, and this is another criteria, if a class is a class used by some official admissible classification system, then there is no question for its admissibility. Classes that can't be attributed to be used by any admissible classification system might be harder to justify, although they might be interesting conceptually or for another reason (there may be a lot of domains for which there is not good classification systems but for which Wikipedia infoboxes do a good job). TomT0m (talk) 21:50, 29 July 2014 (UTC)

Programming a subclass of object orientation but not of activity?

moved from project chat, after concerns about the venue by User:Pasleim

So edits User:Succu [26]. Not sure why he did this, but since he likes to revert my edits, see some tracking at Wikidata_talk:Item classification, the reason may be that I did it, not a specific interest in the topic. OK, is OO programming a subclass of programming? Is programming a subclass of an activity? Or is it as Succu suggests object-orientation? Tamawashi (talk) 20:51, 21 July 2014 (UTC)

@Tamawashi: There are every day dozens of reverts and normally, they get discussed at the involved users' talk pages. If we put every revert discussion directly on Project chat, this page will get crowded very fast.
BTW, according to the articles in enwiki, frwiki and dewiki, OO programming is a programming style and thus not an activity. --Pasleim (talk) 21:14, 21 July 2014 (UTC)
Pasleim - "they get discussed at the involved users' talk pages" - then they would be spread among three user pages, and maybe a month later among another two or three user pages. But OK. I am sorry, I think the better venue would have been Wikidata_talk:Item classification. I just moved it here. Tamawashi (talk) 21:33, 21 July 2014 (UTC)
I checked your three sources and also eswiki, they say it is a paradigm, specifically linking to programming paradigm (Q188267). That in turn in Wikidata is a subclass of "programming style". So, "is a programming paradigm" and the latter being a class, that leaves for "is a " either "instance of" or "subclass of", right? Tamawashi (talk) 21:38, 21 July 2014 (UTC)
Right, but I don't know which of "instance of" and "subclass of" is more appropriate. --Pasleim (talk) 21:48, 21 July 2014 (UTC)
@Emw, Micru: Any idea? Tamawashi (talk) 23:42, 21 July 2014 (UTC)

@Tamawashi: Unfortunately we are suffering of a w:Paradigm#Paradigm_paralysis. The ontological paradigm we were considering so far was to only use OWL's subclassOf/instanceOf to model everything, but we are seeing that it has limitations. Now we are still assimilating FMA's paradigm of reserving subclassOf/instanceOf for things that happen in real life, and is_a for things that are ideals. By its idealized nature, is_a would be suitable to link "object oriented programming (paradigm)" with "programming paradigm" because both represent non-existing concepts (there is not a OO thing or event). OTOH, there is an "object oriented programming (activity)" which belongs to the realm of phenomena (things or events that can be observed in real life). This one is a subclassOf "programming (the activity)". So yes, you both are right, the item needs to be split in two, and perhaps connected with one another, but AFIK we don't have an appropriate way to do that yet.

For now, since we haven't decided yet whether to use distinct properties for real and imaginary entities, my recommendation is to split the item in two and use subclassOf in both cases.--Micru (talk) 08:33, 22 July 2014 (UTC)

The notion to use is a as distinct from instance of and subclass of is a fledgling, unreviewed proposal regarding foundational properties in Wikidata. Let's avoid using language like "we" on that matter until there is consensus from the community.
Other than that, I agree with Micru: it's not entirely clear whether "object oriented programming (paradigm)" and "programming paradigm" should be linked via instance of or subclass of, but it seems fairly clear that "programming (the activity) subclass of object oriented programming (activity)" is correct. Instances of the activity of programming would include things like you sitting at a computer, developing a Java application -- not the abstract thing "object oriented programming". Emw (talk) 23:22, 22 July 2014 (UTC)
"programming (the activity) subclass of object oriented programming (activity)" is correct ??? You mean the other way around. This would mean every time someone programs he uses the object oriented paradigm, and it is not true. TomT0m (talk) 08:12, 24 July 2014 (UTC)

Colors

Red (red (Q3142)) is a broad term, how come an sRGB value FF0000 is stated there? The English Wikipedia article says " 620–740 nm", "color of blood", "color of most ripe strawberries." - FF0000 seems inappropriate. FF0000 is just a subclass.

Furthermore the page says "instance of color". The same claim exists on "Orange-red (Q737438)" which is a "subclass of Red". Tamawashi (talk) 00:28, 22 July 2014 (UTC)

Again, this is another case of real (phenomenon) vs. imaginary (noumenon). They should not be mixed.--Micru (talk) 08:36, 22 July 2014 (UTC)
Tamawashi, I think FF000 is reasonable as a value for sRGB color hex triplet (P465) in red (Q3142). That hex triplet has been the value for the color "red" in W3C standards since at least 1997, see e.g. here and here. The English Wikipedia article Red discusses various shades of that color, but FF000 is the most widely used value. The approximate electromagnetic wavelength range 620-740 nm is probably more precisely suited for shade of red (Q7460345), of which red (Q3142) would be a subclass, of course.
The status of color as an instance or class is discussed in http://bfo.googlecode.com/svn/releases/2012-07-20-graz/BFO2-Reference.docx, e.g. "the color of a tomato", "qualities such as color", "the pattern of red and white swirls on the label of this Coca Cola bottle". While I would say perhaps like Micru that red (Q3142) should not be stated to be both an instance and a class of color, I would say that the abstract thing "red" can be instantiated in a thing like "that red stop sign down the street", or a subject of the statement "x color (P462) red (Q3142)", where x is an instance.
I think changing the P31 claims in red (Q3142) to P279 claims would be a good start in better classifying colors. Micru, what do you think? Emw (talk) 00:05, 23 July 2014 (UTC)
Emw, as in the case of books, I think we need an "embodiment" property. It would allow us to state that "<book> embodiment of <literary work>, or "<shades of red> embodiment of <red>". "Materialization of" could also be a valid label. You can instantiate <shades of red> because it has an impermanent and real nature, but you cannot instantiate <red> because it has a permanent and abstract nature. With that in mind, for the particular case of "red (concept)" vs. "red (w3c color definition)", it would make sense to split it in two distinct items. Claiming that "<red (concept)> sRGB color hex triplet <FF0000>" is akin to state that all "reds" have the specific value <FF0000> - not true.
Other than that I wholeheartedly agree with changing the P31 claims in red (Q3142) to P279 claims.--Micru (talk) 08:20, 23 July 2014 (UTC)

I think we need different item for red as a big range of colors we call red in every day life kind and red as a primary color, who is used as some kind of mathematical basis axis to describe colors or create new colors to paint with, as a pigment. The notion of colorspace color space (Q166863)  View with Reasonator View with SQID or color spectra could be of some help. My feeling is that every day life red color maps with a set of color spectra. The red color used by programmers maps to a frequency, and is used by colorspace basis like the one used in computing to define colors. We can model the CMYK or RGBA color model safely in Wikidata if we want for example. TomT0m (talk) 11:01, 24 July 2014 (UTC)

@TomT0m: We already have an abstract red (red (Q3142)) and a class for all real recognizable "reds" (shade of red (Q7460345)) which has a range of 630–740nm. To that real red class you can add as many subclasses as you wish: "red (pantone)", "red (rgb)", "red (w3c)", etc. The only thing needed is to define each red subclass intensionally, as a point or as a range in the corresponding color space(s) and frequency.--Micru (talk) 11:37, 24 July 2014 (UTC)

@Micru, TomT0m, Emw: Since Emw and Micru wrote they support a change from instanceOf to subclassOf for red, I am now applying "279:1075 -31:1075" via widar, i.e. changing for color (Q1075) all instance of to subclass of. After having converted all colors from P31 to P279 one can use the tree tools to have a visualization. Having that, discussion about ranges and sRGB might be easier. Tamawashi (talk) 16:31, 26 July 2014 (UTC)

@Tamawashi: Don't go that fast, it does not seem to me we really have a meaningful and useful model at that point. There is a lot of things to sort out ... Having all in a giant subclass tree could not be that helpful, or worse, if we don't have a clear view of what the statements actually means and the items involved. TomT0m (talk) 10:23, 27 July 2014 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata_talk:Item_classification/Archive_1&oldid=2108509366"