Wikidata:Property proposal/date of recording

From Wikidata
Jump to navigation Jump to search

recording date[edit]

Originally proposed at Wikidata:Property proposal/Generic

   Done: recording date (P10135) (Talk and documentation)
Descriptiona date when something was recorded
Data typePoint in time
Example 1Baby, You're a Rich Man (Q60678886) → 11 May 1967
Example 2The Jordan B. Peterson Podcast - S4E18: Ten Global Trends Every Smart Person Should Know | Marian Tupy (Q109279272) → 24 March 2021
Example 3JRE #961 - Graham Hancock, Randall Carlson & Michael Shermer (Q107206789) → 16 May 2017
Example 4Here, There and Everywhere (Q60661752) → 14 June 1966
Expected completenessalways incomplete (Q21873886)
See also
  • publication date (P577): date or point in time when a work was first published or released
  • production date (P2754): period of active production of (creative) work; the only date stated should refer to end of production; production starts after pre-production (planning) and is followed by publication date (P577); in general cases, use inception (P571)
  • inception (P571): time when an entity begins to exist; for date of official opening use P1619

Motivation[edit]

Talking about every kind of media, there is often a discrepancy between the recording and publishing. For podcasts it might be recorded a month prior to publishing. Obviously, the recording date can be on the same date as the publishing date. Germartin1 (talk) 07:57, 28 October 2021 (UTC)[reply]

Discussion[edit]

 Support Speaking as someone who mostly edits music, this property has been sorely missing and as a result there is no fixed way of querying for it. Happy to see it! Moebeus (talk) 11:11, 28 October 2021 (UTC)[reply]

 Support Maybe a subproperty of (P1647) inception (P571)?- TiagoLubiana (talk) 23:10, 28 October 2021 (UTC)[reply]

 Oppose Limited to anything that is record-able? Videos, Audio, Text recorded into Memory Cubes, eyewitness account handwritten in notes stored in a box in a cornerstone? I think this is really just a subproperty of inception (P571) which is fine to help music folks I guess with querying. But it's really just inception (P571) limited to lots of domains through further instance of (P31) relations, and I would say not only Music or Audio domains since many things are record-able. So it might be better to just skip creating this property and continue to use inception (P571) for the need and continue to apply appropriate subclass of (P279) and instance of (P31) to items. -Thadguidry (talk) 18:10, 1 November 2021 (UTC)[reply]

@Thadguidry: Yes it is a subproperty of inception, but it's much more precise. For a interview/podcast episode inception could refer to the planning date, or when the script was written. For songs it could inception is also very ambiguous. Germartin1 (talk) 21:32, 1 November 2021 (UTC)[reply]
@Germartin1: So would "date of recording" be equivalent to https://schema.org/MusicRecording - dateCreated ? -Thadguidry (talk) 22:15, 1 November 2021 (UTC)[reply]
Yes I suppose so. Germartin1 (talk) 16:28, 5 November 2021 (UTC)[reply]
Then, can the proposal please be updated to reflect that date_of_recording will be modeled as a subproperty of inception (P571)? Thanks. --Thadguidry (talk) 20:29, 3 December 2021 (UTC)[reply]

 Oppose For the same reason as Thadguidry. If someone can show me a case where date of recording differs from date of creation (of a recording) I am willing to change my vote, but I can't think of any. /ℇsquilo 15:05, 2 November 2021 (UTC)[reply]

See example 1 & 2, most podcast episodes and interviews are not recorded on publication date Germartin1 (talk) 16:24, 5 November 2021 (UTC)[reply]
I think the point is that inception (P571) could just be used then (indeed, it has “date of creation” as alias). The question is more, I think, are there any downsides to use P571? Jean-Fred (talk) 20:18, 5 November 2021 (UTC)[reply]
No, but I think clearer properties are better. Like inception could also refer to the planned date. And also there could (in theory) be two recording dates. Germartin1 (talk) 11:15, 7 November 2021 (UTC)[reply]

 Support @Thadguidry, Esquilo: Recording is a fundamentally different process than instantly creating something (inception). Non-material things like companies or organizations are "created". Sounds and video are not. They are sequences of state captured over time. I believe properties' names and their conceptual definitions should remain true to each other and consistent. That is why I'm in support of this property. Lectrician1 (talk) 02:22, 16 November 2021 (UTC)[reply]

