Property talk:P996

Active discussions

Documentation

document file on Wikimedia Commons
file on Wikimedia Commons related to the content of the source/book/report
DescriptionFile related to the content of the source/book/report
Representsfacsimile (Q194070)
Data typeCommons media file
Domain
According to this template: source and books/reports, also maybe for Wikisource-related material
According to statements in the property:
version, edition, or translation (Q3331189), written work (Q47461344) or volume (Q1238720)
When possible, data should only be stored as statements
Allowed values
According to this template: files on Commons, which contains the text, i.e. not the book-cover or an image of the author
According to statements in the property:
(?i)(.+\.(djvu|pdf|png|jpg|jpeg|tif|tiff|gif|webm)|)
When possible, data should only be stored as statements
ExampleMarch Constitution of Poland (Q2535435)Konstytucja Marcowa (1921).pdf
demographics of Sweden (Q522328)Statistisk tidskrift 1903 h 129-130.pdf
Formatter URLhttps://commons.wikimedia.org/wiki/File:$1
Embed URLhttps://commons.wikimedia.org/wiki/File:$1
See alsoimage (P18), sheet music (P3030), video (P10), digital representation of (P6243), Wikisource index page (P1957), full work available at URL (P953)
Lists
Proposal discussionProposal discussion
Current uses
Total155,219
Main statement154,41299.5% of uses
Qualifier7190.5% of uses
Reference88<0.1% of uses
[create Create a translatable help page (preferably in English) for this property to be included here]
  Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P996#type Q3331189, Q47461344, Q1238720, SPARQL, SPARQL (new)
 
Link to Commons namespace “File”: this property should contain a well-formed link to an existing page on Wikimedia Commons. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P996#Commons link, SPARQL (new)
 
Format “(?i)(.+\.(djvu|pdf|png|jpg|jpeg|tif|tiff|gif|webm)|): value must be formatted using this pattern (PCRE syntax). (Help)
List of this constraint violations: Database reports/Constraint violations/P996#Format, hourly updated report, SPARQL, SPARQL (new)
 
Conflicts with “instance of (P31): film (Q11424): this property must not be used with the listed properties and values. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P996#Conflicts with P31, SPARQL, SPARQL (new)

Commons linkEdit

Can't we have just a standard interwiki link to Commons instead of this property? --DixonD (talk) 09:47, 20 November 2013 (UTC)

I also proposed this as a help for sources. I cannot see that being solved by interwikilinks. -- Lavallen (talk) 16:26, 20 November 2013 (UTC)

WebmEdit

I added webm to the allow file types, since I think this property also makes sense in case for links to Public Domain movies, for example in the case of Sherlock Holmes and the Secret Weapon (Q255314). --Srittau (talk) 15:32, 3 January 2016 (UTC)

As I just discovered video (P10), I think this property fits better in cases, where the Commons-Link contains the whole subject. video (P10) is more like image (P18), e.g. a video "about" t he subject, not the subject itself. --Srittau (talk) 15:36, 3 January 2016 (UTC)
  • Also, for sheet music, in the meantime, there is sheet music (P3030). I removed the alias "sheet music" from this property. --- Jura 12:46, 10 March 2019 (UTC)

Type constraintEdit

I also changed the type constraint from document (Q49848) to work (Q386724). As I understand it, the former is for a particular "document", while the latter is for the theoretical concept. If you have a look at the constraint violations, you see many items that should be ok, but aren't, because they are "only" a work (Q386724). --Srittau (talk) 15:55, 3 January 2016 (UTC)

Renaming for non scanned files proposedEdit

I proposed the renaming for use this property for text that are not scanned at Contact the development team  – The preceding unsigned comment was added by GPSLeo (talk • contribs) at 19:39, January 28, 2019‎ (UTC).

