Shortcut: WD:PP/WORK

# Wikidata:Property proposal/Creative work

 Before proposing a property Check if the property already exists by looking at Wikidata:List of properties (manual list) and Special:ListProperties. Check if the property was previously proposed or is on the pending list. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically. Select the right datatype for the property. Start writing the documentation based on the preload form below and add it in the appropriate section. Creating the property Once consensus is reached, change status=ready on the template, to attract the attention of a property creator. Creation can be done 1 week after the proposal, by a property creator or an administrator. See steps when creating properties.
 On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2018/12.

## Creative work

Software products and brands, see: Wikidata:WikiProject Infoboxes/terms
Books, see: Wikidata:WikiProject Books

### software version of

Under discussion
Description the subject item is a version of the object item software (Q7397) Item item software (Q7397) Firefox 4 (Q1950119) → Mozilla Firefox (Q698) software version identifier (P348)

#### Motivation

Inverse of software version identifier (P348). There are items that are software versions of other items. Currently, there isn't a property that links from the former to the latterMalore (talk) 14:57, 18 May 2018 (UTC)

#### Discussion

•  Support David (talk) 16:38, 18 May 2018 (UTC)
•  Support actually it's not an inverse of software version identifier (P348) since that is a string-valued property and can't have an inverse in wikidata. I think this is the better direction to have this anyway, so definitely I support this. ArthurPSmith (talk) 17:29, 18 May 2018 (UTC)

Notified participants of WikiProject InformaticsChristianKl❫ 15:09, 24 May 2018 (UTC)

We should be creating and using generic properties wherever possible, so as to avoid creating many 1000s of very specific properties. The concept of version is not limited to software, and we do already have based on (P144) and subclass of (P279) which can be used in many situations. Danrok (talk) 01:28, 29 May 2018 (UTC)
@Danrok: You could say the same about edition or translation of (P629), or a bunch of other properties that could be substituted by instance of (P31) and subclass of (P279).--Malore (talk) 16:57, 30 May 2018 (UTC)
• After thinking about it for long time, I  Oppose, since I see two problems here:
• It's to specific. "software version of" makes it usable to only software. If at all it should be "version of" since there are other things that are versioned too (Licenses, 3D-Models, technical Specifications, etc.) and there is a fluid transition. But I would like to have even more abstract properties and share them with other areas where different versions/editions/iterations of things exist, including editions of books. The reason is that the more specialized properties your have for each area the harder it's getting to write queries that (also) work in the border-areas and/or in the bigger picture. An example in this case would be technical specifications and standards which are in between of software and books, but are none of both. Should one then use "software version of" or has edition (P747) or yet another to be created property? When writing queries and would need to know and think of all these special cases, which doesn't work…
• It's semantically not fully correct in most cases – including the reference example: Firefox 4 (Q1950119)Mozilla Firefox (Q698). Firefox 4 is not one version of Firefox. It's a version series. Firefox 4.0.0, 4.0.1, etc. are versions of Firefox. This would be the issue basically always since we so far basically only have items about version-series not single versions. One could bypass this by renaming it, but that would make it uglier and lead to problems if/when we have items about singe versions. And in the end this increases the need for having a more general property.
I see the need to improve the ontology of software versions, but I'm against this property. Sorry! I'm thinking about writing down all the open questions & issues about software versioning (there are a lot!) and make a working group or a big RFC, but I sadly don't have the time right now. -- MichaelSchoenitzer (talk) 11:49, 8 June 2018 (UTC)
• In order to simplify the queries, we could make "software version of" and edition or translation of (P629) (and eventually other properties such as "specification version of") subproperties of "edition or version of".
"software version of" and edition or translation of (P629) should be separate properties because they have different qualifiers and the model that describes books - the FRBR model - is different from the software version one (in fact, there isn't a universal versioning model, but every software can adopt its own).
• Firefox 4 is a major version of Firefox, while as far as I know Firefox 4.0.0 and Firefox 4.0.1 are called releases. They are different type of versions, but they are both versions.
However, even if "software version of" wasn't the best solution, it's better than the current management of software version and I think it doesn't create problems if we want to change the model in future.--Malore (talk) 16:08, 8 June 2018 (UTC)
•  Oppose Use generic properties whenever possible. Many types of things are versions of something, this concept is not limited to software. Danrok (talk) 01:32, 29 May 2018 (UTC)
•  Oppose I think we would be better off expanding the scope of edition or translation of (P629) to include "or version". Is there a reason this wouldn't work? --99of9 (talk) 01:24, 1 June 2018 (UTC)
• @99of9: edition or translation of (P629) would no longer be the inverse of has edition (P747) - unless we change it into "edition or version" - and it would no longer be an instance of version, edition, or translation (Q3331189) - unless we change it into "version, edition, translation or version". Probably other things should be modified because these properties are thought for books, not for software. I think we can use similar structures in order to describe software and books, but not the same one--Malore (talk) 04:02, 1 June 2018 (UTC)
Ok, I've struck my opposition. --99of9 (talk) 12:26, 14 July 2018 (UTC)

### subject term (OR keyword)

Under discussion
Description term or concept used to contextualize this item, for example via an external vocabulary, catalog, or other datasource index term (Q1128340) Item creative work (Q17537576) any A systematic arrangement of British plants :with an easy introduction to the study of botany (Q51423679) → Great Britain (Q23666) + plant (Q756) Upload a dataset of 225,000 subject keywords for books etc that we have items for from the Biodiversity Heritage Library (Q172266) main subject (P921)

#### Motivation

(See also the later comments in this discussion at WikiProject Books, in particular the comment by User:Valentina.Anitnelav, 10:56, 4 May 2018)

The Biodiversity Heritage Library (Q172266) (see Wikidata:WikiProject BHL) includes a dataset with 225,000 subject keywords for the books etc we have items for, that I would like to add to the relevant items here.

However, it seems to me that main subject (P921) is not the right property for the job. Consider a book like A systematic arrangement of British plants :with an easy introduction to the study of botany (Q51423679). Its "main subject" might be classified in library catalogues as "Botany -- Great Britain" and "Botany -- Ireland" (in fact, that is exactly what is stated for its subject at OCLC Worldcat).

But the keywords file gives keywords "Great Britain", "Ireland", and "Plants". However "Great Britain" is not the main subject of the book. Anyone looking for a book on "Great Britain" generally would be disappointed if a search returned this book, because it is not a book on Great Britain generally. Therefore IMO it would be wrong to record main subject (P921) = Great Britain (Q23666).

Instead, "Great Britain" is an aspect or a facet of the main subject of the book.

It's very useful to be able to record this, because one can then ask for the set of books which have "Great Britain" as a facet of their subject, and then what other facet-topics it is found in combination with, and thus progressively derive a narrower and narrower, more and more refined final solution set - a process known as faceted search (Q1519370).

This is therefore something valuable to be able to record. But these are not "main subject"s of the books, so P921 is not appropriate, and we would therefore benefit from having a new property for statements of this kind instead. Jheald (talk) 23:10, 10 June 2018 (UTC)

#### Discussion

Comment A subject keyword is a main subject (P921). So what you propose is a "Schlagwortkette" (subject string / subject chain)? For creating "Keyword: Great Britain (Q23666) – subfield: plant (Q756)" we would need to add the qualifier series ordinal (P1545). Otherwise subject keyword + subject keyword = main subject (P921) + main subject (P921). --Kolja21 (talk) 01:49, 11 June 2018 (UTC)

@Kolja21: No, I don't think so. As I understand it, a P921 value should correspond to a complete "Schlagwortkette". This is why in English property P921 is called "main subject". An appropriate P921 for the book above would be a non-category item corresponding to Category:Flora of the United Kingdom (Q6324043).
That is why I am proposing this new property, for an individual Schlagwort from that Schlagwortkette.
Your suggestion of how series ordinal (P1545) might be used as a qualifier is interesting, although that information will not necessarily always be available (eg when just a list of keywords is supplied), nor necessarily unique (eg if both "Great Britain -- Botany" and "Botany -- Great Britain" were given as Schlagwortketten). Jheald (talk) 07:09, 11 June 2018 (UTC)

Support To summarize the discussion at Wikidata_talk:WikiProject_Books#subject_areas_and_genres: There is a need to express that a book is written in (or of interest for) a certain academic discipline/subject area. Sometimes genre (P136) is used, but it is at least debatable if mathematics is a genre. To use main subject (P921) would lead to problems, too, as the academic discipline is rarely the main subject of a book written in it, leading to many false positives. This property could be used to indicate this information without "dumping" it into main subject (P921) (and making it more or less useless for some topics). - Valentina.Anitnelav (talk) 15:43, 11 June 2018 (UTC)

•  Support To avoid confusion in current use of main subject (P921). We would probably want to split off some of the aliases there (for example "keyword") that are not entire subjects in themselves. ArthurPSmith (talk) 18:38, 11 June 2018 (UTC)
•  Support Very helpful for many of the books I add. - PKM (talk) 22:12, 11 June 2018 (UTC)
•  Question As usual with those kind of « fit all property », « a facet » is something undefined. What does this mean? The proposal does not say this. It just explain, totologically, « "Great Britain" is an aspect or a facet of the main subject of the book. » (it’s a facet because it’s a facet) . Actually, the book seem to be about the botany of some places in the world. « plant of great britain » seem to me a legitimate item, and instead we can use location and usual more precisely defined properties to describe this item. Why not doing this? This is the Wikidata way. But I guess this kind of argument is bound to fail when I’ll get tired of saying this again and again… Put another way, if we want to explain what a facet it, we have to put a list of what a facet could be? We know currently « a facet can be the location of the stuff the book describes ». Or pretty much anything else? This is just a proxy for « the book has a vague relation with this topic ». Same problem with categorisation. author talk page 15:23, 12 June 2018 (UTC)
@TomT0m: "Location" is not what we are looking for here. We are not trying to say where the book is located, we are trying to indicate what it is about. The whole point of keywords is that they can be almost anything, and the mechanism of combined keyword search still works the same. If one wants to look up what kind of thing a keyword is, one can look up its P31 -- one doesn't need (or want) a separate property to indicate keywords relating specifically to location.
I am all in favour of adding main subject (P921) to books as well, if the data is there, and items exist for the relevant values. But I don't have a dataset of 225,000 "main subjects", what I have is a dataset of 225,000 keywords -- which I think it would be useful to be able to add. Jheald (talk) 18:24, 12 June 2018 (UTC)
@Jheald: I did not mean put « location » on the book item, I meant having an item « flora of GB » which would held the value. « one doesn't need (or want) a separate property to indicate keywords relating » this is exactly what « facet » is, it seems, « related to ». I guess it’s something we always avoided in Wikidata, putting « related to » which basically could be a superproperty of any property, conceptually, as the all point of property is to establish a relation. I’d actually be in favor of having a « keyword » property (specific to your dataset) that links our items to the used lexeme, this would be interesting, but I’ll always favor more semantic relationships, especially if the (raw) datas are available elsewhere, over importing raw but less wikidataish datas such as « keywords ». There is probably a service somewhere on the Internet where these documents can be queried by keyword, isn’t it?
Having a location as a keyword does not explain how the topic of the book is related to the location itself. Can be location of the intrigue, or a book entirely dedicated to the location itself, or a book about something that is located in this location, … author talk page 18:46, 12 June 2018 (UTC)
If the book is "entirely dedicated" to the location, that should be indicated with main subject (P921). What keywords allow is a more exploratory search style: having searched eg for a keyword that is a location, one can then see what different other sorts of keywords are associated with that set of items -- eg "crime", "plants", "history", etc -- and make a choice at that point as to how to further narrow down the selection, rather than having to know and precisely specify the full subject at the start. It's a powerful (and quite simple) technique, which is precisely why so many information retrieval systems find keyword indexing a useful thing to include. Indeed, it's exactly what the Structured Data project is hoping to create for Commons -- for images we already have the depicts (P180) property which works like this. This equivalent for other kinds of creative works would be useful. Jheald (talk) 19:08, 12 June 2018 (UTC)
In a keyword system, the main topic should hopefully be reflected in the keyword :) so that does not exactly seem like a good argument as you plan to mass import the keywords without verifying if the keyword is actually a main topic. For images, the semantic is pretty clear, there is a representation of the item’s topic in the picture. But if your proposal is structured datas, then wikipedia categories are as well :) But it is not: it’s not, by current definition, it’s not a set of relationship beetween the topic of the book and the topic of the keywords according to a data model, it’s just a bag of keywords with no hint on the relations. author talk page 19:22, 12 June 2018 (UTC)
A bag of keywords can actually be a useful model. In fact, as many information retrieval and library systems have found, it can actually be the most useful retrieval model -- more useful than old-school subject-string models. I'm not against adding detailed "main subjects", but stop getting in the way of this, which is (i) available, (ii) useful, (iii) very widespread across the board as keywords given for articles, papers, journals, books, etc, etc. It's data we ought to be able to reflect. Jheald (talk) 20:08, 12 June 2018 (UTC)
@Jheald: I don’t really like that tone. Please don’t make this personal or give orders. « It's data we ought to be able to reflect » As it’s an argument I already think I gave my opinion on, this information is already queryable on the web, I don’t really see how it’s really important to have it in Wikidata in the same exact form. Also you try to fit different indexation systems into one database, Wikidata, whereas those different database may have different policies on keywords and index the same documents. How to deal with this with only one property? If keywords are structured by an ontology as you seem to imply without really explaining clearly how, are they useful without importing that ontology as well? Also I don’t really understand the relation with faceted search, which rely on faceceted classification. We can already do faceted classification with metaclassification for example using instance of and subclass of, but faceted search means adapting the presentation of the search interface or the result to the topic of interest, for example what resonator does by displaying differently different kind of items. Or displaying a human which is both a scientist and an artist as a scientist is displayed or as an artist is displayed. But to do this, you need to have informations about the properties, not keywords! On does that mean that having a « scientist » facet for a book means you can search using a search interface which is specialized to find scientists?? for example a field the search for the university in which he graduated? Sorry but I’m deeply confused by your approach of the topic and your arguments. author talk page 21:18, 12 June 2018 (UTC)

