Wikidata:Property proposal/official websites
official website
editOriginally proposed at Wikidata:Property proposal/Generic
Description | MISSING |
---|---|
Data type | Item |
Allowed values | item instance of official website (Q22137024) |
Example 1 | OpenStreetMap (Q936) → www.openstreetmap.org (Q110251495) |
Example 2 | Python (Q28865) → www.python.org (Q114737009) |
Example 3 | Rust (Q575650) → www.rust-lang.org (Q114755723) |
Motivation
editThe idea is to relabel:
- official website (P856) to "official website URL",
- official blog URL (P1581) to "official blog URL" and
- official forum URL (P10027) to "official forum URL"
and to then introduce three new properties with the same semantics but data type Item instead of URL.
Xofficial website URLZ should be regarded as equivalent to Xofficial websiteY & YURL (P2699)Z and so on.
Note that such a website item (Y) should only be created if:
- it is a clearly distinct entity from X: generally this means that X is NOT an instance of a website (Q35127) (e.g. Python is a programming language but not a website)
- and you want to express additional statements about the website
(there's no point in creating such items if they only contain ...instance of (P31)official website (Q22137024) and ...URL (P2699)... and the item is only referenced once with ...official website... ... then you could just as well use "official website URL")
Modelling these websites as separate items as opposed to statement values let's us express more detail such as:
- OSM API (Q25822543)part of (P361)www.openstreetmap.org (Q110251495),
- Python Insider (Q114755811)software engine (P408)Blogger (Q171186) or
- Rust Users Forum (Q114756070)instance of (P31)Discourse forum (Q114755914)
which just wouldn't be possible with qualifiers due to property scope constraints.
Note that there has been a previous proposal which has been rejected. I believe that this proposal has significantly better examples and motivation to justify the creation of these properties. The comments in the previous discussion suggested linking between website and item using properties such as operator (P137)/item operated (P121), creator (P170), maintained by (P126) or publisher (P123). None of these would fit for the examples of this proposal, for example: the Python programming language certainly does not operate or create, maintain or publish a website ... if anything that's done by the organization behind Python.
--Push-f (talk) 09:19, 19 October 2022 (UTC)
Discussion
edit- Comment Why not use the qualifier statement is subject of (P805)? -wd-Ryan (Talk/Edits) 15:46, 19 October 2022 (UTC)
- Thanks, very good question! The currently existing properties official website (P856), official blog URL (P1581) and official forum URL (P10027) are all statements about the subject having a URL. Qualifying these statements with statement is subject of (P805) to link respective instances of official website (Q22137024) wouldn't be accurate in my opinion because the official websites are not about the URLs. An example to illustrate what I mean: Google Maps (Q12013)official website (P856)https://www.google.com/maps
statement is subject of (P805)Why Doesn't Google Maps Use Its Own Subdomain?. --Push-f (talk) 05:01, 20 October 2022 (UTC) - I think this is exactly what that property is used for, though. -wd-Ryan (Talk/Edits) 22:07, 20 October 2022 (UTC)
- @Wd-Ryan: I discourage the usage of a qualifier that is as generic as statement is subject of (P805) for adding this information. The main reason is that it has a higher barrier for contributors to do consistent data modelling, because this requires adding two statements instead of one. If we had these properties proposed by @Push-f: a single statement would be enough.
- It requires more effort for a contributor to create the 1st statement shown below than creating the 2st statement shown below. Needless to say that inexperienced contributors would struggle more to remember and to correctly use statement is subject of (P805).
- If I misunderstood your suggestion, please let me know.
- Rdrg109 (talk) 16:41, 24 October 2022 (UTC)
- Thanks, very good question! The currently existing properties official website (P856), official blog URL (P1581) and official forum URL (P10027) are all statements about the subject having a URL. Qualifying these statements with statement is subject of (P805) to link respective instances of official website (Q22137024) wouldn't be accurate in my opinion because the official websites are not about the URLs. An example to illustrate what I mean: Google Maps (Q12013)official website (P856)https://www.google.com/maps
- Comment Do you plan to migrate all the existing website information to this new format? It yes it would be a big upheaval, and if not you'd have the complication of having to write a query to combine two formats. Allowing official website (P856) to take multiple values with purpose qualifiers seems less disruptive. – The preceding unsigned comment was added by Vicarage (talk • contribs) at 18:59, 24 October 2022 (UTC).
- @Vicarage: I think the migration could be optional: Some contributors might feel more comfortable adding URLs through official website (P856), official blog URL (P1581) or official forum URL (P10027), while others might feel more comfortable creating Wikidata items for websites and link them with appropriate properties.
- However, if the migration is mandatory (to avoid having two properties with the same meaning), then it can be progressively done in the following way: the existing properties (official website (P856), official blog URL (P1581) and official forum URL (P10027)) are discouraged to be used, while these new proposed properties are promoted. One way to discourage the usage of those properties would be to add the statements instance of (P31)obsolete Wikidata property (Q18644427) or instance of (P31)partially deprecated Wikidata property (Q37911748) as has been previously done with other properties. Rdrg109 (talk) 01:54, 25 October 2022 (UTC)
- Support These properties would encourage the creation of Wikidata items for websites which brings some advantages to the community
- Relevant information about those websites could be stored as statements. We could store, for example, the web server used by the website (nginx, Apache HTTP Server, etc.), the static site generator used (Jekyll, Hugo, etc.), API endpoint URL (P6269), Alexa rank (P1661) (I'm aware that Alexa Internet is discontinued), etc.
- It helps in reducing conflated items. Some written works discuss about a website of an entity, while others about the entity that is strongly related to that website. For example, the main subject (P921) of this news article (archive) is the official website of TalkTalk Group (Q3514518) while the main subject (P921) of this news article (archive) is the company as a whole: TalkTalk Group (Q3514518).
- Sidenote: I think some people might perceive the creation of a big number of new items as the downside of creating items for websites. Personally, I think this go hand in hand with accurate modelling of new knowledge in Wikidata. If you know other downsides, I'd appreciate you could also point them out. Rdrg109 (talk) 01:28, 25 October 2022 (UTC)
- Comment The web presence of an organisation has lots of promoted URLs, main website, forum, API, blog, RSS feed, developer and in the past mobile enhanced versions, variants for children, Facebook, Twitter handles etc. But if there is merit in creating a 'web presence' entity, it should be a single one, not the 3 proposed here, and if its just full of URL/purpose pairs, then that seems better done under the organisation's entity as now. I'd need to see complicated, concrete examples of these new entities compared with the same information mapped in the existing structure to be convinced. Vicarage (talk) 06:03, 25 October 2022 (UTC)
- Creating a single web presence entity doesn't make any sense. The whole purpose of introducing separate entities is that more detail can be expressed e.g. www.python.org (Q114737009)source code repository URL (P1324)https://github.com/python/pythondotorg or www.python.org (Q114737009)depends on software (P1547)Django (Q842014). Have a look at the 9 example items I already linked on this page (in the blue boxes). Push-f (talk) 10:56, 26 October 2022 (UTC)
- Comment I believe similar properties have been suggested before. The result then was to use owner of (P1830) instead. /ℇsquilo 17:15, 25 October 2022 (UTC)
- Aofficial websiteB does not necessitate that:
- Aowner ofB e.g. the OpenStreetMap geodatabase does not own www.openstreetmap.org, the Rust programming language does not own www.rust-lang.org,
- or that there exists an O for that Oowner ofA and Oowner ofB, case in point OpenStreetMap is community-owned, while www.openstreetmap.org is owned by the OpenStreetMap Foundation
- So it does not seem to be a good way to model these relationships. Push-f (talk) 11:13, 26 October 2022 (UTC)
- Aofficial websiteB does not necessitate that:
- Oppose "Official" is pretty subjective. How do you know openstreetmap.org is the "official website" of the OpenStreetMap database? Couldn't https://planet.openstreetmap.org/ be the official website as that is where the database is official sourced from? I know this sounds pretty dumb but it's something to consider. I believe we should stick to semantically factual relationships. Not things that are "inferred". If you want to relate openstreetmap.org with the OpenStreetMap database and state it has some sort of official status, you would say openstreetmap.org -> owned by openstreetmap foundation and planet.openstreetmap.org -> owned by -> openstreetmap foundation. They're both owned by OSMF, so they can be considered "official" together in that way. If you want to relate python.org with Python, you would say python.org -> owned by -> Python Foundation and Python -> owned by -> Python Foundation. Likewise, the same for Rust. I also oppose official blog and official forum for the same fundamental reason. A blog or forum has no direct relationship with a database or programming language. Lectrician1 (talk) 22:48, 25 October 2022 (UTC)
- Except that OpenStreetMap is not owned by the OSMF; OpenStreetMap is community-owned. See osmwiki:FAQ#Who owns OpenStreetMap?. Also I really think it is quite clear that www.openstreetmap.org is the official website for OpenStreetMap because openstreetmap.org redirects there (and not to planet.openstreetmap.org or elsewhere). --Push-f (talk) 11:02, 26 October 2022 (UTC)
- OpenStreetMap data is owned by the community. The OpenStreetMap website and database is owned by OSMF which is owned by the community. Lectrician1 (talk) 20:48, 30 October 2022 (UTC)
- My point still stands that OpenStreetMap (Q936) currently denotes the OpenStreetMap project, which is not owned by the OSMF but still uses the website run by the OSMF as its official website. (Sidenote: I don't think it's accurate to say that the OSMF is owned by the community but that's not really important for my point.) Modelling this via ownership doesn't make sense. I'd argue that if we have a property for "official website URL", which we do, it only makes sense to have a property "official website" as well. Btw blogs and forum can already very much have direct relationships with a database or a programming language via main subject (P921). But there's a big difference between some blog/forum and the official blog/forum. I don't find your argument that "official" is pretty subjective to be convincing at all. In most cases the official resources are very clear. In cases where they're not this could be qualified via e.g. nature of statement (P5102)disputed (Q18912752). --Push-f (talk) 07:24, 31 October 2022 (UTC)
- OpenStreetMap data is owned by the community. The OpenStreetMap website and database is owned by OSMF which is owned by the community. Lectrician1 (talk) 20:48, 30 October 2022 (UTC)
- @Lectrician1: I understand your concerns on some scenarios (e.g. programming languages). However, I think this property is suitable for other scenarios: For example, some organizations have their own own website (W) and it links to their blog (B). In this case, we say that the organization has an "official website" and an "official blog". Here are some examples where this happens.
- The official website of Google Open Source (Q111351974) is https://opensource.google/ (archive). That website contains a link to this blog: https://opensource.googleblog.com/ (see screenshot).
- The official website of Internet Archive (Q461) is https://archive.org/ (archive). That website contains a link to this blog: https://blog.archive.org/ (see screenshot).
- In these cases that I described, I think the properties "official website" and "official blog" are suitable.
- Note that you are opposing to the concept of these properties when they already exist. This proposal is for creating properties with the same purpose, but with different data type. If you want others to know your opinion, I think you should also post your thoughts in the discussion page of those properties: official blog URL (P1581), official website (P856) and official forum URL (P10027). Rdrg109 (talk) 19:21, 4 November 2022 (UTC)
- Except that OpenStreetMap is not owned by the OSMF; OpenStreetMap is community-owned. See osmwiki:FAQ#Who owns OpenStreetMap?. Also I really think it is quite clear that www.openstreetmap.org is the official website for OpenStreetMap because openstreetmap.org redirects there (and not to planet.openstreetmap.org or elsewhere). --Push-f (talk) 11:02, 26 October 2022 (UTC)
- Support I agree with Rdrg109's comments above: these properties would improve our ability to model the web presence of various entities, and reduce conflation. Nice proposal btw, well described and motivated. --Waldyrious (talk) 11:31, 26 October 2022 (UTC)
- Oppose I think the plan does not cover all the issues, will cause significant disruption and has not been well explained. Vicarage (talk) 21:42, 30 October 2022 (UTC)
- Would you be so kind to elaborate? Which issues do you think aren't covered? Why do you think this will cause disruption? What don't you understand? I thought I made my proposal very clear but I am happy to elaborate. --Push-f (talk) 07:27, 31 October 2022 (UTC)
- You never addressed my previous comments to my satisfaction. Vicarage (talk) 09:20, 31 October 2022 (UTC)
- Oh sorry about that. No I am obviously not trying to migrate all the existing website information to this new format. I don't even understand why you'd ask that because I made that very clear in my proposal "Note that such a website item (Y) should only be created if ..." / "there's no point in creating such items if they only contain ...". --Push-f (talk) 11:25, 31 October 2022 (UTC)
- You never addressed my previous comments to my satisfaction. Vicarage (talk) 09:20, 31 October 2022 (UTC)
- Would you be so kind to elaborate? Which issues do you think aren't covered? Why do you think this will cause disruption? What don't you understand? I thought I made my proposal very clear but I am happy to elaborate. --Push-f (talk) 07:27, 31 October 2022 (UTC)
- Notified participants of WikiProject Websites. --Push-f (talk) 08:28, 1 November 2022 (UTC)
- Oppose statement is subject of (P805) does the job already well. statement is subject of (P805) takes items as values and not urls so Why Doesn't Google Maps Use Its Own Subdomain? is clearly no valid value. When thinking about creating new Wikidata property it's important to actually look at what the existing properties do in their existing usage instead of assumming to much about them based on their label. Reusing existing concepts like statement is subject of (P805) makes it more clear to users that they can reuse it in the future for other cases as well. ChristianKl ❪✉❫ 13:41, 5 November 2022 (UTC)
- I know that it takes items as values ... it was just meant as an example. If that blog post was notable it would clearly fit better with statement is subject of (P805) than the official website. My point that statement is subject of (P805) does not properly fit semantically still stands ... and I do think that semantics are very important for any knowledge base. --Push-f (talk) 16:17, 5 November 2022 (UTC)
- No. It's not. Using the example shows that you don't understand what the property is about, it's a bad example. The example having the wrong datatype is a pretty straightfoward clue for it being a bad example. statement is subject of (P805) does not exist to link to blogposts.
- If you want to understand the meaning of statement is subject of (P805) it would be helpful to look at the examples of the property. The first one is Barack Obama (Q76) position held (P39) President of the United States (Q11696) statement is subject of (P805) presidency of Barack Obama (Q1379733). presidency of Barack Obama (Q1379733) is not an article or blogpost, but the actual thing that's described. Using statement is subject of (P805) to link to a blog post about the presidency of Obama would be wrong. It would violate the semantics of the property as proposed in the property discussion and as demonstrated by the examples of the property. ChristianKl ❪✉❫ 16:46, 5 November 2022 (UTC)
- Thanks for elaborating. Let me give you a better example: Examplehas official website URLhttp://example.com/
statement is subject ofURL of Example this would be an accurate usage of statement is subject of (P805) ... with the caveat of course that URLs are generally not notable enough to have their own data items. A website and a URL are however two distinct things so Examplehas official website URLhttp://example.com/ statement is subject ofWebsite of Example does not match the semantics of statement is subject of (P805). --Push-f (talk) 16:58, 5 November 2022 (UTC) - There's no property called "official website URL" on Wikidata currently. The property is called "official website". ChristianKl ❪✉❫ 17:02, 5 November 2022 (UTC)
- Oh yes you are right the conflation between URLs and websites already starts at the property label. The data type of official website (P856) is URL, so by its very definition it can only be used to state the URL of a website.
- (Sidenote: of the 41 URL (P2699) subproperties currently 27 contain "URL" in their label and only 14 do not contain "URL" in their label, so official website (P856) not having URL in its label is really rather an outlier and should probably be relabeled for the sake of consistency and clarity). Anyway any statement using a property of datatype URL is a statement about a URL of something, not about the something directly. --Push-f (talk) 17:46, 5 November 2022 (UTC)
- There's no property called "official website URL" on Wikidata currently. The property is called "official website". ChristianKl ❪✉❫ 17:02, 5 November 2022 (UTC)
- Thanks for elaborating. Let me give you a better example: Examplehas official website URLhttp://example.com/
- I know that it takes items as values ... it was just meant as an example. If that blog post was notable it would clearly fit better with statement is subject of (P805) than the official website. My point that statement is subject of (P805) does not properly fit semantically still stands ... and I do think that semantics are very important for any knowledge base. --Push-f (talk) 16:17, 5 November 2022 (UTC)
- Oppose statement is subject of (P805) does the job already well. statement is subject of (P805) takes items as values and not urls so Why Doesn't Google Maps Use Its Own Subdomain? is clearly no valid value. When thinking about creating new Wikidata property it's important to actually look at what the existing properties do in their existing usage instead of assumming to much about them based on their label. Reusing existing concepts like statement is subject of (P805) makes it more clear to users that they can reuse it in the future for other cases as well. ChristianKl ❪✉❫ 13:41, 5 November 2022 (UTC)
- Withdrawn I withdraw this proposal in favor of my new proposal Wikidata:Property proposal/object identifies. Using a qualifier indeed is a better approach since we don't have to create a new property for every property of type URL. --Push-f (talk) 08:10, 6 November 2022 (UTC)
official blog
editOriginally proposed at Wikidata:Property proposal/Generic
Description | MISSING |
---|---|
Data type | Item |
Allowed values | item instance of official blog (Q41557148) |
Example 1 | OpenStreetMap (Q936) → OpenStreetMap Blog (Q76435019) |
Example 2 | Python (Q28865) → Python Insider (Q114755811) |
Example 3 | Rust (Q575650) → Rust Blog (Q114755834) |
Example 4 | Internet Archive (Q461) → Internet Archive Blogs (Q114868457) |
See #official website for the motivation and discussion.
official forum
editOriginally proposed at Wikidata:Property proposal/Generic
Description | MISSING |
---|---|
Data type | Item |
Allowed values | item instance of official forum (Q114756109) |
Example 1 | OpenStreetMap (Q936) → OpenStreetMap community forum (Q114755901) |
Example 2 | Python (Q28865) → Python community forum (Q114756015) |
Example 3 | Rust (Q575650) → Rust Users Forum (Q114756070) |
See #official website for the motivation and discussion.