The BFI is a widely known and important source. They are also interested in matching items in their database to Wikidata, which this property will facilitate NavinoEvans (talk) 10:53, 10 March 2016 (UTC)
@Máté: As mentioned in the discussion linked above, there is no formatter url at present but I'm going to find out if they are interested in setting up a new structure (probably a long shot, but worth a go). As you mentioned, the codes in the url are not related to the id numbers. You can get to these pages via the BFI's database search page, but I'm trying to arrange a mass export from the BFI that could be uploaded to mix'n'match. NavinoEvans (talk) 22:01, 10 March 2016 (UTC)
@NavinoEvans: Done, no objections. Of course it would be great, if the BFI could implement a way to automatically link to their information page, but just recording the ID for now is useful as well. ---Srittau (talk) 19:35, 4 April 2016 (UTC)
Very widely used and important identifier. Many other datasets link to EIDR identifiers, so allows error checking and mapping to new datasets NavinoEvans (talk) 11:37, 10 March 2016 (UTC)
Sorry I've just read a bit more and I see that it's built on the DOI system. How can the fact it's a DOI help us navigate to the page on EIDR though? It seems to me like we could still benefit a lot from having the EIDR identifier property with url pattern but I may be missing something here. NavinoEvans (talk) 11:41, 16 March 2016 (UTC)
It isn't the job of Wikidata to link to sites but to provide machine-readable data (which can then link it to wherever it wants to), however, this property still may be useful as a subproperty of (P1647): DOI (P356) partly due to the unique formatter URL that can be associated to EIDR and the more refined regular expression. – Máté (talk) 12:14, 16 March 2016 (UTC)
Yes, sorry that wasn't a very clear message, I agree that's not Wikidata's role but the ability to link to an external dataset with a url makes it far more useful than having to dig our that info elsewhere - I think having it as a subproperty of the DOI would be the way to go. I should have mentioned in the motivation for this, that it was prompted by my conversations about data imports and Wikidata matching with the BFI, who said how important EIDR identifiers are for them and others (e.g. Amazon and Netflix) who use them widely. NavinoEvans (talk) 22:31, 16 March 2016 (UTC)
Isn't the point of a DOI to have a single one? Eventually Mediawiki should support multiple URLs per property. This could but needn't be applied for EIDR DOIs. --- Jura09:00, 18 March 2016 (UTC)
Yes I do see your point, I'm sure multiple formats will be supported soon. Anyway, I just checked to see what happens when you add an EIDR code using DOI (P356) and it actually auto redirects to the EIDR page from the target page at https://dx.doi.org/ (e.g. Never Say Never Again (Q180279) ) - Basically everything is perfectly covered with the DOI property as Jura said, so this proposal should be removed now I think NavinoEvans (talk) 10:28, 18 March 2016 (UTC)
You might reconsider the withdrawal: Just because something works when considered as a DOI it is not automatically semantically one: When I see the DOI I assume it gives me access to the object itself (or some very close surrogate). EIDR Ids however seem not to attemt that, they are DOIs not for the object but rather to an document with an extensive description of the object (metadata consedered as data). So there is a difference between the DOI for that film and its EIDR. -- Gymel (talk) 19:47, 18 March 2016 (UTC)
@Gymel, Pigsonthewing: +1 for reviving this one for consideration. I hadn't realised the EIDR, DOI distinction, but that does make sense. It looks like Andy's suggestion does the trick really, it's just a question of whether its important enough to go one further and get a property. I think it's worth it, but would still be happy with the "described at" approach. NavinoEvans (talk) 23:59, 21 March 2016 (UTC)
http://www.cagematch.net/?id=2&nr=$1 (English) or http://www.cagematch.de/?id=2&nr=$1 (German)
Robot and gadget jobs
We might be able to scrape values from German Wikipedia
Motivation
cagematch.net (or cagematch.de, which is the german address, it is mainly a german site) is a database of Professional Wrestling performers, shows, PPVs, matches, etc across a number of different promotions (WWE, TNA, etc). It seems to be very comprehensive. This property is for what they call "workers", which seems to be mainly wrestlers, but also announcers, referees, and sometimes celebrities have cameos. They have 16945 people listed. I don't know how much of the information we can use here, but they have basic biographical information, and authority control could be useful, as articles for wrestlers often use ring names rather than real names. I'm not sure about the label and description, but I think the English and German versions should refer to the corresponding versions of the website, and similarly for the formatter URLs, if we can do that. It seems we could import values from the German Wikipedia, but they only have raw links to the website, so we would have to scrape the wikitext. Silverfish (talk) 02:15, 27 March 2016 (UTC)
Identifier for an author, in Persée, an open access digital library of French-language scholarly journals, established by the Ministry of National Education of France.
Identifier for a journal in Persée, an open access digital library of French-language scholarly journals, established by the Ministry of National Education of France.
Providing valuable data to authority control templates in different wikipedias. Author identifier from unz.org. Strakhov (talk) 17:59, 31 March 2016 (UTC)
Providing valuable data to authority control templates in different wikipedias. Journal identifier from unz.org. Strakhov (talk) 17:59, 31 March 2016 (UTC)
- there is some programs who are both transmited by radio and television
Robot and gadget jobs
check consistency of the instantiation relation wrt. these statements
Note
This proposal is a proposal for Two properties:
UnionOf
DisjointUnionOf
(to get the definition of the first, take the text in green, resp in red for the second) plus one new qualifier :
Together With.
Motivation
Sometime users use has part(s) (P527) as a kind of inverse properties of subclass of (P279). This is semantically wrong as has part if for composition relationship of physical objects (or classes of those type) that are parts of other (bigger) physical objects (or classes of those whole objects), per Help:BMP, and NOT to give a list of the subclasses, like in the example give who was modeled as has part.
There would not be a case if we were just talking of an inverse property of subclass of (P279), but we're not. Here we want to say that the set of all instances of a set of classes (here proton and neutrons), when regrouped, is exactly the set of instances of the superclass (here nucleon). No instance of nucleon is neither a proton nor a neutron.
Example : let Academics be the set of person who teaches, studies or research in a faculty.
let teacher, student, researcher (be the class of persons who teaches, rep. studies and research in a faculty.
means that any student, researcher and teacher is an academic, that no person who is neither student, researcher nor teacher is an academic. But a student can also teach, as a researcher.
With the disjoint variant (in green), the constraint is added that an instance of nucleon is an instance of one and only one of the subclasses. Said differently, that the set of subclasses is a partition of a set (Q381060) of the subject class.
as a nucleon is a proton or a neutron, but not both.
So the motivation is double :
give an alternative to those who want to put a list of subclasses of a class (don't do that, this is incorrect, do that instead)
improve our modeling expression power.
Note : the qualifier Together Withof (P642) is here because the set of subclasses must exist in the same statement. This is because if we gave the list of classes in a list of statement, we could not express that there is no other subclass needed to cover all the instances of the superclass, as Wikidata follows the open-world assumption (Q851949) (This means we could even use two statement to model two alternative divisions of the class in subclasses for all of its instances). For example let's just add a subclass to nucleon, I don't know highly energetic nucleon. It's a subclass of nucleon, but it would not make sense to add it into
because either a proton or a neutron could be highly energetical. It's a different classification axis. TomT0m(talk)15:26, 9 May 2015 (UTC)
Note2 : DO NOT USE if the class list is not close, of course, that is if there is instances of the superclass that is not an instance of any of the child classes, or if it's not sure whether or not.
@Visite fortuitement prolongée: should be better now. this and that is a common way to speak of resp the subject and the object of the claim. The names are the name given in owl as the links can show, but other are OK if people find this more clear. Union in math is the operation on set, for sure. I don't know about common english
Per Help:Classification for an explanation. A class is a set of indvidual. two classes unionned gives another set of individuals, another class. A class of class unioned with a class of class gives a class of class, similarly. But a class should not be unioned with a metaclass to avoid some ontological problems. TomT0m(talk)20:38, 11 May 2015 (UTC)
I'm not sure if I get the "Together with" qualifier point. Qualifiers are also open to be extended, so I don't see why having all values within a statement makes it more close than having one statement for each value. Qualifiers are extendable as statements are, there is no way to prohibit that. Therefore, I'm also not sure if we should actually introduce such limited classes, as that is contradictory to the open system of Wikidata. -- Bene*talk21:08, 9 May 2015 (UTC)
Good question. I take the opinion of Markus here : see this post on the ML. I think this makes sense for closed lists, it's an easy way to express that, way easier than for example having a sequence of items with followed by (P156)/follows (P155) terminated by
This way, it can not work. TomT0m need a change of Wikidata data structure, or a trick. "together with" is a trick. Of course, since TomT0m has not show an actual example of several, distinct, subclass lists, I do no support "together with", and you are free to oppose it. But I hope that with my explanation, you understand the need. Visite fortuitement prolongée (talk) 19:43, 11 May 2015 (UTC)
It's not a trick, it's a use of qualifiers to express close lists. TomT0m(talk)
@Filceolaire: No. This must be expressed in one statement. It make sense to say that Paul is a son of Jack. It also make sense that Jenny is a daughter of Jack. But from these two satements, we can't say if Jack have more children per open-world assumption (Q851949) which is reasonable in Wikidatas case. With disjoint union this does not make sense to say « nucleon union of proton » and « nucleon union of neutron », no more than in english. This has to be « nucleon union of proton and neutron ». Plus this allows us to say the list is close (see the discussion with Bene* above and the linked mail for this.) Without a qualifier this is as good as «has subclass». TomT0m(talk)19:58, 11 May 2015 (UTC)
« Without a qualifier this is as good as «has subclass». » → Not exactly. "nucleon => UnionOf => proton, neutron, antiproton, antineutron" say more than "nucleon => subclass => proton, neutron, antiproton, antineutron"; because it say that the classes list is complete ("closed"). The difference is that without "Together With" qualifier, an item can have only 1 classes list, so we could no tell that... wait, what was this real example of you? Visite fortuitement prolongée (talk) 20:20, 11 May 2015 (UTC)
No, the meaning argument that a set of two sentence is not the same as one sentence still holds. But you're kind of tiring me. If you really don't want to be convinced follow the links to the owl properties, you'll see they uses one compound statements, not several statements with the same properties, for good reasons. TomT0m(talk)20:30, 11 May 2015 (UTC)
* Oppose I never thought I would O in a proposal of mine the solution without the qualifier. Without it it's as good as has_subclass, as explained above. Of course I Support the original proposal :) TomT0m(talk)20:14, 19 May 2015 (UTC)
@Visite fortuitement prolongée: That's nonsense, really. First, it's not meant to ba an inverse property of subclass of. Second, I am one of the authors of this template and I can make your example work in no time, no problems, it's not hard. But the real solution is to wait for the devteam to implement simple queries to compute inverse relations, then we will be able to adapt the template properly. TomT0m(talk)20:39, 17 June 2015 (UTC)
Comment I am vaguely supportive of this initiative, but I would prefer to have a way to declare two classes disjoint before adding a way to declare them disjoint while also declaring another class to be their union: disjoint union is syntactic sugar.= for this specific combination. Useful, maybe, but not good for all cases. So I would prefer to have union of, and introduce disjoint with independently. --Markus Krötzsch (talk) 16:13, 11 November 2015 (UTC)
@Markus Krötzsch: I'm all for introducing a Disjoint with property, I'll make another proposal, but I'm not sure I agree that this is "syntactic sugar". This looks like an "AllDisjointWith" construction, which allows to replace n*(n+1)/2 constraint, and seem very similar to a "Global constraint" like AllDiff (see for example this paper that is exploited during constraint solving to build more efficient algorithms compared to the set of "local" constraint solutions. Of course an "AllDisjointWith" is weird to express in Wikidata as it has no natural "subject item", except in the case of a disjoint union ... author TomT0m / talk page21:20, 11 November 2015 (UTC)
Comment I am in favour of picking a different encoding, where the classes in the union are treated in a symmetric way without singling out one as the main value. This could be achieved by using no specific main value, but just specifying "some value" there. Moreover, we could use of (P642) as an existing qualifier property instead of making a new one. For example:
This modelling would also be closer to the approach in OWL, which represents unions as anonymous individuals ("some value") that have several classes, which are all on an equal footing without any one being more important than the others. In Wikidata, one could also use a specific placeholder value rather than "some value" since we (unlike OWL), we don't need this value to be different for each union. Maybe one could create another special purpose item that leads to a readable statement. For example:
⟨ Academics ⟩Union ofSearch⟨ set of several classes ⟩ has elementSearch⟨ Teacher ⟩ has elementSearch⟨ Student ⟩ has elementSearch⟨ Researcher ⟩
This is mainly a question of readability. My main technical comment is that we should not be forced to single out one class to be the main value of the union. --Markus Krötzsch (talk) 16:13, 11 November 2015 (UTC)
Comment Parallel to this discussion, it may be worth noting a recent proposal at Wikidata:Property proposal/Property metadata for a Expected completeness property, to indicate whether a complete set of statements for the property were either (a) believed to be present; (b) aspired to (eventually); or (c) not aspired to.
This was originally proposed simply as a property about a property; but it has been suggested that it could also be applied as a qualifier to a statement of the form subject "object of" property, to indicate that it was indicated to have complete statements for the property for a particular value -- eg
This also might work well with Markus's proposal above,
⟨ class ⟩"union of"Search⟨ set of several classes ⟩ "degree of overlap"Search⟨ "disjoint" ⟩ "expected completeness"Search⟨ "believed to be complete" ⟩ has elementSearch⟨ subclass1 ... ⟩
One thing that is perhaps clear to everybody already, but that I would like to underline -- I would stress that I would like to see this mechanism as additional to using subclass of (P279), not as an alternative for it. In the example above, one should still create statements
, even if the denumeration above existed. Direct statements like P279 are simpler to write queries for, and can also be made part of path queries (eg wdt:P31/wdt:P279*) in a way that is not possible for statements which necessarily involve qualifiers. Jheald (talk) 12:18, 13 November 2015 (UTC)
I'm not sure about what would be the best format for these. Using together with (P1706) is definitely wrong, as it means a different type of link for one item in the set than the others. Listing the values as straight unqualified statements per union part results in unusable data. Markus's proposal above makes it difficult/confusing to add/read statements. I support the union/disjoint union proposal in principle, but it needs a usable format. Ideally we could have a new datatype for arrays of values, but I don't think the developers are going to be able to spare the amount of time necessary for creating that. --Yair rand (talk) 22:22, 10 January 2016 (UTC)
What's difficult/confusing ? A few constraint report would help us to find the mistakes, and people just need to be pointed to an example / guidelines the first time they use it. author TomT0m / talk page13:04, 11 January 2016 (UTC)
@TomT0m: Properties can normally be used without any explanation being necessary. Wikidata is hard enough to use as it is, requiring instructions that the editor must put "unknown value" as the value (am I understanding this correctly?), and the values as the qualifiers, is enough to make it too difficult for most contributors to use. --Yair rand (talk) 21:52, 11 January 2016 (UTC)
@Snipre: Sorry what ? The meaning seems pretty precise to me. There is queries pretty easily buildable from this statements. if A union of B and C, the query "instances of A" minus "instances of B union instances of C which is writable in sparql must return no result. Add the query "instances of B intersected with instances of C" which should be empty for disjoint union. author TomT0m / talk page17:33, 18 January 2016 (UTC)
@TomT0m: What's about inferences with your system ? What's about property inheritance. Right now if A is an instance of B and B a subclass of C, A is an instance of C too. How will your new relation define the properties inheritance ? Snipre (talk) 17:05, 21 January 2016 (UTC)
@Snipre: : it does absolutely change nothing and is entirely consistent with this. Both relations exists in OWL without problem. author TomT0m / talk page17:13, 21 January 2016 (UTC)
Comment Item Q21073936 has a label with "and" in (fr)/(es), a label with "or" in (en). This may not work well for your sample. --- Jura18:19, 1 March 2016 (UTC)
@Jura1: It's the item for languages or which there is only one concept for the brothers of sisters of a father or mother. It's a case of ambiguity of the "and" and the "or" in natural languages. If there is a better labelling(s) i'll take it but I don't think it's a blocker. author TomT0m / talk page11:05, 2 March 2016 (UTC)
@TomT0m: This proposal has changed and evolved considerably. It is now for two properties; it should have two separate property documentation templates (they can be discussed together or separately as they are slightly different). I recommend you close this discussion and create two new proposals immediately below so we can have a clean discussion on what to do here. I personally am still uncomfortable with the use of of (P642) as the qualifier property to link elements, to me at least it looks wrong. Do we need another qualifier property to indicate "has element"? Also I would like to see a clearer justification of why this is necessary - the examples provided don't seem to add anything over what one can get using a instance of (P31) or subclass of (P279) SPARQL query - for example tinyurl.com/jtmbuff . ArthurPSmith (talk) 14:56, 23 March 2016 (UTC)
@ArthurPSmith: : No I don't want to do that. This is the same proposal, only with minor points moved and clarification and explanations. I explicitely pushed for beeing able to make several proposals in only one request and nobody seemed to have a problem with that, please ask the other property creators. I would not care a "has element" property, except it is way too close of "set membership" imho. but this should not be a blocker !!! It's a mini point. An example of things that this allows to model : the class of all atoms can be divided according to all of its en:Isobar_(nuclide), where each atom as exactly one isobar, OR according to the set of all its isotopes, of all of its isotone. Likewise each atom has only one corresponding isotone. This is what you can do with this property that you can't do with the existing one. For just union of, you say that therer is no instance of the parent class that is an instance of none of the givent classes. And that too you can't do with existing properties. author TomT0m / talk page15:59, 23 March 2016 (UTC)
@TomT0m: Well, have it your way, but this makes it hard to figure out (for a new or returning reader) what is current and what is outdated in the discussion. The motivation section for instance contains a number of things that don't seem to be part of the current proposal. Can you fix that? I think it would be better to start fresh and clean. I did clean up the titles here so it is clear (I hope) what the properties should be named, and you had some examples mixed about (chemical compound was in both). I hope the changes I made are what you want. But here is the problem with your examples - none of them seem to add anything right now beyond a simple subclass query, either that or I don't think they are right. The only subclasses of nucleon in wikidata are 'proton' and 'neutron'. The only subclasses of 'platonic solid' are the five platonic solids (by the way when I did this search I found a duplicate of "regular tetrahedron" that needed merging). For the union property, chemical compound is specifically stated in its description to include more than one element, so "simple substance" would not qualify (and that particular grouping seems very odd with the self-reference). And neither "solid" nor "liquid" is a subclass of "chemical compound" (they can obviously be mixtures), and you don't seem to have an exhaustive list of material phases there if that was the intention. I would recommend you clear out all the contrived examples here and come up with one good example for each property that would demonstrate the usefulness of this property. I don't doubt that it has a use, but the examples here (and the contrived ones you just mentioned) just don't demonstrate it. ArthurPSmith (talk) 20:28, 23 March 2016 (UTC)
@ArthurPSmith: actually you messed things up adding to subtitles. It's really a pain and fastidious to make several proposals for several very closely related proposals, and it's useless votes for everybody to make for everybody for a group approval/disaproval. Also some people accepted the property AFTER significant rewrite of the proposal, so you already come one war too late ...
The element example is really hard to manipulate, because of the english Wikipedia using a different definition for chemical element (class of atom / class of substance see two points of http://goldbook.iupac.org/C01022.html enwiki uses one, frwiki and other the other), but still you did not answer to the example of isotopes/isobars which are several ways to partition the atoms/pure substance. Could you do that please ? this is the most complete and relevant example. To be clear here I use the definitions that classify the atoms, not the substances, it's easier, see
For the proton/neutron : using just subclass of, you just can't express : 1/ that a nucleon is either a proton and a neutron, but not both . 2/ that there is no other kind of nucleons, because Wikidata might not be complete, it's the "open world hypothesis". My properties are supposed to give a way to express this. author TomT0m / talk page20:58, 23 March 2016 (UTC)
also if I forgot some state of matter, please just add it. I just took the example from a wikipedia article that might not be complete. author TomT0m / talk page21:21, 23 March 2016 (UTC)
TomT0m I'm trying to help you get this proposal to where it can actually be implemented. I don't find the examples compelling, especially the "chemical compound" ones. Property creators are supposed to actually implement the examples you give when creating the property, I do not think what you have here is correct or appropriate in the case of "chemical compound". Similarly, I cannot imagine anybody implementing what you seem to be proposing just above (if I even understood it) with regard to "atoms" and isotopes/isobars. Isotopes are not a closed list in the first place; supposedly the tetraneutron was recently discovered (an isotope that is not even any kind of atom), and adding every possibly discovered isotope to a list of subclasses of an atom seems silly - the example seems, as I said, contrived. You have two stated purposes for these proposals: first to do as you describe for nucleon, express aspects of the subclass relationship (the subclasses are exclusive and there is "no other kind"). Ok, the nucleon/neutron-proton case (and the Platonic solid case) does demonstrate that. If that's all the property does, I guess that's fine. But you have also been arguing this allows for multiple ways of partitioning subclasses of a class that can't be done with the subclass relationship. I think the one case you might have among your examples that could be a good illustration of that is the "broadcast program"; I'm not sure it's a great example, but as you have done here you can partition by medium (television or radio - what about internet broadcasts though?) or perhaps by type of program (news, entertainment, sports). Is there an exhaustive list of those subclasses (if they have even been defined yet)? That might be a good simple example that would be practical to implement here. I would recommend you remove the "chemical compound" examples completely though, they don't make sense and are not helpful. ArthurPSmith (talk) 21:33, 23 March 2016 (UTC)
@ArthurPSmith: Then there is poor communication on the proposal process, I did think examples were here to illustrate the idea, not to be implemented and extensively discussed ...
I still think the "chemical compound" example make sense. Think of liquid water, this is a subclass of all water substances at some point in time. Of course if the list is not complete we might
Of course any non trivial statement of completeness needs a source.
The broadcast example may be a definition : we might explicitely state that this item, for some reason IS NOT for internet broadcast, this is a possible usecase opened. Then we would make the statement in a language agnostic form that may replace some usage instructions of properties that needs to be transated.
A statement that is complete wrt. the current knowledge is the normal way to do stuffs in WIkidata. We might extend it / deprecate it when new atoms are synthetised or proved to actually exists, this seem the normal process. We must be correct wrt. the current state of sources and knowledege, we must not predict future. author TomT0m / talk page21:49, 23 March 2016 (UTC)
Step 2 in WD:PTC is "Add the new property to the example item(s) from the proposal. If there was no example in the proposal, try to find one." Yes, the examples should be correct statements that would actually be useful to add to wikidata, because the property creator is going to actually add those examples (or should do so) when creating the property. I hope you have other cases beyond these few that you feel are needed - if abuse of "part of" in this way is as much a problem as you've said then presumably there are. plenty of other examples out there. If you don't feel you have a good example on what I suggested was your second reason for these properties, then that's fine, the first reason is good enough. I was just hoping to see a clear case where that was a real issue. The only other problem I have with your proposal now is the qualifier property in the examples of (P642) - in English that has the label "within the scope of" and that still seems wrong to me, there has to be a better property to use as qualifier here. ArthurPSmith (talk) 00:26, 24 March 2016 (UTC)
@ArthurPSmith: Just create a query "A subclass of B ; B part of A", you'll find many. "within the scope of" : we definitely have a problem with labels of properties defining their usage wrt. multilingual project. just changing a property label SHOULD NOT BE enough to change the intended meaning, especially when it's supposed to be a multipurpose qualifier like here : I'm not aware of any discussion releted to this. This means the change of label might be the decision of a single person that did not spread out to other languages of they did not have the property page in their watchlist ... still a (non) communication problem then. As the creators supposed to implement the property, this should not be knowledge of the creators only, the proposers should be aware of this especially if they could be refused a property on the judgement of a creator because of this. I see in your message that you also are supposed to find one, which suggest it should not be a blocker. author TomT0m / talk page10:56, 24 March 2016 (UTC)
I'm following up in the discussion page for of (P642) - the change to "within the scope of" from "of" was recent, and I believe wrong - it was only done in English language labels. If this gets fixed I Support creation of the above two properties using this approach (but NOT using the chemical compound examples). ArthurPSmith (talk) 13:27, 24 March 2016 (UTC)
@Pasleim: Good question, I don't really remember but what stopped me was probably cases of difficult gender issues ... It's conservative. But maybe it's not justified. author TomT0m / talk page16:58, 25 March 2016 (UTC)
Since the discussion has been going on forever and has become very hard to follow, let's have a quick counting of votes to decide what to do. If you support or oppose the creation of these two properties, please add your vote and (optionally) a short reasoning below, even if you already have voted before. Please keep long discussion above this line.
Question Why would we restart from the start ??? we already have clear votes. I don't get how this is useful. author TomT0m / talk page15:25, 25 March 2016 (UTC)
Oppose I find the label of these properties misleading. They are "class selectors", however neither "class" nor "selection" are mentioned in the label. It is also unclear to me why an additional property is needed as qualifier.--Micru (talk) 07:43, 25 March 2016 (UTC)
@Micru: Your second point is simply wrong : I don't require a new qualifier anymore, and simply totally minor. Your first point does not make any sense, at least with a few explanation words, because indeed nobody used the "selectors" because ... nobody knows what that mean here, and nobdy explained. With that in mind I'd tend to reject this vote as invalid. author TomT0m / talk page15:03, 25 March 2016 (UTC)
@TomT0m: In the property proposal the example is given with qualifiers, if that is no longer so, you should update it. I reiterate that the current label doesn't reflect what it is intended, therefore I keep my opposition. If you come up with a better label, I will reconsider my vote.--Micru (talk) 15:12, 25 March 2016 (UTC)
@Micru: How to take you seriously when you avoid ansering questions ? The question of qualifiers is explained in the proposal, please read the explanation. author TomT0m / talk page15:23, 25 March 2016 (UTC)
@TomT0m: Which question did I avoid answering? I didn't detect any question in your message, maybe you could clarify your question or at least state it more clearly? --Micru (talk) 15:31, 25 March 2016 (UTC)
Well, it seem you did not mind really explaining why the label is really confusing, to explain your weird claims about the "class selector", not to mention the fact that it's kind of weird to oppose a property for the reason of a label ... that can be changed anyway after later, it's weird that it's a blocker. First you talk about a new qualifier, then you talk about using qualifiers at all, and you don't provide any alternative. To me it's like you just want to oppose and just provide any nonsense explanation. To me this vote is still invalid because of poor justification. author TomT0m / talk page15:48, 25 March 2016 (UTC)
(edit conflict)The label is confusing because it deals with classes and it deals with selection of classes without mentioning that. "Class selector" was just a suggestion to make it more clear, if you think you can come up with a better label, please feel free to propose it, but "union of" is not self-explanatory, which I think it should be a requirement to wide use properties like this one. It is common to ask for label changes, or oppose properties based on their label, nothing weird about it, as you seem to imply. Regarding the qualifier issue, I think you understood me wrong, my concern is not about a "new qualifier" but about needing a qualifier at all. Why do you need to use of (P642)? Why not to use the property directly with the values? --Micru (talk) 17:03, 25 March 2016 (UTC)
@Micru: qualifier : Please read the proposal and the followed discussion, this is extensively explained, and I won't explain that again. Name: this is blocking things for a way minor issue. Do you really could provide example of usecases where it could be misused ? I don't. So at that point this is a non problem to me, and we should not wait another year for a non problem. If we add to do this for every item in every language, we would never finish because there will always be an ambiguity somewhere somehow. We have a lot of properties with similar name and this is not a blocker. author TomT0m / talk page17:00, 3 April 2016 (UTC)
Support See TomT0m's SPARQL query above, there are a large number of cases in wikidata right now that are using "has part" to handle this sort of situation; I believe this would be a better model for that information for the reasons he has given here. ArthurPSmith (talk) 16:50, 25 March 2016 (UTC)
@TomT0m, Filceolaire, Visite fortuitement prolongée, ArthurPSmith: Done, after long deliberation. I think there is consensus that we should have these properties, the only question was, how it is going to be implemented: with qualifiers or without. (Sidenote: The correct solution would be to use something like rdf:List, but we don't have anything like that at the moment. I asked the development team about it here.) In the end there was enough support for the proposal as is (i.e. with using a dummy value) that I created the properties using it. (I added a special value list of values as qualifiers (Q23766486), instead of reusing "no value" or "unknown value", which don't seem to fit.) One of the examples given only works with this solution anyways. I think we need to gain some experience with this property, and if we learn that it doesn't work out, we can always change it. It's a wiki after all. --Srittau (talk) 12:01, 9 April 2016 (UTC)
voting system
Withdrawn
Description
this type of election is made using that voting system
@Joshbaumgartner: This defines partly the voting system : there is all king of tokens of votes with this property, so this is a class of votes. By combining with other properties we can define precisely the voting system. Or we create a class specifically for the precise definition of the voting system, but this would be a subclass of this item anyway. author TomT0m / talk page11:36, 15 November 2015 (UTC)
Oppose Not in this form. Voting system is quite complex issue with different combination of many characteristics. While it is theoretically possible to create an item for every existing system, many such items would be only applicable to the elections to one body, or even to one instance of elections. I'd rather recommend to create a group of properties describing the characteristics of the election.--Shlomo (talk) 10:28, 23 October 2015 (UTC)
Let's start from the example given by the proposer. The suggested value universal suffrage (Q319891) is hardly a "voting system" It's more a value, a concept (as the English description of the item also suggests), which has to go all the way through stating principles, preferences, combining them with each other as well with geopolitical conditions and traditions a.s.o. At the end we will get some set of the rules, which could be (with a big portion of benevolence and abstraction) called voting system. Which rules we can derrive from the universal suffrage (Q319891)? Something like: "Every citizen can vote." Really every citizen? Including minors, prisoners, insane, citizens living abroad? Sometimes yes, sometimes no. All these limitation are considered comportable with the concept of universal suffrage (Q319891) and they can (but needn't) be part of the system. And vice versa, we have often elections, where all the "inhabitants" with some kind of permanency status are entitled to vote, irrespective of citizenship. AFAIK elections like this are also described as universal suffrage (Q319891). Well, at least we can presume, that there is no discrimination based on race, sex, nobility and similar. But this seems a little weak for a definition of a voting system. Today, nearly every election in the world will declare itself "general, equal and democratic". It's the specific rules that show, how much these concepts and principles are really applied.
Further, the item gives no clue about who can run for the election. Anybody? Citizen? Age limitation? Political party? Person nominated by a political party? Person supported by a petition of ...citizens? Inhabitants? OK, let's say the property is proposed as a "voting" system, not "candidacy" system, but still, the rules for the candidacy are not less crucial for the election than the voting rules.
Then we come to the election itself. Majority rule, or proportional representation? Take in account, that we usually won't deal with "pure" majority or "pure" proportional systems, surely not in corporate bodies. There are some factors that tell some important parts of the story about the extent of "proportionality" of the election. Like number of election districts, number of representants for each district, election treshold, cogency of tickets vs. possibility of preference votes (in the ticket or across the tickets), mathematical model of converting the number of votes to the number of representants...
Even the elections for a single position (which are more "majority" type) need some additional information: relative, absolute, or qualified majority? Number of rounds? Elimination of candidates between the rounds?
@Shlomo: We don't have to have a plan to put evey details the first time. We can refine the election type in a dedicated item, but we can also put as a value a less specific items that don't contains all the details. That's not a reason to oppose. At first we can use a very generic item likeauthor TomT0m / talk page16:05, 24 March 2016 (UTC)
Support. This should be able to have multiple values, as Shlomo said. There will be some dificult cases but that isn't a reason not to go ahead with all the easier cases. Joe Filceolaire (talk) 20:38, 25 October 2015 (UTC)
Agreed, multiple values are a must, as there are many different items that can be deemed a voting system, and they can be mutually applied to instances of elections. Josh Baumgartner (talk) 17:02, 28 October 2015 (UTC)
Oppose. The proposed variant is not very useful. But if this property will be like
Comment After some thought - and an edit seen in my watchlist, I think this can be solved by generic classification properties - we may just be talking of election types. I'll withdraw if no opposition. author TomT0m / talk page16:05, 24 March 2016 (UTC)
Support as a useful property. I think the datatype should probably be just Quantity. It seems there are two approaching to this property, either without qualifiers, which could mean the current rate, and with qualifiers (start and end time seem appropriate), that would describe the period of time that a rate applied. We could say that the value with no end time (or with end time set to novalue) would be the current value. By the way Template:Infobox_economy has a parameter bankrate that seems to correspond to this property. I don't know if equivalent infoboxes in other languages have an equilavent parameter. Silverfish (talk) 21:24, 30 September 2015 (UTC)
The banking industry has a mandatory capital ratio requirement for banks (meaning that a bank must hold a minimum amount of money in its coffers at any given time). Its disclosure is required to the authorities. See en:Basel III. Leo Fischer (talk) 14:17, 9 July 2015 (UTC)
Discussion
Comment @Leo Fischer: What type of capital ratio would be required ? Tier1 Common Capital ratio or total capital ratio ? By the way, the capital ratio does not at all mean an amount of money the bank is required to keep in its coffer. It means that when a bank wants to take on more risks, it has to raise more capital.--Casper Tinan (talk) 20:16, 10 July 2015 (UTC)
This ratio can't be negative, so I figured that nonnegative was the way to indicate it (as well as the fact that it must be between 0-100). Does "numbers" reflect this correctly or is there a more appropiate datatype? Leo Fischer (talk) 14:33, 13 July 2015 (UTC)
I changed "allowed values" to 'positive numbers' as that seems closer to what you meant to say. Are sure the number can't be negative? I'm sure some banks have gone bankrupt on occasion and we probably want to record how bad their 'Capitol Ratio' got in the end :) Support. Joe Filceolaire (talk) 23:11, 6 October 2015 (UTC)
Support I support this property as Tier 1 (CETI) capital ratio. Should the name of this property be changed to 'Tier 1 (CETI) captial ratio'? Will each type of capital ratio need it's own property? Mcnabber091 (talk) 03:21, 15 December 2015 (UTC)
@Srittau: I don't think this is a duplicate with total revenue (P2139). There needs to be a property specifically for the central government fiscal revenue that would apply to a country. 'Total revenue' of a country doesn't make perfect sense. Mcnabber091 (talk) 15:16, 9 April 2016 (UTC)
Maybe this should be restated in terms of ranking? If something is changing, that means we should always a) have a preferred value which is the current period and b) retain the data from previous. --Izno (talk) 19:20, 24 November 2015 (UTC)
I haven't made any items as values for this property, but the nature of change or update mode seem good points to include. These can be a factor in ranking. Maybe we should seek a standardized way to describe on a property level what we think gets this or that rank. It could clarify things. --- Jura19:47, 24 November 2015 (UTC)
Many building templates have a number of rooms parameter to indicate how many rooms a building or a hotel have. In the case of hotels, the number of rooms is a common measure of how large the hotel is compared to other hotels. Mippzon (talk) 08:27, 25 March 2016 (UTC)
Comment @Pigsonthewing: Could you show an example on an item? I think I know what you mean and it sounds reasonable, but I would like to see it in practice :) //Mippzon (talk) 16:56, 27 March 2016 (UTC)
Comment The number of rooms is also used in a broader context when speaking about a tourist destination, like a city, to stress the hotel capacity (Q2937179) of that place. Therefore, if the property is created, I wonder if the allowed values should not include any populated place, on top of hotels and such. Thierry Caro (talk) 09:16, 26 March 2016 (UTC)
Emot Hotels do not only have rooms to rent, but also rooms to store sheets, instant coffee and pickles, so a more specific approach like that Andy shows would make more sense. -- Innocent bystander (talk) 14:41, 30 March 2016 (UTC)
(for example the description of clay animation (Q870889) in english is clear ... stop-motion animation made using malleable clay models it's a subclass of animation movie. Stop motion is an artistic form, like a literary genre (Q223393) so it's essentially a type of work. But I agree we need to be more able to define what is stop motion ... and which type of materials the artists uses when they build the work : drawings for old Walt Disney, CGIs for modern animations, papers, ... so i'll Oppose the creation of what is essentialy a specialized property, but I will Support the creation of properties to describe more precisely the material and techniques used for the kind of artworks. TomT0m(talk)18:20, 16 July 2015 (UTC)
Oppose as specifically for films, but Support as a broader 'production technique' (method or technique used to create or produce the subject) that could be used as follows:
As an aside: the proposal for P2079 was actually made after this proposal, so it could not be found when this proposal was made. --Srittau (talk) 13:53, 27 March 2016 (UTC)
Complementary property to the proposed above. A simple software reverse feature won't be enough. I can't have examples ATM to present to you, but a given work can be created in reply to one or more works but a third reply can be created only in response to a portion of the works-tree. Example:
A is replied on B
C is replied on D
E replies to B and D
F replies to A→B→E without any mention to the C→D→E sequence
This complementary property can be delayed to get created only in the stage that the hypothetical F (not so hypothetical, I only don't remember any of this situation presently, but it certainly is somewhere else) appears on Wikidata. But to make consistency will be necessary to fill all previous records with this kind of data. Creating the property right now at the very same time than the other proposed property will prevent us of being crazy with this: we just start to store this in both directions/entries (maybe with some sort of bot help to check if both pages/entries have both directions of data; IF a is a response to b BUT b didn't says that is replied on a, bot adds b→a record on b page). Lugusto (talk) 18:37, 31 October 2015 (UTC)
@555, Filceolaire, Swpb: Done, only lean opposition. None of the properties mentioned seem to really fit a direct answer of one work to another. I tried to make that clear in the English property description. --Srittau (talk) 21:57, 28 March 2016 (UTC)
In case of NMHH film rating (P2363), this certificate number is featured on movie posters and home media covers along with the rating itself, and would help finding the film's record in the .xlsx given as source on the property page. MPA film rating (P1657) has a similar number which is listed on filmratings.com and IMDb. Most content rating systems have a similar reference certificate number. Máté (talk) 06:56, 15 December 2015 (UTC)
Discussion
Comment Should be, say, "rating certificate ID", as the examples include letters. Also, perhaps we need a separate property for each issuing body, so that we can use formatter URLs? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits17:02, 15 December 2015 (UTC)
MPAA calls its own ID "certificate #" that is why I chose the name, but I'm happy either way. (NMHH also calls its own "nyilvántartási szám [registry number]" but it's like production and serial numbers, those also contain letters, don't they?) As for the formatter URLs—it may be a good idea to have separate ones, if there really are content rating bodies where you can access the decisions by an URL containing the certificate number, but in the case of these two specific examples, it is not so (in case of NMHH it makes it easier to find the decision in the spreadsheet, but you can't link to it). The main use is being able to differentiate among multiple ratings for the same item (when it's revised, or when there are several cuts/releases).
@Pigsonthewing: So, what say you? I changed the name, but on this limited sample (these are all the film rating properties we have right now) it doesn't seem to be useful to split it to multiply qualifiers since URL formatting is not an option, even for FSK it could only be computed from this qualifier and point in time (P585) (which could be added as another compulsory qualifier to these properties, btw). – Máté (talk) 21:30, 30 December 2015 (UTC)
I'm halting uploading data for NMHH till this is sorted. @putnik, Mps: maybe you have something to add as you proposed the MPAA and FSK properties? – Máté (talk) 08:33, 21 January 2016 (UTC)
@Máté: This property is really necessary, but I don't know whether it should be a qualifier, or better to create it as a separate property. As I understand it, is's not just a rating certificate, it's a film certificate (including a rating). It may be benefits from the use of this data separately from the rankings. —putnik21:01, 31 January 2016 (UTC)
@putnik: in the above examples the IDs correspond to certain rating decisions (e.g. FSK had two IDs for Mad Max, one for the theatrical release, one for home media, albeit with the same preceding number. This example may help:
primarily likely to be user-supplied using a specific tool; but in some cases might possibly be available from external references
Formatter URL
https://tools.wmflabs.org/zoomviewer/proxy.php?iiif=$P18/$1/,240/0/default.jpg (where $P18 is the value of property P18)
Robot and gadget jobs
I would imagine a tool similar to the crop-tool on Commons, challenging the user whether can they find this item as a detail in this image, and to move a rectangle around the detail if they can.
Motivation
At the moment, the Crotos tool can show paintings that include depictions of particular things, noted by the P180 statement -- eg here are some paintings with items that include depicts (P180) = house cat (Q146) : Crotos.
With this property, a similar tool would be able to show just the cats, or just the clocks, or just the examples of whatever particular detail we were interested in, rather than the whole image.
More details about the IIIF syntax used in the URLs (an international open standard being developed primarily by libraries around the world) can be found at http://iiif.io/api/image/2.0/
The proposed syntax for the property is intended to be identical to the {region} part of the IIIF URL, so pct:x,y,w,h specifies x-offset (from left), y-offset (down from top), width w, and height h of the crop region (as a percentage of the whole image).
The percentage format is particularly useful here, as it makes the property independent of the actual image file used: if the image is later replaced by a different photograph that is a different size, the percentages should be unchanged, so long as both images only show the painted area of the painting (ie not the frame). This should also make the property re-usable, including by users who may have different preferred images of the same painting.
It could be quite a treasure hunt to find all the details we have recorded for all the paintings we have items for -- but it makes the P180 statements much more precise and valuable, if we can indicate exactly what is the specific part of the canvas that we are identifing as item Qnnnn. Jheald (talk) 23:51, 15 December 2015 (UTC)
I think "pct:" is useful, because when people read the wikidata item page it makes the numbers more self-explanatory, underlying that they are proportional to the overall size, and that they are percentages out of 100 -- neither of which would necessarily be so obvious without the "pct:". Note also that, in the IIIF standard, if "pct:" is omitted in the {region} part of the URL then the values are interpreted as pixel counts -- something that we would wish to avoid, as it would tie us too closely to one specific scan on Commons, rather than a general statement about the painting as a whole. I think that including the "pct:" helps make more explicit the choice we would making. It doesn't seem to me that we're so hard up for storage space that we should worry too much about four extra characters. As to the second point, I think that because what the property is describing is something that makes sense as a distinctive thing in its own right, namely a region of a larger painting, it makes sense to keep the full specification of that region together as a single value of a single qualifier, rather than breaking it apart across multiple different statements. (It also means that if e.g. a canvas contains images of two cats, the positions of these can then be given with two simple region statements, rather than having to untangle which of 8 different co-ordinate statements belonged to which cat). Most of the time, the all-in-one string format will actually be an advantage, because it can be slotted straight into a IIIF URL. There may be some analyses where one might want the individual numbers -- eg if one wanted to filter to only extract details that take up more than 15% of the painted area. This could be done in SPARQL (though it might be a little slow), using the STRBEFORE and STRAFTER string operators to successively extract the parts of the string before and after each comma. Jheald (talk) 16:09, 16 December 2015 (UTC)
I don't think there's any precedent for including definitions for humans, ("pct" as "percent") in values, nor do I think it would be wise to introduce one. As for pixels vs percent, that can be covered adequately in the property definition (and formatter URL if any). I do find you argument on my second point convincing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits18:32, 16 December 2015 (UTC)
Support the principle also - could be useful also for P18 on Q5, when the image is a group portrait (or 2-5 people) to indicate which one is the item ;) — don't see the need for pct: indication either --Hsarrazin (talk) 11:42, 28 December 2015 (UTC)
Comment Support here for the principle, too, cf. the idea before we had IIIF support. And I think it should be considered to add the "pct:" though I am not decided about it. I doubt the possibility to preserve the value between different image files. (Pictures get cropped over the history and unfortunately most image files are also at least slightly cropped and not all by the same amount for one physical object. That is why I'd like to propose a slightly more complex system: The image (P18) statement on the item gets qualifier that relates an image to a reference grid. The depicts (P180) statement gets a qualifier for the relative position that refers to the grid. Like this:
Creation of a reference grid for two dimensional objects on Wikidata based on Commons images that can be reused by third parties.
Reusability of the given relative positions on section images on Commons.
Ability to adjust the rotation of a file with the rotation value of IIIF that will probably be necessary in some cases even though the IIP Image Server does only support 0, 90, 180, 270 and 360 degrees for now. In the example I added an additional "/0" for the relative position to reference grid property.
Disadvantages:
More complex system that relies even more on additional tools. (Though the need of tools for an nifty use would probably exist anyway.)
I also think we should support free forms for regions. This requires an other syntax for the value of the "relative position within image" property. But the outer borders of a free form can easily be evaluated and passed to IIIF.
@Marsupium: For use on Wikidata, I think we want to have a property syntax which relates only to the painting, not the image of it. Therefore I would recommend this property formally be used to indicate the relative position within the painted area of the painting.
In most cases (not all cases, but most cases), our P18 "primary image" property does correspond to an image which has been cropped to the painted area. I suggest that, at least to start with, this property should only be formally supported for images where that is the case.
In cases where the primary image is larger than the painted area (eg where it includes the frame), one could perhaps define another property to indicate relative position of painted area within the image. One would thus be able to specify the relative position of the extract within the painted area, and the painted area relative to the image -- from which the relative position of the extract within the image could be calculated. But that would need specific code, even if just to compute (xP+wPx, yP+hPy, wPw, hPh), to combine the two into a single cropping instruction to pass on to IIIF.
For the moment, lets not seek to run before we can walk. My view is that it is worth starting as simply as possible, just to get people used to the idea (and the possibilities) of being able to specify and show just a part of a Commons image. If we start just with what is simple, but possible now, then more sophistication will surely come. Jheald (talk) 23:27, 10 February 2016 (UTC)
As you say: „For use on Wikidata, I think we want to have a property syntax which relates only to the painting, not the image of it.“
That is exactly the aim of my proposal! In many (or perhaps most) cases essentially two-dimensional visual artworks (the domain of this property should not only be paintings, but it applies to them just as well) do not have a something like a „painted area“. And if they have it it is not possible to define it properly and even less if we cannot go to the original object, take it out of its frame and look where the canvas ends beneath its frame (what will mostly be the case).
And virtually all images on Commons are cropped and do not represent the outer border of the represented object in real life. I guess the mean value will be something like 1 cm per side, but there are many worse cases we won't even notice without examining the original object. Examples: Head of a Woman (Q797902): evidently no not cropped image on Commons; Vitruvian Man (Q215486): Which Commons image shall we take for the image (P18) statement?; Battle of the Centaurs (Q2313006)?; Taddei Tondo (Q2500548)?; …
And also the original objects get cropped during their production or during their history. Printed graphic is not even physically bound in the way that the paper sheet objects produced by one printing plate and unfortunately we cannot refer to printing plates on Wikidata since many are lost and we do not have images for those which survived. Examples: The Night Watch (Q219831): Shall we take File:The Nightwatch by Rembrandt.jpg for the image (P18) statement? Can we describe then the position of the leftmost person of the state till 1715, cf. File:Nachtwacht-kopie-van-voor-1712.jpg?
Even with my proposal we run into problems with objects that got sticked together of course.
And there is yet another occurrence of the problem: What about those items that have more than one image (P18) statement? The proposed property refers to the first one? When the order gets changed we need to change the qualifiers with the proposed property?
After all the one additional qualifier with the additional property I proposed is not a big deal in my eyes. It could even be added by bot and will still make our system more stable and Commons image independent (though Commons image defined).
And to the passing of the value to IIIF: At least for clickable links we will anyway need a tool since we cannot simply give a formatter URL (P1630) for the proposed property. And other tools which retrieve the values will probably not have big problems to execute simple subtractions. And if we set the standard to state:
⟨ object ⟩image (P18)⟨ the only image file or possibly first of several and perhaps order constant images files ⟩ relative position to reference gridSearch⟨ pct:0,0,100,100/0 ⟩
those tools do not even have to calculate the values but can simply take them as in your proposal.
Though I'd love to have a property to indicate areas of essentially two-dimensional objects, I actually also {{oppose}} to the introduction of a property which arbitrarily relies on the given borders of one Commons file. --Marsupium (talk) 12:04, 11 February 2016 (UTC), changed 14:11, 11 February 2016 (UTC)
@Marsupium: You call for perfection, but as a result you would see us end up with nothing.
What I too would like to see is feature-positioning data that is as reusable as possible -- in particular potentially by museums, galleries, other projects that may have their own images. It would be good for them to be able to combine our feature-positioning data with their images, as painlessly as possible.
I agree that that means one needs to be able to give features relative to some reference grid -- and it seems to me that, ideally, that reference grid would be based as far as possible on the properties of the object, rather than some abstract set of edges we have defined purely for wikidata. In a very large proportion of cases, it does seem to me that the most obvious features of the work to choose for such reference coordinates would be the opposite corners of the visible painted area -- so, specifically, for a painting the area visible within the frame; and for a print, the corners of the main feature image of the print.
(And in some cases that might lead to some co-ordinates that were negative, eg to specify a feature in the frame).
So in broad terms I can see that dependence only on the object to fix a co-ordinate system, rather than any particular image, would be good. But you are right that there are harder cases, when such natural corner points are not so obvious. In such cases, one probably does end up having just to say: this is the particular reference grid we're using. And in such cases the most portable way the most portable way I can see to do that would seem to be to make the key points the opposite corners of a particular reference image. Then at least someone else can use image-matching software to come up with a mapping from those co-ordinates to co-ordinates based on their own image. So in that case one probably does have to declare a reference image.
And perhaps, it's no bad thing to define the co-ordinates in relation to a particular reference image anyway -- that saves questions like what is the relevant visible painted area. I accept that in the simplest cases, it may not much matter which baseline image one takes, if we're only interested in eg roughly where the rabbit is in the overall picture, which may be only accurate to half a percentage point anyway, so changing one baseline image for another, cropped very slightly differently, may hardly make an appreciable difference. But if we want to allow for higher precision work (eg precisely how one image maps to another) maybe it's not the worst thing in the world for the feature-positioning to be specified formally to be in relation to a particular reference image.
So having started by thinking that definition with reference to a particular image was a weakness of the proposal, maybe it's not such a bad thing after all.
Probably though one should allow the possibility to be able to specify a particular reference image as a qualifier, as an override for the default P18, to allow the positioning to be specified relative to that, rather than the default. Jheald (talk) 13:52, 11 February 2016 (UTC)
(edit conflict) :-) @Jheald: Yes, I agree and had changed my mind before your reply. Unfortunately I was AFK some time. I should have made this an additional property proposal before. Sorry! Better late than never though. Would you mind if I moved our discussion there (at the weekend)? --Marsupium (talk) 14:11, 11 February 2016 (UTC)
@Jura1: Not really -- the aim here is to record properties of the underlying painting itself, independent of the image (or images) of it on Commons. This can go ahead and be useful now, without CommonsData. (And for works that have items here, CommonsData wouldn't be the appropriate place to store this information). Jheald (talk) 22:42, 10 February 2016 (UTC)
I like the idea and would love to have this, but "string" is the wrong datatype so I reluctantly Oppose this. Did anyone already file a bug for a datatype which could properly contain this? Multichill (talk) 21:09, 3 February 2016 (UTC)
@Multichill: Using string is not the cleanest solution of course. Could this datatype you imagine be used for other properties as well? And do you think the introduction of a new datatype and the necessary tribute to Occam's razor (Q131012) outweigh the practical disadvantages of the need to parse a string for tools? --Marsupium (talk) 20:41, 10 February 2016 (UTC)
@Multichill: The advantage of this string is that it can go straight to the IIIF service without any further parsing. IMO, it also fits much better into an RDF/triplestore framework to store all 4 numbers in a single object, rather than splitting them out over 4 different ones, that then have to be kept in sync. Perhaps in future one could migrate the datatype, in a similar way to what is about to be done for the external ID datatype, so that one could offer the 4 numbers individually hung off the statement, as well as the string for the 'simple' value of the property. But let's not let the best become the enemy of the good. With a string value, this can be implemented right now, and we can start gathering the data & showing off what it can do. That doesn't stop us migrating the data to a complicated datatype in due course -- but it means we can go ahead, without having to wait around while somebody might or might not develop it. Developer time is scarce, and they have no shortage of other commitments already in the queue to have to be processed first. Jheald (talk) 22:58, 10 February 2016 (UTC)
I see. And it came to my mind that this can also enable the use of free forms rather than rectangular forms which is quite attractive in my eyes! Though I also do not think that the datatype should be an obstacle to create a string property for now. --Marsupium (talk) 12:04, 11 February 2016 (UTC)
@Jheald, Pigsonthewing, Hsarrazin, Marsupium: Done, including the pct: prefix. The prefix is useful, because it defines the format for the following values. If we get a proper datatype for those kind of values at some point, we can always replace this property with a new one. --Srittau (talk) 23:02, 28 March 2016 (UTC)
TV.com is a huge database comparable to IMDb which is used extensively in several Wikipedias as a source and for external links, so have properties for it in Wikidata would make linking more efficient.
How many properties we should have is up for discussion. As you can see, the ones I've proposed for show, episode and seasons all use the same formatter URL, so they could quite easily be merged into one property. And if we want just one property, we could do that by including the "show"/"movie"/etc part of the URL (so the allowed values would be something like (show|movies|people)/[a-z\d\-/]+), but I personally don't favour that idea as it might get a bit messy. But input would be appreciated. Jon Harald Søby (talk) 11:25, 18 December 2015 (UTC)
@Máté: Since there were no other comments for a while I have reworked the proposal to be about just one property that can take lots of different input instead of one for each. If you approve, please support. Jon Harald Søby (talk) 15:12, 5 January 2016 (UTC)
In order to easily add a link to the related page of Russiancinema.ru for each Wikipedia article about soviet and russian films. Antenor81 (talk) 22:04, 7 January 2016 (UTC)
We have already some specific properties for special contributions to a book (translator (P655) and illustrator (P110)) so instead of creating a special model using qualifier to store the author of the preface of a book I think we can create a specific property. Snipre (talk) 16:28, 22 January 2016 (UTC)
Still unsure so Neutral for the moment. Comment did we really need a specific property? Will there be some specific constraints? (I see that translator (P655) has only one constraint : which is identical to constraints on author (P50), other constraints on author (P50) could apply to translator (P655)) What is wrong with using author (P50) with qualifiers? If this property is created, how to distinguish the author of the preface(s), of the foreword(s) and of the introduction(s) (and other stuff at the beginning like prolegomenon (Q1361348)). Cdlt, VIGNERON (talk) 13:21, 24 January 2016 (UTC)
@Snipre: very true: unity in structure is essential but I still have some comments 1. why don't we use the same structure with qualifiers for illustrator, translator, etc.? 2. how many specific properties should we create: 10? 100? why not 3 properties to distinguish the writers of preface/foreword/introduction? I feel like one proprety for everyone who is an author lato sensu is easier and better per Occam's razor (Q131012) ; but maybe I'm missing something. Cdlt, VIGNERON (talk) 15:01, 4 February 2016 (UTC)
Oppose There shouldn't be a class "books" at all which could serve as domain here. By the FRBR model we are trying to adhere here, there are creative works and their "editions or translations" and prefaces or introductions are something which only applies to the latter. To be more precise, the author of an introduction is - uhm - the author of the introduction as a small work in its own right and some edition encompasses these distinct works. Even if we take some shortcuts here the question is whether the introduction more often than not deserves an WD item of its own? -- Gymel (talk) 21:13, 27 February 2016 (UTC)
We have already some specific properties for special contributions to a book (translator (P655) and illustrator (P110)) so instead of creating a special model using qualifier to store the author of the postface of a book I think we can create a specific property. Snipre (talk) 16:41, 22 January 2016 (UTC)
Copyright status of an artwork; similar to the license codes (PD-Art-100, CC-by-SA, etc) used on Commons but not limited to artworks on Commons, so included other non-Commons supported copyright licenses
Question Wouldn't a system where you could indicate who owns the copyright at the same time better? Also, probably it should be used with qualifiers start time (P580) and end time (P582), with the current one having preferred rank. – Máté (talk) 12:31, 23 January 2016 (UTC)
Probably. I think several other qualifiers are in order as well, such as inferred death date of the creator related to the country of creation and associated copyright terms, etc. --Jane023 (talk) 14:45, 23 January 2016 (UTC)
Possibly this should be a request for two properties to be used in combination: "License" and "issued by", with agreements for public domain and photo uploads (or else we will need to import commonist uploaders as creators, which is a bit much I think). --Jane023 (talk) 09:08, 25 January 2016 (UTC)
@Jane023: I would have thought two properties; the first being "copyright status", qualified by "copyright owner" (and possibly also by "jurisdiction") and the second (which might also be a qualifier) "licence". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits21:10, 25 January 2016 (UTC)
Hmm interesting. Yes I think you are right. So should this be a double set of double properties? Or one property with certain required qualifiers? I see what you mean in that 2 properties may not be enough. --Jane023 (talk) 16:20, 28 January 2016 (UTC)
Taking a stab at some common copyright situations:
PD-Art: for artworks in and out of copyright (items to be accepted could be linked to specific templates on Commons?)
PD-old: for works out of copyright which accepts a date such as artist death date or creation date
PD-Wikimedian: Wikimedia user who released his/her rights
PD-author: for works released into the public domain by non-Wikimedia users
PD-reason: takes reason items for a lack of copyright, such as PD-USGov for work by the U.S. federal government
Yes I picked this example because it is a classic example of messiness (legally shown on Hermitage website, "fair use image" available in English Wikipedia article, not on Commons). It is specifically cases like this that we need to model correctly in order to start gaining editors who understand our "copyright gap" in art coverage. --Jane023 (talk) 09:08, 25 January 2016 (UTC)
Modeling copyright is no easy task. In the current status I Oppose this property proposal. We have two things here:
How to model the difficult world of copyright?
Do we want to model copyright here?
For the first part we had quite extensive discussions on the project kick off of c:Commons:Structured data. One property won't do it. As for the second part. I'm not sure. In this example case it looks like derived information that can't be sourced from a reliable source. I'd rather provide an automated way for people to figure out the copyright status of a work of art. Multichill (talk) 21:02, 3 February 2016 (UTC)
We have Property 275 for "License", which is a good way to indicate if something has been proactively given a Creative Commons license for example. However, that is not an appropriate way to express Public Domain because PD is not a license, it is the expiration or absence of a license. There are many diverse ways for a creative work to be PD (as our many and various templates on Commons demonstrate!), but these are nuances of why something is PD - which should be handled by Qualifiers here in Wikidata. Wikidata is also capable of modelling contested copyright statuses in different jurisdictions or competing claims. For example, with this property, it is possible to say that something to be "Public domain" (with a qualifier of "start date") and simultaneously has a copyright status of "in copyright" (with the qualifiers of "license" if needed, "owner" if different from "creator", "country" if it's a copyright status specific to a particular jurisdiction). Both of these statements can be given an equal rank. It is also possible to model the fact of something that will enter the public domain at a certain point in the future (by giving an "end date" qualifier), or equally we can model that someone has made a claim of copyright on an artwork that, according to Reliable Sources, is considered invalid (we can use a deprecated Rank for that statement). Wittylama (talk) 14:40, 4 February 2016 (UTC)
The example provided doesn't make sense, additionally the conflict with the "License" property is not addressed. Such a property can be added only if it's extremely clear what is valid as object. DPLA and Europeana tried a "standardisation" effort with http://rightsstatements.org/ which is extremely hard and we risk adding further confusion. Nemo15:51, 4 February 2016 (UTC)
Can you clarify which example doesn't make sense to you, please? Regarding what I see as a limitation of the "license" property: I don't think it is sufficient to express the concept of Public Domain/out of copyright. It's not right to say "license -> public domain" because PD is objectively not a license (CC0 is not even a license, it's a "dedication"). Equally, I don't think "license -> expired" (or something similar like "not applicable"?) is an effective way of phrasing it either. By contrast, if this property was created, we could say "copyright status -> public domain" (with a qualifier for start date etc if desired). Does that explain my point? Wittylama (talk) 17:04, 4 February 2016 (UTC)
filmportal.de is the german association to collect all german produced and financial supported films. All german films have to register at filmportal by german regulations, so it's a good identification like ASIN for audio-visual works. Fililipa (talk) 15:45, 24 February 2016 (UTC)
I've encountered several artworks already for which we'd need this property. This is different from pendant of (P1639), which refers to two artworks on different carriers that were created to complement each other. I also propose the reverse property. Both must be named clearly (or get several crystal clear aliases) so that they don't get mixed up with their reverse. Spinster (talk) 15:21, 29 February 2016 (UTC)
Discussion
Are verso and recto that important? Are "A" and "B" sides of singles (vinyl) also considered valid uses for this property? Alternatively one could think of a single and slightly more general property "shares carrier with" which would allow for more than one work on each "side", e.g. when several (unrelated) small sketches are located on the page verso. -- Gymel (talk) 16:27, 29 February 2016 (UTC)
I have encountered it very commonly in art collections, here's an example from one museum. Since it's indicated even in the inventory number, I think it's considered to have some art historical and practical importance so yes, I want to stick with the narrow definition. Spinster (talk) 16:45, 29 February 2016 (UTC)
Support I have also seen this for old books without pagination, and also for old drawings and prints. Support both, voting here. Jane023 (talk) 19:02, 29 February 2016 (UTC)
Support - I've been working on the collection of Bosch paintings, quite a few of those are two-sided and would benefit by this property. Husky (talk) 20:42, 12 March 2016 (UTC)
Comment This is an example of a concentration, and as previously discussed "%" is meaningless if we don't know what has been measured (For alcohol mostly volumen, but we need to be explicit). We have items for concentrations: e.g. millilitre per litre (Q21075844) --Tobias1984 (talk) 21:25, 10 January 2016 (UTC)
@Jura1, Pasleim, Tobias1984: Done Ranges can be supplied as part of the quantity datatype (although there is currently a bug: see [1]), the property makes it clear that we are talking about volume percentage. --Srittau (talk) 19:02, 26 March 2016 (UTC)
The proposal was for either version. Infoboxes use various measures. Can you relabel it as proposed? Somehow the sample link to frwiki was deleted by (I let you guess who). --- Jura19:21, 26 March 2016 (UTC)
The leading ontologies for describing datasets are VOID, DCAT and ADMS by the W3C. The Getty LOD documentation shows summary diagrams & links, and uses all of them to describe the Getty dataset. Our intent is not to replicate all this information, but to provide only some critical entities and properties to allow finding datasets and access points. This is a somewhat complex topic, so before proposing properties, we should look at the above models, look at some examples, and synthesize a simpler version.
Dataset Distribution (Q): particular version/release/format of a structured Data Set (database) that is publically available. May be created and published by other than the database owner (that's quite common)
Question @Vladimir Alexiev, Filceolaire: ZIP is not really a primary file format, "Zipped TTL" may be. We need a more expressive way to hadle fie formats. media type (Q1667978) can identify some formats. As for ontology. An ontology can be express in numerous file formats ... Would we need a more specific "ontology" property ? author TomT0m / talk page17:10, 12 November 2015 (UTC)
@TomT0m, Filceolaire: To handle a file or URL, an application needs to know all applied formats, not just the "primary" (content) or "secondary" (compression). Combining them into one (eg "zipped turtle") is not a good idea since we'll cause a combinatorial explosion. We could split into two props if you prefer? (eg HTTP has Content-Type vs Content-Encoding) I didn't want to complicate it too much, but now that I think about it, I'm in favor of splitting.
As for Ontology, I completely agree to split it out. It's the same as void:vocabulary. (I just didn't think the WD community would be so interested in RDF datasets :-). Should I make a proposal for it? --Vladimir Alexiev (talk) 21:07, 16 November 2015 (UTC)
In general we will have an item for the dataset. We need properties to link to the various datafiles for that dataset. The question then is whether we have properties for each type of file with qualifiers for the file format and compression format (my preferred solution) or if we have separate properties for each datafile/file format/file compression format (seems clumsy). Joe Filceolaire (talk) 03:59, 22 November 2015 (UTC)
PLEASE first comment on the need to describe Datasets, and then on the specific implementation proposed above (of course, we could have a different implementation)
I welcome thoughts on how to describe datasets, and the above is a good basis for having a discussion around that – thanks, Vladimir. The proposed implementation would seem to work for the examples given, but I am missing thoughts on licensing and versioning of datasets, as well as on the scope of datasets to be annotated this way. For instance, if there is an item about a scholarly publication and that publication has some associated data in a database, it would make sense to annotate the item about the paper with information about the dataset. This would not necessarily require an item about the dataset itself, though that might be an option if WD:N does not stand in the way. --Daniel Mietchen (talk) 00:48, 20 January 2015 (UTC)
Suggesting if there is a CKAN/DataHub entry, that should be linked from the WP page? Other than that, I think VoID actually does do a good job at the provenance. Other than that, what is the envisioned difference between a data set and a data base? The latter has a clear visibility, with a website, etc. What makes a data unique? Egon Willighagen (talk) 07:49, 20 January 2015 (UTC)
Egon, Datahub is just one of the important URLs: above I give other examples. VOID does a good job, but is only applicable to RDF datasets, and less than 30% have a VOID file.
"Dataset" and "Database" are just about the same, and there are many other similar items (eg Authority list). I've only proposed a property "dataset distribution" to point to a particular distribution of a database, since often there are many: see GND examples above.
Hi I started to work on this subject. Can I reuse or complete or duplicate the box "Property documentation" ? I write these box in the comments ? or in talk page ? May be create a project Wiki4R and create a subpage for this part ? --Karima Rafes (talk) 13:57, 20 January 2015 (UTC)
Karima, go ahead and edit above, it's a wiki. I added "protocol". If you want to move the section "Datasets" to a more permanent location, go ahead: but after the voting for the properties (when it will be moved to a subsection "Archive". --Vladimir Alexiev (talk) 18:56, 21 January 2015 (UTC)
Hello, I splited the dataset distribution in dataset and distribution like in the ontology dcat. I proposed some properties in the aim to make a map like on the website https://io.datascience-paris-saclay.fr/ and for the future web agents. I don't know exactly if the properties exist or not in Wikidata. --Karima Rafes (talk) 14:26, 22 January 2015 (UTC)
@Karima Rafes: 1. Don't see a need for "dataset" vs "distribution" property, and you don't seem to propose different examples. We don't need to copy dcat or any other ontology. 2. The markup following "Here proposition for the infobox" is broken, please fix it!! 3. Put your contributions in separate sections (one per property) and sign them (not just this comment). 4. If you want to propose a property (eg xxx:statusAccessURL), do it using the appropriate template at the top of this page, so it can be discussed and critiqued independently. (Critique about this one: one dataset may have several access URLs, so a single "status" prop won't do. 5. "I don't know exactly if the properties exist or not" is no excuse: don't propose properties before checking whether similar properties already exist. Pick any item, go to Claims, click Add and use the autocomplete. --Vladimir Alexiev (talk) 08:41, 25 January 2015 (UTC)
1. "We don't need to copy dcat or any other ontology." DCAT is an ontology for the software agents. If you don't split, you impose that there is only one way to access the data and so, only for the human. It's not logic to use DCAT only for human. 2. Sorry, I have no the time for the moment. I try to fix if wikidata want to be a hub for the software agents. Is it the moment for this debate ? (good place?) 3. 4. 5. it's not urgent. I moved my examples in my personal page for the moment examples of properties for a object dataset and distribution --Karima Rafes (talk) 09:30, 25 January 2015 (UTC)
I think wikidata should aspire to be a hub for software agents.
I think that there is a case for specialised url properties rather than using "of" as a qualifier, particularly for 'machine readable' access and particular types of info - such as 'technical info URL', 'VOID url', 'API url'.
'Datahub' should perhaps be a string property since it always refers to the datahub site - like all the other database properties.
A 'download url' property should be designed to be useable to download digital copies of books or songs as well as databases. This applies in particular when the content is available as a free download but the licence terms are not compatible with Commons.
I support 'file format', 'compression file format', 'protocol' as qualifier properties.
Agree to have "specialised URLs" since these are easier to work with than "of" qualification (both for WDQ and SPARQL querying). I just wasn't bold enough to propose so many new properties.
If you think from the FRBR "work-expression-manifestation-item" point of view, a Distribution is similar to Expression or Manifestation: if it's done by someone else through significant conversion work then it's Expression (similar to a translation of a book); if it's just an update or editorial work, then it's aManifestation (simlar to an edition of a book).
Instead of a new prop Distribbution, we could use software version identifier (P348) but currently it's for "software" only and doesn't have a "derived work" aspect (typically each consecutive version is made by the same people). It seems that has edition or translation (P747) is a better fit (it's the same idea!), but do you think bibliophiles will allow the alias "distribution"? Or maybe keep them separate just for clarity?
Agree about doing "Datahub page" as an ID rather than a URL. (they did change their base from ckan.org to datahub.io a few years back) --Vladimir Alexiev (talk) 11:53, 31 July 2015 (UTC)
@Srittau: thanks for being so scrupulous. Guess I started with dataset vs distribution but then decided one is enough. And looking at the worked examples it is. Cheers --Vladimir Alexiev (talk) 04:59, 5 April 2016 (UTC)
The Carnegie Classification of Institutions of Higher Education (Q4223026) encodes the type of educational institution based on a number of constituent datapoints (such as percent of students studying a certain major, like engineering). By adopting this widely-used classifier, Wikidata can similarly store the type of institution without having to store all of its constituent data. This field is higher education's equivalent of "genre" for movies.
An alternative to a strings value could be entities corresponding to the limited number of classification classes.
Support. If we go with an item datatype then we can make statements about each class of institution. Do we want to do that? String seems wrong when these are not identifiers for each institution so I think item would be better. Joe Filceolaire (talk) 21:17, 12 September 2015 (UTC)
Question @Jura1: Jura, do you mean that we don't create a new property because we can simply use another formatter URL somewhere else? Or that this type of information is out of scope of Wikidata? Or something else? I understand your comment that we *can* use Integrated Postsecondary Education Data System ID (P1771) to look up the information, but does that mean that Carnegie Classifications just won't be in Wikidata at all? Runner1928 (talk) 17:27, 28 October 2015 (UTC)
Strong support I don't understand @Jura1:'s suggestion - this is not an identifier for an educational/research institution, it is a classification of the TYPE of the institution. Sorry I didn't notice this earlier; I think it is very important for coverage of US institutions. Unfortunately I don't believe the classification is used outside the US, but within the US the Carnegie classification is a key way to group institutions of similar type. ArthurPSmith (talk) 19:10, 9 December 2015 (UTC)
Strong support with a clarification that there are seven separate classifications in this typology; although most attention is given to the "Basic Classification" the other classifications should be included, too. Additionally, it may be desirable to split one of the classifications - "Size & Setting" - into two data elements since, as the name implies, it's really two descriptors (inexplicably) concatenated into one. Finally, there is also a "Community Engagement" classification that is optional and maintained by a separate organization; it would be nice to also include this but it's (conceptually and logistically) different from the other typologies so I can understand if we want to discuss it separately or defer it indefinitely. ElKevbo (talk) 19:42, 2 January 2016 (UTC)
Additionally, it might be better to get the data directly from the research center in Indiana as it may take several months or longer for the information to make it into the federal goverment's database(s) especially since the current update is not only an update to the classification of many institutions but an update to the classification schema itself. ElKevbo (talk) 21:01, 2 January 2016 (UTC)
Update based on the URL from the previous commenter: in the new 2015 system, there are six classifications. Basic (32 options), Undergraduate Instructional Program (21 options), Graduate Instructional Program (18 options), Enrollment Profile (7 options), Undergraduate Profile (16 options), and Size & Setting (18 options). Options tend to be somewhat hierarchical so that, for instance, Basic - Doctoral Universities has Highest, High, and Medium Research Activity levels. The organization sometimes publishes reports using the top of the hierarchy (e.g., Doctoral v. Master's. v. Baccalaureate) and sometimes at the more granular level.
I suggest creating items for the approximately 100 classifications, plus the hierarchical modeling. E.g., Basic - Doctoral - Highest Research is subclass of (P279) Basic - Doctoral subclass of (P279) Basic. Then this new Carnegie Classifications property can have an Item datatype as well as start time (P580) and end time (P582), for when the organization releases its next classification in five years. An Item datatype especially makes sense because the Carnegie organization offers no easy URL for formatter URL (P1630). Their search URLs use some internal ID. But we can at least manually provide those URLs on the individual classification items. I prefer a single new property that points to six items per educational institution, rather than six new properties. The big advantage to multiple properties (the formatter URL) isn't available to us here. Runner1928 (talk) 16:23, 11 February 2016 (UTC)
Scraping of the CRICOS website would be possible, with data added to mix-and-match for further import into Wikidata
Motivation
CRICOS stands for the Commonwealth Register of Institutions and Courses for Overseas Students and is in place to ensure international students studying in Australia and New Zealand get a good quality of education. All universities and colleges in Australia that accept international students must be CRICOS registered, to meet the requirements set out in the National Code of Practice which was set up to protect the interests of international students studying on Australian soil. This provider code allows one to look up the CRICOS database to access further data on Australian education providers such as locations/campuses, the courses on offer at each location/campus, contact details and the student capacity of each provider. Addition of this property, with a mix-and-match approach to importing data into Wikidata, would significantly enhance Wikidata's knowledge of Australian education providers. Dhx1 (talk) 04:26, 22 November 2015 (UTC)
The teams of the member nations of FIFA, football's world governing body, are ranked based on their game results with the most successful teams being ranked highest.
Common international standard identifier for banks and bank branch offices. Usually required when making international wire transfers. Intgr (talk) 14:57, 26 January 2016 (UTC)
This key references a German tax office by a 4-digit number (which is also part of the Steuernummer, assigned to individual taxpayers by that authority).
Bei den Finanzämtern ist das primäre Ordnungskriterium die vierstellige bundeseinheitliche Finanzamtsnummer (BUFA-Nr.). Maggot27 (talk) 20:07, 30 January 2016 (UTC)
For any geographical entity such as a US state, specify the number of representatives that represent this entity within larger entity, such as United States. For the state of New York, this number would be 27 (excluding the 2 for the senate). France could have this value set to 74 (representatives in EU. Each value should have a timestamp at which point this value was valid.
Comment If this is implemented (and I'm not sure if I support it or not) then it needs some way of specifying which body is being represented as some entities can conceivably be represented in multiple bodies (regional/national/supranational parliaments, international bodies, etc. I suppose a mandatory qualifier might be able to do this. Alternatively this could be represented on the page about the representative body. I'm not sure which is better without more thought. Thryduulf (talk: local | en.wp | en.wikt) 19:36, 13 February 2016 (UTC)
Question Is there a formatter URL? And where exactly on the site can you find these IDs? The site's database seems to use a different kind of ID in the URL: http://www.bfi.org.uk/films-tv-people/4ce2b69589d6e. – Máté (talk) 16:20, 10 March 2016 (UTC)
Comment Some related discussion at: Wikidata:Project_chat#Property_for_British_Film_Institute_URL
Support but can we change the en to have the language of Wikidata user (fr for example) ? --Tubezlob (🙋) 08:14, 16 March 2016 (UTC)
⟩ disjoint union of (P2738) ⟨ Researcher ⟩
Oppose "together with" qualifier property. Instead of listing some subclasses with a qualifier you should just add more values to the main property.
Done Of course, there is plenty of examples. OK now ? author TomT0m / talk page 18:12, 1 March 2016 (UTC)
On hold Pending units data type (cannot be a bare number; is "200 wheat" tonnes, bushes or grains?). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:25, 23 March 2015 (UTC)
Neutral leaning
WikiProject Books has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. Snipre (talk) 16:45, 22 January 2016 (UTC)
Strong support I don't understand @Jura1:'s suggestion - this is not an identifier for an educational/research institution, it is a classification of the TYPE of the institution. Sorry I didn't notice this earlier; I think it is very important for coverage of US institutions. Unfortunately I don't believe the classification is used outside the US, but within the US the Carnegie classification is a key way to group institutions of similar type. ArthurPSmith (talk) 19:10, 9 December 2015 (UTC)
Not done duplicate of total revenue (P2139) --Pasleim (talk) 23:02, 23 March 2016 (UTC)