Wikidata:Property proposal/mirror URL
Jump to navigation
Jump to search
mirror URL
[edit]Originally proposed at Wikidata:Property proposal/Creative work
Not done
| Description | qualifier indicating the URL from which the claim was mirrored |
|---|---|
| Represents | mirror storage (Q654822) |
| Data type | URL |
| Domain | software (Q7397)   website (Q35127) |
| Example | libreboot (Q20085696) → http://git.savannah.gnu.org/cgit/libreboot.git |
| Planned use | add to source code repository URL (P1324) that are mirrors of another source code repository URL (P1324) |
- Motivation
A mirror is the replication of another website. This type of website is used as a response to spikes in user visitors. Mirror sites are most commonly used to provide multiple sources of the same information, and are of particular value as a way of providing reliable access to large downloads.
Dachary (talk) 12:07, 14 September 2016 (UTC)
- Discussion
A discussion in the FLOSS project page motivated the proposal of this new qualifier.
- This can actually be done with source code repository URL (P1324) <source repo> P794 (P794) "mirror". --Izno (talk) 12:32, 14 September 2016 (UTC)
- You would know that it's a mirror, but ... a mirror of what ? Dachary (talk) 11:42, 15 September 2016 (UTC)
- Clearly the unqualified repository also using the source repo property. Or perhaps the "preferred" rank claim. And if it's not a mirror of one of those URLs, then it's not really a mirror for our purposes, no? --Izno (talk) 16:50, 15 September 2016 (UTC)
- You're right when there only are two URLs, one of which is the mirror. But when there are more and there maybe are two mirrors, things would get complicated. Having a qualifier with a URL object is unambiguous. Dachary (talk) 16:33, 16 September 2016 (UTC)
- I don't see how things would get complicated. We should always have a (single?) canonical source repository available as a link. If we do not, what's the point of the property? Mirrors don't mirror mirrors, and if they do, they're not useful to us because that's not where the work is being done on some project X or Y. --Izno (talk) 17:28, 16 September 2016 (UTC)
- We should have a single repository most of the time, indeed. But two forks of the same software can co-exist. For instance libavcodec (Q217647) has https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcodec and http://git.libav.org/?p=libav.git;a=tree;f=libavcodec;hb=HEAD and there is no consensus on which one is the authoritative upstream. Another case (more common) is when a repository is outdated. For instance when projects move from code.google.com to gitlab.com or from sf.net to github.com. I'm not denying that it would be possible to use P794 (P794) instead. But it would require more explaining and could become ambiguous as soon as an editor who did not carefully read the conventions adds a new repository. The property I propose requires less explaining and has no risk of being ambiguous. Dachary (talk) 10:41, 17 September 2016 (UTC)
- The former case should use criterion used (P1013) and probably a common rank of "normal" and the latter case should use one of the myriad of time properties and a "normal" rank rather than the preferred rank. This is no different than the rest of Wikidata. --Izno (talk) 15:17, 17 September 2016 (UTC)
- We should have a single repository most of the time, indeed. But two forks of the same software can co-exist. For instance libavcodec (Q217647) has https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcodec and http://git.libav.org/?p=libav.git;a=tree;f=libavcodec;hb=HEAD and there is no consensus on which one is the authoritative upstream. Another case (more common) is when a repository is outdated. For instance when projects move from code.google.com to gitlab.com or from sf.net to github.com. I'm not denying that it would be possible to use P794 (P794) instead. But it would require more explaining and could become ambiguous as soon as an editor who did not carefully read the conventions adds a new repository. The property I propose requires less explaining and has no risk of being ambiguous. Dachary (talk) 10:41, 17 September 2016 (UTC)
- I don't see how things would get complicated. We should always have a (single?) canonical source repository available as a link. If we do not, what's the point of the property? Mirrors don't mirror mirrors, and if they do, they're not useful to us because that's not where the work is being done on some project X or Y. --Izno (talk) 17:28, 16 September 2016 (UTC)
- You would know that it's a mirror, but ... a mirror of what ? Dachary (talk) 11:42, 15 September 2016 (UTC)
Support This is a common property of a repository or a website. Johanricher (talk) 11:46, 15 September 2016 (UTC)
Oppose For this reasonable use-case, use existing properties, with a qualifier. The main repository can be ranked as "preferred". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:33, 17 September 2016 (UTC)
- I could not find an existing property that could be used instead. Do you have one in mind ? Unfortunately (see the libavcoded above and the case of repositories moving from one hoster to another) there does not always is a single authoritative repository. This is the nature of Free Software: it invites forks and parallel evolution :-) Dachary (talk) 08:18, 18 September 2016 (UTC)
- this, for your example (note also that I have edited the example you gave, above, because the item is required). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:17, 20 September 2016 (UTC)
- what you suggests works well when there only is one source code repository. When there are multiple source code repositories (say A and B) and they are mirrors of C and D respectively, knowing they are mirrors is not enough. You need to know from which URL they were mirrored. As Tobias1984 pointed out below, this would be better served with a claim/statement rather than a qualifier. Does that sound sensible to you ? Dachary (talk) 06:50, 21 September 2016 (UTC)
- this, for your example (note also that I have edited the example you gave, above, because the item is required). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:17, 20 September 2016 (UTC)
- I could not find an existing property that could be used instead. Do you have one in mind ? Unfortunately (see the libavcoded above and the case of repositories moving from one hoster to another) there does not always is a single authoritative repository. This is the nature of Free Software: it invites forks and parallel evolution :-) Dachary (talk) 08:18, 18 September 2016 (UTC)
- Support Mirror url should not be separated from original website url and I can't find other existing qualifier which let us adding an URL and both specifying this url is a mirror. — Metamorforme42 (talk) 14:05, 18 September 2016 (UTC)
Comment The qualifier should be used to give details about the original value and not add additional information. In my understanding of qualifiers this proposal is more of a property. But then again, as Andy says, the existing properties might be sufficient. Is there an estimate how many items will receive a mirror statement and how many statements will be added in total? --Tobias1984 (talk) 20:51, 19 September 2016 (UTC)
- Using mirror URL as a claim instead of a qualifier would also work. So that it can further be qualified with end time (P582), for instance, to reflect the fact that the mirror stopped at a given time. I tried to figure out a way to use existing properties instead and came up with that: URL (P2699) → http://notabug.org/software with qualifier P794 (P794) → mirror storage (Q654822) (as suggested by Izno) and qualifier source code repository URL (P1324) → http://github.com/software (in case it is a mirror of a software repository). As for the number of mirror URLs there currently are no more than a few dozens in the case of FLOSS, IMHO. I sometime run into obsolete URLs that no longer respond and when there is an another web site or an another source code repository, it would be useful to know if it was meant to be a mirror of that particular URL or not. Dachary (talk) 06:40, 21 September 2016 (UTC)
Today I looked into Apache Wicket (Q617162) which has an official git repository at git://git.apache.org/wicket.git and a mirror at https://github.com/apache/wicket. I added to source code repository URL (P1324) https://github.com/apache/wicket the P794 (P794) qualifier with mirror storage (Q654822) and the reference URL (P854) git://git.apache.org/wicket.git as a reference/source to state that it was mirrored from this URL. The only downside is that there are a few other items with a label identical to mirror storage (Q654822) and it is likely editors will sometime select the wrong one. Does that look like a reasonable way to implement the use case ? If so I will withdraw this property proposal and document this. Dachary (talk) 10:03, 23 September 2016 (UTC)
- Since there has not been any objection, I'll document the above and withdraw this proposal. Thanks everyone for the constructive feedback ! Dachary (talk) 12:18, 28 September 2016 (UTC)