Notified participants of WikiProject Source MetaData Jheald (talk) 17:59, 12 June 2018 (UTC) Notified participants of WikiProject Source MetaData/More Jheald (talk) 18:00, 12 June 2018 (UTC)

• The topic of a book could be qualified. The subject could be plants (or ferns, trees ..) location Great Britain.. When this is done right, these would be the ingredients for a query. A similar pattern is used for "Catalog contains" where "human" combined with "position held" "position" is used extensively. So no, this would not work for me. Thanks, GerardM (talk) 18:22, 12 June 2018 (UTC)
• @GerardM: I have 60,000 titles. I don't have the means to work out how all those keywords relate to each other, all I have is the dataset of the keywords without relationships given between them. The whole world uses keyword search and finds it useful. (cf category combines topics (P971)). The data is there for us, all nicely made ready on a plate. All we need to add, to be able to upload it and use it, is a property to link a title to a keyword. Jheald (talk) 18:33, 12 June 2018 (UTC)
• @Jheald: When I get the time, I need a few days to achieve this, I will be able to have all the books and authors of the BHL organised so that it becomes easy to link them through identifiers and insert both books and authors to Wikidata. When there is a book with keywords: "Great Britain" and "Ferns" then with some simple logic it is easy to understand those relations. So no, we do not need this. Thanks, GerardM (talk) 19:22, 12 June 2018 (UTC)
• @GerardM: No, Gerard, please don't upload any more BHL titles for the time being. It is enough trying to digest the first 60,000, de-duplicate them, identify authors properly, work out which ones should be editions, periodicals, etc., put them into proper work -- edition relationships, etc, etc. Until we can get this first batch properly cleaned up, more items would not be helpful right now.
And please also don't sabotage the possibility of straightforward keyword searching. Jheald (talk) 19:59, 12 June 2018 (UTC)
• @Jheald: In a previous life I earned a considerable amount of money as a database programmer. When I have the database downloaded and properly organised on my computer, I will perform disambiguation using database tools. Many of the books of the BHL have been identified with LoC identifiers. The BHL content resides typically on the Internet Archive. I have my contacts there. I will prepare my database in a way that allows me to ingest new content from the BHL and know they are new. When I can get an export from Wikidata, I will be able to associate books with authors per the existing links. Now you can tell me nothing what I do at home. What I will do when I am done is explain the process I have performed.
As to this proposal apparently people are only allowed to agree with you. I do not. Thanks, GerardM (talk) 20:46, 12 June 2018 (UTC)
@GerardM: Beware. I was looking at the LoC identifiers this afternoon. It's not that good a dataset. Of the 60,000 BHL 'title' items we currently have, about 28,000 have LoC identifiers, but many of them are wrong. So it's important to check them against the LoC itself, to make sure they are actually correct.
Secondly beware that not all books here have proper instance of (P31)s as books or as editions, nor do they necessarily have author (P50)s rather than author name string (P2093)s.
Thirdly, please make sure that any matching is rather better than your often-proclaimed 4% error rate. In my view, to be acceptable, an error rate ought to be nearer 0.01% -- ie no more than 10 mismatches or duplications in 100,000 entries. That's the standard a data upload should be trying to achieve.
Finally, I don't mind people disagreeing, or having vigorous discussions to find the best data modelling. What I do object to is people blocking whole approaches entirely to the extent of preventing whole data retrieval structures and delaying particular data uploads indefinitely. It may be that you want to be able to represent things differently, I'm not stopping you, but get out of the way of people who do want to be able to do things this way, and accurately represent data (in this case keyword information) in the way it is/was presented in the sources it was derived from. Jheald (talk) 21:16, 12 June 2018 (UTC)
@Jheald: You are telling me what to do and what not to do. Let me do my own research and let me consider what I think is reasonable. I do not subscribe to your notions. I do not agree with your approach because your argument is basically "it is the same shit, so who cares it is shit". Your notions about error rates are unrealistic it is not achieved in our data at all. Thanks, GerardM (talk) 01:08, 13 June 2018 (UTC)

Comment Hi, I'm a librarian, I leave out the last part of the discussion: I think that generic "keyword" could be good. However, it is very important to always add references to the thesaurus or ontology of origin of the terms. Nonoranonqui (talk) 08:12, 13 June 2018 (UTC)

Oppose Just creating complexity for nothing. Why is it a problem to say that the subject of the book is about botanic, Great Britain and Ireland ? The generation of a huge list of possible items if looking for all books having Great Britain as subject ? But this is the idea. Botanic of great Britain is part of Great Britain, so I don't understand why we have to consider it in a different way. The main problem with the proposal is the lack of rule specifying what should be in the defined by the subject property and what should be defined by the subject facet property. This is completely arbitrary so if people will do as he wants and at the end it would be impossible to propose a correct way to build query using two different sets of data. Snipre (talk) 23:00, 13 June 2018 (UTC)

Support, as per Valentina. But: is there a way to use a more general 'keyword' property? Is tihs really specific to 'subjects' or is it about facets of any sort of work more generally? Sj (talk) 19:18, 8 July 2018 (UTC)

Discussion linked to from wikicite-discuss mailing list. [1] Jheald (talk) 07:09, 27 July 2018 (UTC)

Comment I'm generally in favor with this proposal and in agreement with the motivations, but I wonder how external data providers will feel about a controlled vocabulary being casually mapped to Wikidata items by contributors. Case in point: a bibliographic catalog maintains a vocabulary of keywords that are not yet mapped to Wikidata. Bibliographic data from this catalog is ingested into Wikidata and the community start manually adding subject facet statements matching keywords in the original record (or creating new topical items when needed). At some point, the organization behind the catalog introduces a formal mapping of their keywords to Wikidata items. How is this situation going to be handled in the case of conflicts and is this going to be a common scenario? Basically a community member and the original authority behind the data may disagree on the proper target of this property when interpreting the meaning of a keyword. I think the proposal should also clarify if the values should be restricted to those specified by the authority for this record (in which case provenance information should be made mandatory), or can be freely added by Wikidata contributors.--DarTar (talk) 23:09, 26 July 2018 (UTC)

@DarTar: You may be more familiar than I am with organisations taking on to map their own controlled vocabularies to Wikidata themselves. I am sure that does happen, and in future I hope it will happen more. But in most cases (as has been the case with eg the matching of external thesauruses using Mix'n'match), I would think the values will have to be matched and added by the community (or more likely by one or two motivated individuals, perhaps using OpenRefine, and then batch-adding the relevant 'subject facet' statements), because that's how I think this will get done.
But you raise an important point, about transparency and traceability and contestability and improveability of the matching of the controlled vocabulary -- because (unlike matching a thesaurus to an external ID), the matching will not have a visible localised nexus in a single particular statement on a single particular item, but will be embodied implicitly in statements across the dataset. So how to retrieve and review and if necessary correct or improve such matches, after the event? Well, I'm a big fan of broad use of the stated as (P1932) qualifier. Using this one can attach the original string to a statement, as well as the Wikidata Q-number. If this is systematically used, then that gives us the traceability, and it becomes straightforward to produce a query or a Listeria page, matching the original controlled-vocabulary string to the Q-number (or Q-numbers plural) that have been used to represent it. If the data-source has a Wikidata project page (eg Wikidata:WikiProject BHL for the Biodiversity Heritage Library), the matching of various strings could then be discussed on the talk page, or perhaps just a note left to say that some of the matching had been updated, and was everybody okay with that. If there was a Listeria page, then that would give an audit-trail history of precisely what changes had been made over time.
P1932 can thus be used for subject keywords that are given as a string. If the subject keyword is given as a coded thesaurus identifier, then it may make more sense to give that as the qualifier instead (or as well). These qualifiers would be queryable in exactly the same way.
If keyword statements are coming from an external source, then yes the source should definitely be referenced. That should indeed be a mandatory thing. But there may be cases, for example, where there isn't any external source that has subject-indexed a particular set of works. Then editors should be free to add subject keywords from their own assessment; and it's probably also important to be able to add additional subject keywords, even when a set is available from an external source. How should this be indicated? One alternative would be the keywords simply not having a reference statement in such cases. A different approach, that might be preferable, could be to require a reference statement (subject to a constraint check), but allow people to give stated in (P248) = <no value>, or inferred from (P3452) = title (Q783521), or inferred from (P3452) = "Schlagwortkette". That would then clearly distinguish keywords that were editor-supplied, as against cases where the reference had simply been forgotten. Jheald (talk) 08:28, 27 July 2018 (UTC)

