Support The presence of the authority control values as wikidata property would allow data distribution to various projects via Lua as used in Q11640331 Module:Authority control and also at projects using previous versions of Q3907614 Template:Authority control. לערי ריינהארט (talk) 08:24, 7 October 2013 (UTC)
note: viaf:66477450 shows RSL|nafpn-000080362 so one is using a prefix as well : "nafpn"
scanning the viaf.org source code page for lines using "new Node" helps identifying
new Node("RSL|nafpn-000080362", "RSL", "Russian State Library-test");
International Securities Identification Number uniquely identifies a security, e.g. a public company (all of them). Globally, this is a very widely used code in the financial industry. Used as a key within URLs on many financial web sites, databases, as well as official use. See International Securities Identification Number.
The presence of the authority control values as wikidata property would allow data distribution to various projects via Lua as used in Q11640331 Module:Authority control and also at projects using previous versions of Q3907614 Template:Authority control.
Link generation is trivial for this identifier.
It is already used at various versions of Q3907614 Template:Authority control. לערי ריינהארט (talk) 08:51, 7 October 2013 (UTC)
the country or other power the person served. Multiple countries may be indicated together with the corresponding dates. This field should not be used to indicate a particular service branch, which is better indicated by the branch field.
Comment should this be lead programmer (as per infobox desc., usually only one person), or all programmers (potentially 100s of people)? Lead programmer only seems best to me. Danrok (talk) 10:26, 12 September 2013 (UTC)
I think mixing programmer and author could be a little messy. For example, a video game based on a book has an author (of the book), and programmers. Danrok (talk) 20:07, 29 September 2013 (UTC)
Comment programmers are not always the creators, in the same way that a script writer is not always the creator of a TV show.
In this example I wouldn't say that Michael Abrash was a creator, "The Quake engine was developed from 1995 for the video-game Quake, released in June 1996. John Carmack did most of the programming of the engine, with help from Michael Abrash in algorithms and assembly optimization. It was later upgraded to id Tech 2 (Quake II engine)."
--Danrok (talk) 17:01, 3 October 2013 (UTC)
Neutral, not sure if it's better to name it 'SUPPORTED data base management system' instead of 'used'. Many software allows the user to choice the underlying DB. But while I'm typing this sentence, I notice that we can use qualifiers for this (sub-qualifier-property 'selectable' or something like that). Therefore I also Support this proposal now, but I don't agree with the proposed name. I suggest to write 'database' in one word. I'm also not sure if we better should use it without 'management system' only 'used database'? --Nightwish62 (talk) 14:57, 30 March 2013 (UTC)
Oppose This proposal seems a bit muddled, but it may be onto something useful. Two initial problems stand out: 1) "files" and "no database" are not database management systems, and 2) regarding the "database" ~ "DBMS" claim above, I think it would be best to not conflate those terms. They're sometimes used interchangeably in conversation, but they clearly mean significantly different things. A more generic name seems like it could solve the problem, but I'd object to calling 'files' and 'no database' DBMS's, as I would calling Oracle and SQLite databases.
Further, if we're going to use qualifiers as suggested above (which I think would be a good idea), then I see no need to have 'used' in the property label. ('Used' would presumably be a qualifier.) I would suggest this proposal perhaps be split into several properties: 1) data store, to distinguish between 'file system', 'spreadsheet', 'DBMS', 'distributed DBMS', etc., and 2) a property for each of those data store types listed in (1), e.g. to specify whether the software uses or supports MySQL and PostgreSQL, etc. Emw (talk) 03:53, 10 April 2013 (UTC)
Per my prior post at Wikidata:Project_chat#Question_about_building_lyrics_external_links_database, I need a way to catalog external websites that legally (with a license) host lyrics for specific songs, albums, and artists. I would use this information to generate links to lyrics pages in "External links" sections of articles on songs, albums, and artists. This would permit me to offer a choice among several providers and avoid endorsing any single provider, as I currently do with MetroLyrics (see en:Special:WhatLinksHere/Template:MetroLyrics song).
Update: The title has been generalized to "full text available at" so that it may link to legal online providers of the full text of any non-free creative work, including e.g. books, scripts for plays and speeches, etc.
N/A - this property will be used to generate external links (although it could conceivably also be displayed in the infobox)
Domain
creative work (intended for songs, albums, and artists)
Allowed values
Valid, working external links
Example
Never Gonna Give You Up (Q57) <full text available at> [http://www.rickastley.co.uk/discography/singles/never-gonna-give-you-up/ Rick Astley official website] Never Gonna Give You Up (Q57) <full text available at> [http://www.metrolyrics.com/never-gonna-give-you-up-lyrics-rick-astley.html MetroLyrics]
Never Gonna Give You Up (Q57) <full text available at> [http://www.allmusic.com/song/never-gonna-give-you-up-mt0003819583/lyrics AllMusic]
Format and edit filter validation
(a filter recognizing external links would be helpful, if one exists - it is useful to be able to specify the display text as well as the URL)
Just as en:User:LyricsBot has been inserting en:Template:MetroLyrics song into articles, the same bot would be populating this property on relevant items. I would need to implement new functionality for each site that would be listed. It would also periodically check the property for dead links and incorrect manual links to unlicensed content.
Open questions: 1. Is a more specific name called for like "has lyrics at URL", "has lyrics at external URL", "has lyrics at external website", or "has licensed lyrics at"?(name is now decided) 2. What is the best format for the value? Initially I suggested bare URLs, but these were inflexible as they didn't allow display text to be specified. Wiki external links contain the necessary information but require parsing to separate the URL and display text (it'd be nicer if I could do a tuple (URL, display text) if that's supported). Any URL-based scheme is also going to be necessarily fragile if the source websites change their URL scheme, although automatic conversion should be straightforward. Dcoetzee (talk) 07:06, 3 September 2013 (UTC)
Lyrics for most modern music are, in general, not available under free licenses however they are starting to become available under restricted licenses at certain websites (usually printing out for personal use only, no reposting, web page must include a link to buy the record or similar). We can't include these lyrics in our projects but this property lets us link to the sites that do have the lyrics. Filceolaire (talk) 15:52, 3 September 2013 (UTC)
Most lyrics to modern popular music (which includes most songs notable enough to have a Wikipedia article) are not available under a free license, because their copyright holders (typically major record companies) seek to monetize them. Where lyrics are either in the public domain or available under a free license, we can add them to Wikisource or to the article directly, obviating the need for an external link. Dcoetzee (talk) 22:12, 3 September 2013 (UTC)
I think the value of this field should be restricted to the few Resources who are ether under free licenses (eg. wikisource.org) or at least Legally available (eg. metrolyrics.com. When the work itself is under a free licence everything could be linked (something with an api would be preferred) are such restrictions possible? --Shisma (talk) 09:33, 4 September 2013 (UTC)
In short, no. It is not possible to limit this field to a small, fixed number of domains, because, as illustrated by the first example above, official artist sites (of which there are many thousands) often feature legally licensed lyrics, and there are also at least a dozen and growing sites now licensing works from the LyricFind licensor (such sites are easy to start - their Lyrics for Free program lets any website use their works in exchange for placing ads). Moreover even on "good" sites like MetroLyrics some pages are user-contributed and so can't be linked. So it's necessary to review them on a case-by-case basis. Sites that are 100% bad can be blacklisted, and LyricsBot can patrol the property for known infringements and flag suspicious values for review, but a complete and accurate filter is not feasible. Dcoetzee (talk) 10:26, 4 September 2013 (UTC)
Comment, does it need to be restricted to songs ? I would think we should have a general "text available at" property. If we need a special property for music, that would rather be for the score. --Zolo (talk) 10:37, 4 September 2013 (UTC)
I am fine with this suggestion. After some thought I could imagine, in principle, other creative works like books, plays, papers/essays, and speeches making their written text available under a restricted license on an external website in a similar manner. For the purposes of LyricsBot I can look at items to see if they're derived from musical work (Q2188189) and otherwise ignore them. This name does feel quite ambiguous though - I would prefer "full text available at". Dcoetzee (talk) 17:07, 4 September 2013 (UTC)
This makes sense to me at least in some cases - it could be used to indicate that the external website is under either a Wikipedia-incompatible free license (e.g. CC-BY-NC) or in the case of proprietary licenses, it could provide a link to the complete license terms. Dcoetzee (talk) 22:27, 5 September 2013 (UTC)
I need the ability to specify the display text for the link as well (see the examples above, particularly "Rick Astley official website"), so a bare URL would not be sufficient, but some other specification might be possible. Dcoetzee (talk) 23:04, 12 September 2013 (UTC)
I just explained this immediately above your comment. Can you please explain how I should encode both the display text and the URL of the link, if the field does not accept both? Both of these are needed since it might be linking minor websites of individual artists. Do I need two fields here or some kind of qualifier for the display text or what? Dcoetzee (
I think it the property itself should only contain the URL. I do not know exactly what to do for the associated text. Not sure that a "display text" property is the best solution as it is language dependent and somewhat subjective. We could potentially have automated analysis of the URL or things like "instance of official website" as qualifiers, but that may be a bit tricky to make it work. --Zolo (talk) 06:35, 14 September 2013 (UTC)
Use the property label ("full text available at" in English) as the link text as this can be translated into other languages. This works for the 'official website' property too. Filceolaire (talk) 17:23, 14 September 2013 (UTC)
Property to flag items for places, buildings, museums, administrative units, works of arts, etc, that can have geographical coordinates or already have geographical coordinates. Allows to do an initial selection, cross-checks and sort for all such items.
Data type
item (as boolean isn't available)-invalid datatype (not in Module:i18n/datatype)
Domain
places
Allowed values
"yes" (new item to be create specifically for this property); possibly: "no", "TBD"
Example 1
MISSING
Example 2
MISSING
Example 3
MISSING
Robot and gadget jobs
add from items with coordinate location (P625) (if globe=earth), items with P107 = geographical feature (Q618123)
I guess the question is if we can efficiently distinguish between "somevalue" and real values. We already have 500'000 items with coordinates and at least 1,000,000 items that still lack them. Coordinates are already only partially supported in the GUI, so I doubt we should complicate things further. -- Docu at 12:03, 24 August 2013 (UTC)
Interesting suggestion. I think it might work for some of them. We would miss out on museums and possibly other structures that might not be classified as geographical feature. Erroneous inclusions might be class items themselves. Geographical features elsewhere than on earth would be included as well. A simpler solution to the mere check for items that need coordinates could be this property: make it simple. -- Docu at 09:18, 31 August 2013 (UTC)
Museums and structures and streets and villages should all be labelled with 'located in the administrative territorial entity (P131)' rather than this property. If you think it is important to identify items which are on earth then the way to do it is to use 'instance of (P31)' 'museum' or 'structure' or other suitable class for each item that isn't a 'terrain feature' or an 'administrative area'. Then create a hierarchy of classes using the 'subclass of' property to link all these classes to a 'place on earth' item/class. All these items will then be members of the class of 'places on earth'. Filceolaire (talk) 22:17, 7 September 2013 (UTC)
Alternatively, both "is in administrative unit" and "is on terrain feature" (location as well) are transitive, which means that thing A in unit B in unit C implies thing A in C. If C is on Earth, A must also be. That would make a class or set of classes unnecessary. --Izno (talk) 03:44, 17 September 2013 (UTC)
Oppose, per Filceolaire. We have 3 or 4 different methods in terms of properties which eliminate the need for this property, besides coordinate location. --Izno (talk) 16:46, 13 September 2013 (UTC)
Which ones? If we need to do P1=Q2 OR P2=Q4 OR P3 OR P4, then a more comprehensive approach is clearly needed. -- Docu at 09:33, 14 September 2013 (UTC)
This property suffers the same problems. "locatable on earth" only leads to "locatable on Mars", "locatable on Jupiter", "locatable in Solar system" etc. It all ends up back at the location property which was proposed but which people thought too generic to use. You want a fix? Make "location" or "located in" your goal. :) --Izno (talk) 17:01, 14 September 2013 (UTC)
You'll note that I didn't disagree with the need for a more comprehensive approach. I only disagreed that your solution—this property—I do not feel to be the correct "more comprehensive approach". And no, I do not withdraw my previous opposition. Why don't you bug Filceolaire instead, as he stated why as well? :) --Izno (talk) 03:38, 17 September 2013 (UTC)
not so sure: IPNI is nomenclatural in nature, and as such of limited value. Why would anyone want to refer to it? Better the IF. - Brya (talk) 17:06, 17 September 2013 (UTC)
IF = Index Fungorum, just as authoritative as IPNI from a nomenclatural perspective, but with a taxonomic component, offering an up-to-date classification. - Brya (talk) 16:21, 26 September 2013 (UTC)
Yea, but the value of Wikidata is as much in what it excludes as in what it includes. It is axiomatic that if you include everything you will end up with nothing of value. - Brya (talk) 04:42, 27 September 2013 (UTC)
Could we have two properties for this? One for the more general treatment categories (surgical/medical/expectative) and one for specific treatments (e.g. appendectomy for appendicitis)? --WS (talk) 14:26, 2 August 2013 (UTC)
I think there should only be a property for what you list as 'specific treatments'. Referring to very broad categories does not seem very helpful to me.
Comment Couldn't part of (P361) be used here? I don't have any medical education, and there might be subtle differences, but it sounds to me like this would be mostly the same thing, only with a narrower domain. --DSGalaktos (talk) 23:34, 10 October 2013 (UTC)
Comment - a qualifier could express if the neurotransmitter is excitatory or inhibitory. Or should we make two properties instead? --Tobias1984 (talk) 10:58, 19 July 2013 (UTC)
I am having difficulty understanding what all of these neuron properties are supposed to do or mean. Will these templates share data or interpretations? Are all the fields here to be taken from some data table which everyone accepts as true? Thanks. Blue Rasberry (talk)12:58, 23 July 2013 (UTC)
Same thought here. Apparently this is inspired by the infobox neuron on the english wikipedia? This infobox is only used by about 50 articles and most of them don't have the parameters above filled in. Perhaps easier to start with nerves rather than neurons. --WS (talk) 13:45, 23 July 2013 (UTC)
I don't really know what either comment has to do with the proposals. The template says in the field "infobox parameter" that these properties are intended to map infobox neuron. We are planning to gather all or most of the data from infoboxes. If anyone feels like it, the can work on any other infoboxes (Anyone can make proposals). I also don't understand what "interpretation" and "truth" are supposed to mean in this setting. This is pretty much text book neurology knowledge. I don't think that anybody is doubting the existance of any of these things? Sorry for my confusion.. --Tobias1984 (talk) 14:20, 23 July 2013 (UTC)
Support Would be useful for infoboxes and querying all the neuron types that are activated by a certain neurotransmitter (probably has pharmacological use) Macadamia1472 (talk) 09:25, 15 October 2013 (UTC)
More properties for items for properties?
if we can create items for properties, can we migrate these data to wikidata database?
Comment. This is a significant change and needs a well thought out RFC, not a bunch of property proposals. The RFC should include
Examples for various properties
Do we need IF/AND/OR/logic for constraints (Range is class A if Domain is class B but Range is class C plus class E if domain is class F)? If yes then how would we do this? Filceolaire (talk) 17:52, 21 September 2013 (UTC)
International Standard Classification of Occupations (en) / Clasificación Internacional Uniforme de Ocupaciones (CIUO) (es) / Classification internationale type des professions (CITP) (fr)
Standard International Classification code for jobs. "ISCO is a tool for organizing jobs into a clearly defined set of groups according to the tasks and duties undertaken in the job."
The presence of the authority control values as wikidata property would allow data distribution to various projects via Lua as used in Q11640331 Module:Authority control and also at projects using previous versions of Q3907614 Template:Authority control. לערי ריינהארט (talk) 08:40, 7 October 2013 (UTC)
The presence of the authority control values as wikidata property would allow data distribution to various projects via Lua as used in Q11640331 Module:Authority control and also at projects using previous versions of Q3907614 Template:Authority control.
Link generation is trivial for this identifier. לערי ריינהארט (talk) 08:46, 7 October 2013 (UTC)
The presence of the authority control values as wikidata property would allow data distribution to various projects via Lua as used in Q11640331 Module:Authority control and also at projects using previous versions of Q3907614 Template:Authority control.
Link generation might be added as soon as documentation is available.
The [[User talk:Magnus Manske/authority control.js}} tool detects NLI already. Please note that Q79822 Adam Mickiewicz multiple script versions for the same value are displayed, The tool offers the addition only one time. לערי ריינהארט (talk) 20:23, 10 October 2013 (UTC)
Artist IDs point at artist objects at MusicBrainz. This would point to labels. So Aviv Geffen wouldn't get one as he isn't a record label. I'm not entirely sure what you are asking, so I hope this helps. CyberSkull (talk) 08:30, 9 October 2013 (UTC)
Support But believe that there should be some consistency i.e. " Division: <> Plot: <>" as opposed to "Plot number 21 of the twelfth division (by the magnolia)" Macadamia1472 (talk) 06:58, 15 October 2013 (UTC)
Guests of honor are an important and highly visible aspects of conventions and similar events; however, I'm not seeing any obvious way of associating a GoH with an event right now, hence this proposal. Schneelocke (talk) 10:51, 15 September 2013 (UTC)
Support. Where guests have a special role (Toastmaster, Fan guest of Honour etc.) this can be indicated by using 'instance of (P31)' as a qualifier. I'm not sure if this can stretch to cover keynote speakers too. That might need another property. Filceolaire (talk) 20:44, 22 September 2013 (UTC)
yeah, this was to be expected: the default oppose attempting to mix this with other topics (industry, field of activity that can be in P31) while hardly ever using P31 in practice. -- Docu at 05:05, 6 September 2013 (UTC)
IBNR station reference always consists of 7 digits, beginning with a 2-digit UIC country code. If the station code consists of less of 5 digits, fill with 0.
Support as a nominator. Even if we will support the whole shape of such objects in future its good to have such data separately. uk: Підтримую як номінатор. Навіть якщо у майбутньому ми будемо підтримувати повні форми таких об'єктів все одно добре мати ці дані окремо. --Base (talk) 12:44, 28 June 2013 (UTC)
Comment As a string how would this information be machine readable/usable? Would it not be better as separate properties, e.g. page number, paragraph number, etc.? Danrok (talk) 02:24, 27 August 2013 (UTC)
We already have volume (P478), chapter (P792) and page(s) (P304). This will work with those properties though I think 'section or verse' would be a better Label. The Description can have the extra info on how to use it. e.g.
Added the template above. Someone may want to propose/create it. Property would make it easier to differentiate from other images of the event/organization. Could be used to replace P623 (P623). -- Docu at 08:07, 15 August 2013 (UTC)
I think we can show a captcha when sb query this property too often, of course we should update the software and API.--GZWDer (talk) 04:39, 29 June 2013 (UTC)
Comment The values of this property seem quite "prosaic", rather than data-like. Even though this property is used in the Neuron Infobox, I wonder if this should be taken over by Wikidata. The other Neuron Inforbox properties are fine, however. So if it makes sense to move all properties to Wikidata (to fully replace the current infoboxes), Then I guess it makes sense to take over this property as well. --Matthiassamwald (talk) 19:58, 5 August 2013 (UTC)
SupportOppose(Datatype changed to Item) would support this if was linked to an Item as implied with the 'item' datatype. For example (don't quote me on the neurology ), <retinal ganglion cell> neurological function <phototransduction>. Whilst this would only give broad functions it would be multilingual and query able. I also think the property should be renamed to 'biological function' or just 'function' so that other biological structures and systems can have their functions described. Macadamia1472 (talk) 08:20, 15 October 2013 (UTC)
I did consider having one property for all of these but they will be used as qualifiers so they cannot have qualifiers of their own. Filceolaire (talk) 16:34, 18 August 2013 (UTC)
Maybe the (future) monolingual text can be used for these cases. I would wait until we have it and then we can decide.--Micru (talk) 16:44, 18 August 2013 (UTC)
Support. as nominator. Official names in scripts you don't know can be confusing. Adding a transliteration may be helpful. Filceolaire (talk) 16:32, 18 August 2013 (UTC)
Support. as nominator. Official names in scripts you don't know can be confusing. Adding a transliteration may be helpful. Filceolaire (talk) 16:32, 18 August 2013 (UTC)
Oppose First of all, transliteration of 'City of London' is 'سيتي آف لندن', what you wrote is translation. I'm oppose because the is no unique transliteration of a name in different branches of Arabic (and similar to Arabic like Persian) for example 'City of London' in Persian is 'سیتی آو لاندن' and has no use in Persian (or Arabic) Amir (talk) 13:21, 8 September 2013 (UTC)
True, how the Swedish transliteration of Osama bin Laden (Q1317) looks, depends on if he is arabic or north-african. I think this is solvable with mulitling-datatype when/if it comes. This even if it means that we need several statements in one object. (One for each kind of transliteration.) -- Lavallentalk(block) 13:30, 8 September 2013 (UTC)
How much manual effort would this property require? For example, the Commons category linked to Category:Dutch politicians -- Category:Politicians_of_the_Netherlands -- has categories 'People of the Netherlands by occupation', 'Politicians by country' and 'Politics of the Netherlands'. You suggest Category:Dutch politicians be mapped to 'Netherlands' and 'politician', but it seems that getting those mappings is not easily automatable. So it seems that the endeavor this property entails would require a large amount of manual contributor effort.
If we want to enable faceted search as your roadmap describes, shouldn't we be mapping intersection categories to more descriptive properties? This property seems like it would map the Wikipedia category system to atomic keyword tags, which are much less structured and expressive than categories. As described in Faceted Navigation by Marti Hearst, a pioneer of the subject, faceted search is based on annotating subjects with values for descriptive properties like 'date', 'genre' and 'author'. This isn't to say that tag-based search isn't useful -- Stack Overflow executes it well (e.g. http://stackoverflow.com/questions/tagged/sparql+rdf) -- but tag-based search is not faceted search.
For example, consider the mapping Category:American politicians (Q7029555) => United States of America (Q30) and politician (Q82955). The mapping loses significant information. On Commons, at least, searching for the intersection of United States of America (Q30) and politician (Q82955) could well return politicians from any country that have been photographed in the Unites States (say, giving a speech at the United Nations General Assembly in New York City). A more descriptive set of properties than is possible with atomic keywords is needed to narrow the result set to what a user would expect.
A couple of years ago I did quite a bit of work on this on Commons to improve the quality of Commons::User:CategorizationBot. Turns out that a lot of topics are intersected by time (mostly year) and location/country/nationality. The Netherlands is actually one of the harder cases of the "The" and "Dutch". In the past I broke the name of the category up in two parts and had lookup tables for the parts. Also the category structure contains a lot of information. Take for example commons:Category:Politicians. All the subcategories have to do something with politicians. Categories like commons:Category:Politicians by country are even more useful because the sortkey of the category contains the name of the country (if I remember correctly I used that data in the categorization bot too). With over 1 million items it won't be easy, but a lot of it can be automated
If we have a category's main topic (P301) we probably don't want to add this property. We don't live in a perfect world so we'll have exceptions, but I don't see a bot adding them. Say C is the set of all items about categories here than A is the subset using category's main topic (P301) and B the subset using this property. A ∩ B should be small.
I guess my chief remaining concern is that this property entails a keyword-based decomposition of categories, which seems like it would cause information to be lost as described in my 'Category:American politicians' example above. Another concern is that this keyword-based approach would not enable faceted search.
Let's consider a few examples and compare the keyword-based approach implied in the proposal to an alternative claim-based approach. The example decompositions of intersection categories are based on what kind of query could precisely select subjects of the category.
Mapping intersection categories to claims with our existing properties would preserve more information. Bypassing keyword-based decompositions and going directly to conventional claims also seems like it might be more efficient -- conventional claims are presumably what we'd eventually want to map categories to. Emw (talk) 05:00, 14 October 2013 (UTC)
Support Multichill and I talked over the points above, and his answers resolved my concerns about this proposed property. He says the keyword decompositions will be the first step in a two-step process. After intersection categories are broken up into keywords, he would run claimit.py to add the missing claims to subjects of the category. (And only then would faceted search be possible.) As someone interested in this subject, it would help to have commons:User:Multichill/Commons_Wikidata_roadmap#Model_intersections updated to contain some of that detail. Emw (talk) 18:55, 14 October 2013 (UTC)
It seems to me that, if we are to use the categories as a tool for bots classifying wikidata items then it's not enough for the bot too know that Category:Dutch politicians combines topics 'The Netherlands' and 'politician'. The bot can't just use 'instance of' for these. The bot needs to know that it should add statements 'country:the Netherlands' and 'occupation:politician' to items in this category. For 'Category:United States Senators from Delaware' the bot needs to add the property 'office held:Senator' with qualifiers 'of:United States Senate' and 'electoral district:Delaware'. I don't know how to express that in a property. Filceolaire (talk) 20:24, 12 October 2013 (UTC)
Comment it seems similar to some use of classes we already do. Actually in OWL classes are already mapped to queries which defines them. It the class Dutch Policitians is a sublclass of both <Dutch people> and <Politician>, and class politician is defined as item with an <OfficeHeld> item, and class Politician is defined as value of occupation is policician, then we exactly have the intersection of category described. TomT0m (talk) 19:13, 14 October 2013 (UTC)
Comment Please not that not all Dutch people who are politicians are Dutch politicians. A person of dual Dutch-French citizenship who runs for office in France would probably not be considered a "Dutch politician" for purposes of the category. --Yair rand (talk) 19:20, 14 October 2013 (UTC)
I am wary that this property would find its way onto categories which do already have a main topic relation setup... Do we have a "Do not use on items which have these claims" constraint template?... --Izno (talk) 22:12, 15 October 2013 (UTC)
Well, there could be more catalog numbers (see the link above) because some records are made in different versions (limited edition, special edition, etc.). We should specify this too, maybe as a source. --Viscontinotalk20:28, 2 April 2013 (UTC)
Yes, now there are qualifiers and we could use them. So, who support this property? and, which could be an appropriate qualifier? --Viscontino (talk) 10:34, 19 April 2013 (UTC)
The catalogue number does not really have a meaning by itself, I think. For music, I think it could be a qualifier of the label. For visual artworks, it would have to be a qualifier of a "catalogue" property. --Zolo (talk) 07:44, 24 April 2013 (UTC)--Zolo (talk) 07:44, 24 April 2013 (UTC)
Support, but I think it should be combined with catalog code (P528) to make things unambiguous (see Property talk:P528). I do not have any strong opinion on which should be the qualifier - and which should be the main property, but I think we should choose the same format for everything. --Zolo (talk) 21:27, 10 June 2013 (UTC)
For certain classical music, "catalog number" would be a main-property identifier not associated with a particular label ... unless (see below, discussion request) there is a separate field for "classical catalog/opus-number identification" or some such. StevenJ81 (talk) 14:13, 11 June 2013 (UTC)
Oops I had it backwards. Actually, I think this property already exists as catalog code (P528), I should have kept my proposal for a "catalogue name" qualifier instead. --Zolo (talk) 14:42, 11 June 2013 (UTC)
catalog code (P528) can be used inside sources or directly in statements. In the second case it would be useful a qualifier with the item of the catalog. If this proposal will change as Micru suggestion, I will support it. --Paperoastro (talk) 14:35, 19 August 2013 (UTC)
Support if it is changed as Micru except that I think 'Catalog' or 'Catalog item' would be a better name for this property. 'Type of Catalog' would suggest a property for classifying Catalogs by types - 'online database', 'classical music opus list', 'Register of historic monuments' etc.
This can be used in Sources if it replaces 'stated in'. This should be acceptable - Help:Sources already says web page references shouldn't use 'stated in'.
As this property can be used to replace all the 'Authority control' properties we should probably move the proposal to Wikidata:Property_proposal/Authority_control. It may even need an RFC.
As the catalog is now defined in an item instead of a Property therefore the proposed Formatter URL property can be used on the Catalog item. A simple gadget should then be able to convert 'catalog codes' into urls provided the catalog code is a qualifier to the 'catalog' property. Filceolaire (talk) 21:11, 19 August 2013 (UTC)
Creative works, celestial objects, probably other things.
Proposed by
various
The above proposal for a "catalog number"is outdated, as we already have catalog code (P528). But, as mentionned there we need a "catalog name" property. I think "catalog" is better than "catalog type" that seems a bit unclear or "catalog name" (on logical grounds, because the value is an item, not a string, and because I am not sure that the catalog always have a name, for music it might simply be the label).
I think that catalog/catalog number should be associated by a main snak/qualifier relation but I am not sure which one should be the main property. It would sound more logical to use "catalog number" as the qualifier but I am not sure it is more convenient: sometimes, the catalog number is widely used without explicitly stating the catalog name (that is often the case for music, and in some contexts, visual artworks)
Support. I've thought about this a bit and concluded the catalog code (P528) should be the main property with this as the qualifier. This is because in many cases the catalog reference is well known by itself (Beethoven's fifth). The qualifier is there to remove any ambiguity. Filceolaire (talk) 16:14, 12 October 2013 (UTC)
Indicates that an URL describes the same object as the Wikidata URL. A semantic web standard. See also Wikidata:Project chat/Archive/2013/07#Identifier mess…. This strongly overlap with "authority control" identifiers but we can' really have a property for every case. I think we have two solutions: either use this one only when no specific property exist, or use it in all cases -even when it is redundant with another property- as it does not do much harm. --Zolo (talk) 13:56, 3 September 2013 (UTC)
Can you show an example in any item as an example, to show how you mean? You can use a sandbox-property with string-datatype, instead of the url-datatype! -- Lavallentalk(block) 19:11, 3 September 2013 (UTC)
Yes, I do not find the label very intuitive either. It is the standard owl name but I am not sure that it is relevant when the link goes to a page that does not use a semantic web format. And in Wikidata, that sounds a bit too much like said to be the same as (P460). I cannot think of any good label though, "external link" is a bit too vague. --Zolo (talk) 09:35, 4 September 2013 (UTC)
"Same as database:"?
I am also looking for something for databases like: Rundata (Q492230). A link can be provided for all of the database, but not to a specific page. The signum cannot directly be used to create any links. It's possible that this is so important that a specific property can be used, since almost every item in the database, at least in Sweden, can be found on Wikidata. -- Lavallentalk(block) 11:53, 4 September 2013 (UTC)
We already have lots of pages with four or five or more links to databases all of which refer to the same thing as the wikidata page. I am not clear why we need this property. Can you give an example of how this property works with those pages. Filceolaire (talk) 21:30, 4 September 2013 (UTC)
There are also websites to which we do not have any properties. In the Louvre example I provided in [2], one link goes to http://www.louvre.fr/en/oeuvre-notices/mona-lisa-%E2%80%93-portrait-lisa-gherardini-wife-francesco-del-giocondo The identifier is mona-lisa-%E2%80%93-portrait-lisa-gherardini-wife-francesco-del-giocondo, which is a bit clumsy, and given that no Wikipedia template provide links to this website, it would be simpler to just provide the full url. Another link goes to http://cartelfr.louvre.fr/cartelfr/visite?srv=car_not_frame&idNotice=14153 in this case, there is a simple identifier 14153, but sometimes, there is a link to an equivalent page in English using a different URL. As the English link does not work for all artworks, using a dedicated property would be incomplete or buggish. If we use the full urls, things can be fine-tuned.
Also, there are so many specific properties that it is difficult for users to know them all. A general property could be used as a fallback. A user could simply add a url using this property and a bot could check whether it can be replaced by something more specific. --Zolo (talk) 06:06, 5 September 2013 (UTC)
I think Wikipedia has already done a lot of work around these problems. There will certainly be things that we can reuse. --Zolo (talk) 20:33, 5 September 2013 (UTC)
Oppose this is semantically wrong. same as would indicate that the thing described by the data item is the same as the thing referenced by the URL. I have already written about this before [3], but to summarize: when dealing with the semantic web, and especially with owl:sameAs, be extremely careful not to confuse identifiers for things with identifiers for the (formal) description of these things. So
if you say that Q90 owl:sameAs http://some/uri, you are saying that http://some/uriis the city of Paris! That's wrong, of course.
What we really want to say is that there is another document describing the same thing. So, there should be a property called "formal description" or "external dataset" or "RDF description" or some such, that can then happily point to other descriptions of Paris. That property could be formalized as schema:about. -- Duesentrieb (talk) 12:41, 13 September 2013 (UTC)
I am a bit confused, as the official documentation says
owl:sameAs construct to define class equality, thus indicating that two concepts have the same intensional meaning. An example:
<owl:Class rdf:ID="FootballTeam">
<owl:sameAs rdf:resource="http://sports.org/US#SoccerTeam"/>
</owl:Class>, which seems to be exactly that. Anyway, as I said, I have no strong opinon about the label. I was proposing to have links to various external resources, not just RDF, but calling it "external links" would be just as fine with me. --Zolo (talk) 13:16, 13 September 2013 (UTC)
Zolo, note that you refer to a superseded version 1 of the OWL standard. You can check out the current OWL 2 Primer for some notes on equality in OWL. The property owl:sameAs is used to encode the SameIndividual feature of OWL in RDF. It really just says that two identifiers refer to the same thing. It is not common to use it on classes; one should rather use owl:equivalentClass there, which encodes extensional equality. --Markus Krötzsch (talk) 15:05, 13 September 2013 (UTC)
CommentDuesentrieb, you are right that care is needed, but your interpretation of "Q90 owl:sameAs http://some/uri" is not correct. In this statement, http://some/uri is an identifier. If what it identifies is Paris (as in the case of http://www.wikidata.org/wiki/Id/Q90), then the statement is correct. If it identifies an HTML document, then the statement would not be correct (even if the document contains text about Paris). The common practice is to use different HTTP return codes to hint at whether a URL stands for a document (200) or just redirects to another document (302). The meaning of schema:about is of course different; the request here should probably be rephrased to be clear which of the two semantics we are discussing here. --Markus Krötzsch (talk) 13:27, 13 September 2013 (UTC)
Right - if <http://some/uri> is indeed an identifier for Paris in some scheme, then it would be fine. But as I understood this proposal, it would point to descriptions, that is, the values would be URLs of data sets. For that, sameAs would be wrong.
while it would be possible top have correct sameAs relations in Wikidata, I fear the potential for abuse is high - actually higher than the actual utility of such claims. I would much more advocate a way to link to other datasets describing the same thing.
Comment Let me make some more comments here, especially regarding the current practice in OWL and RDF. The property owl:sameAs is used to say that two things are exactly equal. One could also say that sameAs declares two identifiers to be synonymous. So anything that was said for the one identifier could also be said for the other. In particular, this means that both things have the same properties. It is a very strong statement of absolute and unlimited identity.
In practice, sameAs is heavily used to relate one dataset to another. This is very valuable since it allows information integration across datasets. However, one has to be very careful: many datasets talk about very similar things but don't mean exactly the same, so that sameAs is too strong. This is even the case for identifiers. For an example from Wikidata, consider Fatboy Slim, who has three MusicBrainz IDs. Each of these IDs refer to an artist who, as a person, is identical with Q272619, yet the IDs do not refer to the same thing (the artists have different names and are associated with different works). So sameAs would be wrong here. Yet, there are correct uses of sameAs, and having such links to other datasets can be extremely valuable for reuse.
Finally, please keep in mind that the property proposed here is just a Wikidata property with label sameAs. It does not in a formal way represent owl:sameAs. In particular, the RDF export of Wikidata will not represent it as owl:sameAs. We can learn a lot from the use of sameAs in OWL, but our property will not have all the same strong consequences on the level of OWL/RDF (we can say that these should be the consequences, but there are no tools that rely on this interpretation). Note that this is similar to Wikidata's ID properties, which also have a rather vague and unspecified semantics. The Fatboy Slim example shows that we do not mean "is identified by this ID" but rather "is (somehow) related to this ID". A similarly vague "sameAs" could be similarly useful. In the same sense that we use the label "MusicBrainz ID", we could use the label "URI" for this vague version of sameAs. --Markus Krötzsch (talk) 15:28, 13 September 2013 (UTC)
So maybe we whould simply called this property "item also described at url" or something like that, and leave more restrictive properties for later ?--Zolo (talk) 06:45, 14 September 2013 (UTC)
Support As with the already active Army and Navy designation system properties which cover designations up to 1962, this property will cover US designations from 1962 on. Joshbaumgartner (talk) 01:33, 2 October 2013 (UTC)
Oppose The fact that the actual code is not displayed on the player information suggests to me that it is a internal number and not intended to be used as a reference. Therefore unlike ISBN numbers which are standardised and immutable this website could be rebuilt tomorrow with a completely differetn sytem and break the references. Also lacks notability as there are countless of these internal references on various websites. maybe <Sean Lamont> database id <"4689"> {for: RaboDirectPro12 Database} using qualifiers that would link to the database and possibly provide instruction on how to retrieve the data i.e. <RaboDirectPro12 Database> item access URL <"http://www.rabodirectpro12.com/statzone/players.php?player=<-->&includeref=dynamic"> Macadamia1472 (talk) 07:08, 15 October 2013 (UTC)
The website has been into two major rebuildings in the last six years and the ID has always been the same (as a matter of fact a player has the same ID both on English Premiership's website and Pro12's). The ratio is the same as this and this, which are already existing properties.-- Blackcat (talk) 22:03, 17 October 2013 (UTC) P.S. I would also add that in the as unfortunate as reasonably unlikely fact that reference were broken, you would have at the worst to change only the centralized source on 'data instead of every Wikipedia chapter...
Oppose I think 'landing site' i.e. itemValue for place would be more meaningful i.e. <STS101>landing site <Kennedy Space Center> or <Apollo 11> landing site <Sea of Tranquility><Pacific Ocean>. Ultimately co-ordinates could be derived from the Kennedy Space Centre item. However for more broad sites i.e. pacific ocean co-ordinates could be given as a qualifier. Macadamia1472 (talk) 06:06, 13 October 2013 (UTC)
I was looking these days at the catalog of the National and University Library of Iceland (Q627423) . There the search for the author Gunnhildur Heiða Axelsdóttir is something expanded from [4] by adding session parameters. I experienced many sites which require exact (not fuzzy) search. YIVO, LibraryThing etc. You need to know exactly how the authors are spelled Karl Bretapríns is Prince Charls etc. In Romania it makes sense to know the spelling if the old or the new orthography is used. So whatever the key / identifier is it is helpfull not to try Sergiu, Serghei, (English transliteration of Russian names: Sergey) etc. Regards לערי ריינהארט (talk) 06:22, 21 October 2013 (UTC)
comment from: LibraryThing chat / topic : I started to add links to the Romanian National Library. Please search for the string alephnew.bibnat.ro at the 7 days helpers log ... (url)
I added <font id="NLR" /><font id="RNL" />RNL (Romania) identifier at the top of this section in order to have simple (url) anchors to this page.
If the proposal is created the name should be NLR (Romania) identifier. i.e. NLR and notRNL. לערי ריינהארט (talk) 03:00, 27 October 2013 (UTC)
Done I do not believe the current oppose has a strong enough rationale to prevent the creation of the property. Perhaps it is too early however the properties aim is to identify and it fulfils that need. Also it seems it is being (or is going to be used) on a project. This therefore means it may be necessary to keep data linked within Phase II. John F. Lewis (talk) 22:01, 27 October 2013 (UTC)
This should be useful for articles with spoken versions in main Wikipedias, as well as for Wikisource, for spoken works. This should be separated from audio (P51) as this specifies more accurately what is the audio file. If we are to import these declarations to Wikipedias, it will need to be explicit for machines whether it is a spoken audio version or another type of audio. Probably needs qualifiers for languages. Pikolas (talk) 05:00, 6 September 2013 (UTC)
Support. There are a few different issues with this. We need to distinguish between a recording of the item (for a poem this would be a spoken word audio) and a recording of the wikipedia article in a particular language. If this property is only for use with recordings of the wikipedia articles then I think it needs a different name - "Wikipedia spoken version" or something like that. It will need qualifiers to identify the source wikipedia, date (so we know which version of the article it is based on), section title (if each section is a separate audio file). When Commons gets wikidataised this info may end up being moved there but we can keep it here until then. Filceolaire (talk) 11:44, 6 September 2013 (UTC)
I think it would probably be better not to specify "Wikipedia" in the label, so that it might be used for other projects, such as Wikivoyage. --Yair rand (talk) 19:00, 8 September 2013 (UTC)
No, not all connected pages are going to be "articles", exactly. On Wikibooks it would be "book pages", and Wikiversity calls pages "resources", I think. --Yair rand (talk) 14:03, 9 September 2013 (UTC)
OK. If the audio file is a recording of the item itself (the text of a poem or a speech, the performance of a piece of music or a play etc.) then it should be attached to the version of the item on wikisource (which will get wikidata-ised soon). This should be called "audio". Until then link the url for the file on commmons using the 'full text available at' property with a qualifier to say it is 'instance of:audio'.
This property should be used if the audio file is a recording of a wikipedia or wikivoyage article and it needs qualifiers to say which version of wikipedia or wikivoyage it is a recording of and (perhaps) a qualifier to say whose voice is reading it - user:Pigsonthewing has a project to get the subjects of wikipedia articles to make a recording of them reading the article. Filceolaire (talk) 20:15, 20 September 2013 (UTC)
Oppose Each flavour would have a different barcode, as would each packaging size and each label language. It is possible that different stores carrying the same item could have different barcodes. This could mean a single item i.e. M&M's could have hundreds of barcodes. It might also be difficult to collect information without buying heaps of items or scanning them in-store (both could violate 'original research'). Even if this data was collected it would be difficult to track changes to barcodes. Macadamia1472 (talk) 06:00, 14 October 2013 (UTC)
Comment 2 projects are trying to achieve just that by different means. Top Down is Product Open Knowledge Foundation which aims at lobbying and forcing companies to release product data identified by barcodes (and yes M&Ms will typically have hundreds of barcodes associated to them), and bottom up is OpenFoodFacts which wants to do the same by crowdsourcing barcode and packaging scanning using mobile apps--Teolemon (talk) 11:18, 15 October 2013 (UTC)
We should probably wait until such time as they are indeed standardized. Even two groups seeking to standardize them does not fix the problem and will not fix the problem for what is likely to be a long time. --Izno (talk) 22:05, 15 October 2013 (UTC) @Izno now that time has passed, maybe is time to reopen the discussion, I think that a lot of people could benefit from storing open product data in wikidata as I explain here https://meta.wikimedia.org/wiki/WikiObject
The w:Library of Congress Subject Headings (LCSH) comprise a thesaurus (in the information science sense, a controlled vocabulary) of subject headings, maintained by the United States Library of Congress, for use in bibliographic records.
Wikidata has effectively got its own controlled vocabulary - the wikidata items. For me this property should only be used to link an item to its corresponding "subject heading". If the LOC name doesn't exactly correspond to the item name well that is what aliases are for.
A different property such as "main topic" should be used to link creative works to wikidata items which may or may not be linked to subject headings. Filceolaire (talk) 05:22, 28 August 2013 (UTC)
If I understood right, you are suggesting that we would only link items to subject headings that match exactly the content of the item. I agree with that. Would it make sense to use "main topic" for items that represent articles too?
I agree that the LoC Subject Headings would be a useful addition. I proposed adding them to the German Wikipedia's authority control template years ago, but people didn't seem very interested. It's similar to the German GND ID (P227) (which also includes "terms") or the Italian BNCF Thesaurus ID (P508). But I'm not sure whether the LCSH need a separate property or if we can simply use Library of Congress authority ID (P244). According to this site by the LoC, the LCSH IDs seem to be normal LCCNs. --Kam Solusar (talk) 11:51, 1 September 2013 (UTC)
As you said the LCC identifier works with subject headings too, so probably there is no need of a property to connect with the subject headings of the LoC. What about a property to show the link between items in Wikidata according to the Library of Congress? Should we use "main topic" with source the LC?--Micru (talk) 18:21, 3 September 2013 (UTC)
I suppose we could use 'subclass of' with a qualifier to say the relationship is 'as:LoC subject headings' rather than having a separate property for each set of subject headings. Filceolaire (talk) 18:07, 14 September 2013 (UTC)
You might consider using FAST which is LCSH derived and less cumbersome (and also meant for "non professional" aka non librarian use). It's being used more frequently with tools like MARCedit accommodating it. FAST project pageMerrilee (talk) 23:33, 21 October 2013 (UTC)
I presume this is just for books at www.gutenberg.org. Project Gutenberg also has independent sites in Canada, Australia, Scandinavia, Europe etc. and they each seem to have their own numbering system. See en:Project_Gutenberg#List_of_affiliated_projects.
Oppose It should be tied to an edition of the book, and since PG doesn't record to which edition of the book the transcription belongs, it would be impossible to know. --Micru (talk) 10:56, 22 September 2013 (UTC)
Number for the Lattes Platform entry on the person or group. This platform is a database of curricula and other information on researchers and research groups maintained by the Brazilian government.
Comment I wasn't so sure of the proper datatype, let me know if 'item' works best. The number in question is part of the link for each entry. Pikolas (talk) 20:09, 16 September 2013 (UTC)
They are for very different purposes. That is for people reading the content of Wikipedia or other wiki- project pages; this is for the subjects speaking as themselves. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits16:13, 9 October 2013 (UTC)
Oppose. Using MultilingualText would completely ruin the point. How would this be "structured data" in any way? This is just writing out the person's name independently in each language. --Yair rand (talk) 15:41, 20 October 2013 (UTC)
For this entry, the brand is http://fr.openfoodfacts.org/marque/u. They also added the brand in the Product name, but what can be linked to Wikidata are the brands already existing in Wikidata, not the individual products (we'd be talking of several million records then). Teolemon (talk)
it seems they use the barcode as main key for each product. so maybe we should collect barcodes instead?! --Shisma (talk) 12:21, 6 October 2013 (UTC)
Adding potentially millions of products to the DB seems a little overkill to me. But I'm unsure about the final purpose of WD. Eating all other DBs eventually and becoming sentient ;-) Teolemon (talk)
Weak oppose I think a database that contained information for generalise food i.e. typical nutrition information of Apples or Chocolate (averaged across brands) but specific food brands and flavours is, as per the barcode discussion, could become too niche Macadamia1472 (talk) 05:13, 16 October 2013 (UTC)
So every individual elected would be listed in this? For example, in the German Bundestag elections, every one of the ~600 elected representatives would be listed? --Yair rand (talk) 00:16, 20 March 2013 (UTC)
Comment not in all cases. It is possible for the successful candidate to concede to their opponent (for whatever reason). Danrok (talk) 22:17, 30 August 2013 (UTC)
Comment P39 is a property of people - the office they hold. This proposal seems to be the reverse if it is the in the domain of constituencies or offices with the property Office holder. Filceolaire (talk) 11:38, 6 April 2013 (UTC)
P39 is not the reverse of this property as someone can be in charge of an office without an election even if there is normally an election for the office. Dom (talk) 03:35, 25 October 2013 (UTC)
Support The title of this property is still problematic... 'official winner' or 'winning candidate' would be more clear. However in general it is clear we need a little more structure for the data that goes with elections, so I am complimenting your proposal with some other properties I think would be very useful for elections. Joshbaumgartner (talk) 05:10, 13 May 2013 (UTC)
kommunkod=dddd, länskod=dd, tätortskod=Tdddd alt dddd (T is optional but recomended, the number ends with 0,2,4,6, or 8, former urban areas has replaced the first digit with an X), småortskod = Sdddd (S is optional but recomended, the number ends with 1,3,5,7 or 9), Parish-code = dddddd, ATA = dddd. I am not sure, but the urban-area and minor urban area-code is chosen by Statistics Sweden. Parish-code, Municipality code and County code is (for me) of unknown origin, but extendily used by them. The ATA-code is from "Antikvarisk-topografiska arkivet", a part of "Swedish National Heritage Board". The ATA-code is sometimes identical to the municipality-code for historical municipalities.
Example
T0106 -> Q2378068 (urban area), 14 -> Q103093 (county) etc...
Format and edit filter validation
Maybe, but I have no experince with such tasks.
Source
I recomend Statistics Sweden as source, for all except for ATA
Robot and gadget jobs
I intend to compare the values with the present on svwp and on Statistics Sweden, before I starts to use them.
I expected some kind of generic solution for these kinds of code, but I fail to see any such use here. There are also some other kind of code for other kinds of urban/rural areas, but they are rare as items. Therefor I would like to see a generic solution. A property named something like "Statistics Sweden-code" with all these kinds of codes used as qualifiers. Observe that one item can have more than one kind of code. An urban area can have a history as a "minor urban area" for example, and an "minor urban area", can at the same time be a "fritidshusområde" (Concentration of weekend and holiday homes). The exception here is the ATA-code, which I prefer to name as ATA-code and nothing else, since it is unrelated to Statistics Sweden. -- Lavallen (block) 16:30, 30 April 2013 (UTC)
Support As long as all of the codes are officially assigned by Statistics Sweden to the item in question, this seems to make sense to me. Only note is that the '-' should be removed from the English-language version of the property label. Joshbaumgartner (talk)
I added a few links to the above proposal. Unfortunatly, most descriptions there are in Swedish. It seems to me that these are several different identifiers used in Sweden by various institutions, rather than one scheme with multiple aspects. I'd tend to create one property for each identifier. -- Docu at 01:18, 9 May 2013 (UTC)
Good enough!
There is a redirect in sv:Sockenkod describing the Sockenkod/ATA-code. Four digits.
Fritidshusområde (en:Concentrations of weekend and holiday homes) has no article/item for the code. The syntax is four digits.
Arbetsplatsområden has no article/item yet, even less for the code. I will come back in that subject if/when it is needed.
Regarding the "tätortskod". Urban areas who ceased to exist before the codes where introduced have an "X" instead of the first digit. It can be written without an initial letter "T" but I would recomend it. Normaly the number is even.
Småortskod has an "S" followed by four digits, the number is nomally odd. "S" can be excluded but it is not recomended.
Församlingskod has 6 digits, municipality 4 and county 2.
When the districts are introduced in the near future, they will likely be the same as församlingskod, since their geography is identical. I will come back when they need items and a new property. -- Lavallen (block) 12:39, 11 May 2013 (UTC)
And urban areas who ceased to exist before the standard for urban areas was introduced 1960, has "novalue" as urban-area-code. -- Lavallen (block) 12:42, 11 May 2013 (UTC)
Pastoratkod" (not been able to translate it, it's an administrative level between Parish and Diocese for the Church of Sweden, the Church of Sweden is still not completly separated from the administrative division of the nation, but it will shortly in the future) Example: 100109 for Nora-Skogs församling (Q10601889)
I created templates for the missing properties. We need them anyway for the talk pages of the respective properties. Could you look for a machine readable source or a webpage where the strings could link too? --Tobias1984 (talk) 12:59, 1 August 2013 (UTC)
Machine readable is hard since SCB likes publishing things as pdfs. Still...
Ecclesiastical parish code (Church of Sweden)/Församlingskod/LKF-kod: pdf. This is actually made up by the county code (two digits, a numeric alternative to P:P507) + municipal code (two digits, makes up P:P525 together with the county code) + ecclesiastical parish code (two digits).
Pastoral district code/Pastoratkod/SKP-kod: [7]. This is actually made up by the Diocese code/Stiftskod (two digits) + Rural deanery code/Kontraktskod (two digits) + Pastoral district code (two digits)
Based on this I'd also suggest creating the Diocese code (two digits) and Rural deanery code (four digits). Same source as pastoral
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Is this thread ready for the archive or should I move it to a Sweden task force page? --Tobias1984 (talk) 11:03, 7 August 2013 (UTC)
Comment waiting for examples. Also, the code doesn't have a wiki-page. That makes me wonder if this meets notability. Please check with Swedish wiki if such a page would be notable and if it is, it would be good to have at least a stub-class article. --Tobias1984 (talk) 13:27, 1 August 2013 (UTC)
Many "minor urban areas" are at the same time "weekend and holiday homes". It's true that there is no parameter in any template for this yet, but it is our ambition to create and use such parameter from now on. An article about "code for weekend and holiday homes" would normally not meet the notability-standards on svwp, but it's ok as an redirect to "weekend and holiday homes". I created this object only to be able to describe this (proposed) property properly. This set of articles have a lower notability than the larger urban areas, but it is our ambition to improve them. There is a large set of values that can be added from Statistics Sweden for this kind of object. -- Lavallen (block) 15:41, 1 August 2013 (UTC)
There is also a fourth set of urban areas (Arbetsplatsområde), but I have today not found a single article on svwp about them, and I have doubts that they will come in a close future. We need somebody interested in the subject first. -- Lavallen (block) 15:41, 1 August 2013 (UTC)
Vet inte hur mycke koll du har men Arbetsplatsområde är (förenklat) SCB's benämning för industriområden utanför tätorter, jag har inte hittat några artiklar på svwp om några exempel på sådana än. De ingår förstås sedan I A/FA resp LA-regioner. Finns det koder för dessa regioner som är lämpliga att föreslå? Annars tror jag de är lämpliga att hantera som en "administrative indelning" ungefär som storstadområden och län. -- Lavallentalk(block) 19:35, 7 August 2013 (UTC)
Det här är väl också begrepp som vi inte har egna artiklar om än. De är dock värda att skapa object runt, oavsett hur det blir med artiklarna. -- Lavallentalk(block) 06:20, 8 August 2013 (UTC)
Water body identification code: most of countries have a classification for water body. This property will be common to all national codes and will use a qualifier to identify the country/national office which is using them.
w:en:Template:Infobox_station has ADA for wheelchair access, although this property can be more generic. access = wheelchair or maybe access = bicycle for a hiking trail or something else (although could need qualifier -- geographic or text -- if maybe only a segment of a hiking trail is accessible). OpenStreetMap also has an access tag. http://wiki.openstreetmap.org/wiki/Key:access and separate wheelchair tag http://wiki.openstreetmap.org/wiki/Wheelchair (details in the wheelchair tag can be suitable as qualifiers)
I am open to other suggested ways of representing such data, but this is the most generic and useful way I can think of at the moment. Aude (talk) 22:10, 1 August 2013 (UTC)
Comment This information can be useful, but how can we reliably source the information and keep it up to date? Also, this information may not be useful in some countries because wheelchair access is a legal requirement for many types of building. Danrok (talk) 20:20, 3 August 2013 (UTC)
Systematic classification and coding of geographic areas of the Philippines. It is based on the four well-established hierarchical levels of geographical-political subdivisions of the country such as the administrative region, the province, the municipality/city and the barangay (administrative subdivision).
This property will be placed in all Settlement Infoboxes on Philippine administrative units . PSGC is present at the German Wikipedia on Philippine administrative units. (Sample) Exec8 (talk) 21:45, 23 September 2013 (UTC)
The relations here are sometimes so complex that it would simplify if it could be described by the help of a separate property. Today, we in Sweden for example have two paralell systems depending on what kind of court case is regarded, and historically has it been even more complex. Some courts did not take care or onwership of real estates, while other didn't take care of taxation-cases. Lavallen (talk) 13:37, 27 September 2013 (UTC)
Do you seem to think that this would duplicate a relation already existing? I can't think of one off the top of my head, but you must have some relation in mind... --Izno (talk) 00:50, 28 September 2013 (UTC)
Older statistics describes Swedish older relations (19th century) like a Municipality "is in" Jurisdiction, and Jurisidiction "is in" County, but that is a very simplified description. If it would have been simple relations, I guess it would have been possible to use located in the administrative territorial entity (P131) or "part of", but I fail to describe it with those properties. -- Lavallen (talk) 06:36, 28 September 2013 (UTC)
If a place is in three different jurisdictions, depending on the type of case, then this property will have three values each with a qualifier giving the type:
'belongs to' is too broad and could lead to misuse as owner i.e. <Mona Lisa> belongs to <The Luvre> or <Puerto Rico> belongs to <United States of America> Macadamia1472 (talk) 07:07, 14 October 2013 (UTC)
This is not the same as Wikidata:Property_proposal/Place#MusicBrainz_area_ID. Area IDs basically are for settlements (villages/towns) and everything larger than that. Places however are for... places where some musical performance happens (concert halls, studios): we currently have 2 type of them, studios and venues. Places can be linked to releases (= albums) and recordings (= songs as they appear on albums). We currently have relationships along the lines of 'mastered at', 'mixed at' and 'recorded at'. Mineo (talk) 19:51, 18 October 2013 (UTC)
The same purpose as all the other MusicBrainz IDs: linking to a website that provides detailed structured and machine readable information about places where musical events (concerts, studio recordings, etc.) happened. The Abbey Road Studios mentioned above have a (still growing, places have only been available in MusicBrainz for 10 days) list of performances. That's a really popular example but we also have smaller/less popular places like the St. Mary Magdalene Church in Wroclaw at [9] or the Kabarett im Hofgarten in Aschaffenburg at [10]. A map of all the currently existing places with coordinates is available at [11]. AFAIK Wikidata doesn't even have properties for mixing/mastering/recording location (yet?) --Mineo (talk) 08:57, 24 October 2013 (UTC)
Motivation: We need a fast way to add statements based on categories. Bot operators are already doing this, but by simplifying the process we will allow more people to participate in converting categories into statements. The name of the property is intentionally general so it can be used to other tasks as needed (for instance, constrain checks).--Micru (talk) 20:04, 17 August 2013 (UTC)
In what cases do you see this as useful? I would imagine that it would be more useful just to add the properties as necessary. I know for example that for video games the addition of properties was trivial... --Izno (talk) 00:03, 18 August 2013 (UTC)
It is not only for existing articles, but also for new articles. Do you have a bot watching the videogames categories and adding statements as new articles are being written and categorized within? This could be a way of having a constant watch on the categories. And there are many categories with the same problem. Bot operators run their bot once and they forget about it... if we have a system like this in place we can make sure that the categories are always being monitored and that a minimum set of properties is added to their items.--Micru (talk) 00:10, 18 August 2013 (UTC)
Are you suggesting that I could put this property on an item, and a bot might come along and fill it in? --Izno (talk) 00:13, 18 August 2013 (UTC)
Not on any item, just on WD items representing Wikipedia categories. An example of this could be:
Ohhhhh, that's a neat (good) idea, though we might want to be more descriptive with the name. I understand the desire for having a broad property, but things could get really messy without a good definition of the property. --Izno (talk) 01:16, 18 August 2013 (UTC)
It can be done the same way as the Array properties gadget, with another property to indicate which articles to ignore and the recursion depth. This kind of feature should be supervised, adding this property could issue an approval request. This is also how the "Array gadget" works, with the difference that it is a one time job instead of continuous monitoring.--Micru (talk) 07:59, 18 August 2013 (UTC)
I am not convinced that you will be able to tell for all language versions of Wikipedia which articles to exclude. Besides you cannot know in advance if any new articles added to a category should be excluded. So I do not like this form of automated statement addition. Byrial (talk) 08:18, 18 August 2013 (UTC)
I agree with you, the best would be a mix between the template "constraint" and the array gadget, which means that having a template in the talk page of a category item would create a list of potential candidates articles (for only a language), and then it could be decided if the automated task is applied to all the candidates (same as now happens with the constraint template).--Micru (talk) 18:16, 19 August 2013 (UTC)--
That's a neat idea, though I'm not very comfortable with such use of properties. IMHO we should continue to keep "background jobs" invisible, using e.g. the Array properties gadget: so, Weak oppose --Ricordisamoa08:51, 18 August 2013 (UTC)
This could probably be implemented in the talk pages like the constraints and such we are using now, come to think of it. A property seems unnecessary. --Izno (talk) 17:16, 18 August 2013 (UTC)
Looking at how the Array properties gadget works, I agree with Izno that it could be done on the talk pages as templates and probably per language since each Wikipedia has a different organization and exceptions.--Micru (talk) 17:43, 18 August 2013 (UTC)
I saw on GZWDer's talk page that he will be gone until August. I think somebody has to jump in and fill the gaps. --Tobias1984 (talk) 10:09, 16 July 2013 (UTC)
Note: This was in fact created on 26 October 2013 before the oppose vote and subsequent rejection, but the proposal wasn't updated. - Nikki (talk) 12:08, 7 June 2016 (UTC)
Comment For what it's worth, BIBSYS is a state organization, and their database is used exstensively by all public and academic libraries in Norway (afaik). - Soulkeeper (talk) 17:29, 22 October 2013 (UTC)