Comment Suggesting "floor count" as the label, and to include all floors including mechanical plant floors, floors below ground. Danrok (talk) 16:06, 24 February 2013 (UTC)
Support, but some languages (/countries), count the ground floor, other that do not. It would be nice if we could find a label that makes it clear, which system we use. --Zolo (talk) 09:57, 11 February 2013 (UTC)
Support, but additionally to the ground floor counting, it needs to be mentioned if floors below ground level are also counted. I would count all floors of a building (ground floor + floors below ground level), since they are all floors and a building which only a ground floor still exists. --Faux (talk) 08:35, 19 February 2013 (UTC)
What about more than one property, for instance "total number of floors" and "number of floors above ground" ? Wikidata infoboxes allow free-text, and we need to have more properties, if we want to be as detailed here. --Zolo (talk) 08:08, 1 March 2013 (UTC)
Sorry. What do you need ? An property with a numeric datatype ? Or a property representing a numeric concept with a string as datatype ? If I take your example with swiss franc you want something like "currency division" to give the nominal value of each coin/note ( 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 20, 50, 100, 200, 1000)? Snipre (talk) 21:03, 22 March 2013 (UTC)
In fact I think a good thing would be a generic property (e.g. "DrTrigonBot Value" or even more generic "Bot Value") for the bot in cases when it has data to write for which no property was created yet - as it is the situation right now for a property "Currency Exchange Rate" (or similar) that is needed for swiss franc. This would allow the bot to already be tested or used without having the need to create always the suitable/correct property before being able to check if the bot works at all (in that specific situation), e.g. That would be a really good and useful/helpful thing! Thanks a lot for considering this and Greetings --DrTrigon (talk) 21:41, 22 March 2013 (UTC)
Just for a test you can see if there is a property in request for deletion using string as datatype or a property which not used in a lot of item or finally try on the demo version of wikidata. Snipre (talk) 22:05, 22 March 2013 (UTC)
Thats clear, currently I am using something else. Also the demo was already used to adopt the bot code. What I need is something permanent. In future and daily (usual) operation there will always be a case where you have to test, since the bot is freely configurable from here - by any user. --DrTrigon (talk) 22:36, 22 March 2013 (UTC)
It is not testing bots, but testing setups - as on wikipedia itself you will always have situations were you have to change something, modify setup of data, configuration and so on... at least that is what holds for me. Then I have to disagree because testing of bots is needed, e.g. in order to fullfill the bot flag request a given number (e.g. 250) of test edits have to be done. And there will in future clearly be other situations - as soon wikidata will be used frequently... Greetings --DrTrigon (talk) 20:55, 23 March 2013 (UTC)
I mean ... it does not need to be something bot specific, what about general maintenance (for human users)? I would even more support such a property, that can be used if it is e.g. not clear yet what property to use, one has to be renamed, other name conflicts or anything else... --DrTrigon (talk) 20:59, 23 March 2013 (UTC)
Why not simply a sandbox property per datatype ? I do not see what harm can be done with that, as long as it is clear that it is a sandbox. --Zolo (talk) 21:29, 23 March 2013 (UTC)
Do you plan using that sandbox property only on sandbox/test items, or also on production items? --Faux (talk) 12:12, 24 March 2013 (UTC)
I do not see anything wrong in using it other items. It will not look very good, and if we can avoid using it too massively, that is better, but raw Wikidata items do not look very good anyhow. The important thing is that it does not unintendedly get transcluded to Wikipedias and other clients. And as long as they do not query sandbox statements, I see no reason for that to happen. --Zolo (talk) 12:22, 24 March 2013 (UTC)
So... are we done here, or for what are we waiting? ;) If you agree I would step forwards and create following 3 properties:
Label: Sandbox-CommonsMediaFile / Description: Sandbox property for value of type "Commons Media File" / Data type: Commons Media File
Label: Sandbox-Item / Description: Sandbox property for value of type "Item" / Data type: Item
Label: Sandbox-String / Description: Sandbox property for value of type "String" / Data type: String
Comment I think we should not count the number of platforms, but the number of tracks that are next to a plaform, as there are platforms with one edge, but also platforms with two edges. Regards --Iste (D)17:01, 1 March 2013 (UTC)
Comment. Isn't his just going to be problematic? Constantly changing on a day by day basis. Seems like a maintenance nightmare waiting to happen. I would not have thought that trying to capture rapidly dynamic information was of value. Maybe it is different when people have retired from a sport. — billinghurstsDrewth09:41, 29 March 2013 (UTC)
At least on enwp, there are people that do this sort of updating fairly often, though I don't follow well enough to know if they bother after every single match, or just every so often. I would wonder if it is just an enwp thing to update, or is the work getting done multiple times per player per match, in which case the proposal makes sense. Courcelles (talk) 20:01, 5 April 2013 (UTC)
Support bearing in mind it has to be cited. If people are already doing it, and can reference it, we might as well allow it on Wikidata. Superm401 - Talk00:57, 6 April 2013 (UTC)
Support keeping this up-to-date for active players will be no bigger issue than any other statistic. When we get date functionality, we will have an 'as of' qualifier that can be used to indicate how recently a statistical claim was updated. Joshbaumgartner (talk) 09:54, 9 May 2013 (UTC)
A further specification of the tournament's category (e.g. ATP, WTA, ITF), which is used in the infoboxes for many players, can be done using a qualifier.--Kompakt (talk) 03:00, 15 June 2013 (UTC)
A further specification of the tournament's category (e.g. ATP, WTA, ITF), which is used in the infoboxes for many players, can be done using a qualifier.--Kompakt (talk) 03:00, 15 June 2013 (UTC)
property that describes the location of an item in a specific village or neighborhood. This property is needed to locate e.g. a railway station in a village/neighborhood; the location of a heritage monument; the location of a statue; the location of a building or construction, etc. At the moment there is no property to link such items with their location: when we use the administrative location (municipality) property located in the administrative territorial entity (P131) we are always limited to administrative area's which is not sufficient. A separate property is needed and will be used next to P131: some municpalities are also a 'village'.
Support i think located in the administrative territorial entity (P131) makes sense as it is, concentrating especially on the next higher administrative level, so pure "administrative trees" can be created. but a new property for locations which are below the lowest level of administrative units is also very useful. For example for urban quarters, smaller villages and settlements and in Germany also for Gemarkung (Q1499928) (type of cadastral division) which does not count as a real administrative unit by most definitions. Holger1959 (talk) 22:26, 3 January 2014 (UTC)
Support However, it will (especially in Germany) be difficult to define what is an administrative entity yet or still only a locality. Many cities and municipalities are dived into Stadt- or Ortsteile which do not have an administrative status but do have exact borders defined by a local law or by-law and thus stretch even into areas outside the populated area. So, even a wayside cross in the midst of the forest can be assigned to a specific (non-)administrative entity.--Leit (talk) 23:57, 30 January 2014 (UTC)
Support - This is good. I'm wondering about the documentation, though, and whether or not it shouldn't say that it is meant to be used as a qualifier right up front in the description. Also, shouldn't the "domain" be something like "statement"? (But I guess that's a discussion for another day.) Klortho (talk) 17:01, 30 January 2014 (UTC)
I have a lot of questions and worries. To start: this is going to be a property, not a qualifier? This would work if there were a rule of only one name per item, which would be fine by me for better than 99% of the items.
A lot of the terms above have no nomenclatural meaning, but are taxonomic (or obsolete). Some are ambiguous (in what sense is "nomen alternativum (nom. altern.)" used here), or relative. I would indeed like "replacement name" added, and also "later homonym".
I certainly would not use the vocabulary at the Darwin Core [brr!], but rather a more reliable source - Brya (talk) 17:41, 30 January 2014 (UTC)
Perhaps it should say so ("to be used as a qualifier"). I am not so sure about "replacement name": I would be inclined to have a link in both items "Arbor novum is a replacement name for Arbor erronis" as well as "Arbor erronis is the replaced synonym for Arbor novum". This would be good for new combinations, as well.
Some provisional notes:
nomen abortivum (nom. abort.): does not mean anything to me; not a name
nomen oblitum (Q901847): only in zoology and should be only used as part of a pair with nomen protectum -> thus a separate property
--** opera utique oppressa (opus utique oppr.) : needs to be rephrased, and even then not really useful = nom. inval. (not a name)
orthographical variant (orth. var.): surely we are not going to have separate items for orthographical variants
nomen protectum: only in zoology, and should be only used as part of a pair with nomen oblitum -> thus a separate property
nomen provisorium (nom. provis.): useless distinction?
nomen rejiciendum (nom. rej.): this is ambiguous. If not a "nom. utique rej. prop.", it is relative and should be only used as part of a pair -> thus a separate property
nomen rejiciendum propositum (nom. rej. prop.): see above
nomen utique rejiciendum propositum (nom. utique rej. prop.): yes
nomen subnudum (nom. subnud.): quite dubious (informal term), but might (occasionally) be useful?
nomen superfluum (nom. superfl.): useless distinction? = nom. illeg.
I make that five useful terms: 1) nom. cons., 2) nom. cons. prop., 3) nom. illeg., 4) nom. utique rej., 5) nom. utique rej. prop. As well as a number of new properties to be made that could be useful. - Brya (talk) 18:12, 31 January 2014 (UTC)
Pairs that would really benefit by new properties:
If I understand your comments right you principally agree with my proposal. Mind to vote? Your suggestions are welcome, but you should file a formal property proposal. l--Succu (talk) 23:23, 2 February 2014 (UTC)
I think the basic idea is a good one. At this stage I still do not really know what exactly I would be voting on. - Brya (talk) 06:29, 3 February 2014 (UTC)
+1 If we have an item for each isotope the number can be defined through the query of all isotopes of an element. Snipre (talk) 20:39, 2 February 2014 (UTC)
Comment I am not native English: I thought you can only solve a calculation and that proving that something can be calculated is called "proving"? Is this not similar to the property for scientific discoverer? Possibly use qualifiers for that property? --Tobias1984 (talk) 14:53, 9 December 2013 (UTC)
No, you solve a problem, for example whether or not there is an answer to a question, and you prove a theorem. The question can be wheter or not there is an infinite number of prime numbers, which is a problem, the answer is yes, and the proof makes "there is an infinite numbers of prime numbers" a theorem. The question has been answered by Euclid, by proving the theorem. TomT0m (talk) 17:59, 9 December 2013 (UTC)
Support No good reason not to crate and useful, left to long on property proposals. (in those kind of cases we should create for the proposer imo). TomT0m (talk) 22:27, 28 January 2014 (UTC)
This will enable us to generate lists of stratigraphic units, in which certain fossils are found. The reason to go "stratigraphic unit --> fossil" is that I suspect that stratigraphic units have less statements and that index fossils would get very many statements in which formation they are found. But that is open for discussion. The property might also double as a qualifier for statements about geologic time units. --Tobias1984 (talk) 19:38, 2 December 2013 (UTC)
I indeed wondered why you choose this direction. The property "t-rex" -> in stratigraphic unit -> "Holocene" seems more fitting to me, as you can easily select all units in which T-Rex bones where found so far but you cannot find all taxa which lived in the Jurrasic. — Felix Reimann (talk)
@FelixReimann: I think for queries both would work equally fine. Having both properties would have the advantage of very good constraint violation control. The temporal range of fossils can also be checked against the temporal range of the units they were found in, giving us additional validation. By the way: Have you thought about adding support for temporal range start (P523) and temporal range end (P524) for the WikiData Taxobox? --Tobias1984 (talk) 09:28, 6 December 2013 (UTC)
@Tobias1984: not yet. But this is in principle no problem. However, I'm not sure if we should distinct fossils (which then get a palaeobox) from extant taxa (and extant extincted taxa) with instance of (P31)="fossil taxon". But I'm not sure if the definition "fossil=extincted before Holocene" is non-controversial.
Regarding the proposed property: I'm not sure if you really gain something if you have both, a property A->B and a property B->A. For checking constraint violations, you can use queries (and while they are not implemented, WikiDataQuery). Having both, you just add the need to hold the data coherent, i.e. you add constraint violations without additional information. — Felix Reimann (talk) 09:50, 6 December 2013 (UTC)
@FelixReimann: Wow, that was fast with the temporal range. Thank you very much. About the proposal: Ok lets do only one. I will try to get a few people from WikiProject Paleontology to give their opinion. There is also the question what kind of qualifiers should go with the property. For large fossils it might be interesting to know if the skeleton is complete or just some bones. From a stratigraphic point of view a qualifier for the position in the stratigraphic column would be useful. Often times fossils only occur in one horizon which might have a separate Wikipedia entry. --Tobias1984 (talk) 17:54, 7 December 2013 (UTC)
I have no strong feelings here. My expectation would be that this would work great for some select cases (in either direction), but that in many other cases there would be so many data that it would be close to useless. However, this is not based on a close familiarity with the field. - Brya (talk) 17:33, 16 December 2013 (UTC)
Tobias, RDF, RDFS and OWL do not support qualifiers. There are some ideas on how to represent Wikidata qualifiers in those languages, but it will likely be kind of a hack. Concretely, I think this means qualifier-centric data will be a pain to deal with in SPARQL, the W3C recommendation for querying Semantic Web data, and a likely future direction for Wikidata queries. So I think it makes sense to use qualifiers sparingly. The examples above use qualifiers rather heavily.
Furthermore, when I look at the examples, I see them describing an instance of a class -- an individual organism of a taxon. A fossil is obviously a long-since-deceased and materially diminished form of the specimen, but ultimately it represents an individual organism. I would recommend creating a new item for such things, and linking them to the taxon via instance of (P31).
This would make it straightforward to link multiple specimens to a given taxon or stratigraphic unit. The qualifier-centric approach in the examples above makes that impossible, or at least quite cumbersome. Emw (talk) 21:29, 22 December 2013 (UTC)
That sounds reasonable. For notable specimen we create items and greatly reduce the number of qualifiers. For non-notable specimens we just link to the taxon and try to use as little qualifiers as possible. --Tobias1984 (talk) 21:42, 22 December 2013 (UTC)
@TomT0m: Thanks for the link. To be honest I have to read these text around 10 times until I have a grasp of what they are saying. - What do you think about this property? Are we compliant enough with semantic web and which direction should the property point to? --Tobias1984 (talk) 23:35, 22 December 2013 (UTC)
Conditional support I'd support this, but I think the name should be changed to "fossil found in this unit" (singular instead of plural) since the object should be one fossil, and the word "lists" taken out of the description. Editors here know, in general, that a property like this can be used multiple times, right? I also agree with most of what Emw wrote above, not because I think we should eschew qualifiers in general, but because I think in the example given, some of the things that were qualifiers would be better coded as properties on the specimen. So, I'd change it to:
IMO, all of the other relations ("parts", "in museum", "catalogue number", etc.) would be better if they were statements on the specimen itself, or qualifiers on those statements. Klortho (talk) 02:05, 2 February 2014 (UTC)
@Klortho: Sounds like a good idea. Notable fossils get an item with more properties. Non-notable fossils just get a statement. Can you still give your opinion if the data should be stored with the formation or the fossil:
Comment With option 2, couldn't a formation contain dozens of fossil types (thus cluttering the item) and with option 1, couldn't a fossil possibly be found in a large number of rock formations (also cluttering the item)? --Jakob (talk) 13:22, 3 February 2014 (UTC)
@Jakec: The amount of clutter is going to be pretty equal with both choices. Fossils can be found in hundreds of formations, and some formations can contain hundreds of fossils. On Wikipedia choice number 2 is the standard. For example en:Horseshoe Canyon Formation has a table that shows which fossils are found in the unit. The fossils tend to have more detailed descriptions about their bones, evolution and other biological things. Maybe we should try to stay the most compatible with Wikipedia. --Tobias1984 (talk) 18:26, 3 February 2014 (UTC)
Done Not enough votes to decide which direction property should take. I am going to create it in the way that I think is more compatible to Wikipedia. --Tobias1984 (talk) 15:08, 4 February 2014 (UTC)
Date added to the NRHP
Not done
Description
Date that an object was added to the National Register of Historic Places
Oppose This is solved by using instance of (P31): L-(+)-tartaric acid, D-(−)-tartaric acid are instance of tartaric acid which is considered as the racemic acid. This implies the creation of 3 items, one for the racemic and one for each isomer. If you take the CAS number or the PubChem ID for exemple each isomer has their own identifiers and often the racemic a set of specific identifiers too. Snipre (talk) 12:22, 29 January 2014 (UTC)
A catalog record numbering system, uniquely identifying records, used by PICA (Project voor geIntegreerde Catalogus Automatisering) integrated library systems.
This is the standard number used in most Dutch libraries, and some German libraries as well. Documentation is a bit sparse (especially in English) but a description from OCLC in Dutch is available here. These PPN's are already linked in VIAF, so it might make sense to do an import from there.
Okay. Thanks for noticing that. I must say that my knowledge of all these identifiers is a little too limited, so i asked a colleague to weigh in on this subject. Husky (talk) 09:59, 31 January 2014 (UTC)
Of cause P1006 is not "the PPN" in general, since it makes no sense to add numbers that are ambiguous. The PICA system is used by various libraries. As you already noticed it may be a number of a book or an authority record. You can add two or three of these numbers and never know to which library they belong. --Kolja21 (talk) 13:45, 4 February 2014 (UTC)
AFAIK PPN's are not unique to a single library. For example, here's a book with the same PPN in the catalogues of the KB and the NA. If we want to link Wikidata to the National Library of the Netherlands i can't figure out another way than PPN's. Husky (talk) 14:03, 4 February 2014 (UTC)
We already have student (P802) but "teacher" is usually more important (a professor usually has more influence on her students than the other way around) and usable in more items (more people have had professors than students) --Zolo (talk) 18:26, 17 December 2013 (UTC)
Support, seems useful. "Student of" might be a better label -- it's the convention for inverse properties, and avoids confusion between the several different types of "teacher" one might have (professor, teacher, etc.). Emw (talk) 21:39, 22 December 2013 (UTC)
Support as nominator. There is currently no clear way to link something fictional to the series that it's in. We could use "part of =>" or "fictional character => of =>". But I think this usage is specialized enough that it would be very useful to have its own property with its own constraints. This would also keep the "part of" property free to say what the subject is part of in-universe. Arctic.gnome (talk) 20:59, 20 December 2013 (UTC)
Interesting question. I'm inclined to say no. The question of which work a fictional entity is from is a defining feature of that entity. Real-world entities, on the other hand, are notable for something else and it's only incidental to their notability that they have a book about them. Also, we would have to somehow find a way to cap the number of narratives that a real-world entity has listed; how many narratives feature Napoleon or New York City? Probably way too many to list. --Arctic.gnome (talk) 01:11, 30 December 2013 (UTC)
@Yair rand: True, but I would say that the defining feature of "elf" is being a mythological creature, whereas the the defining feature of "jedi" is being from Star Wars. Maybe a more accurate title for what I have in mind is "invented in the fictional work" --Arctic.gnome (talk) 17:41, 19 January 2014 (UTC)
That substantially narrows down possible uses for the property. If the object is always going to be the "source" narrative, so to speak, then I think both the label and the description should be modified. "Invented" might not be the correct term, though. I don't think people tend to refer to characters as being "invented", in general. --Yair rand (talk) 18:04, 19 January 2014 (UTC)
How about "from narrative" or, more specifically, "originally from narrative"? Narrowing scope is fine. I mostly just wanted a way to link pages like Narnia or Thought Police back to their source material. For items that have hundreds of books about them, like Napoleon or dragons, it might be a better idea to link from the work's page using a property like "is a work about". It might seem counter-intuitive for me to propose one property from the subject and one property from the work, but I'm trying to minimize the number of times we have to have giant lists of 100 links for one property. --Arctic.gnome (talk) 06:39, 20 January 2014 (UTC)
Oppose In preference to storing this type of data with the work. As we are already doing to some extent with similar properties, e.g. "narrative set in". We would then be able to get a list of all works which refer to a character via a query. Danrok (talk) 15:50, 5 January 2014 (UTC)
What property would be used for that? Should we create a property called "contains fictional entities" that lists every character and fictional object in the story? For long stories with a large editing base, like Harry Potter, there would be a huge number of items linked. --Arctic.gnome (talk) 21:38, 6 January 2014 (UTC)
Support Do we have a VIAF equivalent, or some other identifiers affiliated with national libraries? I will ask to the National Library of Florence. Aubrey (talk) 06:43, 20 January 2014 (UTC)
Comment Difficult, not only because edition is ambiguous: There exist proper authority records for individual expressions (in FRBR lingo) like a italian translation LCCN no2003071617. Unfortunately these are just in the process of being installed, the authority record does not yet tell us about the translator or more general about which of (presumably) several italian translations it is about. Likewise at the moment there do not exist LC authority records for english expressions of works, be it the original language or the language of a translation. The realm of the property here for "ordinary" LC records would be manifestations, e.g. a printed version from that and that year with such and such imprint and so many pages, but not the e-book with the same text content. The item given in the example arises from the digitization and transcription of a certain copy ("University of California Southern Branch" - they probably hold several items but logically none of them is shown by the catalogue of the Library of Congress: different libraries, different copies) of the said 1911 edition which seems to be notable because of the illustrations. The introducing text in wikisource gives a short description of the publication history, unfortunately I'm not able to decide whether this 1911 "edition" should be considered a mere manifestation (identifyable by its LC number "for books") or should be considered an expression (identifyable by a LC authority record with number Library of Congress authority ID (P244) which unfortunately does not exist at the moment). Thus exactly like OCLC control number (P243) and Open Library ID (P648) the property proposed here can only serve to give proof that an "edition" with the properties (Publisher, Year of Publication, ...) asserted in the wikidata item indeed does exist. -- Gymel (talk) 07:32, 20 January 2014 (UTC)
Support Helpful for organizations. For persons it's not useful, unless we want to add qualifiers like "90% left" (own view, 2001-2004), "15% left" (external view) etc. For persons please use properties like member of political party (P102). --Kolja21 (talk) 07:22, 4 February 2014 (UTC)
Comment Could also be used as a standalone property in place of the proposed "number of instances" but I am not sure. --Zolo (talk) 07:09, 14 October 2013 (UTC)
Zolo, a couple of comments. I see what you are referring to about the units datatype, but I don't think changing the datatype of this to "number" is a viable solution. We could ask on the discussion page over there if there's any possibility of defining properties that take any generic scalar quantity as an object, with dimensions determined at statement-creation time. Otherwise, you would need a qualifier on this qualifier, to determine the units, and I don't think that's supported or reasonable. Also, I didn't see any link (which you said you added) from Wikidata:Property proposal/Economics to this discussion, so I added one here. Klortho (talk) 20:19, 12 January 2014 (UTC)
@Zolo: - Great thanks. I'll archive this in the next run. And now I think I understand p1113 and p1114. Do you have time to vote on the proposal for mathematical constants (bottom of this page). --Tobias1984 (talk) 15:45, 10 February 2014 (UTC)
Topics and their associated Wikimedia portals are currently not explicitly linked on WD. It seems to me they should be, because it's useful information to have that is only implicit on Wikipedia and other projects. A reverse property "Wikimedia portal main topic" should probably be created too. -- Bjung (talk) 05:21, 11 January 2014 (UTC)
The names should be changed to "topic's main portal" and "portal's main topic" for consistency with "topic's main category" and "category's main topic."--Erasmo Barresi (talk) 13:30, 15 January 2014 (UTC)
Comment would this be claimed in the "instance items", e.g. an instance of a comic, or only in the "type item", e.g. comic? --Danrok (talk) 16:47, 3 October 2013 (UTC)
It would be set on the type item. We would be mapping their media topic vocabulary to Wikidata items, not usign their vocab to classify Wikidata items. -- Duesentrieb (talk) 21:23, 13 November 2013 (UTC)
w:Scopus, including Free Lookup Form. The ORCID database also includes scopus author ids.[4] Each university in Australia has its own database of Scopus Author ids for their academic staff, as the Australian government research data collections have required it since 2008, and research data repositories also record it[5].
ORCID is slowly being adopted, but Scopus Author IDs are what research organisations actually typically use, for good or ill. Scopus extracts the author information on publications[6], but also has author merge processes which include human reviews by their staff. This ID is needed to query the Scopus APIs. John Vandenberg (talk) 03:30, 1 December 2013 (UTC)
Thanks for the link to the "Free Lookup Form" but if I want more information I have to pay: "Login Required to Access Scopus". The database of Amazon.com is completely free but I would also oppose a property for e-commerce. There are no general restrictions against private companies but against paid content. --Kolja21 (talk) 02:48, 2 December 2013 (UTC)
IMDB is not completely free. Amazon only provides the first layer of IMDB information free, and you need to pay to access IMDbPro. Find a Grave memorial ID (P535) and Emporis building ID (P455) are the same. We also have Google Books ID (P675) (which links to lots of ecommerce functionality). You say that you can access the webpage links that I provide, but call it paid content. It is freely accessible public profiles of every active researcher of the world, in nearly every discipline of research, and those freely accessible webpages contain information that you will not find in any other system, like h-index, publication counts, primary disciplines. Most of the DOIs on Wikipedia and Wikidata are going to be e-commerce. Scopus is not e-commerce. You can't buy anything on any Scopus website. Either you have access to their advanced functionality, or .. you don't and can't get it. Scopus only enter into institution licenses, like OCLC, to provide additional services for institutions and academics. John Vandenberg (talk) 04:51, 2 December 2013 (UTC)
Support I see no compelling reason to prohibit authority control identifiers simply because they come from entities that are operated by private companies and require a subscription. Emw (talk) 04:03, 3 January 2014 (UTC)
The main problem I see here is that a given researcher may have more than one Scopus ID (e.g. due to a change in affiliation or research subject, or after marriage). I don't have access now but I once found 3 or 4 IDs for me. --Daniel Mietchen (talk) 04:23, 3 January 2014 (UTC)
Daniel Mietchen, those are only artifacts of the person publishing under different names, which all databases suffer from in this domain. Scopus has a process to have identities merged, which may be initiated by the author, the institution, or by Scopus themselves. Scopus does not want multiple identities for the same person, it is not in their commercial interest; they win bids for large bibliometrics contracts based on having high quality identity data, and in Australia at least the data is almost perfect since 2003 as each institution works closely with Scopus to fix any author identity problems during the government audit of research activity. See the many libguides about that. John Vandenberg (talk) 04:46, 3 January 2014 (UTC)
SupportGerardM (talk) 08:08, 1 February 2014 (UTC) We add value by linking to external sources.. Scopus is hardly the only resource and as its open competition does a better informative job, they will increasingly do better.
Academics will often search Scopus for a paper to cite; lets make it easy for them to create a source item and add source clauses. Also Scopus EID are used in the data warehouse of most universities, in order to extract citation counts out of Scopus via the Scopus API. We have a proposal to add 'impact factor' (Wikidata:Property_proposal/Creative_work#impact_factor), and I expect a proposal for 'citation count' to be coming soon ;-) Adding a link to scopus allows academics in wikidata to quickly jump to Scopus to see the citation count, and view related academic papers. This ID is needed to query the Scopus APIs. John Vandenberg (talk) 03:30, 1 December 2013 (UTC)
Following the issue raised by Kolja21 above regarding datasources that require a subscription, it may be that links to publications in Scopus do not always work without a subscription. I am not sure, as I havent seen any official statement from Scopus that publication pages are always accessible via Scopus Preview (as opposed to author profiles, which are public). However I have tried it using a random scopus ID I saw last night ( here) without a subscription and it worked for me (in Indonesia), and the cited-by functionality also works. Kolja21, do these links not work for you? The 'Scopus Preview' pages have limited functionality, but it is the metadata that people need to view. fwiw, in Australia all universities have full access to Scopus - a country wide agreement exists. I have found this info from a third party website which says "Non-subscribers of Scopus can view all articles on the Scopus Preview page with limited functionality." John Vandenberg (talk) 02:28, 2 December 2013 (UTC)
Hi John, the links work fine but as said above a free preview is not enough. We have the same problem with the NYT and other reputable publishers: If they only provide a preview for their articles the external links in Wikipedia will be deleted. Sorry --Kolja21 (talk) 03:12, 2 December 2013 (UTC)
Support I see no compelling reason to prohibit authority control identifiers simply because they come from entities that are operated by private companies and require a subscription. Emw (talk) 04:04, 3 January 2014 (UTC)
Scopus has a very good database of affiliation for research articles, and for the academics, and most importantly includes hierarchical information about the structure within organisations and relationship between organisations. Public library data and DOI data is typically sourced only from the publication metadata, which includes lots of errors in affiliation (misspellings, use of non-legal entity names). This ID is useful for querying the Scopus APIs. John Vandenberg (talk) 03:30, 1 December 2013 (UTC)
Scopus has a very good database of journals, and includes publisher, issns, SNIP and SJR indexes, and subject area (fields of research, discipline) classifications. This ID is not very useful for querying the Scopus APIs regarding publications, and mandatory to use for using the Scopus API to access information about journals. John Vandenberg (talk) 03:30, 1 December 2013 (UTC)
The data can be imported from their regularly updated spreadsheet (9MB). It also has a flag to say whether the record has been added since the last published version of the spreadsheet. The spreadsheet contains the following properties for each journal: Source ID, ISSN, E-ISSN, Title, Source Type (Journal vs Conference), Active vs Inactive, Registered in DOAJ.ORG flag, Journal merges and renames, publishers name, publisher country, and ASJC codes (All Science Journal Classification). It is this source list of 32,000 journals and the classification scheme that the majority of the sector uses, and builds bibliometrics on top of (see http://www.journalmetrics.com/documents/SNIP_SJR_complete_1999_2012_v1.xlsx 12Mb) I have this data in a database and am working on a bot to import it into my local copy of Wikidata. John Vandenberg (talk) 01:06, 1 January 2014 (UTC)
nonnegative integers (including 0 if the TV series was planned but never produced); or positive integers (excluding 0 if we can leave out this parameter entirely)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Even though we don't know exactly how the number with unit type is going to work, it's pretty clear that this isn't necessary. --Izno (talk) 02:02, 13 February 2014 (UTC)
Not done
Description
height of a geographic location above or below the Earth's sea level in metres
We should be able to indicate the order of any finite group. Helder 16:16, 28 November 2013 (UTC)
Comment - I would try to find a more specific name for the property. With the current name the property might be used for other things than numbers. The question is also if a more generic number property is specific enough. --Tobias1984 (talk) 16:48, 28 November 2013 (UTC)
Alternative (but less common) names would be "Group size" or "Cardinality of the group". Helder 17:53, 28 November 2013 (UTC)
Comment I hate them, and they are going out of fashion thankfully (see w:San Francisco Declaration on Research Assessment), but people continue to use them so it is useful. However, I am concerned about sourcing the data from Thompson data (or other bibliometrics based on Scopus), as it could be covered by a w:database copyright, as those corporations derive a lot of profit from the publication of those numbers. Wikipedia is wildly incomplete, so not a major concern, but Wikidata can easily be complete, which may cause them to seek remedies. http://uifactor.org/ is also not free data. I would prefer that we use w:Eigenfactor, as they are quite clear they hold no IP rights over the data (http://www.eigenfactor.org/faq.php # 6), but it still uses Thompson data, but it it is less risky. John Vandenberg (talk) 10:36, 30 November 2013 (UTC)
Gewässerkennzahl (de) – (Please translate this into English.)
GKZ are given on most rivers and streams in european countrys. Including them makes it easier to cross-reference entries with other sources. Ogmios (talk) 09:44, 18 December 2013 (UTC)
Handles are used for digital objects, especially by photographs by GLAMs and research papers held in academic digital repositories. The example provided is a Wikisource transcribed digital object provided by a GLAM. I can also provide an example of a notable research paper with a handle if required, but that will take a bit more searching. John Vandenberg (talk) 18:02, 28 January 2014 (UTC)
It worked a few days ago. "Many ejournals and databases will be unavailable 9pm 2 February until 7am 3 February 2014 due to hardware upgrades." --Kolja21 (talk) 02:01, 2 February 2014 (UTC)
Comment, Hi Emw, I added some claims to these items, but I'm wondering if they are not duplicates, for example dominance (Q6531938) is labelled in french as a transmission mode, not a dominance relationhip. Duplicate or conflict ? TomT0m (talk) 20:11, 28 February 2014 (UTC)
I think datatype should be string instead of Number as it displays listing/authority control rather than Quantity. What you say? -Nizil Shah (talk) 20:29, 2 March 2014 (UTC)