Comment Not sure the current framing of the property is useful/ actionable as it stands. I agree that we need something besides main subject (P921), but that something and its use should be better defined (and delineated from P921) than what we currently have in this property proposal. Something like "keyword" also seems to be a more promising way of framing this than the very nebulous "facet". --Daniel Mietchen (talk) 11:32, 27 July 2018 (UTC)

Comment Agree with Daniel that this proposal needs a little bit more thought before we proceed. It's especially important that we first think of some way to source the values so that people won't just start adding random values to items. Husky (talk) 12:09, 27 July 2018 (UTC)

• @Jheald: it seems people would be happier with "keyword" (or "subject keyword"?) as the English label of this property, is this ok with you? Regarding the discussion on sourcing above - how is this different from any other data in wikidata? ArthurPSmith (talk) 17:07, 27 July 2018 (UTC)
• @ArthurPSmith: Yes, absolutely, whatever people want to call it. Keyword is obviously the much more familiar term. The one reason I didn't go for it is a slight mantra that Wikidata items represent things, not words or terms; also "keyword" might suggest something language-dependent, whereas Wikidata's aspiration is to represent things in a way that is as language-independent as possible. But I am not going to get on any horse about what the property is called -- what it operationally does is what matters. As for sourcing: agree completely, how or why is this different to anything else that goes or doesn't go on Wikidata. Jheald (talk) 19:31, 27 July 2018 (UTC)
• Yea, it seems like a fine + useful use of this for anyone to add a keyword -- as long as we can distinguish a definitive map stated by an existing ontology, from the analysis of an individual editor. Community norms would govern what constraints if any there are on sourcing, a norm that might change by field or topic. Sj (talk) 21:29, 27 July 2018 (UTC)
• +1 for using "keyword". As to whether that implies a word vs. a concept, I note that FRBR-aligned Bibliographic Ontology (Q44955004) has "subject term" <subclass of> "concept" defined as "A concept that defines a term within the controlled vocabulary of a particular classification system ... used as an annotation to describe the subject, meaning or content of an entity." I'd say the property fabio:hasSubjectTerm is an exact match for what is proposed here (and perhaps "subject term" would be a good alias for "keyword" on that basis). Details of "subject term" in FaBiO here, p. 7. Perhaps we should change the description of this property to something like "term or concept used to contextualize this item in an external vocabulary, catalog, or datasource". I'd like to include catalog since publisher's catalogs frequently have a list of keywords for books they publish. - PKM (talk) 21:21, 28 July 2018 (UTC)
• @Jheald, PKM: I updated the label and description based on PKM's comment above. The "OR" is to indicate one of these should be label, the other an alias, as our property templates don't have a spot for aliases. Any further thoughts? @Valentina.Anitnelav, TomT0m, GerardM, Nonoranonqui, Snipre: @Sj, DarTar, Daniel Mietchen, Husky: please note "facet" is no longer part of label or description here. ArthurPSmith (talk) 13:45, 30 July 2018 (UTC)
•  Support as amended, and happy with either “subject term” or “keyword” as the label. Very useful in my work for books used as references where the publisher may choose keywords like “costume” and “textiles” for cataloging options but where WD can support a more specific “main subject” like “medieval costume” or “costume of Spain”. - PKM (talk) 17:39, 30 July 2018 (UTC)
So the argument is to allow importing publisher keywords of low quality such as “costume” and “textiles” and keeping such broad keywords instead of grudually improving them with more specific terms such as “medieval costume” or “costume of Spain”?! -- JakobVoss (talk) 05:50, 8 August 2018 (UTC)
•  Support in the amended form. Slight preference for 'subject term' because 'keyword' seems to suggest you can use arbitrary words, while 'term' feels a little bit more strict and defined. Husky (talk) 20:51, 30 July 2018 (UTC)
•  Comment Hi, sorry for joining in late. I recognize the problem, that the wording "main subject" does not always capture is, besides just suggesting there should be a "minor subject" too. To me, this proposal sounds a bit like the "minor subject", and I agree that could be a nice complementary property. But I would like to make people aware that we already have another granular mechanism to say what a paper is about: using that paper as "reference" for Statements. For example, if we have some paper as reference on the statement that the chemical compound acetic acid (Q47512) pKa (P1117) 4.74 (the reference paper actually being Small Scale Determination of the pKa Values for Organic Acids (Q23571464)), this also provides topics the paper is about, one perhaps a "main subject" (the compound) and the other (the concept of acid dissociation constant (Q325519) via the property) perhaps being a "subject facet"... --Egon Willighagen (talk) 05:38, 7 August 2018 (UTC)
•  Comment What's to stop someone adding all the keywords from the index of a book, to the item about that book? We all know that, if someone can do so, they will. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:39, 7 August 2018 (UTC)
•  Oppose A new property this broad should be justified by more and independent use cases, in addition to the dump of keywords to be imported into Wikidata. The proposal only gives a single example and wrongly assumes a narrow use of main subject (P921). The existing property is also used as proposed with "main subject" as "one of the most relevant topical aspects or facets" instead of "the primary and only subject". -- JakobVoss (talk) 20:44, 7 August 2018 (UTC)
•  Oppose. This would be insufficiently structured. "Botany in Great Britain" could be a valid main subject, which could then be properly informative and filled with useful statements. A set of keywords tells us nothing. --Yair rand (talk) 06:24, 20 August 2018 (UTC)
@Yair rand: A set of keywords is very helpful for retrieval -- so "it tells us nothing" is simply not true. The question here is whether we use main subject (P921) = "botany", "Great Britain" for such keywords (per User:JakobVoss above), or whether we use a different property and reserve P921 for subject-strings that are more encompassing. Jheald (talk) 10:28, 20 August 2018 (UTC)

### title in TeX

Under discussion
Description The title of an work in TeX, if it can not be expressed by plain string precisely. Mathematical expression work On the Integers of the Form xk +yk (Q56458961) → On\ the\ Integers\ of\ the\ Form\ x^k+y^k (${\displaystyle On\ the\ Integers\ of\ the\ Form\ x^{k}+y^{k}}$) First Observation of the Doubly Cabibbo-Suppressed Decay of a Charmed Baryon: Λ_{c}^{+}→pK^{+}π^{-}. (Q50609473) → First\ Observation\ of\ the\ Doubly\ Cabibbo-Suppressed\ Decay\ of\ a\ Charmed\ Baryon:\ \Lambda_c^{+}\to pK^{+}\pi^{-} (${\displaystyle First\ Observation\ of\ the\ Doubly\ Cabibbo-Suppressed\ Decay\ of\ a\ Charmed\ Baryon:\ \Lambda _{c}^{+}\to pK^{+}\pi ^{-}}$) Measurements of the branching fractions of [Formula: see text] decays. (Q35209922) → Measurements\ of\ the\ branching\ fractions\ of\ B^{+} \to p \bar{p} K^{+}\ decays (${\displaystyle Measurements\ of\ the\ branching\ fractions\ of\ B^{+}\to p{\bar {p}}K^{+}\ decays}$)

#### Motivation

I don't know whether this is the best solution. GZWDer (talk) 11:45, 4 September 2018 (UTC)

#### Discussion

•  Comment Hmm - seems like we really need a wikitext data type so that you don't have to pretend the non-math part of the title is actually math? ArthurPSmith (talk) 20:24, 4 September 2018 (UTC)
•  Comment I agree we need something similar to that, but am not sure this is the best way to go about it. Here's also a query that get's works that have "Formula: see text" in their title, usually but not always due to TeX in the source title. For instance, there are also HTML and other markup tags that made their way into labels and titles here. --Daniel Mietchen (talk) 10:09, 5 September 2018 (UTC)
•  Comment What about title (P1476) plus some qualifier related to the markup used? --Sabas88 (talk) 15:34, 10 September 2018 (UTC)
•  Weak oppose I think, rather than create other property, we should improve title (P1476), in order to allow TeX code directly. -- diskutujo 02:34, 16 September 2018 (UTC)
•  Comment It's probably needed and I can't think of a better solution. Given the problems with the datatype, I'm not really sure we should create more of them. Maybe we could start with one for titles requiring HTML markup. --- Jura 11:32, 13 October 2018 (UTC)
•  Weak oppose I see the need but would oppose to just allow TeX. This is not about mathematical expressions but about textual markup. Why not Wiki-Markup or Markdown or HTML instead? CSL-JSON support a limited set of markup: bold, italic, subscript, superscript, small-caps, and "nocase". Maybe bold, italic, subscript, and superscript are enough. TeX is only one possible expression of this formatting. By the way, the examples are wrong because they also contain normal text which should not be typed in italic. -- JakobVoss (talk) 20:50, 29 October 2018 (UTC)

### Non-free artwork image URL

Under discussion
Description URL for image of copyrighted artwork on official collection or artist website work of art (Q838948) URL First Lady Michelle Obama (Q50304023) → http://ids.si.edu/ids/deliveryService?id=NPG-PA_NPG_18_57 Cloud Gate (Q589099) → https://www.cityofchicago.org/content/dam/city/depts/dca/Public%20Art/cloudgate800.jpg Martin Luther King, Jr. Memorial (Q536802) → https://www.nps.gov/npgallery/GetAsset/2CF47D2F-1DD8-B71C-079F463EAF89C187?

#### Motivation

It is important to be able to link to images of contemporary artworks, even when they are not on Commons. We cannot display the images here of course, but they are still very valuable. I was surprised to learn at Wikibase Summit NYC this week that some cultural institutions are putting their collections on a private Wikibase rather than Wikidata, largely because they cannot link to their images. The requirements for this property include that the URL be to an official collection or artist's website, so we are not linking to any potential copyright-violating sites.Pharos (talk) 16:09, 22 September 2018 (UTC)

#### Discussion