Sound is created by instruments, voice reeds and similar, but that is not the issue here. What's discussed here is the creation of a recording. A conservation of sound in a recoverable and reproducible state. /ℇsquilo 07:54, 16 November 2021 (UTC)[reply]
@Esquilo I'm saying that the creation of a recording is done over a time frame (the duration of the recording) vs. something like the creation of an organization which is instantaneous. Inception describes something that is instantaneous, something the creation of a recording is not. It also is for this reason that inception also "sounds" weird to put on a recording.
Just to further support this property, another use case could be for a pre-recorded television episode. It's both weird and unsuitable to use "inception" for this. "date of recording" would be much better. Lectrician1 (talk) 19:56, 18 November 2021 (UTC)[reply]
@Thadguidry: @Esquilo: We have filming location (P915) and recorded at studio or venue (P483) but not date for it. Even Youtube's API has a field "recordingDetails.recordingDate" which is obviously before the publishing date. Germartin1 (talk) 09:11, 23 November 2021 (UTC)[reply]
And that's why we have publication date (P577) which is separate from inception (P571). /ℇsquilo 17:57, 23 November 2021 (UTC)[reply]
  •  Support--Trade (talk) 19:14, 23 November 2021 (UTC)[reply]
  •  Support-Yupik (talk) 01:40, 30 November 2021 (UTC)[reply]
  •  Comment @Germartin1: I don’t know about any strict guidelines on this, but marking this as ready is a bit premature I think − I don’t think there’s consensus yet about this. Jean-Fred (talk) 12:55, 30 November 2021 (UTC)[reply]
  •  Comment I sympathise with the clarity troubles of using inception (P571) for this − while I agree with @Thadguidry: that this is essentially the same, just scoped to creative works, I don’t think this necessarily disqualify the existence of the property. But I don’t think this property can get away with "only be about music". On Structured Data on Wikimedia Commons (see commons:Commons:Structured data/Modeling/Date), we have similar issues with P571: typically, is it the date of the depicted antique artifact, or the date the picture was taken (and more in general folks find the name weird, which may or may not be a good reason). If this property is created, then it will (and should) be used for audio recordings and video recordings on Wikimedia Commons − then should it not also be used for images too? Should this then be named/aliased to "date of capture" or "date of creation"? Jean-Fred (talk) 13:02, 30 November 2021 (UTC)[reply]
    @Jean-Frédéric I'd support a new property separate to this for image capture dates such as "date of capture". Lectrician1 (talk) 14:03, 30 November 2021 (UTC)[reply]
    But how would that hypothetical “Date of capture” be any different from this “date of recording”? Isn’t recording just the name we use for audio capture? Jean-Fred (talk) 14:09, 30 November 2021 (UTC)[reply]
    I've kind of developed a stringent personal policy that properties and their functions/definitions should be exactly defined. The process of recording is different than capturing. Recording is honestly just a series of captures, but still it's different. Therefore, they have different definitions and should have different properties. I also explain this above in my response to ℇsquilo.
    In addition to this reason, it'd also just be better to have a separate properties for ease of interpretation. "date of capture" works perfectly for photos but not for recordings. "date of recording" works perfectly for recordings, but not at all for photos. "date of creation" and "inception" is too unspecific for both.
    Creating two properties is not a big deal. In the long run, we're improving Wikidata's interpretability and data consistency since these properties will be meant for specific items. Constraints can be created and everything can work. That's why I support these two. Lectrician1 (talk) 15:06, 30 November 2021 (UTC)[reply]
    Well having several properties arguably makes querying harder. Taking the SDoC example, if I query for a bunch of media files (per user, per subject, etc.) with their "date of creation", I need to retrieve both Pxyz “date of capture” in case this is a still image, and Pabc “date of recording” in case it’s a video or audio.
    Also, I find that focus on the name of the properties missing the point. Names don’t matter that much − what matters is the agreed-upon relationship between items that is encoded by the property. And really, the English name should matter even less. I find the distinction drawn between Capture and recording somewhat less convincing in French (one does not exactly “enregistrer” a photograph, but that’s not wrong at all, as we use the same word for “Save” and “Record” and when I take a digital photo it’s a file being saved so…), and I can certainly imagine other languages not making the distinction either. Jean-Fred (talk) 22:40, 30 November 2021 (UTC)[reply]
    Actually, this is pretty convincing. However, now that I think about it, it seems like we should just rename inception (P571) to "date created". All of the linked external properties use that terminology as well. And, it would make sense for organizations, works, recordings, and photographs. Lectrician1 (talk) 16:11, 1 December 2021 (UTC)[reply]
    we should just rename inception (P571) to "date created". Well − the French, Italian, Spanish labels already are “Date of foundation or creation” (and from the looks of it, other languages as well). This property was originally created as “foundation/creation date”. It was renamed with apparently no discussion either. Jean-Fred (talk) 20:25, 2 December 2021 (UTC)[reply]
    I opened a thread at Wikidata:Project_chat#English_label_of_inception_(P571)
  •  Support Orlandata (talk) 21:53, 30 November 2021 (UTC)[reply]
  •  Support Seems reasonable. While I understand the points being made by Thadguidry and others about the relationship between this property and inception (P571), I think those points have been answered adequately in favour of creating this. (I also think P571 is probably too broad, as exemplified by the list of English aliases in it, but that's a discussion for another time and place.) Jon Harald Søby (talk) 22:12, 1 December 2021 (UTC)[reply]
    Sorry, but as I read it, there are two concerns here, and I don’t see how they have been answered:
    1. « inception (P571) works just fine for this » − I’m missing any counter-argument besides “inception is a bad, confusing name” (there was another example given by User:Moebeus on another forum, where the “date of recording” and “inception” would be different, did not fully look into it)
    2. « this cannot just be about music/sound, in particular given SDoC ». I am not even sure whether other users agree with that − but if they do then the examples should reflect it.
    I think the question of whether “P571 is too broad” is completely central to this property proposal: if it is, then it makes sense to have sub-properties ; if it’s not, then it does not make sense.
    Jean-Fred (talk) 20:25, 2 December 2021 (UTC)[reply]
    • The way I read this proposal (and hope to see it materialize) was as a dedicated property for the "canonical" date of recording of sound. Bringing other types of media into it will likely just lead to confusion and yet another ambiguous property - I'm not a fan.
    • The "official" date of recording is encoded in the industry ISO standard ISRC and might differ from when the process of recording initiated (inception). In fact it almost always does for music created in a modern multi-track studio environment. It is not uncommon for the recording process to last weeks (or even months and years in the case of some megalomaniacs creative geniuses).
    • Anecdotally, I think it's pretty evident that "fuzzy" properties, left up to the interpretation of editors, lead to all sorts of wrong and/or exotic uses, and the broader properties are in scope, the harder it gets coming up with good property constraints to avoid that type of thing.
    • That's it really, I'm still very much in favor of this proposal. As one of the editors that has added the most music tracks to WD I have never once used "inception", and I don't think I will start even if this doesn't go through. It's just not a good fit for music. I hope that clarifies my position, and even if it did nothing to persuade you I think we'll still mange to be friends :) Moebeus (talk) 21:17, 2 December 2021 (UTC)[reply]
    Well, the thing I see coming from a mile away is:
    1. the Property Pxyz “date of recording” gets created ;
    2. it gets used on music items (all good) ;
    3. eventually, it gets used on Wikimedia Commons audio files (because why not?), potentially on video files ;
    4. Querying Wikimedia Commons becomes super annoying because you never know whether you should retrieve P571 (for images ) or Pxyz.
    Perhaps we can disallow the use on M-items through constraints. Or perhaps the future lies with a proper “date of creation” property (which would sit between P571 and “date of recording”). Or perhaps we can word this date of recording in a way to make it unambiguously clear that it is scoped to Audio.
    I’m still not opposing this ; but I just have a bad feeling about this that there is trouble ahead :-) Jean-Fred (talk) 13:24, 3 December 2021 (UTC)[reply]

 Comment rescinding my support for now. As stated before, if this property is approved, a property dedicated to photographs should also be approved. The issue at hand seems to be having properties that define when something is created. That is why I think we should just rename inception. I'd encourage everyone to give their input on that on this discussion.

@UWashPrincipalCataloger I don't think this was a good idea...
Commons still uses inception (P571) for videos. Do/Should I now create a Phabricator task asking them to switch all videos over to recording date (P10135)?
And then, should I also create a proposal for photographs like "date captured"? Lectrician1 (talk) 17:51, 12 December 2021 (UTC)[reply]
@Lectrician1 But what is meant by inception (P571) in Commons for videos? Is it the date of creation of a moving image work or the specific dates of recording? One could say that a work was created in 2021, but the specific dates of recording would be something more specific. UWashPrincipalCataloger (talk) 18:42, 30 December 2021 (UTC)[reply]
@UWashPrincipalCataloger I don't know 🤷. I created a thread on their structured data page about the creation of the property, so you should probably bring it up there. Lectrician1 (talk) 18:53, 30 December 2021 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/date_of_recording&oldid=1552777774"