There's actually no need for developers to get involved. But we should contact users of this property and those involved in earlier property discussions. @Lavallen, Micru, Danrok: any opinions on this change? I would suggest perhaps the new name "content file on Wikimedia Commons? ArthurPSmith (talk) 21:13, 28 January 2019 (UTC)
There is a template says "This entity (P996) is used by Wikimedia's setting of Wikidata. Please contact the development team or file a bug on Phabricator before big changes (renaming, deletion, merging, etc.)" so I just did it. --GPSLeo (talk) 21:37, 28 January 2019 (UTC)
Ah, good point, I stand corrected! ArthurPSmith (talk) 13:00, 29 January 2019 (UTC)
The problem is that the label and the description have been translated into many languages, so in order to make a clean renaming all those labels and descriptions should be removed so that editors can enter new ones according to the new label. It seems like a big change, so I guess it needs broader discussion before proceeding (posting on relevant wikiprojects and on the project chat). I don't know if there are other factors to consider besides of what I mentioned.--Micru (talk) 21:52, 28 January 2019 (UTC)
No one was against the renaming, so we can rename and redefine it now? --GPSLeo (talk)
Removed the Labels and Descriptions for a clean redefinition. Adding them new in the languages is needed now. --GPSLeo (talk) 14:35, 12 February 2019 (UTC)
Maybe "full text file" would be better. Commons includes also data files and image files that shouldn't use this. --- Jura 16:16, 12 February 2019 (UTC)
I thought that first too, but then I saw "full movie" as an alias. --GPSLeo (talk) 18:26, 12 February 2019 (UTC)
I just removed those aliases. Per #Webm, I had added a constraint to exclude films [1]. I think there were only three uses. --- Jura 17:56, 15 February 2019 (UTC)
"Full text file" implies a TXT format, but many of these are DjVu or PDF. We need a label that doesn't create confusion about the file format. --EncycloPetey (talk) 23:50, 24 February 2019 (UTC)
Then call it "file of the full text"? --GPSLeo (talk) 13:11, 25 February 2019 (UTC)
If all the files were text, that might make sense, but some are printed music or mostly images. These files are often scans of books, whether books in text, books of artwork, or books with musical scores. And many are not books, but may be scholarly articles, historical photographs, or other works. A scan of a photograph collection or a musical score is not "the full text". --EncycloPetey (talk) 15:06, 25 February 2019 (UTC)
Then "File on commons that is not a P10/P18/P51"? We just need to to the "scanned" out of the label and description. --GPSLeo (talk) 15:14, 25 February 2019 (UTC)
Why? There is no explanation why the change is needed. --EncycloPetey (talk) 01:15, 26 February 2019 (UTC)
That was decided here: Wikidata:Property proposal/full work on commons --GPSLeo (talk) 09:09, 26 February 2019 (UTC)
Why not simply add "native digital text file" as an alias? --EncycloPetey (talk) 05:00, 28 February 2019 (UTC)
There are already aliases like "full text", "document file on Wikimedia Commons" or "Volltext" in German. But if the label excludes a usage an alias can not include it. --GPSLeo (talk) 11:20, 28 February 2019 (UTC)
Would "digital document file on Commons" include everything needed, while still excluding what needs to be excluded? We unfortunately do not have a full description of what kinds of files are to be excluded from this property. --EncycloPetey (talk) 01:45, 1 March 2019 (UTC)
I think that is good. --GPSLeo (talk) 09:43, 1 March 2019 (UTC)
I don't think "text" implies a specific file format, at least for non-programmers. In any case, I don't think this property should be used for images (there is P18). Don't we also have another property for musical scores? --- Jura 11:25, 3 March 2019 (UTC)
I associate text with "TXT", while is a file format. We don't have a separate property when the file is a scan of a printed book. Wikisource includes books with printed text, books with images, books with musical scores, and books that are combinations of these formats. It would be counterproductive to have different properties for each kind of book scan based on the content of each book. --EncycloPetey (talk) 16:06, 3 March 2019 (UTC)

Generalize scope to "digital representation"Edit

I am wondering if the "scanned" part of this property an integral part of how it is used? I would like to be able to use this property for digitized archival holdings. Not all of these have been technically digitized through the use of a scanner—or, more often, the digitization method is not explicitly stated in the data—but the important concept is that they are an exact digital representation. Currently, there is no property similar to this one for any other digitization methods, which means it is not possible to add this concept universally to all types of works—but I wonder if it is really necessary to have separate properties for every method, especially since methods may be known in all cases of digital representations. It seems to me that the best approach is to generalize this property's scope to "digital representation on Wikimedia Commons" (or "digital version", "digital copy", etc), with an optional "digitization method" qualifier (similar to fabrication method (P2079)) which could take values such as scanning (Q59155052), photography (Q11633), or even video capture (Q2778015). Thoughts? Dominic (talk) 17:10, 5 June 2019 (UTC)

"Digital representation" or "digital copy" is far too general. That might mean a scan, but it might also mean a video recording, an audio recording, a Morse code representation, or any other form of digital encoding. None of these forms are intended for this property. I suggested "digital document file on Commons" in the previous discussion, but only one person commented. --EncycloPetey (talk) 23:35, 5 June 2019 (UTC)
@EncycloPetey: Yes, I think that is what I am suggesting. The original property proposal over 5 years ago only involved 3 people, so I think it's worth revisiting. What would be the downside to generalizing this to be about any of those types of materials that you listed? If I understand your suggestion of "digital document file on Commons", it's not necessarily important for the purposes of this property that the digital file was created with a scanner, but it is important that it is a "document" (by which I assume you mean an analog physical paper object, though that has other meanings in the digital sphere, too). I guess my confusion is about how that attribute is not already covered by other properties, where you can say, for example instance of (P31) document (Q49848) or made from material (P186) paper (Q11472). It seems to me that we can preserve the meaning, but represent it in a better way. Dominic (talk) 17:47, 6 June 2019 (UTC)
Indeed. The most difficult issues are (a) determining what related properties exist, (b) which other properties can or should overlap with this property, and (c) which other properties cannot or should not overlap with this property. If we had a solid understanding of these three points, it would be easier to settle on the correct label. --EncycloPetey (talk) 21:03, 6 June 2019 (UTC)
  •   Comment We have digital representation of (P6243) to link from Commons files to Wikidata
    For the opposite ;) --- Jura 11:54, 6 June 2019 (UTC)
    • @Jura1: Yes, but, if I am understanding that property correctly, that is for SDOC, which is why it has 0 uses still. In the absence of structured data on Commons, we need the inverse, to be able to point to the files on Commons that are representations of cataloged items. Dominic (talk) 17:26, 6 June 2019 (UTC)
      • Sure, but users will still be expected to pick among the two. In one "digital representation" seems to refer to the metadata and in the other to the content. If you change this to "digital representation", I think the other needs to be changed to something else. --- Jura 04:11, 7 June 2019 (UTC)

Display thumbnail based on file page (P7668) or title page number (P4714)Edit

Please see Wikidata:Contact_the_development_team/Archive/2019/12#Page_for_thumbnail.

Eventually a new request should be made as suggested there by Lea. --- Jura 13:51, 3 April 2020 (UTC)

Return to "P996" page.