• Thank you, please note that this is much narrower than the previous proposal, in that this is restricted to copyrighted artworks on official collection or artist's websites.--Pharos (talk) 17:53, 22 September 2018 (UTC)
• @Pasleim: What if we require a reference URL for the page with the license information and perhaps a publisher (P123) as qualifier? I think that should address your concern.--Pharos (talk) 00:57, 3 October 2018 (UTC)
•  Support Cwf97 (talk) 16:04, 3 October 2018 (UTC)
•  Support Germartin1 (talk) 10:55, 4 October 2018 (UTC)
•  Oppose use "official website". --- Jura 16:26, 4 October 2018 (UTC)
•  Comment @Jura1: Why should "official website" be used for an image url? Germartin1 (talk) 19:57, 4 October 2018 (UTC)
• To link to the page containing the image. It would be an official copy, not some random one? --- Jura 16:24, 6 October 2018 (UTC)
• That's an entirely different thing. The main official website may or may not have the best official image, and it is not possible to extract one url from the other. Often the best official copy will be on a sub-page of the official site, or on a site belonging to the artist rather than the museum, etc. We have proposed to use the website that the image is published on as a qualifier per Pasleim's concern above.--Pharos (talk) 19:27, 6 October 2018 (UTC)
• So you would link to non-official copies of copyrighted images?  Strong oppose --- Jura 12:18, 31 October 2018 (UTC)
• Jura, that's not what he's saying. He's saying that websites often use URL's that are different from the URL of the official Website. A photograph could be kept somewhere 5 layers deep, whilst the official "website" often is the main URL. If you want to link directly to the image, you'll have to use the URL that is linked to the image, which is the page on which the image is kept and differs from the official "mainpage", for which the property "official website" exists. So in my opinion they are two completely different things.Oliviervd (talk) 09:20, 6 november 2018 (UTC).
•  Support This would be so helpful and a gap bridged for many GLAM's working with Contemporary art! --Oliviervd (talk) 12:15, 31 October 2018 (UTC)
•  Support Beireke1 (talk) 13:11, 31 October 2018 (UTC)
•  Comment @Oliviervd, Jura1: please abstain from voting twice. Germartin1 (talk) 09:03, 6 November 2018 (UTC)
•  Comment I think essentially this makes Wikidata a catalog of images for sale. I don't see how this is compatible with its purpose. --- Jura 14:06, 6 November 2018 (UTC)

### OSM zoom level

Under discussion
Description Zoom level that would be requested for 512 x 512 pixel OSM map that could contain the boundaries of this map related topic: Web Mercator (Q18155718) String "zoom" in c:Template:Map map (Q4006) "\d\d?"; in practice 0 -> 23 (perhaps 24) none AMERIQUE MERIDIONALE (Nicolas Sanson, 1650) (Q56759862) → 3 John Speed's map of Wales (Q22912348) → 7 c:File:Plan of Dudley Castle (1897).jpg → 18 world map (Q653848) → 0 Given by the calculation $zoom = int((-log ($range / 360) / log(2)) + 1), where $range = MAX ( ($east - $west), ((180/$pi) * ( log(tan(45 + $north/2)) - log(tan(45 +$south/2)) ))) I'm currently working on items for some C18 engravings and maps. The property will also be very useful when Structured Data for Commons arrives, to feed c:Template:Map

#### Motivation

OSM zoom level gives a convenient logarithmic scale for the extent of a map, giving a useful set of integer bins to allow maps depicting subjects of a similar real-world size to be easily extracted from a larger set.

I have used it extensively to analyse and organise the 50,000 maps in the BL C19 map georeferencing project on Flickr and Commons, and would similarly intend to use it for the 17th and 18th-century maps I am currently working on. It is very useful to be able to specify that one exclusively wants to look at maps in a particular set of zoom-numbers; also, to the compare the zoom numbers to the features that the maps are said to depict, to spot anomalies.

The zoom level is a straightforward enough function to find given the bounding-box of the map; however it is well beyond the capabilities of the WDQS query service (particularly the step of Mercatorising the north-south extent), given that SPARQL does not offer trigonometric functions, or even logarithms.

In any case, what SPARQL is most efficient at is indexed lookups. By storing the zoom value as a pre-calculated integer, SPARQL can then extract relevant items (and only relevant items) directly, without calculation, and without having to load the full set and filter it.

The definition above, in terms of the tile level required to fit the maps within a 512 x 512 pixel OSM map, seems to work well in practice. It allows one to specify by fiat that whole world maps should have zoom level 0, separated from slightly smaller maps of not-quite the whole world with zoom level 1.

I have requested datatype "string" since "number" gives 'not available yet', and integers may anyway be better indexed as strings than as reals. Jheald (talk) 23:43, 30 September 2018 (UTC)

#### Discussion

• Proposed. Jheald (talk) 23:43, 30 September 2018 (UTC)
•  Support David (talk) 08:07, 1 October 2018 (UTC)
• can't you use the bbox? That information is already stored in the commons. It is very common, it is independent of a specific service or screen resolution and it is a string. 😉 --Shisma (talk) 09:02, 1 October 2018 (UTC)
@Shisma: Not easy to access from WDQS. Also, there are/will be map items that don't have Commons images. Also, one of the main points of Wikidata and the forthcoming CommonsData is to avoid having to scrape data out of templates, to use properties and statements instead. See eg this query: tinyurl.com/ybhrl9wm for what can be done with bounding box data on Wikidata, as opposed to stuck in a template on Commons. Being able to make zoom-level data similarly accessible to WDQS to allow selectivity would similarly be very useful. Jheald (talk) 09:52, 1 October 2018 (UTC)
•  Comment Better express the maximum extent of the map with data type Quantity, e.g. 250 km instead. This implies zoom level and can be used for other calculations as well, e.g. together with scale (P1752) it gives you the rough size of the map unfolded. See also Wikidata:Property proposal/bounding box which could be build on. -- JakobVoss (talk) 21:35, 29 October 2018 (UTC)
•  Oppose as per JakobVoss--Shisma (talk) 21:43, 13 November 2018 (UTC)
• @JacobVoss, Shisma: To take the second part of JakobVoss's comment first, a bounding box isn't a substitute. AMERIQUE MERIDIONALE (Nicolas Sanson, 1650) (Q56759862) effectively already specifies a bounding box, using coordinates of easternmost point (P1334), coordinates of northernmost point (P1332), etc. But SPARQL doesn't have the computational abilities to turn that into either a zoom level or a maximum extent, still less make those things rapidly searchable. The size of the map unfolded is already given by height (P2048) and width (P2049). Maximum extent could possibly be given by radius (P2120), but I would prefer not to use that for things which are not circular or spherical. Also how would one define it? From the centre to the corner of the bounding box? But the map may not extend to the corner of the bounding box. From the centre to the furthest-away side? Perhaps. And yes, it might be a useful number to have. But the zoom-level is also a useful number to have, giving a convenient logrithmic scale of buckets from zoom 0 to zoom 20+ that conveniently groups maps together. Moreover, zoom-level is what is being used by the Commons template. By your !vote, you prevent this number being stored in Wikidata or CommonsData, so you prevent it being moved out of the template text. Is that really what you want to do? And as Wikidata users, do you have the standing to prevent the better structuring of data on Commons, eg on CommonsData? Jheald (talk) 16:39, 14 November 2018 (UTC)

### (de)evolution method

Under discussion
Description method used to evolve a Pokémon or to make it regress along its evolutionary line Pokémon evolution (Q1040143) Item "causaevolve" in it-wiki's Template:Infobox Pokémon Card (Q6509891) Items to be created Bulbasaur (Q847571) → by level (16, result: Ivysaur (Q1636903)) Kadabra (Q2269206) → by trade (result: Alakazam (Q2069801)) Golbat (Q2345661) → by friendship (result: Crobat (Q2481075)) Growlithe (Q2312415) → by evolutionary stone (Fire Stone (Q27915858), result: Arcanine (Q2486279)) Azumarill (Q2705265) → by breeding (result: Marill (Q2705258)) Azumarill (Q2705265) → by breeding while holding an item (Sea Incense, result: Azurill (Q2739480)) Alakazam (Q2069801) → by megaevolution (Alakazite (Q56676293), result: Mega Alakazam (Q56676707)) it.wiki for sure eventually complete (Q21873974)

#### Motivation

Notified participants of WikiProject Pokémon WD:PKMN seems dead so I make this proposal here, without a earlier discussion. Some Pokémon species change, they evolve and since 2nd generation they can also recess by making an egg and sometimes the original Pokémon must own an item. There are also many ways to evolve a Pokémon: some by level, some by giving a stone, some in a particular (and unmappable singularly) way (e.g. by level and turning 3DS upside down, under the rain or when another Pokémon reach a level, there is room in the team and you have a Pokéball in the bag). This kind of information is important and must be mapped in Wikidata but as long as it need some subproperties to define the way to evolve, I think this needs a standalone property. The name of the property is temporary so if needed, change it. I'm going to show you how to map items: the property will be useful for both evolution and "deevolution" (I don't think there is a specific term for that kind of operation). The property must have one of these as statement, for each way of (de)evolving:

• leveling up
• leveling up with high level of friendship
• leveling up while holding an item
• leveling up while knowing a certain move
• leveling up in a certain location
• leveling up during a certain time of day
• leveling up while holding an item during a certain time of day
• leveling up while is a certain gender
• leveling up in a certain game
• leveling up with a certain Pokémon or Pokémon of a certain type in the party
• leveling up while the Nintendo 3DS is upside-down
• leveling up a Pokémon during certain types of weather.
• trading the Pokémon while holding an item
• trading the Pokémon for specific Pokémon
• using an evolutionary stone on it
• by a particular method
• breeding
• breeding while holding an item

Items must be created yet. Then:

• In case of leveling up, it needs numeric value (P1181) to define which is the lower level in order to trigger evolution
• In case of item to be held, I honestly don't know if applies to part (P518) or item operated (P121) should work
• In case of move/type of move to be known, the time of day, the gender, the game, the Pokémon/Pokémon type, the weather, the specific Pokémon to be traded and the evolutionary stone to be used, the property applies to part (P518) should work well.

Every statement should have also direction (P560) in order to define which Pokémon you get after the (de)evolution.

I think I wrote everything. During next week I will create items about evolution, if a sort of consensus is found --★ → Airon 90 09:24, 3 October 2018 (UTC)

#### Discussion

This property could be used also to map mega evolution (Q16577590), as example 7, but I don't know how to link back, as I don't think it is possible to use the same property again. --★ → Airon 90 09:32, 3 October 2018 (UTC)

•  Support David (talk) 08:32, 4 October 2018 (UTC)
•  Comment I know we have lots of Pokemon items, but this seems awfully specific for a property. Could you perhaps use instead followed by (P156) or a similar property, with appropriate qualifiers? ArthurPSmith (talk) 18:01, 4 October 2018 (UTC)
I already considered this option but don't think it is useful, because it would need a qualifier for the qualifier and as of now, Wikidata doesn't have such option: indeed, if I use followed by (P156) then I need a qualifier to define how the item (de)evolves into that specified Pokémon and then I need a qualifier for the qualifier to clarify level/item/Pokémon/...
See examples in order to understand how many data would this operation needs.
Other way to mapping these data are obviously welcome! --★ → Airon 90 06:48, 7 October 2018 (UTC)
EDIT: IMHO, I also think that it doesn't have any sense to partially map the way of evolution. It is useless to just know that certain Pokémon evolve leveling it up or trading it with another Pokémon withour specifying the level which it evolve since or the Pokémon needed to be traded to trigger evolution. I think that either we allow mapping all data properly or it is useless partial work and it would be then better not to map at all these data :) --★ → Airon 90 06:53, 7 October 2018 (UTC)

