Documentation

title
published name of a work, such as a newspaper article, a literary work, piece of music, a website, or a performance work

Represents

original title (Q1294573), title (Q783521)

Data type

Monolingual text

Domain

work (Q386724), cross-reference (Q1302249), order (Q567696), collection (Q2668072), occurrence (Q1190554), item of collection or exhibition (Q18593264), fonds (Q3052382), system (Q58778), legal norm (Q216200), organization (Q43229), law (Q7748), group of works (Q17489659), release (Q115668308), exhibition (Q464980) or fictional work (Q124301146)

Allowed values

(?i)((?!\b( | | |)).)*((?!</?[Ii]>).)*(?i)((?!\b(|||||)).)*(?i)((?!\b(|)).)*

Example

Nature (Q180445) → Nature
On the Origin of Species (Q20124) → On the Origin of Species by Means of Natural Selection

Tracking: usage

Category:Pages using Wikidata property P1476 (Q23909058)

Discussion

Any allowances for titles with no language?

Is this intended to replace P357? Or can that property be used if the title has no discernible language? -Moogsi (talk) 17:37, 4 October 2014 (UTC)[reply]

For the records: P357 (P357) had been deleted (see Wikidata:Requests for deletions/Archive/2015/Properties/1#P357). So yes, this property replace P357 and yes, it can be used « if the title has no discernible language ». Cdlt, VIGNERON (talk) 14:54, 2 October 2018 (UTC)[reply]

Language part of the title

I see that now the language of the title has become part of the title, so that anybody doing a copy-and-paste is going to end up with the wrong title. Why this weird and confusing approach? Why not just have a separate field for the language? - Brya (talk) 06:04, 9 January 2015 (UTC)[reply]

@Brya: That's not true. The language is not part of the title as you can see using the API: [1]--Jobu0101 (talk) 11:49, 16 April 2015 (UTC)[reply]

Ah, what you are saying is that what my eyes see (and what presumably every user sees), they are not seeing because an API says so? Sure! - Brya (talk) 16:28, 16 April 2015 (UTC)[reply]

@Brya: I'm not talking about your eyes. I'm talking about how data is stored in Wikidata: The language is definitely not stored within the title string but separately like you originally wished. --Jobu0101 (talk) 16:55, 16 April 2015 (UTC)[reply]

Well, eyes are what I use (and so does mostly everybody) to check and correct content. If eyes were not important why put it onscreen at all? - Brya (talk) 05:30, 17 April 2015 (UTC)[reply]

I think the key is to use eyes and brain simultaneously. If title and language is printed on screen in the same line this doesn't imply that they are stored as one string. Also note that you don't enter them into the same field when you assign P1476. Finally, my API example shows that they are indeed stored separately as they should. --Jobu0101 (talk) 16:13, 22 April 2015 (UTC)[reply]

It is not possible to use eyes separately from the brain. If title and language are printed on-screen in the same line the title cannot be easily checked or corrected; and that pretty much negates the whole idea of having it on-screen. - Brya (talk) 16:24, 22 April 2015 (UTC)[reply]

@Jobu0101: It should be possible to ease the brain's work by telling the eyes that it's two different pieces of data. Any easy way to do that would be to display the language with a smaller font-size, a lighter color or a font-style itallic. Just as it is done for language fallbacks. But differently, otherwise those might be mistaken - Zorglub27 (talk) 09:36, 9 June 2015 (UTC)[reply]

Ask the designers to do so. But this does not only apply to the title property here but to all fields using Monolingual texts. --Jobu0101 (talk) 09:43, 9 June 2015 (UTC)[reply]

Original title (originally asked in Wikidata:Project chat)

How do we capture the concept of the original title of a film/book/etc in Wikidata? --Jobu0101 (talk) 18:21, 14 April 2015 (UTC)[reply]

title (P1476). Sample at Q15624215. --- Jura 18:27, 14 April 2015 (UTC)[reply]

For me isn't clear how to use title (P1476). Why must be Monolingual text? Original title isn't the same in all language? (except maybe for the transliteration) --ValterVB (talk) 19:16, 14 April 2015 (UTC)[reply]

The original title is the same in all languages and it may differ from all local titles. --Jobu0101 (talk) 19:45, 14 April 2015 (UTC)[reply]

So title (P1476) is not what I'm looking for since this is used for the local titles. --Jobu0101 (talk) 19:48, 14 April 2015 (UTC)[reply]

title (P1476) is for the title of the film/book/etc. that is the subject of the article. For books each translation should have it's own item with it's own title (P1476) statement. Use has edition or translation (P747) to link to the item for the translated edition and edition or translation of (P629) to link back. For films the same should apply. Since each dubbed versions has it's own title, voice actors, release date etc. so each dubbed version should be a separate item.

If there is a good case to be made for an edition of a film having multiple official titles then title (P1476) can have multiple values. Some of these may be in the same language (e.g. "Star Wars" and "Star Wars: A New Hope"). Use the Label for unofficial local titles which don't appear on the film/book itself. Filceolaire (talk) 00:04, 15 April 2015 (UTC)[reply]

@Filceolaire: So then I misinterpreted the concept of title (P1476). For example it was wrong what I did in Q172241. But somehow nobody cares and reverts it. How can I find items which use title (P1476)? Query: claim[1476] does not work. --Jobu0101 (talk) 06:12, 15 April 2015 (UTC)[reply]

Jobu0101 not necessarily wrong - especially if we have not yet created a separate item for the german language version of that film - provided that german title has some official status. Once upon a time the german language version of a film would appear in german cinemas. Today we get a DVD with multiple soundtracks. Is that one edition with multiple sound tracks or separate editions sharing a disc? For me it comes down to the statements we want to state. If we aren't bothered about listing the voice actors then we can probably put off creating the extra items for now - especially as we have a statement that the original language of the work is English. Filceolaire (talk) 22:15, 15 April 2015 (UTC)[reply]

@Filceolaire: I don't like this mishmash. In future Wikidata will help us more and more to generate parts of Wikipedia articles and keep the information there up to date. Therefore it is necessary to receive the original title by a simple API query. This means if we allow the title (P1476) property to have several titles we have to create a new property for the original title or (what I think is the better approach) introduce some qualifier which marks the original title as an original one. --Jobu0101 (talk) 07:03, 16 April 2015 (UTC)[reply]

Jobu0101 I agree this is a bit of a mish mash. It is further confused by the fact that in many cases the original title is not the one by which the work is generally known - see Diary of Anne Frank (Q6911). There are movies where multiple language versions were prepared and released at the same time so it is hard to say which is the 'original' language of the work. I believe this is common for video games as well. How to express all these options in statements is not obvious. Filceolaire (talk) 05:01, 18 April 2015 (UTC)[reply]

@Filceolaire: So do you have recommendations on how to proceed? --Jobu0101 (talk) 14:56, 18 April 2015 (UTC)[reply]

I will look into this discussion a bit more in the next days. Just some things I want to mention. Let's say Korean movies usually have original titles written in Hangeul, the Korean alphabet. In the Wikipedia infoboxes, the title therefore is transcripted. So, somehow a property for the tracription of the original title is needed, I guess. It will be also the same with Japanese, Chinese or Russian movies. Furthermore, till about the 1980ies, Korean movie titles were expressed in Chinese characters (Hanja). The title still was Korean, of course, however, the used characters were Chinese characters. However, in the Korean Movie Database for example, the original titles are usually written in Hangeul. Maybe this could lead to confusion. My third note is that today, nearly all Korean movies have an "international title". Means: the producers decide additionally to the original title a title for international activities. However, let's say the movie later is released in Germany, too, it maybe doesn't choose the international title but just a third localized title. Maybe these "international titles" should be recognized with a property, too, or maybe not... --Christian140 (talk) 18:18, 20 April 2015 (UTC)[reply]

@Christian140, Jobu0101: You miss part of the concept: if the Korean movie is available in Germany, this often mean that the movie is translated. In this case we have a translated version and a new item is necessary like it is the case for translated books. For the question of transcription, we have to think to use a qualifier or to consider the different types of transcriptions as language in the language menu of the monolingual datatype. Snipre (talk) 16:00, 22 April 2015 (UTC)[reply]

What if the original movie is available in Germany but only with subtitles? Do we also have to create a new item in this case? And which item should be linked to German Wikipedia? The new item or the original one? --Jobu0101 (talk) 16:48, 22 April 2015 (UTC)[reply]

I don't quite get the concept either. In case of literary and audio works I see why the separate item may be necessary, but definitely not in the case of (audio)visual works. A painting is the same even if it gets a foreign language title when on display in another country. Films are often under a title in the local language(s) when they don't even have any dialogue, are screened in the original language, are only subtitled, or are on a DVD or blu-ray with five or more different language tracks. The title corresponds to a territory (distribution market) not to a certain dub. If we want to create items for dubs, that's fine (Star Wars: Episode V – The Empire Strikes Back (Q181795) has like four and a half Hungarian dubs anyway but were released on DVD only with subtitles until recently). But that is not a translation of the original work in a way the translation of a novel or a different language recording of a song is. – Máté (talk) 15:38, 4 January 2016 (UTC)[reply]

The label was changed in English to original title, and I reverted that. This property can be used for editions of a work, and each edition has a specific title, it is what it is, so the concept of "original title" is redundant or an anathema. The above conversation seems to confuse the overarching work, from the editions. The original work will have a title (an original title in a language), the editions will each have a title that may or may not replicate the original work. If something has been dubbed or has subtitles in a different language from the original, that probably should be called an edition of its own, so will have a title of its own for that edition (in my opinion). — billinghurst sDrewth 04:22, 14 January 2016 (UTC)[reply]

Still, it should be made a lot clearer that this is for the (work's or edition's) original language title only, and not for localized titles. If not in the label (although, that is the most effective), then in the description or in comments. – Máté (talk) 06:43, 14 January 2016 (UTC)[reply]

Adding name in another language

Why is it impossible to save the name of this property?--Redaktor (talk) 22:04, 18 May 2015 (UTC)[reply]

@Redaktor: What do you mean? --Jobu0101 (talk) 09:41, 9 June 2015 (UTC)[reply]

I mean that when I try to edit the title and save the translation into Yiddish (yi) I get a bunch of error messages. --Redaktor (talk) 15:13, 9 June 2015 (UTC)[reply]

@Redaktor: Same problem. I let a message on the dev team page here. Snipre (talk) 15:38, 9 June 2015 (UTC)[reply]

I think we had the same problem before. Not sure where the report went. Someone had added new constraints (system side) and not adapted all conflicting labels/descriptions. --- Jura 15:44, 9 June 2015 (UTC)[reply]

Änderung Originaltitel

@Succu: [2] Warum? Queryzo (talk) 14:40, 21 December 2015 (UTC)[reply]

The name of this property was the generic Title from the beginning as P357 (P357). Your problem is discussed above, I think. --Succu (talk) 14:59, 21 December 2015 (UTC)[reply]

The meaning of this property seems to have changed from title of a work [3] to original title. In some language, e.g., Danish, this change has not occurred. I do not see the reason for the change. — Finn Årup Nielsen (fnielsen) (talk) 00:21, 22 April 2016 (UTC)[reply]

The contraint of a single value is a recent invention [4]. I think we need to go back to title, - not original title. — Finn Årup Nielsen (fnielsen) (talk) 00:30, 22 April 2016 (UTC)[reply]

Why isnt Label sufficent for titles? Queryzo (talk) 06:36, 22 April 2016 (UTC)[reply]

@Fnielsen: Even in its title form it was always only meant for a single value. The reason why original was not in the property name, is because that could have been misleading for editions, theatrical productions, etc. the (single!) titles of which do not necessarily coincide with the work's original title. – Máté (talk) 07:24, 22 April 2016 (UTC)[reply]

Consider A nude woman doing her hair before a mirror (Q6644913). This may never have had an original title set by the artist. At one point is was referred to at "En nøgen fra ryggen set kvinde sætter sit hår foran et spejl" by the museum. Now the museum calls it "En nøgen kvinde sætter sit hår foran et spejl" and "A nude woman doing her hair before a mirror". These titles can be referenced (as they are) with authoritative sources. — Finn Årup Nielsen (fnielsen) (talk) 07:45, 22 April 2016 (UTC)[reply]

Qualifier place of publication (P291)

I've seen in Zootopia (Q15270647) that people had the clever idea to use title (P1476) with qualifier place of publication (P291) in order to represent the different titles of a film in the different countries. I think this is a good solution to the problem which was already discussed above by me over a year ago. The solution of creating a new item for each publication different from the original publication is too effortful so I think using place of publication (P291) as qualifier is a good alternative and should be suggested. Do you agree? --Jobu0101 (talk) 08:47, 28 July 2016 (UTC)[reply]

And how would you differentiate the one title which is its current scope? Because matching it with country of origin (P495) wouldn't yield the desired outcome all too often (see int'l co-productions). Probably we would manage better with a separate alternate title property which could be qualified by P291. – Máté (talk) 09:03, 28 July 2016 (UTC)[reply]

