User talk:Dcflyer

From Wikidata
Jump to navigation Jump to search

Inception[edit]

I'm confused by your edit summary and revert here. What purpose does "inception" serve there that "date of official opening" does not, especially with less precision (year versus day)? Thanks, Pi.1415926535 (talk) 04:10, 1 April 2021 (UTC)[reply]


@Pi.1415926535, you left out the fact that the above revert was the undoing of your revert. The properties inception (P571) and date of official opening (P1619) are distinct concepts; inception is when an entity came into existence or was formed, while date of official opening, per its en label, is the "date or point in time an event, museum, theater etc. officially opened." The latter property's proposal was made as an addition to the property officially opened by (P542). In addition to the fact that an entity cannot logically have a date of official opening, grand opening, etc. without previously or simultaneously having come into existence, queries for the inception (P571) of items would be negatively affected if P1619 was solely used as item statements.

13,760 items with the instance of railway station (Q55488) currently utilize both of these properties: https://w.wiki/39dm N.B.: an item with a date output of January 1, XXXX, is for the year XXXX, e.g., January 1, 1976 = 1976. ⚊⚊ DCflyer (talk) 10:32, 1 April 2021 (UTC)[reply]

I'm still confused, sorry. So you're saying that P571 and P1619 should both exist for railway stations, but that P571 should be the year and P1619 the date? To me that seems like pointless duplication. There are a number of different times you could peg as the station coming into existence - when it was first proposed, when construction was approved, when construction began, when construction was completed, or when it opened (which is sometimes before construction is completed). All of the current uses of P571 for railway stations are simply duplications of the year of P1619, which doesn't seem to hold any value. Pi.1415926535 (talk) 17:41, 1 April 2021 (UTC)[reply]
I did not say that "P571 and P1619 should both exist for railway stations, but that P571 should be the year and P1619 the date."
inception (P571) : "date or point in time when the subject came into existence as defined" = owl:equivalentProperty http://purl.org/dc/terms/created , https://schema.org/foundingDate
date of official opening (P1619) : "date or point in time an event, museum, theater etc. officially opened" ≈ http://wordnet-rdf.princeton.edu/pwn30/02426171-v
Two different concepts. ⚊⚊ DCflyer (talk) 01:34, 2 April 2021 (UTC)[reply]
You're still not answering the questions: what does coming into existence mean for a train station, and why add it with only a year (as you have done) when the exact opening date is know? Pi.1415926535 (talk) 19:02, 9 April 2021 (UTC)[reply]
A train station coming into existence: the date the physical structure was built (completed). Official opening: the date it officially opened to the public and/or commenced service, which for some classes appears to be the same as service entry (P729). ⚊⚊ DCflyer (talk) 19:16, 9 April 2021 (UTC)[reply]

Deleting data[edit]

Please do not delete data. Marking data as "deprecated", then immediately deleting it because it is "deprecated" is unethical. --EncycloPetey (talk) 20:15, 8 May 2021 (UTC)[reply]

Data is on Library of Congress Classification (works and editions) (P8360). Your false accusation is bad faith and unethical. ⚊⚊ DCflyer (talk) 20:24, 8 May 2021 (UTC)[reply]
You have not explained why you marked data as "deprecated" then removed the data for being "deprecated". Please cease the removal of data. --EncycloPetey (talk) 20:32, 8 May 2021 (UTC)[reply]
Adding an undiscussed property constraint to justify your actions is also unethical. --EncycloPetey (talk) 20:34, 8 May 2021 (UTC)[reply]

TikTok username as a qualifier[edit]

"It is it not also used as a main value?"

It is, but this constraint raises a warning when it is used as a qualifier. (See "social media followers" on Among Us (Q96417649)) I don't know much about property constraints. AntisocialRyan (Talk) 19:18, 24 August 2021 (UTC)[reply]

@AntisocialRyan
My apologies for not adding the property scope (P5314) as qualifier (Q54828449). I added the property scope constraint (Q53869507) (as main value (Q54828448)), because the lack of property scope constraint for property constraint (P2302) was itself creating a constraint violation. I did see that out of 3,696 uses of TikTok username (P7085), 42 are as qualifier; as well as 17 as reference. I can add property scope as reference (Q54828450), if you think that it's appropriate as a reference. ⚊⚊ DCflyer (talk) 19:51, 24 August 2021 (UTC)[reply]
Oh no worries, I didn't know they worked like that. I've seen many identifiers used as reference (Q54828450), so I think that would be good too. Thanks! AntisocialRyan (Talk) 23:15, 24 August 2021 (UTC)[reply]

title (P1476)[edit]

Revision

The purpose of the change was to allow multiple titles. I'm saying that multiple titles should be allowed.

