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)
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. 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)
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)
12:30, 16 June 2013 (UTC)
07:54, 18 June 2013 (UTC)
16:00, 2 February 2014 (UTC)
number of tournament victories in doubles / Anzahl Turniersiege im Doppel
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'.
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)
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)
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, 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:
@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 18:26, 3 February 2014 (UTC)
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
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.
23:31, 30 January 2014 (UTC)
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 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)
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)
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)
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)
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)
Jonathan A. Eisen (Q2000017) => 7005368498, Marc Greenberg (Q15217445) => [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 publications03: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)
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 04:46, 3 January 2014 (UTC)
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 ( 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)
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)
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
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)
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)