Good point. I would be okay with a new property for such non-original titles. Instead it would also possible to mark the original title with another qualifier and use value original title (Q1294573). --Jobu0101 (talk) 09:12, 28 July 2016 (UTC)[reply]

@Jobu0101, Máté: And how do you want to add the name of the people in case of dubbing ? Snipre (talk) 09:27, 28 July 2016 (UTC)[reply]

In that case you may create an individual item. But in most cases you simply want to add a title in another language. --Jobu0101 (talk) 09:30, 28 July 2016 (UTC)[reply]

Yeah, dub localizations deserve their own item, but many movies are not dubbed, yet marketed under different titles in other territories. – Máté (talk) 09:38, 28 July 2016 (UTC)[reply]

No, we can't work like that: we can't once it is an item because I add that data and once this is not an item because I don't add some data. Just try to think about query. With your proposition it is not possible to get all data with one query as data will be stored in different structures. No need of data if nobody can find it later because the storage of data is not uniform.

@Máté So the structure should be different according to the type of movie: all dubbed movies have to have their own item. Snipre (talk) 09:51, 28 July 2016 (UTC)[reply]

I don't know if there is a simple solution. The clearest would be to list titles of dubbed versions on the dub's item, and list the original version's alternate titles across territories on the main item; so yes two structures. However, (a) it is almost impossible to enforce, (b) it doesn't make queries any less complicated, (c) there are issues that complicate things. Issues like The Empires Strikes back has had three to five Hungarian dubs over the years (depending on how you're counting), under at least three somewhat different titles. Also, many movies are released both dubbed and not, often under the same foreign language title. There is a cinema in Budapest that shows films in original language, without any subtitles, yet lists them with their Hungarian title. Oftentimes a single dub is used in multiple territories (Slovakia often uses the Czech dub, and Belgium also borrows from France, and the Netherlands), and multiple language dubs may be used in certain territories. We may just assume, that the alternate title per territory and dubs' (spoken) titles are two different entities, which usually coincide, and record them twice when necessary. This would create duplication which is dreaded in databases, but it would be theoretically justifiable (they are different things, although they look the same). – Máté (talk) 10:12, 28 July 2016 (UTC)[reply]

I don't see an advantage of adding it to some other series of item that is difficult to scope.
--- Jura 10:16, 28 July 2016 (UTC)[reply]

@Máté: The question is not to know what happens in the reality, the question is to know what is done on WD. In WD depending on the level of information we want to add we have to define a structure and to keep that structure. What kind of movies do we have currently in WD ?

Original movies: for each movie, a new item
Dubbed movies: for each version (even in the same language), a new item, because we add the names of the voices. If in two different versions of dubbed movies in Hungarian the voices are changing we have to be able to distinguish the differences.
Subtitled movies: no consensus until now.

So at the end no need to have special properties for title. Snipre (talk) 14:17, 28 July 2016 (UTC)[reply]

@Jobu0101, Máté, Jura1: Better continue the discussion there Snipre (talk) 14:22, 28 July 2016 (UTC)[reply]

Your three types are a bit odd: many movies get dubbed and we include key information (such as title, available languages, release date) in the main item.
--- Jura 14:38, 28 July 2016 (UTC)[reply]

@Jura1: It is not odd: this is just how we have to work if we want to have one data structure. How do you want to feed data in a WP infobox with different ways to store data ? Just an example: if WP:fr wants to add in its movie infobox the publication date defined as the date where the French version was available in France, how do you proceed ? With my odd classification, one line of code is enough, with any other classification you have to test if the data is store in original version of the film or in specific item created for the French version of the movie. So 2 lines of code for every property. Snipre (talk) 15:13, 28 July 2016 (UTC)[reply]

It just not the way we work. If you need two lines of code in LUA, so be it.
--- Jura 15:16, 28 July 2016 (UTC)[reply]

Jura That's the way we work for books (see Wikidata:WikiProject_Books#Bibliographic_properties) and this the way we are taking for movies (see Wikidata_talk:WikiProject_Movies). It is a pity that WikiProject_Movies didn't propose a policy for dubbed movies earlier but due to WD development with more and more detailed information added in the items, we have to adapt. And don't expect to see more contributors from WPs joining the WD community if your only reaction to their remarks is "it is not our way to work". Snipre (talk) 15:55, 28 July 2016 (UTC)[reply]

Essentially that's what you are saying yourself, without trying to figure out how things work. Really, a pity. Maybe you want to re-read Máté's post. I don't see issues about having detailed items for dubbings or DVDs in libraries, but that's just a different question.
--- Jura 16:19, 28 July 2016 (UTC)[reply]

Jura My position about one unique structured way of storing data is not my personal opinion but the position of the Wikproject Books and of some members of the Wikiproject Movies, position defined in order to simplify data extraction. So now whats is your argumention apart "It just not the way we work" ? I have no problem with other position but this should based on more solid argumentation.

I read the comment of Máté and I don't take care of what happens in some cinemas of Hungary. I take care of what happens in WD. So what happens in WD ? The trend about dubbed movies is to add specific data like the ones presented there which means that you can't mix data from several dubbed movies in the same items. So why is it a problem to create in a systematic way items for each dubbed movie ? Why do we need to create multiple claims with long list of qualifiers and special properties when you can solve the problem by separating data in different items ? Snipre (talk) 17:43, 28 July 2016 (UTC)[reply]

Simply put: alternate titles (in a foreign language or not, since many films have different English, French, Spanish, or Portuguese titles in different territories) are not attributes of dubbed or subtitled versions. Those versions have their own spoken or written titles, but these alternate titles we are talking about, are not them. They are attributes of the original version. Offtopic: please, when writing in English, do not add a space before question marks, exclamation marks or colons. I know that is the correct French way, but makes it harder for me to read your text. – Máté (talk) 18:05, 28 July 2016 (UTC)[reply]

I tried an approach for Quebec titles of films. It could probably do for this too. Maybe the Q15270647-approach combined with ranks could work?
--- Jura 10:16, 28 July 2016 (UTC)[reply]

How to deal with multingual title ?

Hi,

I just stumble upon Gwerziou Breiz-Izel (Q20560253) whose title is « Gwerziou Breiz-Izel. Chants populaires de Basse-Bretagne », the first part being in Breton (Q12107) and the second one in French (Q150) (and almost a translation of the first part, but the first word is very specific and difficult to translate). How can I deal with that ? The only solution is can see right now is to split the title in two and to put each part separately... (which will break the single value constraint violations).

Cdlt, VIGNERON (talk) 15:56, 8 August 2016 (UTC)[reply]

Language code "mul"?
--- Jura 16:06, 8 August 2016 (UTC)[reply]

Isn't the second part better suited for subtitle (P1680) anyway? --Srittau (talk) 19:51, 8 August 2016 (UTC)[reply]

+1 Snipre (talk) 21:53, 8 August 2016 (UTC)[reply]

-1 --Succu (talk) 22:00, 8 August 2016 (UTC)[reply]

Jura1 'mul' is a solution but it's not really meningful or even useful...

Srittau maybe... maybe not... It doesn't seems quite right. Which part would be the subtitle ? the french or the breton ? For a French speaker, the breton part could be the subtitle (or more accurately a surtitle) ; for a Breton speaker, the French part could be the subtitle...

I've got other bilingual books in french and breton in the same situation...

Cdlt, VIGNERON (talk) 07:58, 9 August 2016 (UTC)[reply]

It's the applicable solution. If we would use fr or br, that would be inaccurate, incorrect or plain wrong, depending on the point of view.
--- Jura 09:01, 9 August 2016 (UTC)[reply]

@VIGNERON: I speak neither French nor Breton, so take everything I say with a big grain of salt. But looking at the way the cover is layed out here or here, I would probably model it as title/sub-title pair if it had an all-English like "Foobar: Popular songs from Basse-Bretagne". --Srittau (talk) 10:24, 9 August 2016 (UTC)[reply]

Hi! I am a new editor, and have just come a cross a number of multi-language works with a parallel title -- a publication in two or more languages. Same work, different language all in one. One is not a subtitle of the other. They carry equal "weight". This happens a great deal in Canadian publishing, as we are a bilingual nation -- and it must also happen in other mutli-lingual nations? Perhaps we should take the constraint off this for bilingual publications? Or at lesat note that there are times when the constraint "flag" must remain. Bibliojo (talk) 19:02, 12 June 2020 (UTC)[reply]

Ontology-alignment, how to associate compositions?

Exact matching with other (external) ontologies is possible, but for class specialization, by statement composition:

http://schema.org/CreativeWork + https://schema.org/name

...

--Krauss (talk) 11:10, 27 September 2017 (UTC)[reply]

Hi @Krauss:, can you give us an example or URL of what you mean by a "composition"? Then we can better answer your question. -- Thadguidry (talk) 16:28, 17 July 2021 (UTC)[reply]

Language in case of simple titles like "P" or "III"

What would be the correct language value in cases like III: The Ritual (Q46384970) or P (Q7121254), where the original title isn't in a specific language? --Kam Solusar (talk) 12:09, 22 December 2017 (UTC)[reply]

Please have a look at Help:Monolingual_text_languages#Special_language_codes Snipre (talk) 21:00, 22 December 2017 (UTC)[reply]

What happened to the type constraint?

I was wondering why this property on Mount Everest (Q513) didn't display a constraint violation. It appears that @Snipre: removed the constraint [5]. Why is that? Should this property be used on any type of item? --- Jura 10:08, 27 November 2018 (UTC)[reply]

@Jura: If you look at the list of constraint violations, perhaps you will see cases where the constraint is not correct: edition, scholarly article,... or just read the recommandations of Wikiproject Books for the use of title for edition, and finally just have a look at help:Sources where title can be used as qualifier for some references in items defined as instance of everything but not a work. If you add constraint and just let the number of violations increasing, the constraints is useless. Snipre (talk) 20:31, 27 November 2018 (UTC)[reply]

I restored the constraint, let's see how many turn up. There seems to have been some bug, so there was no recent update of the report.

If I found the correct version, there might just have been 8 violations in 20,000 uses.

The absence of a constraint leads people to use it in places where they shouldn't, e.g. Q153. Maybe some fine-tuning is still needed. --- Jura 13:57, 28 November 2018 (UTC)[reply]

It took some time to get the reports to work again. It's fine now. There seem to be some 2500 violations. Other than the items currently missing any P31, I can't really see any that should have this property. Maybe the constraint should even be more restrictive. --- Jura 15:35, 8 December 2018 (UTC)[reply]

Format constraint

Currently the constraint is [^<]* and has some 3160 violations. It finds things like   ([6]) and  ([7], but many false positives. Maybe we could try more specific ones.

There are probably other things that shouldn't be in there either.

If the data was added by bot, the bots should be adjusted too.

BTW, there is a proposal for an alternate title format at Wikidata:Property_proposal/title_in_TeX --- Jura 15:35, 8 December 2018 (UTC)[reply]

Something is wrong with the regex - disallows English title "Wow"

Hi there! The simple English title "Wow" now throws a format constraint warning, I'm guessing this was not the intention:

The value for title (Wow) should match “set English title in square brackets to deprecated rank and add original language title with normal rank” (regex: ^([^\[].+[^\]].|)$).

Will someone with the necessary regex-chops have a look? Moebeus (talk)

fixed Thanks for noticing. Should only have found Q30331181, not Q27771822. --- Jura 17:40, 20 December 2018 (UTC)[reply]

single value

I removed the "single-value" constraint because the same object can have different titles in different languages. Amqui (talk) 21:43, 16 January 2019 (UTC)[reply]

but it can only have one original title, exeptions are to be defined as exception to constraint (P2303). Queryzo (talk) 12:19, 17 January 2019 (UTC)[reply]

@Amqui: I agree with you. But read Wikidata:Project chat/Archive/2019/01#single-value constraint, non-mandatory, references, state it, module... all over again.... Xaris333 (talk) 20:54, 17 January 2019 (UTC)[reply]

I think in the discussion we addressed all possible issues. Do we have any new ones that came up? --- Jura 14:05, 26 January 2019 (UTC)[reply]

If the one work is published at the same time in two different languages, which is often the case with official documents from bilingual or multilingual countries, then both titles are "original titles". Amqui (talk) 20:51, 27 January 2019 (UTC)[reply]

Nothing currently prevents you from adding this. --- Jura 21:05, 27 January 2019 (UTC)[reply]

If this title property has one single preferred value being original title, why shouldn't a Wikidata item describing a film e.g. have a language specific title it has been published under in other countries? Because of redundancies with "label"? No! THIS is the title property for real life objects with a title. Its aim is different to that of the label of the Wikidata item which well freely may be translated from an other languages title and has no language qualifier describing it at all. If it has one single best value it is up to the software requesting more than that one to decide what to present. And this happens. -Vollbracht (talk) 21:17, 15 January 2023 (UTC)[reply]

How to use for paintings?

Currently the description for this property reads "published title of a work, such as a newspaper article, a literary work, a website, or a performance work". How to read this in the context of paintings? For contemporary art, artists assign titles on a regular basis. Clear cut to use title (P1476) here. But how to deal with (predominantly older) works for which the painter didn't assign a title? In these cases art historians generally assign a descriptive title. Just scroll through this list to see some examples or have a look at Mona Lisa (Q12418). I have been holding off using this property and telling other people the same because when to use it is unclear. It doesn't even show up on the most used painting properties yet although recent imports from Commons have increased the numbers. On a scale I see two ends:

Only use title if the artist assigned a title (preferable documented and sourced). Implication would be that we would remove the title statement from a lot of paintings
Use title for every painting. I can run a re-import of the collections and add it to probably 200.000 paintings. But wouldn't this a bit redundant to the labels?

Or maybe somewhere in between? Either way is fine with me, just want to have clarity so we can move on with this. @Marsupium, Jarekt:. Please ping anyone else you think is interested in this. Multichill (talk) 15:21, 31 March 2019 (UTC)[reply]

I would add that if we go with option 1 create new property for artwork titles. Labels in most cases for artworks contain artwork titles, but in many cases it is a description as in Belt buckle 5-7th century-MCAH Lausanne-On display 9b (Q29946907), and with labels you can not add a reference to state where you got title from. In most cases we do not know who assigned the title. For example in painting like Portrait of a gentleman with a falcon (Q20537391) we have reference [8], which lists a Title field as "Portrait of a gentleman with a falcon". We can deduce that this title probably did not come from the painter. However in case of The Starry Night (Q45585) (referenced by MOMA), van Gogh might have come up with this title, although probably not in English, or the title is the description of the painting that other created. References do not mention who assigned it. So I would stick to option 2 and try to only add titles we found somewhere. --Jarekt (talk) 16:03, 31 March 2019 (UTC)[reply]

So obviously what I've put togehter some while ago under Wikidata:WikiProject Visual arts/Item structure#Titles and labels doesn't reflect a common consensus. ;) I tend to support option 2 as well, but haven't thought it through completely. If we follow this we'll probably have to get rid of the single-value constraint (Q19474404) which has syntax clarification (P2916) "Non mandatory constraint. Add only title of work in its original language. Multilingual works may have several." since there isn't anything like an original language for many (later assigned) artwork titles.
If we don't use this property then we need another one for not artist-assigned titles as Jarekt said I think. Also here some interesting input in my eyes from other ontologies: CONA Editorial Guidelines, section 3.3 Titles and Names and less interesting, but still because it's a common standard: CIDOC CRM class E35 Title. --Marsupium (talk) 21:49, 31 March 2019 (UTC), 22:02, 31 March 2019 (UTC)[reply]
I like option 2 with the best practice of citing the source for the title (which for our purposes will usually be the holding repository, or a catalogue of some sort). - PKM (talk) 01:06, 1 April 2019 (UTC)[reply]

I can think of different types of titles: inscribed, used by the artist, by art critics in catalogs, by the museum. There is often no single title. You can use a qualifier, for example used by (P1535)=museum (Q33506) or painter (Q1028181). --Vriullop (talk) 09:42, 1 April 2019 (UTC)[reply]

I agree with PKM and would strive for sourcing as many statements to museum or publication/catalog sources as possible. Spinster 💬 17:21, 1 April 2019 (UTC)[reply]

The combination used by (P1535) and a reference seems like a good best practice. - PKM (talk) 18:43, 1 April 2019 (UTC)[reply]

WikiProject sum of all paintings has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

Everyone seems to be leaning towards option 2. No need to rush this so I plan to wait at least until the weekend before I do anything.to see if more people have an opinion on this. Multichill (talk) 15:54, 2 April 2019 (UTC)[reply]

Option 2 also, but « (preferable documented and sourced). » as qualifiers and references are what make the difference between a label and a statement. Cheers, VIGNERON (talk) 08:25, 5 April 2019 (UTC)[reply]

Ok it's weekend now. I added some title statements for works in the Metropolitan Museum of Art (Q160236) (English) and Rijksmuseum (Q190804) (Dutch and English). Adding multiple languages seems to trip a constraint single value constraint. Adding multiple titles (quite common with paintings) will also trip the constraint. I see plenty of discussion happened around this (see previous topic) and I'm not going to get involved. Currently importing paintings with Web umenia work ID (P5269). I added title to Wikidata:WikiProject sum of all paintings/Property statistics so we have a baseline and updated Wikidata:WikiProject sum of all paintings/Painting authority control properties because we'll be adding it as a constraint to properties. I'll re-run some of the import bots to add the missing titles and to have the properly sourced. Multichill (talk) 17:22, 5 April 2019 (UTC)[reply]

Ok, you wanted, titles, you got titles: Over 100.000 paintings now have a title statement (and I'm far from done importing). Full statistics at Wikidata:WikiProject sum of all paintings/Property statistics. Multichill (talk) 17:11, 8 April 2019 (UTC)[reply]

Thank you! --Marsupium (talk) 20:25, 8 April 2019 (UTC)[reply]

How to categorize the original title of an academic journal that changed names?

I have a few law reviews that have changed official names since they were originally created. When I add the former title with start and end dates I still get a conflict. Is there a good way to capture original title versus a current title in this case? – The preceding unsigned comment was added by Jdcera (talk • contribs) at 18:40, 20 May 2019‎ (UTC).[reply]

Changing constraint on Title

[The following is copied from Project Chat, where there was no opposition]

Since we now have "suggestion" constraints. I'd like to apply this to the single-value constraint on title (P1476), which specifically states that it's a non-mandatory constraint. Since this is so widely used, I want to confirm that there are no objections to adding suggestion constraint (Q62026391) as constraint status (P2316) on the single-value constraint for title (P1476). - PKM (talk) 21:51, 25 May 2019 (UTC)[reply]

@PKM: Agree! For my sake we could even delete that constraint. --Marsupium (talk) 17:41, 1 June 2019 (UTC)[reply]

+1 - PKM (talk) 20:07, 1 June 2019 (UTC)[reply]

Changed to "suggestion constraint" per no opposition. - PKM (talk) 18:34, 6 June 2019 (UTC)[reply]

New qualifiers for this property: title in HTML (P6833) and title in LaTeX (P6835)

title (P1476) only takes a string (and a language code) as input.

Sometimes, titles should include formatting that renders them differently.

The two qualifiers can include that:

title in HTML (P6833) can include some html tags: sub/sup/i
title in LaTeX (P6835) can take most LaTeX markup available at MediaWiki

If you want to make use of these qualifiers, you could check if one or the other is present and then replace the value of title (P1476) with the value of the qualifier. --- Jura 09:55, 12 June 2019 (UTC)[reply]

Constraint prohibiting '[' and ']' should be deprecated or modified

([^\[].+[^\]].|.{1,3}|) – this constraint should be deprecated. There are many titles with chemical names (such as [(1R,2S)-2-hydroxy-1-thiopropyl]phosphonate(2-) and many many others) that are perfectly fine. Or maybe this constraint should be modified to prohibit only titles with '[' as the first symbol and ']' as the last symbol in the title. Wostr (talk) 13:16, 18 June 2019 (UTC)[reply]

I agree with Wostr, it's also not unusual to insert fake title (title created by the cataloguer as the creator didn't gave a title and in this case, it is the first and last symbol, see [Daniel-Charles Trudaine] BOYER 2455 (Q108795224) for instance ; it's very common among library and museum catalog). Also, the current regex doesn't seem to exactly match the explanation. This constraint was added by Jura1 who is now gone, I suggest to just remove it. Cheers, VIGNERON en résidence (talk) 15:24, 8 August 2022 (UTC)[reply]

No comment for over a month, I deprecated it. Cheers, VIGNERON en résidence (talk) 13:00, 20 September 2022 (UTC)[reply]

I'm unable to edit the title. Why?

Tracked in Phabricator
Task T229604

I've discovered an error in the title of Symbiodinium genomes reveal adaptive evolution of functions related to coral-dinoflagellate symbiosis (Q57139220). The first word of the article's title, Symbiodinium, is missing from the title (P1476) property. I cannot add it. I add the term, the link to publish doesn't become an active link. I have rebooted my browser, closed the application, nothing works. Trilotat (talk) 09:39, 2 August 2019 (UTC)[reply]

Seems to be a general bug that's currently affecting various properties, see Wikidata:Project chat#Unit box not appearing?. --Kam Solusar (talk) 10:40, 2 August 2019 (UTC)[reply]

I don't know how it was resolved, but I can now fix the title in that specific item. I am not, however, making any general statement about the bug (beyond my skillset). Thank you. Trilotat (talk) 18:58, 2 August 2019 (UTC)[reply]

Allow multiple title for different language

A work may be published in multiple languages and more often may have official titles in another language, especially for countries that use more than one official language, therefore, a valid constraint can be language.

I agree with this stance. EDIT: I see the flag appearing when the constraint is broken is just a suggestion Ogoorcs (talk) 16:53, 26 October 2019 (UTC)[reply]

Bilingual title

How to use this if the title of a bug is bilingual or multilingual? --Juandev (talk) 12:45, 29 November 2019 (UTC)[reply]

@Juandev: You can enter “mul” as language to indicate multilinguality. —Tacsipacsi (talk) 20:16, 11 December 2019 (UTC)[reply]

WD property with exact match that is an owl:Class seems incorrect

Hi and thanks in advance: Statements for this property include the assertion that bf:Title (defined as an owl:class) is an exact match for this resource (defined here as an instance of various flavors of Wikidata property).

Without getting into details of OWL (which TBH I'm not terribly familiar with), it seems incorrect to state that an instance of a WD property can be an exact match with an external resource typed as an owl:class. But, am I missing something?

Perhaps this was a typo, and the intent was to assert an exact match with the BIBFRAME title property, not class?

Riesengrey (talk) 00:51, 30 December 2020 (UTC)[reply]

Hi, yes that was a typo. Looks like @Clements.UWLib: has fixed this already and I've thanked them! Thadguidry (talk) 16:45, 17 July 2021 (UTC)[reply]

Deletion of "equivalent property" http://schema.org/name

From the early stage https://www.wikidata.org/w/index.php?title=Property:P1476&oldid=354595783, this property has been marked equivalent with http://schema.org/name. However, the distinct-values constraint cause a conflict with the same property on name (P2561). name (P2561) is the more appropriate equivalent property of http://schema.org/name than title (P1476) because title (P1476) has more specific intension. So I deleted the statement. --KAMEDA, Akihiro (talk) 17:41, 18 September 2021 (UTC)[reply]

@KAMEDA, Akihiro: Thanks, so what I think you are saying is that title (P1476) is actually a subproperty of name (P2561) , but I don't see that statement made on title (P1476) and it probably should be? See my comment under https://www.wikidata.org/wiki/Property_talk:P2561#For_person_names_only --Thadguidry (talk) 18:47, 23 July 2022 (UTC)[reply]

Multiple titles

Follow-up on #Qualifier_place_of_publication_(P291)

See also Wikidata:Property proposal/alternative title

My interpretation of Wikidata:Property proposal/alternative title is that we can use more than one title (P1476) for the different regional titles − for data models that do not prescribe different items for different regional publications, which is the case for video games and anime/manga (and I believe for TV shows too, although I’m not involved in that field here so I might be mistaken).

The question is thus, which qualifiers to use, and which constraints to use.

Do we agree on place of publication (P291)? Or is valid in place (P3005) more appropriate? The former seems somewhat better to me, but the latter is already in allowed qualifiers constraint (Q21510851).
Addition: I have noticed applies to jurisdiction (P1001) used as well Jean-Fred (talk) 12:55, 25 July 2022 (UTC)[reply]
Is it fine to add (if need be) the above-decided qualifier to the single-best-value constraint (Q52060874)
The discussion on the declined proposal also suggests to use object of statement has role (P3831) with values such as localised title (Q107410900) or original title (Q1294573). Is that something we want? @Thadguidry: was not convinced as “localization is already implied with the language attribute” − but I don’t think that’s always the case: Blood Omen: Legacy of Kain (Q2294466) was called “Kain the Vampire” in Japan ; Pirate Radio (Q856805) was called “Good Morning England” in France, etc.

@Thadguidry, Shisma, UWashPrincipalCataloger:

Jean-Fred (talk) 17:53, 23 July 2022 (UTC)[reply]

1. A "titled" thing can certainly be titled differently for various reasons, including publishing for a different audience, culture, place. So yes agree that place of publication (P291) is very useful and you should add that as an allowed qualifiers.

2. The single-best-value constraint (as all constraints are) is just a guide or nudge. I think it's fine to add it, but note that it pushes users to actually add a preferred rank (that might not be wise in the case of "titled" things because the "best" differs by audience, culture, region, etc. Ranking is a way to get consensus, but "titled" things are best left without preferred ranks. Instead queries can simply be re-written to focus on an audience, culture, or region... as long as we have good qualifiers added like place of publication (P291) etc. So again, my vote is YES to adding good useful qualifiers to title (P1476) statements as appropriate. Now, I'm not entirely against ranks on title (P1476) statements because we do now have the qualifier reason for preferred rank (P7452) to help explain why a particular title might be the preferred title for a thing for everyone in the world.

3. I think your examples of localised title and original titles all demonstrate a nice and kind use of place of publication (P291) since you say "in" <a Place> in all examples. Are there other qualifiers missing for a "titled" thing? titled WHO publisher (P123) and author (P50) and more, WHEN publication date (P577) and announcement date (P6949) and refine date (P4241), WHERE place of publication (P291) and valid in place (P3005), HOW language of work or name (P407) and perhaps title in LaTeX (P6835) title in HTML (P6833) for fancy appropriate rendering and sourcing circumstances (P1480) and possibly unabbreviated text (P7008) to account for expanded title text as necessary (I.E. the full title without abbrevations as sometimes supplied by publishers or authors) and my personal favorite that is very useful for Anime titles at times is Hanyu Pinyin transliteration (P1721) etc., what else? Thadguidry (talk) 19:40, 23 July 2022 (UTC)[reply]

in most cases place of publication (P291) is most appropreate since the title goes hand in hand with a release event in a specific place and time publication date (P577). I think those two should be valid qualifiers – Shisma (talk) 20:02, 23 July 2022 (UTC)[reply]

I am a bit confused by all of this. Are we talking about titles by which a work is known by, or titles by which a specific version, edition, etc. (manifestation in IFLA LRM/FRBR) is known by? Manifestations of the English expression of the same work published with different titles in the UK and the US should have separate items (they will have different publishers, place of publication, ISBN, cover art, etc.). When you are referring to a titled thing, are you referring to the abstract work concept or a particular published edition? UWashPrincipalCataloger (talk) 23:01, 23 July 2022 (UTC)[reply]
- a titled thing... see the description way above for this property... "published name of a work, such as a newspaper article, a literary work, piece of music, a website, or a performance work". I just finished a small poem, I titled it, "Why I love Wikidata", it has 3 stanzas. I had my wife translate the title into Chinese.
instance of: poem author: Thad Guidry [ title: Why I love Wikidata language: English place of publication: Texas, United States of America ] [ title: 为什么我爱 Wikidata language: Chinese place of publication: China ] original title: Why to love Wikidata
Thadguidry (talk) 00:19, 24 July 2022 (UTC)[reply]

Why make a 2nd instance of that poem, if that's all I have to say about it? There is no need for only that bit of data (metadata). Until...However, if the poem gets translated and published with a different title in a different country, then it's better to create a 2nd item in Wikidata for an edition to hold all the metadata (qualifiers) that can all be different than the original creation. The hard and fast rule in Wikidata is that, make a new item if it is "not the same thing". The problem often arises to categorize something as "it's the same thing, or it's not". We have already previously clarified that versions, editions, etc. are "not the same thing" (for simplicity of data modeling in Wikidata...when someone wants to see all editions, all translations, all publications of my poem...that's where querying comes into play, which can handle gathering up all the items that are not the same thing, but have relationships in different ways. --Thadguidry (talk) 00:44, 24 July 2022 (UTC)[reply]

- @UWashPrincipalCataloger I think the difficulty in our data model comes into play when folks think sometimes that "it's the same thing" and try to shove many statements under 1 item, when in fact, some of the statements are truly about "a different thing", but no one made a new item for it yet. Does that answer most of your questions ? --Thadguidry (talk) 00:34, 24 July 2022 (UTC)[reply]
- @Thadguidry Yes, it helps a lot. To me there is a difference between a title in another language that simply refers to a work (for example the use of "War and Peace" to refer to Tolstoy's work) and a title that refers to a translation of that work, which will have been published separately and would be "a different thing." The English title for Война и миръ might be the same string that refers to either the work or a translation of it, so it could be a label on the work item and the English edition items. UWashPrincipalCataloger (talk) 02:25, 24 July 2022 (UTC)[reply]
  @UWashPrincipalCataloger: I think the difference you make is an interesting one ; although I am not sure I fully understand it: don’t we refer “informally” to Tolstoy work as "War and Peace", because there are published translations of this work under that title?

- However, even in the second case of a "properly published translated work" some data-models do not make new items for these translations/versions/editions: we have a single item about, say, Tomb Raider: The Last Revelation (Q668568), although it’s been published on 4 platforms, in over 10 territories, under at least 7 different titles − yet we have only one item for it (while we could have up to two dozens). This is the data-model we are currently following for video games, which we might change in the future (but there are lots of open questions on how we would do that, which I won’t bore everyone with here :) )
  
  Jean-Fred (talk) 12:55, 25 July 2022 (UTC)[reply]
  - @Jean-Frédéric: Perhaps in the case of Tolstoy's works, which have been translated into English many times, yes. I've seen many Hebrew novels in my library that have an additional page with a title in English and a romanization of the author's name. They have never been translated into English. If someone writes literary criticism or a book review in English of that novel, they will most likely refer to it using the English title. So this is a clear case where the English title is only referring to a work. UWashPrincipalCataloger (talk) 18:45, 25 July 2022 (UTC)[reply]
    Thanks for explaining, now I understand the difference. Jean-Fred (talk) 08:33, 19 September 2022 (UTC)[reply]
@Thadguidry: Re:constraint: I explained myself badly, I meant to add place of publication (P291) as separator (P4155) to the single-value-constraint (or single-best-value-constraint, I don’t mind either way), so that a warning would not be raised. (I do agree ranks can be a bit of a can of worms here!) Jean-Fred (talk) 12:55, 25 July 2022 (UTC)[reply]
As for additional qualifiers, I guess the whole suite of transliteration properties, listed at Property:P2440#P1659 (also potentially name in kana (P1814)? not sure about that one) Jean-Fred (talk) 12:55, 25 July 2022 (UTC)[reply]

I went ahead and added place of publication (P291) as accepted qualifier and as separator (P4155) to the single-best-value-constraint. Jean-Fred (talk) 08:33, 19 September 2022 (UTC)[reply]

New qualifiers for this property: point in time (P585)

Any reason not to? It's sometimes the case that an event has a different title every year. Pharos (talk) 20:44, 16 August 2022 (UTC)[reply]

Search by title

https://query.wikidata.org/#SELECT%20%3Ftitle%20%3Fstatement%20WHERE%7B%0A%20%3Fstatement%20prov%3AwasDerivedFrom%20%3Fref%20.%0A%20%3Fref%20pr%3AP1476%20%3Ftitle%20.%0A%20FILTER%28%0A%20%20CONTAINS%28%3Ftitle%2C%22International%20Numbering%20Resources%20Database%22%29%0A%20%29%0A%20%7D

Maybe there is a more efficient way to do this. --User123o987name (talk) 22:09, 6 November 2022 (UTC)[reply]

How should this property be used?

I've had a conversation on my talk page with user @Vollbracht on how this property's supposed to be used on filmrelated items. As I've understood it, the property is only supposed to contain the original title. But they seem not to agree and argues that the property should contain all titles in all languages the work has been translated to. So I'm writing here for clarification on how the property's actually supposed to be used. Should it only contain the original title or alla titles? Sabelöga (talk) 18:01, 17 January 2023 (UTC)[reply]

Following reasons are given:

title (P1476) is Wikidata property (P1687) of title (Q783521) AND original title (Q1294573).
title (P1476) may have qualifiers. Label may not.
Value of title (P1476) can be marked as original title (Q1294573) by setting object of statement has role (P3831) qualifier to this value. Label may not.
Lable may reflect the original title, the local title, the wiki page name or whatever. It's a property of the Wikidata item. Every Wikidata item has one.
title (P1476) is a property for Wikidata items describing real life objects that have a title.
title (P1476) may have a reference such as stated in (P248). Label may not.
title (P1476) may have a ranking (ensuring single best value). Label may not.
If a database design would hinder using title (P1476) for other but original title (Q1294573)
- even local language versions would be bound to this.
- there would be no means of connecting external identifiers to both: original and local language version.
I do need it now (with all these features) and I will need it in future for various titles with various qualifiers.

Please do not try to argue with workarounds that may solve problems resulting of binding title (P1476) to original title (Q1294573) only. Give good reasons for doing this instead. Vollbracht (talk) 01:07, 18 January 2023 (UTC)[reply]

Please don't argue with redundancy. If label and title happen to be simmilar we have not lost anything. (...but a few bytes? No! Same values for different properties are different answers for different questions.) --Vollbracht (talk) 01:24, 18 January 2023 (UTC)[reply]

I also find this very confusing. Especially since I think that this property was originally only original title. It would be redundant to the label. And why not argue with that? In a database, these few bytes definitely matter. There should be no redundancy in a database, however, wikidata creates more and more redundancies. Actually, I don't understand Vollbracht's reasons. These all would be solved more neatly when title (P1476) is simply used as original title only. --Christian140 (talk) 06:58, 19 January 2023 (UTC)[reply]

Precisely my thought too. We already use labels for this very function, let's not have more redundancy. Sabelöga (talk) 01:43, 24 January 2023 (UTC)[reply]

The label does not always correspond to an official title in this language. Sometimes there is no title in a language and the label is a transcription of the original title. See the English labels of Vashe zdorove! (Q4105520) or Murzilka na sputnike (Q4308015), for instance. I could not find any policy or recommendation that says that the labels should only hold the official title and that there shouldn't be any label for languages without an official title or version of this item. Currently, Wikidata:WikiProject_Movies/Properties#Label even says "If no working title is available, "untitled <name of director> film" can do"

Anyway, if there should be the intention to restrict this property to original titles (again), participants of previous discussions should probably get pinged. - Valentina.Anitnelav (talk) 08:57, 24 January 2023 (UTC)[reply]

According to the discussion Multiple titles (two sections above) and the (declined) property proposal Wikidata:Property_proposal/alternative_title multiple titles are allowed. The original title should get a preferred rank and the others a normal one. This is also reflected in the current property constraints (single best value constraint, not a single value constraint). - Valentina.Anitnelav (talk) 14:44, 19 January 2023 (UTC)[reply]

Is there an example of a film or novel that uses title (P1476) and original title (Q1294573) and intended? --Christian140 (talk) 06:41, 23 January 2023 (UTC)[reply]

There is The Lord of the Rings (Q15228) and Back to the Future (Q91540). Here is a list of items using title (P1476) qualified with original title (Q1294573) (either via "object has role" or "reason for preferred rank"): query - Valentina.Anitnelav (talk) 10:42, 23 January 2023 (UTC)[reply]

Correct @Valentina.Anitnelav, the thought of "original" is actually captured already by the Wikidata Qualifier system to capture a start or end date or using other qualifiers like object of statement has role (P3831) = original title (Q1294573) on a property value statement. Sometimes a start or end date for the usage of a title is unknown, but the person has references or is knowledgeable in facts that a title is indeed an "original title" (I.E. the first title conceived for a Thing).

The current best practice to capture "original" is by using Qualifiers.

Ranking is how Wikidata handles "consensus opinions over time, while not losing their history, and allowing for contemporary thought or scientific consensus." Qualifiers are how Wikidata handles "value changes over time (or in the case of "original", the first value in its history), while not losing its history". Qualifiers are indeed the way that someone should capture an "original" value for any property. I won't suggest WHICH particular qualifiers are well suited to capture "original" since this might vary by domain or source data available. For questions on which qualifiers are best to use to capture "original", I would suggest looking at the set of available qualifiers or asking other users in Project Chat.

So, for anyone still wondering how to capture an "original title" through usage of title (P1476) Please consult the Help:Qualifiers and perhaps the Help:Ranking pages. -- Thadguidry (talk) 15:51, 24 January 2023 (UTC)[reply]

What language is the right?

Which language to use if the original title is obviously made up of English words but it is the original title of a German only television film? In that case it is the German title, but the title doesn't contain German words. You know, what I mean? Jobu0101 (talk) 22:37, 2 March 2023 (UTC)[reply]

Do you have an example? LydiaPintscher (talk) 17:37, 3 March 2023 (UTC)[reply]

@LydiaPintscher: Sure, see Tatort: Flash (Q111893885), Tatort: Dreams (Q108752140) or most recently Tatort: MagicMom (Q116414339). --Jobu0101 (talk) 18:05, 6 March 2023 (UTC)[reply]

I would surely use English. It's a frequent case when the title has different language than the work itself. --Infovarius (talk) 18:49, 6 March 2023 (UTC)[reply]

@Infovarius: Even if there exists another English title for the English speaking viewers? This is very common in Germany with movie titles of American movies. The Germans don't take the original title but also no translation, they use another English title. --Jobu0101 (talk) 23:37, 7 March 2023 (UTC)[reply]

Hm, interesting. And I think yes even in this case. With appropriate distinguishing qualifiers (like applies to part, aspect, or form (P518)). --Infovarius (talk) 19:24, 9 March 2023 (UTC)[reply]

@Infovarius: Can you give us an example with appropriate distinguishing qualifiers? Here are items to do so: The King's Man (Q61633664), Second Act (Q48672735), Creed II (Q50233658), The LEGO Movie 2: The Second Part (Q23796643), Happy Death Day 2U (Q52715747). All those movies have German titles in English language which are different from the English original titles. --Jobu0101 (talk) 07:13, 16 March 2023 (UTC)[reply]

@Jobu0101: I believe that valid in place (P3005) is ideal for this case. Unfortunately I can't find the item for "Spanish-speaking America". --Infovarius (talk) 12:48, 18 March 2023 (UTC)[reply]

I agree with Infovarius (use English with a qualifier). I think this should also apply to English titles in non-latin scripts like titles of Korean movies using English words but Korean script (there has been a short discussion on ProjectChat about it: Wikidata:Project_chat/Archive/2021/11#P1476_(title)).

I often ask myself what to do with titles just containing a given name (e.g Hanna (Q170268)): which language tag should they get? mul? - Valentina.Anitnelav (talk) 13:06, 10 March 2023 (UTC)[reply]

I would say - use the default (main?) language of the work. If there are several such - mul is a good choice. --Infovarius (talk) 22:04, 11 March 2023 (UTC)[reply]

Multiple titles

I have deprecated the single value constraint. Most of the works I add are mutilingual and have titles in multiple languages. I am talking about individual editions, not films distributed in several countries. The number of exceptions to this constraint would have to be in at least the thousands if it continues to be in place, which is not sustainable. عُثمان (talk) 17:18, 27 April 2023 (UTC)[reply]

Title that is just an Italian artist's name

I have several books with titles that just consist of the artist's name, and the artists are Italian. Examples: Andrea Mantegna, Fra Filippo Lippi, Jacopo del Sellaio, Sandro Botticelli. Would the language of these titles be Italian? The books themselves are written in German and English. Thanks for your help! Aap1890 (talk) 17:56, 30 November 2023 (UTC)[reply]

My intuition tells me that the title should be the language of the book and not of the person. Amir E. Aharoni {{🌎🌍🌏}} talk 15:37, 24 January 2024 (UTC)[reply]

Title case capitalization style

How should Wikidata model differences between sources in capitalization style for values of title (P1476)? I'm talking about, eg. "Sentence case" vs. "Title Case".

Options:

Wikidata picks a preferred capitalization style format, and normalizes source information to match this preference.
Wikidata matches source capitalization style format unless sources differ in capitalization only, in which case only one value is included (hopefully normalized). The sources cited for this value may differ in capitalization from the value they are cited to support, and may (optionally?) note their value in subject named as (P1810) as a reference qualifier.
Wikidata mirrors sources exactly, producing multiple values for title (P1476) which differ only in capitalization.

Which of these options for title (P1476) on Wikidata do we prefer? Are there other options I'm not considering?

Option 2 seems like the least likely to arouse opposition here on Wikidata, because option 1 involves significant change, and option 3 feels cluttered and involves largely duplicate data being stored in Wikidata.

In the short run, for many items, option 2 mirrors sources and can ignore capitalization issues, but in the long run it will surely lead to normalization of most titles. Imagine Wikidata uses two databases for titles, one of which normalizes titles while another reproduces them as printed (or chooses a different normalization scheme). The only thing preventing conflict between these two sources is the incompleteness of their catalogues. As they become more complete over time, every item will have a title conflict. This will happen even faster if the first database uses Wikidata itself as a source. Voila! Every item the external database mirrors is now normalized in Wikidata too.

I'm not sure if this discrepancy between short and long-term values is a serious problem or not. However, I prefer the stability of Wikidata values, so I'd advocate for option 1 at least for periodical titles as soon as a high quality source has a normalization scheme we can follow. I'm not sure that's the case at this time. If we do, in fact, use subject named as (P1810) as a reference qualifier, then errors in automatic capitalization changes could be fairly easily remedied after the fact merely by querying Wikidata's contents without looking into item edit histories.

Both options 1 and 2 would benefit from a standard normalization convention here on Wikidata. I note that ISSN International Centre (Q12131129) leaves this decision up to national organizations which can presumably consider local conventions as well as language and script issues. I don't expect this discussion can consider all languages and scripts. If we don't want option 3, should we use "Sentence case" or "Title Case"? Daask (talk) 19:43, 6 November 2024 (UTC)[reply]

I’d definitely avoid option 1, and prefer option 3 to option 2 – Wikidata collects statements, not facts. Option 3 would also avoid the problem of what to choose, which cannot be answered universally, for all languages: for example, the correct answer for English is likely title case; for French probably sentence case (French tends to prefer sentence case to title case in my experience); for Hungarian “it depends” – according to Q468908, “permanent titles” like those of journals should use title case, but “custom titles” like those of individual journal articles or of books should use sentence case. —Tacsipacsi (talk) 18:49, 24 November 2024 (UTC)[reply]

I was prompted to raise this question largely for my work on periodicals, especially academic journals. I agree that title case is the norm for academic journals in English. However, I noticed that ISSN Portal provides their titles in sentence case, at least for English-language journals published in the United States. If we choose option 3, because external databases are not consistent whether to include the word "The" in the title, The New England Journal of Medicine (Q582728) will probably have four values of title (P1476) (in sentence case and title case, with and without "The"). Daask (talk) 16:11, 25 November 2024 (UTC)[reply]

I went ahead and implemented option 3 at Q582728#P1476 as an example. The property now has 5 values. Daask (talk) 19:06, 25 November 2024 (UTC)[reply]

Property talk:P1476

Contents

Documentation

Discussion

Any allowances for titles with no language?

Language part of the title

Original title (originally asked in Wikidata:Project chat)

Adding name in another language

Änderung Originaltitel

Qualifier place of publication (P291)

How to deal with multingual title ?

Ontology-alignment, how to associate compositions?

Language in case of simple titles like "P" or "III"

What happened to the type constraint?

Format constraint

Something is wrong with the regex - disallows English title "Wow"

single value

How to use for paintings?

How to categorize the original title of an academic journal that changed names?

Changing constraint on Title

New qualifiers for this property: title in HTML (P6833) and title in LaTeX (P6835)

Constraint prohibiting '[' and ']' should be deprecated or modified

I'm unable to edit the title. Why?

Allow multiple title for different language

Bilingual title

WD property with exact match that is an owl:Class seems incorrect

Deletion of "equivalent property" http://schema.org/name

Multiple titles

New qualifiers for this property: point in time (P585)

Search by title

How should this property be used?

What language is the right?

Multiple titles

Title that is just an Italian artist's name

Title case capitalization style

Navigation menu