There are so many songs and works out there that are published with 2 or more titles in different languages. The constraint is not helpful. Lectrician1 (talk) 19:41, 5 September 2021 (UTC)[reply]

Could you please respond to this? Lectrician1 (talk) 10:57, 9 September 2021 (UTC)[reply]
@Lectrician1, regarding the following, "... so many songs and works ... are published with 2 or more titles in different languages", were you referring to songs and textual works that are published with multilingual titles, but retain their original monolingual linguistic content?
However, whether the main content is multilingual or not, the constraint was not an arbitrary addition, as it follows the practices and utilizes the schemas and classification and cataloguing models developed and used by national libraries, other cultural heritage organizations, and standards bodies. For books, Wikidata is in relative alignment with the most widely used conceptual model, Functional Requirements for Bibliographic Records (Q16388) (FRBR) — see WD:Books. If additional titles (multilingual) added as aliases, or a brief note of "also known as" in the description prove to be insufficient, a new item could be created as a version, edition, or translation (Q3331189) for any of these borderline new expressions/manifestations of the original creative work, especially if it was discovered that a differing title also differed in its date or location of publication, publisher, content size, and/or distribution format, etc.; i.e., an actual new manifestation.
Also, the issue of the title language of written works and songs has been discussed for other properties, and consensus was reached to merge in at least one case, but ultimately deprecated due to the large amount of items which would have been affected. See original language of film or TV show (P364) : "language in which a film or a performance work was originally created. Deprecated for written works and songs; use P407 ('language of work or name') instead." & Property talk:P364#Decision is to delete; mark as deprecated & Properties for deletion : 1.9 - language of work or name (P407) and original language of film or TV show (P364. ⚊⚊ DCflyer (talk) 15:52, 9 September 2021 (UTC)[reply]
This problem mostly pertains to songs, and mostly KPOP songs (I mostly work for WP Music). KPOP songs can sometimes be published with English and Korean names. These instances are just one song, not different songs published with respective lyrics in English and Korean. For example, this song.
I am very well aware of the FRBR model as I had to research about it extensively when proposing and arguing for translation of (P9745). I understand completely that different items should be created for books that have different editions in different languages and therefore different titles. I just think that because these instances come up with songs where they are actually published with twos titles, the constraint should be removed, as it's quite annoying. Lectrician1 (talk) 17:31, 12 September 2021 (UTC)[reply]
Any response? Here is another example of a music album that has 2 titles. Lectrician1 (talk) 23:32, 26 September 2021 (UTC)[reply]

MDOT State Highway Administration[edit]

Hi there, I see you reverted a change I made to the Maryland State Highway Administration wikidata (Q5203575). I made the edit in my official capacity as an MDOT representative (you can email me at eplack@mdot.maryland.gov if you'd like to verify). Perhaps the way I updated the name was wrong (novice at wikidata here), but we're trying to shed the "Maryland SHA" identity. Can you help? The only official titles for MDOT SHA are:

  • Maryland Department of Transportation State Highway Administration
  • MDOT SHA
  • MDOT State Highway Administration

I can send you our identity guide if you'd like, or publish it somewhere. We rebranded in 2017. Many places on the web still use the old name --Eplack (talk) 05:01, 22 September 2021 (UTC)[reply]

Labels can be ambiguous[edit]

That is as per Help:Label#Labels can be ambiguous. I do notice that country name is included in labels in several other languages and in Wikipedia category names (Special:Diff/1529402962), but what should we make out of it really? I can't say for sure, possible sources in some language have adopted names of these national designations differently, so that country names are included. Though, in most cases its unlikely and labels in other languages should be corrected as well. As for Wikipedia category names, these don't compare to item labels really. For instance, generic description "Buildings in Paris" is also category name, but we probably wouldn't say that individual buildings in Paris are of special building type named "building in Paris". Titles of Wikipedia overview articles may as well include country name for disambiguation purposes, but as pointed, this is not needed on Wikidata, where we can and should use accurate terms as labels.

A national designation is its own thing, an individual concept, as defined in national legislation, not some category-like pseudo-class with an ad hoc name, if that's what you might think. National park in this case is defined and listed in Estonian legislation, see official English translation, where the term for this type of protected area is simply "national park". As you can check via external identifers added to this item, this is also reflected in EUNIS database, where English name is simply "national park". In fact, I don't know any sources where name of this designation would include country name. Hence current label, including country name, is misleading, as this definitely isn't the "item's most common name" (again, see Help:Label). The same aplies to similar designations in other countries, as you can easily check via CDDA designationTypeCode (P9800) links now. 2001:7D0:81DA:F780:500A:1DCE:4F95:DAB1 08:59, 18 November 2021 (UTC)[reply]