Property talk:P7975

From Wikidata
Jump to navigation Jump to search

Documentation

Filmfront film ID (archived)
identifiers for films in the Filmfront, a Norwegian movie database
Applicable "stated in" valueFilmfront (Q5449120)
Has qualitynumeric identifier (Q93868746)
Data typeExternal identifier
Domainaudiovisual work (Q2431196)
Allowed values^[1-9]\d{0,6}$
ExampleRadio 2 (Q11996817)6402
Jul i Blåfjell (Q19376541)4595
Amalies jul (Q11957654)6816
Star Wars: Episode III – Revenge of the Sith (Q42051)2773
Free Jimmy (Q1755719)4350
The Big One (Q1198825)3844
Sourcehttps://filmfront.no
Formatter URLhttps://web.archive.org/web/0/https://filmfront.no/utgivelse/$1
Related to country Norway (Q20) (See 104 others)
See alsoFilmfront person ID (archived) (P8037), Filmweb.no film ID (P12222)
Lists
Proposal discussionProposal discussion
Current uses
Total21,232
Main statement21,216>99.9% of uses
Qualifier6<0.1% of uses
Reference10<0.1% of uses
Search for values
[create Create a translatable help page (preferably in English) for this property to be included here]
Type “audiovisual work (Q2431196): item must contain property “instance of (P31)” with classes “audiovisual work (Q2431196)” or their subclasses (defined using subclass of (P279)). (Help)
List of violations of this constraint: Database reports/Constraint violations/P7975#Type Q2431196, hourly updated report, SPARQL
Distinct values: this property likely contains a value that is different from all other items. (Help)
List of violations of this constraint: Database reports/Constraint violations/P7975#Unique value, hourly updated report, SPARQL (every item), SPARQL (by value)
Format “[1-9]\d{0,6}: value must be formatted using this pattern (PCRE syntax). (Help)
List of violations of this constraint: Database reports/Constraint violations/P7975#Format, hourly updated report, SPARQL
Single value: this property generally contains a single value. (Help)
List of violations of this constraint: Database reports/Constraint violations/P7975#Single value, hourly updated report, SPARQL
Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P7975#Entity types
Scope is as main value (Q54828448), as reference (Q54828450): the property must be used by specified way only (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P7975#Scope, SPARQL
Label required in languages: nb: Entities using this property should have labels in one of the following languages: nb (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P7975#Label in 'nb' language, search, SPARQL
Label required in languages: nn: Entities using this property should have labels in one of the following languages: nn (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P7975#Label in 'nn' language, search, SPARQL
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

RegEx changed without reason

[edit]

Dear Vera,
Why do you want to absolutely change RegEx for the second time? I see no violation. In the declarations (therefore not in the constraints), format as a regular expression (P1793) makes the link only with regex101.com. The user can test with a finite expression. In the PCRE syntax, ^ starts capturing and $ closes capturing. Thank you for your understanding. Regards. —Eihel (talk) 14:19, 18 March 2020 (UTC)[reply]

the ^ and $ are completely superfluous since the regex needs to match the entire string already. None of the property examples have it and it's not needed here either. 1Veertje (talk) 15:46, 18 March 2020 (UTC)[reply]
If you are talking about other properties: FALSE. There are other Properties with this notation. For the superfluous side, I already explained the reason to you in my first intervention. If you had been a little curious, you would have clicked on a RegEx link.
Explanation: A hypotetic identifier is tested for this property, 1234567. Without ^ and $, there are 2 matches. With ^, only 123456 is retained. With $, only 234567 is retained. With these anchors, 1234567 is not a valid identifier. For information, there are also properties with a RegEx containing "backtracks". In addition, P1793 in the Statements has no effect on the property in production. In WD, the RegEx in the constraints are /contained/ (as in GREL), but there are different "flavors" in Wikidata. If you think these anchors are superfluous and I give you a reason, where is your problem? This is your third modification since last night and your first modification was already wrong. —Eihel (talk) 18:59, 18 March 2020 (UTC)[reply]