Wikidata:Property proposal/web interface software
web interface software[edit]
Originally proposed at Wikidata:Property proposal/Creative work
| Description | the software that generates the web interface for the source code repository |
|---|---|
| Represents | web user interface (Q1981057) |
| Data type | Item |
| Domain | as qualifier on source code repository URL (P1324) |
| Allowed values | instances of software (Q7397) or forge (Q3077240) |
| Example 1 | https://invent.kde.org/office/kexi → GitLab (Q16639197) |
| Example 2 | https://anongit.kde.org/kexi.git → no value Help |
| Example 3 | git://github.com/KDE/kexi.git → no value Help |
| Example 4 | |
| Example 5 | |
| Example 6 | |
| Planned use | Go trough source code repository URL (P1324) |
| See also | software engine (P408) |
Motivation[edit]
The main motivation is to differentiate source code repositories with a web interfaces from repos without a web interface (see example 1, 2, and 3). It is also not unusual that a repo is mirrored so that one can pick an interface based on one’s preference.
“Why not use software engine (P408) instead?” The Wikidata description for software engine (Q2622299) is “central part of a computer program”. Web pages, however, are usually not computer programs and the software that generated the web interface might not be part of the web interface, see static site generator (Q77916592). In Wikidata:Property_proposal/version_control_system User:Waldyrious wrote that “software engine (P408) is too broad for this, so I agree with your suggestion to use a new property.” —Dexxor (talk) 15:06, 17 July 2020 (UTC)
Discussion[edit]
Notified participants of WikiProject Informatics/FLOSS
- I generally
Support this property, but I have some comments I'd like your input on:
- Do you envision this new property to be linked, via Wikidata item of this property (P1629)/Wikidata property (P1687), to web user interface (Q1981057)?
- I wonder if we could make this more broadly applicable without diluting its meaning as a qualifier of a source code repository property. For example, could something like "web hosting service" work as such a broader property? It would then be also usable as a qualifier for, say, official website (P856) or official blog URL (P1581).
- Another possibility that occurred to me was to allow existing properties like operator (P137) or publisher (P123) to be used for this purpose. That would only require expanding the scope of existing properties, rather than creating a new one.
- Looking forward to read your thoughts! --Waldyrious (talk) 16:23, 17 July 2020 (UTC)
- No, if we want to link this property to an item, we probably need to create a new item.
- I agree that “web interface software” sounds odd for blogs and websites. But “web hosting service” is certainly not the solution (from en:web hosting service: “Web hosts are companies that provide space on a server”). How about “website generator”?
- No, possible values for operator (P137) and publisher (P123) are person or organization. If we really want to avoid creating a new property, we should expand the scope of software engine (P408) for websites. —Dexxor (talk) 17:59, 17 July 2020 (UTC)
- Can you expand a bit on how exactly the new "web interface software" property would be different from web user interface (Q1981057)? The distinction is not very clear to me.
- "Website generator" seems much more specific about the toolset used to produce the final web assets served as the website — along the lines of static site generator (Q77916592) or web framework (Q1330336). I was thinking more about something reflecting a web hosting (Q5892272). For example, a website hosted on GitHub Pages (Q30324817) could have "web hosting service" = GitHub Pages (Q30324817) and "website generator" = Jekyll (Q17067385). (By the way, I'd say that the class of companies providing a service should be modeled as a distinct entity from the service itself, as an abstract concept; so I'd suggest creating a new item, e.g. "web hosting provider", distinct from web hosting (Q5892272), for the meaning you're describing).
- I think software engine (P408) would be confusing as a website's platform — IMO it would be more appropriate to subsume the "website generator" suggestion you gave above.
- Overall, I believe the main source of dissonance here is that I'm thinking about hosted services, like GitHub, whereas you're focusing on the tools themselves, and considering also self-hosting solutions. With this in mind, I can understand why it's more important to encode what the repository browsing software is, than the provider that hosts it (especially since the URL already provides that information). If you agree with this, then I would suggest making the new property ("web interface software") a subproperty of software engine (P408), and encoding the hosting provider using, e.g. operator (P137)GitHub Inc. (Q28771536) or publisher (P123)GitLab Inc. (Q55589254). – The preceding unsigned comment was added by Waldyrious (talk • contribs) at 20:16, 15 August 2020) (UTC).
- I distinguish between a web interface and the software which generated the interface but some people don’t. I’m fine with web interface softwareWikidata item of this property (P1629)web user interface (Q1981057) and subproperty of (P1647)software engine (P408).
- You are spot-on when it comes to our dissonance. For modeling the hosting provider I suggest internet hosting service (Q1210425). This is a more general term that includes, among other things, web hosting (Q5892272) (websites) and Git hosting service (version control). —Dexxor (talk) 13:41, 16 August 2020 (UTC)
- I agree with all of your suggestions. That would mean that, besides the "web interface software" property we're discussing here, we'd also request a new property associated with internet hosting service (Q1210425) for the hosting provider, right? --Waldyrious (talk) 10:48, 17 August 2020 (UTC)
- Yes, internet hosting service would need to be a separate property. If you propose it, I would like to know whether your motivation is “because we can” or something else. —Dexxor (talk) 07:25, 18 August 2020 (UTC)
- I believe it would be useful to model whether a web-browsable repository is provided on a self-hosted gitlab instance versus hosted on gitlab.com, for example. But it's not something I feel too strongly about. --Waldyrious (talk) 14:12, 25 August 2020 (UTC)
Comment @Waldyrious, Dexxor: -- If either or both of you are still interested in getting this added, please try and find at least one other supporter, and summarize the discussion above so it's clear to the property creators what exactly is being proposed. JesseW (talk) 17:09, 14 March 2021 (UTC)
Support OK, that makes sense to me, so I've marked it as ready. Hopefully a property creator agrees. JesseW (talk) 21:01, 14 March 2021 (UTC)
Comment I thought long about this and am not sure whether I still support this as it stands now. Considering that GitLab and GitHub provide much more than just an interface to Git repositories, I see three ways to proceed:
- Change the name of the proposed property to "website powered by" or "website software". Should the over 4000 existing software engine (P408) statements on websites in the Directory of Open Access Journals (Q1227538) and a few on MediaWiki websites be changed to use the new property then?
- Limit the property's scope to source code repository software (e.g. GitLab, GitHub, cgit (Q28974765)).
- Throw this proposal away and just use software engine (P408) or don't model the relation at all.
@GNUtoo, Uzume: You participated in the previous discussion, what do you think? —Dexxor (talk) 21:56, 14 March 2021 (UTC)
Comment I'm personally inclined towards Dexxor's proposal #2, but #1 would be fine with me also, if others prefer it. #3 doesn't sound right IMO. --Waldyrious (talk) 23:09, 14 March 2021 (UTC)
Comment I think the term you are trying to capture has changed over time and thus also changed its names:
- forge (Q3077240)
- collaborative development environment (Q5145831)
- online integrated development environment (Q63563749)
- application lifecycle management (Q621590)
- DevOps (Q3025536)
You also seem to want to focus this on user interface. We already have properties for software relationships some user interface specific even:
I see no reason why websites/web applications cannot have core engine software as well as user interface libraries and other dependencies (like crypto libraries, etc.). In fact I was one of the ones that lobbied to get web framework (Q1330336) generalized from web application framework to web framework (including software framework (Q271680) for things like web service (Q193424), web resource (Q3427877), etc.).
Really do not see this as very similar to the the discussion for version control system (P8423) (which was once implemented by protocol (P2700) but perhaps could been also have used file format (P2701) depending on the version control system (Q3257930)). @Dexxor: Thanks for the ping. —Uzume (talk) 15:47, 15 March 2021 (UTC)
- Support, an important property for websites.--Arbnos (talk) 01:52, 20 March 2021 (UTC)
Comment I went ahead with #2, limiting the scope of this property to web interface software for source code repositories, because web interface software would be a weird term for blog software. Changing the name is also not possible because examples 2 and 3 would loose their meaning. For examples 4, 5 and 6 I suggest using software engine (P408) instead. The Wikidata editors using it clearly do not mind stretching the definition of "software engine" a bit, as can be seen with the example "Wikipedia → MediaWiki" on software engine (P408). @Genium, Ipr1, LiberatorG: If you support this proposal, I think it can be marked as ready. I am happy to answer your questions. —Dexxor (talk) 12:33, 20 March 2021 (UTC)
- Support I agree with Dexxor's arguments and final suggestion (maybe call it "source code repository browser" instead of "source code repository software"? Otherwise I'm afraid it can be confused with version control system (P8423)). --Waldyrious (talk) 20:43, 2 April 2021 (UTC)
- Support — MasterRus21thCentury (talk) 05:54, 12 January 2022 (UTC)