### Public presentation

Under discussion
Description time of the first public presentation of a subject by the creator Point in time concept car (Q850270), type of manufactured good (Q22811462) Renault EZ-Ultimo (Q56878821) → 2018-10-02 Samsung Galaxy S9 (Q50102300) → 2018-02-25 Bombardier Global 6500 (Q54370182) & Bombardier Global 5500 (Q57078862) → 2018-05-27 Bavaria R55 (Q57078990) → 2018-01-20 press releases date of official opening (P1619), publication date (P577)

#### Motivation

date of official opening (P1619) and publication date (P577) are both for other types of works and also signify the actual beginning of public use, while this proposed property is intended to be used for the official announcement of the mere existence of the work. MB-one (talk) 10:02, 8 October 2018 (UTC)

#### Discussion

significant event (P793) with qualifiers is currently used for this. But it only really makes sense to use it, if there's a separate wikidata item just for the presentation event, which isn't always the case. This property is intended to be more equivalent to first flight (P606), time of spacecraft launch (P619) or date of official opening (P1619). --MB-one (talk) 17:54, 9 October 2018 (UTC)
•  Support David (talk) 06:57, 9 October 2018 (UTC)
• This seems to be a useful addition, however I think it could be even broader, such as an announcement date or introduction date for a new event, building (especially good for buildings that are being built and don't have a start or public opening date yet), or law (Tax Cuts and Jobs Act of 2017 (Q42955478) -> 2017-11-02 . So I will  Support it as "date of first public presentation/announcement" (announcement can also be in the alias). Further it should have a single value constraint as there can only be 1 first presentation. Germartin1 (talk) 07:34, 10 October 2018 (UTC)
Of course it could be open for more widely usa. --MB-one (talk) 13:04, 15 October 2018 (UTC)
•  Oppose, per ArthurPSmith. Use significant event (P793) with point in time (P585) qualifier, even if there's no dedicated item for the particular item's presentation event, as the property is intended for. --Yair rand (talk) 23:24, 10 October 2018 (UTC)
• @ArthurPSmith, Yair rand: The problem with significant event (P793) is that it can have as value the specific event or a generall occurence. Let's look at the new Pixel 3 (Q57179556), let's use significant event (P793), do we put as a value Google I/O (Q668984), Google I/O 2018 (doens't exist yet) or just presentation (Q604733) or announcement (Q567303) (announcement should have have series ordinal (P1545)=1 so it's clear that it's the first announcement and not just any), or even both. How do you query it??? Having a simple property "date of first public presentation/annoucement" will make it much easier Germartin1 (talk) 09:01, 11 October 2018 (UTC)
• I'm sure this has come up before in other contexts. Maybe we should split significant event (P793) into two, one to point to specific event items, and one to point to generic types of event? In any case I don't think we need special properties for each generic event type. The ones mentioned above were created early on and probably wouldn't be approved now. ArthurPSmith (talk) 18:23, 11 October 2018 (UTC)
• (edit conflict) @Germartin1: Hm, this is a good point, but it's applicable to essentially all the varied uses of P793. The presence of using specific instances of more general classes in P793 breaks use of qualifiers like P1545, and makes querying more difficult in general. Perhaps we should just eliminate use of such instances, and link the more specific item by a qualifier? I don't think working around it for one specific type by creating a new property is a good idea, but this is something that needs to be fixed somehow. --Yair rand (talk) 20:27, 11 October 2018 (UTC)
•  Support Nepalicoi (talk) 17:10, 11 October 2018 (UTC)

Under discussion
Description Title of website, journal, book or other work which a publication is published in. Use P1433 instead if possible. Monolingual text any item which contains referenced statements any text Rick L. Riolo (Q56918163) → The references on these statements link to an obituary, the value might be "mLive Obituaries". Princess Marie Franziska de Paula Theresia Josepha von Liechtenstein (Q43095438) → The references on these statements link to an angelfire website , the value might be "Paul Theroff’s Royal Genealogy Site". Agrinar (Q4694124) → The reference I've added from the Wikipedia links to a blogspot page - the value is "Pesados Argentinos" In the next month I plan to work on a gadget for adding references that will use this property.

#### Motivation

This is necessary for adding full references to any statement where it is difficult to automatically create or disambiguate a new item, particular for websites where there is currently no information on where to store the title of the website in Help:Sources. All standard citation styles require this field when citing websites. For example, the correct way to cite a website is in MLA style is:

“Title of Web Page.” Title of Website, Publisher, Date published in Day Month Year format, URL.

We need the ability to add the statement pointing to the value for "Title of Website." The only current alternatives to this is to use published in (P1433) and create a new item for the website itself. Some websites may be notable and this makes sense, others may not, such as a blogspot subdomain.

Help:Sources prohibits creating a new item for a webpage. How to add the website title to the reference is not covered. This would be useful as a general counterpart of published in (P1433) without the need to create an item in the same way like author name string (P2093) is a counterpart of author (P50). This would expedite the automatic creation of references using Citoid.

This is equivalent to the "website" parameter in the Template:Cite web template on en wiki:

{{cite web |url= |title= |last= |first= |date= |website= |publisher= |access-date= |quote=}}

Alternative names for this property include "Container title" and "Website title" and "Publication title." See more about MLA "Container titles.

Mvolz (WMF) (talk) 15:15, 24 October 2018 (UTC)

#### Discussion

@Mvolz (WMF): Any opinions on using title (P1476) within the reference? Mahir256 (talk) 16:51, 24 October 2018 (UTC)

@Mahir256: That is already occupied by the "Title of Web Page". This is would be for the title of the website. But you're correct that wasn't clear, I'll fill out the example a bit more. You could add title (P1476) twice but then it wouldn't be clear which was the title of the webpage and which was the title of the website. Mvolz (WMF) (talk) 16:56, 24 October 2018 (UTC)
@Mahir256: whoops, I realise I made a typo which lead you to that conclusion. Fixing! Mvolz (WMF) (talk) 19:46, 27 October 2018 (UTC)
Comment Do we really have cases where we wouldn't have or want an item for the website/"container" of a publication? ArthurPSmith (
talk) 18:35, 24 October 2018 (UTC)
@ArthurPSmith: I'm not sure, but Help:Sources seems to forbid this.
One thing is that we are adding this information automatically and it's not always possible to resolve that two containers are actually the same container because we may just have the string - even if the string matches it may not be the same container. In this sense it's a similar problem that resulted in the creation of author name string (P2093). This is further complicated by the fact that a single container entity might have multiple urls that point to it (i.e. google.co.uk and google.com).
In the second example I have added, the source is a personal angelfire page "Paul Theroff’s Royal Genealogy Site" so we would have to create an item for things like that. We would also have to create items for subdomains of blogspot, etc. as in the third example we'd create an item for Pesados Argentinos. Obviously I have picked worse case scenarios here but these are indeed the references used on the Wikipedia pages - so although these kinds of references are discouraged they do exist.
I'm not at all opposed to creating new items for these - but without consensus to proceed in this manner I worry that not having this property in place means it won't get added at all. I would rather wikidata users fix this as needed if they determine the container should indeed have its own item by removing the container title and replacing with stated in as needed, rather continue with only limited data. Mvolz (WMF) (talk) 16:04, 27 October 2018 (UTC)
•  Comment please provide examples Germartin1 (talk) 21:30, 24 October 2018 (UTC)
@Germartin1: I have added two more - it's a little bit difficult because I can't link to references directly but hopefully it's clear. Please let me know if not. Mvolz (WMF) (talk) 16:04, 27 October 2018 (UTC)

Comment Do I assume correctly that this property is equal to the “website” parameter in ENwiki's Template:Cite web? I certainly think that we should have some property that can be mapped to “website”. - PKM (talk) 19:09, 27 October 2018 (UTC)

@PKM: Yes, that is the corresponding field. Mvolz (WMF) (talk) 19:48, 27 October 2018 (UTC)
I am concerned that the label "container title" (although correct) would be meaningless for non-specialists searching for a way to add the property. I would prefer the label "website" or "website title" with "container title" as an alias. I also support adding websites as items if they are going to be used as references for more than 2 or 3 items, but of course, there will be one-offs that are used only on one item. - PKM (talk) 20:00, 27 October 2018 (UTC)
Thanks - I've changed to publication title for now. I guess the reason I prefer publication to website is in case the publication title isn't a website but we still don't want to create an item for it and that's more general, and hopefully have meaning for the website case as well? Mvolz (WMF) (talk) 10:10, 29 October 2018 (UTC)
•  Support per above, as needed to map the “website” parameter in Wikipedia citation templates. - PKM (talk) 05:40, 28 October 2018 (UTC)

Comment I’m a bit confused by your mention of the only current alternative. So far, I’ve used published in (P1433) or publisher (P123) to link to the “container”, depending on whether the best available item looks more like a publication (e. g. TheGuardian.com (Q5614018) or, if a separate item for the online version doesn’t exist, The Guardian (Q11148)) or more like a publisher (e. g. Guardian Media Group (Q2665980)). If I saw a reference using stated in (P248), I would assume that the value is a dedicated item just for a single page, not for the container. --Galaktos (talk) 08:40, 28 October 2018 (UTC)

@Galaktos: Thanks for pointing out published in (P1433)! I'll update that- and good point about assuming the value is a dedicated item for the page, not the website. However it has the same issue of having to create an item for the container. (As for publisher, it is distinct from container title. If you look at the MLA citation field above, you'll see it has a publisher field in addition to the website title. Template:Cite web on en wiki also has "publisher" in a separate field. To full cite a website in any standard style, you need both the website title and the publisher.) Mvolz (WMF) (talk) 10:10, 29 October 2018 (UTC)
@JakobVoss: Very good point, I have updated to reflect this using your suggestion below and also in the explanation text. I started with "references only" because I thought perhaps there'd be less object to using flat data (instead of linked data) in a reference as opposed to biographical data elsewhere, but you're correct that this could be used anywhere and that it's senseless to restrict to references only, as long as people understand published in is strongly preferred.Mvolz (WMF) (talk) 10:01, 31 October 2018 (UTC)
•  Oppose use published in (P1433), revise Help:Sources if needed (it's unclear where though).  Oppose label "publication title" for suggested use. This would need to be more specific. --- Jura 10:05, 30 October 2018 (UTC)
How about label "title of broader work" and description "title of journal, website, book or other work which a publication is published in. Use P1433 instead if possible." -- JakobVoss (talk) 13:16, 30 October 2018 (UTC)
@JakobVoss: Thank you, I've copied this above verbatim, this is great! Mvolz (WMF) (talk) 10:01, 31 October 2018 (UTC)
• From Help:Sources, I think there is no doubt that items for journals and books should be created. For websites, it's a bit confusing, but the guideline mainly wants to exclude items for pages of websites, not websites themselves.--- Jura 19:47, 30 October 2018 (UTC)
@Jura1: This is a very good point. On further reading it's only clear it specifically prohibits creating an item for a *page* but not necessarily the *site.* It is silent however on what do with this particular piece of metadata. I have updated this above, hopefully to more accurately reflect this. Let me know if you think the change doesn't accurately capture your comment. I think it's clear that whatever the outcome here Help:Sources needs to comment on how to add this. Mvolz (WMF) (talk) 10:16, 31 October 2018 (UTC)
Looks better. As your focus seems to be to build a gadget for WP references, wouldn't it be easy to check/create items for websites? It might be more complicated for others. As it's done now for "author name string", people can then attempt to replace values of this property with P1433. --- Jura 08:29, 1 November 2018 (UTC)
Support we can attempt to refine this periodically (similar to author name string). --- Jura 13:39, 28 November 2018 (UTC)
I don't want an item for every Website only because it is part of a reference. Sure we can detect frequently used websites and create items for them in a second step. -- JakobVoss (talk) 19:40, 2 November 2018 (UTC)
• Would narrowing the scope just to websites, and labeling this property "website name" adequately address the concerns above? ArthurPSmith (talk) 19:02, 31 October 2018 (UTC)
I prefer more general properties but nevermind. For normal (non-reference) statements an alternative is this: -- JakobVoss (talk) 19:40, 2 November 2018 (UTC)
subject > published in (P1433) < unknown value Help >
stated as (P1932) < title >
• Oppose. The tool should be able to correlate to known websites. --Izno (talk) 13:29, 27 November 2018 (UTC)

For the record, there is now an RfC about how to store the container or website title – see Wikidata:Requests for comment/Referencing websites: how do we store the website title?. @Mahir256, ArthurPSmith, Germartin1, PKM, Galaktos, JakobVoss: you might want to leave a comment there. --Lucas Werkmeister (talk) 14:48, 29 November 2018 (UTC)

### release artist

Under discussion
Description musical artist who is labelled as a primary contributor to this work Item "artist" in w:en:Template:Infobox album musical work (Q2188189) human (Q5), musical ensemble (Q2088357), group of humans (Q16334295) Break Free (Q17309667) → Ariana Grande (Q151892) Break Free (Q17309667) → Zedd (Q21088) (qualifier: object has role (P3831) → featured artist (Q3546919)) Popular Song (Q7229734) → Mika (Q186329) bot duplication or replacement of performer (P175) on musical works performer (P175)

#### Motivation

Currently, performer (P175) is used on items for music releases and tracks to represent the artists whose names are listed on the cover (i.e. the primary artist(s) and the featured artist(s)), rather than the actual list of performers (i.e. session musicians, band members and background vocalists). This property would separate those two different uses to make it possible to more clearly indicate what someone actually did for a musical work. Jc86035 (talk) 09:34, 31 October 2018 (UTC)

#### Discussion

• While it would be possible to create a property for featured artists and another for main artists, I think it would be better to use one property with qualifiers so that some relationships (e.g. "Artist A vs. Artist B", "Main Artist with Other Artist"; series ordinal (P1545)) can be indicated more clearly without having to create new properties or using qualifiers confusingly. Jc86035 (talk) 09:40, 31 October 2018 (UTC)
•  Support I support this of course, but I would suggest another name than "billed artist", billing/top billing are terms commonly used in reference to concerts, musicals, etc. What about "release artist" or "recording artist"? Moebeus (talk) 11:33, 31 October 2018 (UTC)
• @Moebeus: "Release artist" sounds good; I've updated the title. Jc86035 (talk) 12:53, 31 October 2018 (UTC)
•  Support David (talk) 07:29, 1 November 2018 (UTC)
•  Oppose no need to duplicate performer (P175), just use object has role (P3831): main artist, featured artist Germartin1 (talk) 13:24, 1 November 2018 (UTC)
•  Oppose per Germartin1. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:57, 2 November 2018 (UTC)
• @Andy Mabbett @Germartin1 "performer" is not the same thing as "release artist". Performer probably comes from the musical/theater people, what we need is a property related to what is printed on the cover of singles, albums, etc. Mozart, Bach, Gershwin - these people are not the performers. But they might be the release artists. (EDIT: Gershwin might be a performer of course, but you get what I mean ;-) Moebeus (talk) 01:39, 3 November 2018 (UTC)
• Then use composer (P86). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:54, 3 November 2018 (UTC)
• @Pigsonthewing: That's just not accurate at all. In popular music the "release artist" (main/featured artist) could be the main vocalist, one of the producers (e.g. Break Free), or even someone whose voice is sampled briefly. Usually the "main artist" label doesn't apply to all of the producers (Break Free was produced by Zedd and Max Martin), all of the songwriters (Break Free was written by Ariana Grande, Zedd, Martin and Savan Kotecha), or even all of the vocalists (Popular Song has main vocals by Priscilla Renea as well as Mika). Jc86035 (talk) 07:40, 4 November 2018 (UTC)
• Please provide a link to an item where Mozart, Bach, or Gershwin is "the main vocalist, one of the producers, or even someone whose voice is sampled briefly". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:39, 4 November 2018 (UTC)
• @Pigsonthewing: My comment below discusses the case for not attaching the qualifiers to composer (P86). My point above was not, obviously, that Mozart or Bach would have been performers in recordings of their music. Jc86035 (talk) 18:31, 5 November 2018 (UTC)
• I am able to read, so when you wrote "these people are not the performers", I was able to understand that your point was not that they were. What you did say, though, was that "Mozart, Bach, Gershwin... might be the release artists". You have yet to provide an example where - other then being the music's composer - this is the case. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:55, 5 November 2018 (UTC)
• @Pigsonthewing: There are the albums by Milli Vanilli, for example (since the duo did not actually creatively contribute, but are nevertheless deemed the release artist), and it might be tenuous to call Gorillaz performers due to the majority of listed band members being fictional characters. Moebeus has noted other examples below. Jc86035 (talk) 11:36, 6 November 2018 (UTC)
• I'm pretty sure neither Mozart nor Bach were in Milli Vanilli. Was Gershwin? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:24, 6 November 2018 (UTC)
• I don't understand what you're trying to say – I wrote "in popular music" to specifically indicate that I wasn't implying that Mozart or Bach would have done those things. I hope it is clear enough that this proposed property wouldn't apply to compositions by classical composers, and should only apply to releases of their music where they, in place of or in addition to performers, are explicitly stated to be the primary artist.
• What I was trying to say was that neither of the members on Milli Vanilli (nor the fictional members of Gorillaz) could have been credited as creative contributors to their songs, which would mean that the qualifier approach wouldn't work because none of the existing properties would be applicable. Jc86035 (talk) 08:41, 8 November 2018 (UTC)
• For classical music (as in, the compositions themselves), I would think usually there is no need for a "release artist" distinction because the only contributor is the composer. On the other hand, for recorded music – particularly for recordings of classical music and releases like film soundtracks and Broadway cast recordings – there is probably still at least one release artist, but it might not necessarily match the composer or even the performers. Especially if a release is credited to "various artists", or some artist(s) in particular and also "various artists", this property would be useful because the entity various artists (Q3108914) cannot actually have contributed to the creative work. Jc86035 (talk) 07:55, 4 November 2018 (UTC)
• The Muppets, The Smurfs, Walt Disney.... There are countless examples where the release artist is not the composer, nor even necessarily the performer. This would be useful. Are there any examples of why it might be bad? I welcome any effort to help WD better cover music and this is definitely a step in the right direction imo. Moebeus (talk) 22:36, 5 November 2018 (UTC)

### notable print

Under discussion
Description Qid of a print (there may be more than one) that is a notable old representation of/from/for the work of art (mostly older out-of-print prints, but also paintings, archeological finds, sculptures, buildings, or other artefacts of religion, politics, or works of art) Notability can e.g. be of the forms: catalog representation for the artist or museum, Hollstein number (Dutch & Flemish prints), Bartsch number (old master prints), or some external id for the subject print (Q11060274), engraving (Q22669429), etc Item work of printed art Qid View of Saxenburg estate with bleaching fields near Haarlem (Q21264555) -> Goldweigher's Field (Q21200482) Dr. Brook Taylor's method of perspective made easy (Q55739221) -> Satire on False Perspective (Q7426243) Conus marmoreus (Q1902297) -> The Shell (Q15874034) Schilder-boeck (Q1157807) -> Portrait of Karel van Mander (Q58074274) Two Children with a Cat (Q19326431) -> Two Children with a Cat (Q58074316) Mona Lisa (Q12418) -> Mona Lisa (Q58087321) Bird’s-eye View of Amsterdam (Q17558353) -> Bird's eye view of Amsterdam (Q52062987) The Dream of Frederick III, Elector of Saxony (Q43981335) -> 1617 Reformation centenary broadsheet (Göttlicher Schrifftmessiger) (Q58299699) the documentation for the print should be on the print item part of an ongoing effort to include notable prints in Wikidata never complete

#### Motivation

As a first step to including prints on Wikidata, I think we need some properties to help connect them to other artworks. Once we have a large group of notable prints we can make decisions about how to further construct items about them (e.g. do we really want to import all instances of popular prints?) Feel free to add more than the few examples here. Jane023 (talk) 10:56, 2 November 2018 (UTC)

#### Discussion

Notified participants of WikiProject Visual arts. Jane023 (talk) 11:42, 2 November 2018 (UTC)

•  Support Added the example of Luigi Calamatta's print of Mona Lisa which contributes to the notoriety of the artwork. --Shonagon (talk) 14:32, 2 November 2018 (UTC)
•  Question “notable old representation of/from/for the work of art” is very unspecific. We already have “some properties to help connect them to other artworks”, for each of the examples given so far they are:
To find the same connections you can make a query like (pseudo-SPARQL, equivalent for other languages etc.): ?subject wdt:P4969|wdt:P361|… ?print. ?print wdt:instance of (P31)/wdt:subclass of (P279)* print (Q11060274). In worst case the existence of this property would lead to those properties not being added. Probably we should make them more visible, dedicating a part of this awful guideline we have, Wikidata:WikiProject Visual arts/Item structure, to them. Maybe we could create a place on item pages where they can be expected by adjusting MediaWiki:Wikibase-SortedProperties. Would there still be any advantage of having this property proposed over them? --Marsupium (talk) 16:19, 2 November 2018 (UTC)
Well the reason I am adding more example items is because in the literature there are lots of examples where the relationship is key, although the nature of this relationship can be very different. I am keeping the property unspecific for this reason. So to be clear, first the unspecific relationship can be easily made, and more refined relationships can be created later. It should be eassy to upload notable prints and indicate their strongest relationship to other artworks. Jane023 (talk) 17:04, 2 November 2018 (UTC)
For example I mention Hollstein and Bartsch - I wanted to include Q numebrs and realized they don't exist on Wikidata (yet) except as people. Sigh. We need to make it easy to start and refine through iteration, not decide on some complicated hierarchy beforehand. Jane023 (talk) 17:09, 2 November 2018 (UTC)
@Jane023: Hm, I'm not sure if I get your point. Do you mean it is easier to remember a single property name? Otherwise do you have a concrete single example where using "notable print" instead of one of the existing properties is an advantage? --Marsupium (talk) 17:24, 2 November 2018 (UTC)
The obvious answer is use this property for the earliest or most popular documented print, rather than any of the multiple iterations of prints. We have no way of indicating a hierarchy of importance, especially for prints of specific locations. Jane023 (talk) 17:39, 2 November 2018 (UTC)
Now I understand it, thank you, I had a broader WD:N-like definition in mind and also read that from your text. Also the template fields have confused me a bit. If I understand you right now, what is in the subject item/Represents field should go to allowed values. And the domain (the subject, the item where you want to put the property on) you plan is obviously much broader than “work of printed art”, that's the subject/values. I still think the scope the examples suggest is too broad. --Marsupium (talk) 18:05, 2 November 2018 (UTC)
Hello Jane023 Marsupium. I didn't know this property derivative work (P4969) (many thanks!) and the proposed property seems indeed a subclass of this concept. As Marsupium explain, using the nature of the item/derivative work leads to same idea and logical structure. If we want to limit redundant properties, it may be a better choice. The other things pointed by Jane is about the confusion with prints in wikidata, where works (FRBR) and items (FRBR) are mixed. This one for example met again last night, on which I contributed and which has become a documentary monster: Melencolia I (Q1362177). Happy halloween! With the progress of contribution on prints we come to the point where we need an item for the work and other items for the materializations. And here, I understand the interest of the property, to avoid the possibility to add several versions of the same work as derivative works. Best regards --Shonagon (talk) 18:22, 2 November 2018 (UTC)
Yes exactly - and Melancholia is a good example. Think of this property a bit like notable work (P800) for people. I think that might help too. Jane023 (talk) 22:59, 2 November 2018 (UTC)
•  Support David (talk) 06:41, 3 November 2018 (UTC)
•  Comment Not sure that this is the right way round.
If we have an item for a print, (or for a "print state/print edition", cf map edition (Q56753859)), isn't the proper set of relations:
<print (item)> exemplar of (P1574) <print edition>,
<print edition> edition or translation of (P629) <print>,
<print> based on (P144) <painting> ?
That would seem more suited to what may well be a run of many-to-one relations.
What further does the proposed inversion, <painting> "notable print" <print>, give us?
And what would we mean by "notable"? What would make a print (or rather: print family, because that's really what we mean) notable or not ? Jheald (talk) 17:03, 5 November 2018 (UTC)
Please see the examples in the proposal. The idea of one-way identification (i.e. the print comes after the object) is of course a great idea to do, but we don't have all of those prints for many objects. In the case of paintings, we sometimes know the painting follows the print for example, but we still want the "notable print" on the painting. For painting series of the same subject (and for older series it is not clear whether these were made by the same master) there are often also more than one print, and it is unclear which print should be associated with which painting. This enables a fuzzy link when the relationships you suggest are unknown. Jane023 (talk) 17:24, 5 November 2018 (UTC)
@Jane023: Thanks, Jane. To your first point, however, this proposed property is to be item-valued. So it wouldn't be usable anyway, unless we had an item for the print.
Regarding paintings after prints: it seems to me potentially extremely confusing if this property will sometimes indicate a print that the painting is based on, if almost always it will be indicating a print that is based on the painting. Better to use <painting> based on (P144) <print> for the first case.
As to the case when it is not clear which print should be associated with which painting, I would settle for <print> based on (P144) <painting series> in that case -- it seems the most honest way to express the relationship. Jheald (talk) 17:50, 5 November 2018 (UTC)
Well I can't make prints any more or less confusing than they already are. I see no need to be scared of this property making things more confusing. It is in fact very useful to be able to link a painting to an associated popular print, especially when you can't determine what the print is based on at first glance. In the examples I gave, there are many 1-1 relationships, but of course there can be many-many relationships, where a series of paintings is based on a few prints, themselves based e.g. on various aspects of one popular altarpiece. We may not have many prints in Wikidata yet, but I hope this will change - see my comment under "motivation". I am not proposing to use this property when the relationship is not documented. The documentation should be in the print item (but it is sometimes included in information about objects sold on the art market). Jane023 (talk) 18:18, 5 November 2018 (UTC)
•  Oppose I'm sorry, but I really think this isn't a right way. Unlike what the motivation suggests all the aforementioned properties are there and completely sufficient to describe the relationship itself ("notable" aside). In my eyes there is no need to have a dedicated property for prints as opposed to any other kind of works. The "notable" part indeed seems to make it different somehow, but it isn't well-defined as from what I understand of the proposal so far. If there should be some need to qualify the relation of something to a print of it, then a qualifier would probably be a better way, maybe a derivative work (P4969) and object has role (P3831) combination. --Marsupium (talk) 23:37, 5 November 2018 (UTC)
Again, see my comment about notable work (P800). This property is to include the notable print(s) rather than just another way to link up any prints (which of course can be very many over the centuries for multiple editions, if we ever import bibliographic metadata). I would also be happy btw if that property was expanded to be able to be used on non-human items. Jane023 (talk) 12:14, 7 November 2018 (UTC)
•  Oppose per Marsupium last comment. The proposed property is overly specific and constrains the type of the object (to Print) but that is an inherent attribute of the object, it should not be carried by the prop. (By analogy, Mother is a worse prop than Parent because what happens if you link Mother to a male?). Marsupium and Jheald mention 4 existing props; Jane do you really want to create a 5th one and increase the confusion? What we need is more usage guidelines; and thank you for the excellent examples that move us significantly towards that. --Vladimir Alexiev (talk) 20:37, 14 November 2018 (UTC)
Thanks for liking my examples! I chose them precisely because I want to show the relationship of the item to a print. I find it interesting that you feel I am being specific, because this property is just one of many properties I would like to propose for prints, and this is the least specific of them. Your point that the properties derivative work (P4969), part of (P361), depicted by (P1299), published in (P1433) can be used instead is not true. None of these expect the object to be a print, which is the whole point. Secondly, the study of prints is extremely complex and the examples chosen are explicitly unsuited for derivative work (P4969), which would be very convenient indeed if all prints were well documented as to their origins. I think you will find that some engravers are considered artists in their own right, and many paintings are based on concepts known from "iconic prints" known for their popularity in politics, religion or art. So the same problem holds for depicted by (P1299) in the "chicken-and-egg" cases. The shell case is interesting because it is an exemplar of a period when shell collecting was at its peak. Lastly, whether something is part of a larger work or published in a work is useful, but has no indication in terms of being the "notable iconic image" part of the work. Jane023 (talk) 14:45, 15 November 2018 (UTC)

### work whose melody is quoted

Under discussion
Description other creative work which this work quotes the melody of musical quotation (Q1955297) Item creative work (Q17537576) creative work (Q17537576) Popular Song (Q57899540) → Popular (Q3908430) (chorus of the former) The Carnival of the Animals (Q941724) → Ah! vous dirais-je, Maman (Q18336185) (movement XII of the former – needs its own item) MISSING work sampled (P5707)

#### Motivation

has melody (P1625), but for excerpts rather than the entire melody. This is distinct to work sampled (P5707), which expresses the same relationship for the audio of the original rather than just its melody. If there are qualifiers I'm not sure if they would be allowed to apply to only the original or only the derivative. Jc86035 (talk) 12:00, 12 November 2018 (UTC)

### quotation or excerpt

Under discussion
Description quotation or excerpt from this work Monolingual text creative work (Q17537576) I've Been to the Mountaintop (Q5967210) → [the four quotes used in the English Wikipedia article, split roughly every 400 characters] [virtually any page in q:Category:Productions] MISSING

#### Motivation

We have first line (P1922) and last line (P3132), but it's not possible to add quotes for anything else (in particular things that are only one line long). Qualifiers like page(s) (P304) and time index (P4895) would probably be used for indicating the point within the work that the quotation begins. In addition to use for statements, this would be useful as a qualifier for statements relating between works, like work sampled (P5707). Jc86035 (talk) 17:47, 12 November 2018 (UTC)

#### Discussion

•  Support David (talk) 06:41, 13 November 2018 (UTC)
•  Comment It seems to me like this might be better handled by using/creating a Wikiquote entry for the quote you want, then linking to that item. ArthurPSmith (talk) 21:22, 13 November 2018 (UTC)
@ArthurPSmith: Quotes on Wikiquote don't get their own pages, as far as I'm aware – they're usually associated with the person or work that originated them. Jc86035 (talk) 15:59, 16 November 2018 (UTC)
• Have you thought about the copyright implications? How do you plan to prevent such problems from arising? ChristianKl❫ 14:41, 25 November 2018 (UTC)
@ChristianKl: The 400-character limit for strings should suffice for now; perhaps a complex constraint would be required for items with more than about 4 statements for this property, and statements with more than one qualifier for this property. If it's fine for Wikisource to host massive amounts of copyrighted quotes from TV shows and the like, the implication is that there's nothing wrong with the same thing being done here (and CC-0 probably wouldn't make a difference to that here). Jc86035 (talk) 15:29, 26 November 2018 (UTC)
It is fine for Wikiquote only because that project allows non-free content that is used under fair use (see here, though that is not official policy). I do not believe Wikidata is ready to do so itself. Having said that, I am still supporting this proposal below, as I don't believe the fact that someone could use a given field to add copyrighted information is a reason not to have the property at all. There are plenty of valid use cases for public domain works, so I think the solution should be policing Wikidata's content for policy violations, not preventing this property. Also, I would note the existence of quote (P1683), which already allows quotations on Wikidata (but that property is specifically for use in references). Dominic (talk) 16:04, 29 November 2018 (UTC)
•  Support, though I think this raises other issues. How should we distinguish between a true excerpt and when a full work is short enough to be included in its entirety (e.g. a short poem, short speech, etc.). These are conceptually different, and we would not want to misrepresent a full work as incomplete. For example, I just checked and the entire Gettysburg Address can fit in a single statement (the character limit is now 1500, not 400). And I would note that we already have an inscription (P1684) property, which is essentially a full-text quotation of a very specific type of work. I also think enabling quotations from works implies we should have an equivalent, but separate, property for adding quotations of people or things, since the data is usually given in that context as well. I think there should be three separate properties in total: "excerpt (of work)," "quotation (of person)," "full text/transcript". Dominic (talk) 16:04, 29 November 2018 (UTC)
•  Oppose. This should wait for structured Wikiquote. --Yair rand (talk) 19:53, 9 December 2018 (UTC)
@Yair rand: Why? Lexemes didn't wait for structured Wiktionary. A structured Wikiquote would, in any case, probably require much more software development for Wikiquote than for Wikidata, seeing as all that's required on the Wikidata end is one property and imports, and we could make the property now; whereas structured Wikiquote would require a lot of interface changes to avoid massively disrupting Wikiquote contributors' workflows. Jc86035 (talk) 14:23, 10 December 2018 (UTC)

### code Danmarks Statistiks d'un film (fr) / Danmarks Statistiks filmkode (da) – (Please translate this into English.)

Under discussion
Data type External identifier film (Q11424) \d+ Titanic (Q44578) → 7167 The Olsen Gang Sees Red (Q1215282) → 1995 "Crocodile" Dundee (Q615254) → 5189 https://www.dst.dk/da/Statistik/emner/kultur-og-kirke/film-boeger-og-medier/biografer-og-film 11899 always incomplete (Q21873886) Mix'n'match (Q28054658)

#### Begrundelse

Statistics Denmark (Q1164337) provides statistics for the number of tickets sold for each film premiered in Denmark. This data is available in a spreadsheet where each film is identified with an integer, — "film kode" (film code) as the first column in the spreadsheet. To allow for easier setup and updates of the ticket statistics on Wikidata it would be beneficial to have the identifier added to Wikidata.

I believe the statistics are regularly updated (yearly?), but I have been told that the identifier is stable.

As far as I understand the identifier is not resolvable, so should the datatype be external ID or another type?

Finn Årup Nielsen (fnielsen) (talk) 15:04, 13 November 2018 (UTC)

### New York Times article ID

Under discussion

#### Motivation

Notified participants of WikiProject FranceAyack (talk) 19:48, 3 December 2018 (UTC)
Notified participants of WikiProject France again due to Phabricator T67910. Ayack (talk) 18:12, 10 December 2018 (UTC)

#### Discussion

@ديفيد عادل وهبة خليل 2, Nomen ad hoc, Deansfa, Ayack:  Done: Monument aux morts ID (P6238). − Pintoch (talk) 18:55, 11 December 2018 (UTC)

### Wikia Articles

The following two proposals are aim to associate items to wikia aricles. they mutually exclude each other and only one of them should be implemented. If you vote for one of them, please vote against the other.

Wikia is a wiki hosting service originally founded by Jimmy Wales. Most Wikia-Wikis focus an a specific Entertainment Franchise. Eg Harry Potter, Family Guy, Muppet Show of Wikia wikis many more….

Almost any fictional character, work of fiction, fictional object should have at one Wikia article about it. Not surprisingly a lot of LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20OPTIONAL%20%7B%20%3Fitem%20wdt%3AP973%20%3Fdescribed at URL.%20%7D%0A%20%20FILTER%20%28CONTAINS%28str%28%3Fdescribed at URL%29%2C%27.wikia.com%2Fwiki%2F%27%29%29%20.%20%20%20%0A%7D Items already point to Wikia articles using described at URL (P973).

Reasons why a separate Property is useful:

• Wikia offers a standardized API for all their Wikis even down to the Mediawiki version. An application develoers knows what to expect from a wikia wiki API. Which makes it easy to build applications on top of it.
• Since almost any item under a certain subject should have a Wikia article, a separate Property makes it easier to check for completeness.

so here are two possible ways of collecting these Articles: --Shisma (talk) 10:53, 25 November 2018 (UTC)

URL vs. ID
Wikia URL Wikia ID
Resolvability URLs are already resolved dependent on an external service http://www.wikia.com/wiki/w:c: which doesn't seem to work very well
Stabillity Wikia changed their name in the past, and the seem to plan a change in the future (Fandom). Along with the name, the domains change. The ID should be stable and unique as long as the article itself isn't moved to a new lemma.
Editability Straight forward: Copy and Paste the URL. The ID needs to be extracted from the URL.

#### Wikia Article URL

Under discussion
Description Wikia Article URL URL fictional character (Q95074), television series episode (Q21191270)… things that have articles in wikia ^https?:\/\/(?:[^@\n]+@)?([^:\/\n?]+)\.(wikia|fandom)\.com\/wiki\/.+ (any subdomain of wikia.com or fandom.com) Kermit the Frog (Q1107971) ↳ https://muppet.wikia.com/wiki/Kermit Professor Moriarty (Q283111) ↳ https://bakerstreet.fandom.com/wiki/James_Moriarty ↳ http://de.sherlockholmes.wikia.com/wiki/James_Moriarty ↳ http://es.sherlockholmes.wikia.com/wiki/James_Moriarty ↳ http://pt-br.sherlockholmes.wikia.com/wiki/James_Moriarty ↳ http://de.memory-alpha.wikia.com/wiki/James_Moriarty ↳ http://es.startrek.wikia.com/wiki/James_Moriarty ↳ http://fr.memory-alpha.wikia.com/wiki/James_Moriarty ↳ http://it.memory-alpha.wikia.com/wiki/James_Moriarty Mortynight Run (Q22807440) ↳ https://rickandmorty.wikia.com/wiki/Mortynight_Run ↳ http://it.rickandmorty.wikia.com/wiki/Episodio_13 P973 (with any subdomain of wikia.com or fandom.com) a lot of items use already use described at URL (P973) to point to wikia pages. these could be automatically replaced 2283 yet (see query) Wikia wiki ID (P4073)

#### Motivation

Currently a lot of items point to wikia mediawiki articles with the property described at URL (P973) (see query. Having a separate URL property makes it easier to check for completeness. --Shisma (talk) 10:35, 25 November 2018 (UTC)

#### Discussion

• I don't understand how checking for completeness would be easier with a dedicated property. --Yair rand (talk) 20:39, 27 November 2018 (UTC)
• I see how the fan wiki's benefit from this, but how does Wikidata benefit from it? Should we link to all these pages? Multichill (talk) 12:15, 2 December 2018 (UTC)

#### Motivation

A Wikidata property related to video games (Q28147643) for PC games distributed on the Discord store. Lewis Hulbert (talk) 05:54, 3 December 2018 (UTC)

#### Discussion

Notified participants of WikiProject Video games. Lewis Hulbert (talk) 05:54, 3 December 2018 (UTC)

@ديفيد عادل وهبة خليل 2, YULdigitalpreservation, Esteban16, Macrike, Cwf97, Lewis Hulbert: @Kirilloparma, Sir Lothar, Jean-Frédéric:  Done: Discord Store game SKU (P6229). − Pintoch (talk) 06:52, 11 December 2018 (UTC)

### collection creator

Description entity (person, organization, etc.) that caused a record or collection to be produced or gathered creator (Q59275219) Item generally, items which are a collection (Q2668072) or constituents of them (e.g. using "part of" property) Records of the Bureau of Indian Affairs (Q59405045) → Bureau of Indian Affairs (Q1010563) Records of the U.S. Mint (Q59405223) → United States Mint (Q1141049) Records of the U.S. Information Agency (Q59405192) → United States Information Agency (Q1754777) Records of the U.S. Senate (Q59405097) → United States Senate (Q66096)

#### Motivation

Currently, we lack a property that would allow us to add "creator" in the archival sense. To be clear, I am talking about creator (Q59275219), and not creator (Q2500638), which is the concept the current property creator (P170) refers to. The distinction is that the common understanding of "creator" is about who/what produced something. In archival science, by contrast, "creator" refers to who/what was responsible for a collection of archival materials being produced, gathered, used, etc. In an archival description, therefore, listing a person or organization as a "creator" does not typically imply they physically made it in the same way we mean if we use the current property.

For example, consider a letter sent to the a government agency, which is now in the holdings of the US National Archives. The "creator" would be listed as the agency, as it comes from their records, even though it did not write the letter. The writer, if known, would be listed as a "contributor" (with "role" given as author), if they are described. This is not just a NARA practice. Here is a similar situation in the California State Archives: this document is a trademark filing which contains images and text produced by the applicant—"creator" is listed as "California Secretary of State's Office" (the recipient agency, not the applicant), and the applicant is listed as contributor, "Folger, Schilling and Co."

I would like to be able to add this type of "creator" data to Wikidata. Dominic (talk) 18:34, 4 December 2018 (UTC)

#### Discussion

•  Comment Given we already have creator (P170) you are going to need to provide a different label for this property to avoid confusion. I don't know if "archival creator" is right, but something distinctive enough to be clear what your meaning is. ArthurPSmith (talk) 19:16, 5 December 2018 (UTC)
• @ArthurPSmith: Understood. "creator" is the correct name for this concept in the discipline, so I wasn't sure if that would require disambiguation or not. If so, I would suggest "collection creator," though that makes me a little uncomfortable since it's not the technical term. But I think it's an accurate description. Dominic (talk) 20:19, 5 December 2018 (UTC)
•  Support But: agree with ArthurPSmith's comment above, that we need to give it a different primary label here on Wikidata - otherwise people here will certainly mix both up. In order to further clarify the link with archival description: can you figure out to which metadata fields in EAD, ISAD(G) and perhaps other archival description schemes this corresponds? It would perhaps make sense to point to their URIs via equivalent property (P1628), just like the current creator (P170) points to equivalent properties in schema.org and others. Spinster [[User talk:Spinster|💬 ] 11113, 8 December 2018 (UTC))
•  Comment there was some discussion about this at Topic:Umz0wazbjtf7mwv7. -- [User talkkJura11Juraa] 06618, 10 December 2018 (UTC))
•  Comment There is a Wikidata Projet Archival Description where we try to find a way to describe archival element in Wikidata. Any help is welcome..--[Userr2le2immbdcc2le2immbdcc] (([User talkk2le2immbdcc|span classs=signatureetalkk">{inttTalkpagelinktextt}}<spann>]) 06601, 11 December 2018 (UTC))
•  Support Agree because is one of the 6 mandatory elements of the standard ISAD(G))..--[Userr2le2immbdcc2le2immbdcc] (([User talkk2le2immbdcc|span classs=signatureetalkk">{inttTalkpagelinktextt}}<spann>]) 06605, 11 December 2018 (UTC)

@Dominic, ArthurPSmith:  Done: collection creator (P6241). − Pintoch (talk) 14:26, 13 December 2018 (UTC)

### Paris Musées work ID

Under discussion

#### Motivation

The database covers lots of Turkish movies. ~800 ID can be directly extracted from the template usage in Turkish and English Wikipedia. -- Meisam (talk) 17:05, 9 December 2018 (UTC)

### Multiplayer ID

Under discussion
Description Identifier of a video game from the website Multiplayer.it Multiplayer.it (Q3867056) External identifier video game (Q7889) Metal Gear Solid V: The Phantom Pain (Q717600) → the-phantom-pain-per-ps4 platform (P400) → PlayStation 4 (Q5014725) Metal Gear Solid V: The Phantom Pain (Q717600) → the-phantom-pain-per-xone platform (P400) → Xbox One (Q13361286) Clannad (Q110607) → clannad-per-ps4 platform (P400) → PlayStation 4 (Q5014725) Clannad (Q110607) → clannad-per-pc platform (P400) → Microsoft Windows (Q1406) Use in sister projects: [de] • [en] • [es] • [fr] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd]. https://multiplayer.it/giochi/\$1.html

#### Motivation

Multiplayer.it is an italian website about video games, used in itwiki. Spinoziano (talk) 14:14, 12 December 2018 (UTC)

#### Discussion

•  Support David (talk) 08:32, 13 December 2018 (UTC)