I think the redirects issue has been raised here to make up for the poor Wikidata-Wikipedia integration we currently have. I imagine Winter showing a list of "related articles in other languages". Reusing one of the examples: when viewing [[en:Rob Bourdon]], the software should infer from [[d:Q19205]] that Rob Bourdon is /member of/ Linkin Park (Q261), for which the German Wikipedia has an article, that will in turn be linked. Very little brain work is needed to understand that the German article about the band is likely to contain information about individual members. While this may sound Reasonator-ish, if correctly implemented in Wikibase it could improve interlanguage and interproject links in a way that just cannot be achieved with redirects. Imagine the Wikipedia entries for "Linkin Park" linking (pun intended) to Wikiquote entries of each member.
The trouble is that a particular individual may have many memberships and affiliations -- some perhaps to small units like bands; but some to larger groups like clubs, or artistic movements.
It's better to let humans decide where is the best place in a particular language to redirect people looking for information about a particular person or thing.
And that then also covers hatmakers/hatmaking, or Bonnie and Clyde, and every other example which is not just about a member of bands.
This discussion has been going on for two years now, and every time it has come up (which has been many times -- at least a dozen now?), there have been an overwhelming number of people supporting allowing and marking site-links to redirects.
It's now time to move forward.
In particular, what are the parts of the code that assume sitelinks cannot be to redirects (or that update sitelinks if pages are turned into redirects) ? How do these need to be adjusted, if we move to a model of allowing sitelinks to redirects, but only if a user has explicitly confirmed that that is what they want.
There is a longstanding open feature request for this, https://phabricator.wikimedia.org/T54564 and that is perhaps the place to move to a discussion of which parts of the code would need to be reviewed, if sitelinks to redirects are to become mainstream.
-- James.
On 10/12/2014 06:10, Ricordisamoa wrote:
I think the redirects issue has been raised here to make up for the poor Wikidata-Wikipedia integration we currently have. I imagine Winter showing a list of "related articles in other languages". Reusing one of the examples: when viewing [[en:Rob Bourdon]], the software should infer from [[d:Q19205]] that Rob Bourdon is /member of/ Linkin Park (Q261), for which the German Wikipedia has an article, that will in turn be linked. Very little brain work is needed to understand that the German article about the band is likely to contain information about individual members. While this may sound Reasonator-ish, if correctly implemented in Wikibase it could improve interlanguage and interproject links in a way that just cannot be achieved with redirects. Imagine the Wikipedia entries for "Linkin Park" linking (pun intended) to Wikiquote entries of each member.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hoi, Maybe. At the same time other people are equally opposed to what you favour so much. Your approach is one that is very much Wikipedia oriented. It is not something that makes sense with a more Wikidata oriented approach.
The point is that quite often Wikidata is more informative than what Wikipedia has to say in these redirects. It is also much better to link to Reasonator to inform you about missing information than referring to disambiguation pages or use redirects.
Really your approach does not consider the relevance the information Wikidata and Reasonator holds. Thanks, GerardM
On 10 December 2014 at 10:06, James Heald j.heald@ucl.ac.uk wrote:
The trouble is that a particular individual may have many memberships and affiliations -- some perhaps to small units like bands; but some to larger groups like clubs, or artistic movements.
It's better to let humans decide where is the best place in a particular language to redirect people looking for information about a particular person or thing.
And that then also covers hatmakers/hatmaking, or Bonnie and Clyde, and every other example which is not just about a member of bands.
This discussion has been going on for two years now, and every time it has come up (which has been many times -- at least a dozen now?), there have been an overwhelming number of people supporting allowing and marking site-links to redirects.
It's now time to move forward.
In particular, what are the parts of the code that assume sitelinks cannot be to redirects (or that update sitelinks if pages are turned into redirects) ? How do these need to be adjusted, if we move to a model of allowing sitelinks to redirects, but only if a user has explicitly confirmed that that is what they want.
There is a longstanding open feature request for this, https://phabricator.wikimedia.org/T54564 and that is perhaps the place to move to a discussion of which parts of the code would need to be reviewed, if sitelinks to redirects are to become mainstream.
-- James.
On 10/12/2014 06:10, Ricordisamoa wrote:
I think the redirects issue has been raised here to make up for the poor Wikidata-Wikipedia integration we currently have. I imagine Winter showing a list of "related articles in other languages". Reusing one of the examples: when viewing [[en:Rob Bourdon]], the software should infer from [[d:Q19205]] that Rob Bourdon is /member of/ Linkin Park (Q261), for which the German Wikipedia has an article, that will in turn be linked. Very little brain work is needed to understand that the German article about the band is likely to contain information about individual members. While this may sound Reasonator-ish, if correctly implemented in Wikibase it could improve interlanguage and interproject links in a way that just cannot be achieved with redirects. Imagine the Wikipedia entries for "Linkin Park" linking (pun intended) to Wikiquote entries of each member.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
I think your point is of limited relevance, Gerard.
* If somebody searches on Wikidata or Reasonator, they will be taken to the Wikidata item we have -- so this proposal will make no difference.
* If somebody searches on xx-Wikipedia, and if there is already a redirect, they will be taken to the redirected item, just as they are at the moment -- so this proposal will make no difference.
* If somebody is reading an article on yy-Wikipedia, and wonders how the material is covered on xx-Wikipedia, they will now be able to see that there is not a directly equivalent item, but it is handled by a redirect. That is information we currently do not show them, that may in many cases be useful -- eg it prompts them to look to see whether xx-Wikipedia's existing coverage is adequate, or whether xx-Wikipedia would benefit from a new article being published.
It's worth noting, if they're looking at yy-Wikipedia, they will still be able to see a link to Wikidata (which could/should be made more prominent, by moving it to the "in other projects" part of the sidebar), and from the Wikidata item they can navigate to Reasonator, just as they do at the moment.
* The only real difference is for people searching in xx-Wikipedia, if that get taken to new redirects that didn't previously exist, but that permitting this has encouraged people to create. Your complaint seems to be that they aren't offered a Wikidata/Reasonator link instead.
But then, they're not offered a Wikidata/Reasonator link at the moment -- so really nothing is being loss. Instead, I take what you're saying as a feature request: if somebody is searching on xx-Wikipedia, and that search would have hits on Reasonator that are different from wherever a redirect would point to, then present those options as well.
But either way, that is a future feature request, because it's not an option that people get presented with at the moment.
Finally, you write that the thinking is "very much Wikipedia oriented". And to an extent that is true, because this *is* about the sidelinks people see when they are browsing Wikipedia, and really it affects Wikidata hardly at all -- very little either way.
But there would be one significant advantage for Wikidata, I think:
If people could accurately link to redirects, I think we would have better hygiene here about what items are instances or subclasses of -- eg whether an item was for a profession/professional -- because there would no longer be such a motivation to something that many people do really quite often now -- namely to lump together articles of different kinds from different Wikipedias, purely for the sake of preserving sitelinks, rather than to much more clearly define an item and its true sublinks to strictly reflect what it is an instance of. That is a current problem that I think facilitating sitelinks to redirects would I hope help ease.
All best,
James.
On 10/12/2014 10:11, Gerard Meijssen wrote:
Hoi, Maybe. At the same time other people are equally opposed to what you favour so much. Your approach is one that is very much Wikipedia oriented. It is not something that makes sense with a more Wikidata oriented approach.
The point is that quite often Wikidata is more informative than what Wikipedia has to say in these redirects. It is also much better to link to Reasonator to inform you about missing information than referring to disambiguation pages or use redirects.
Really your approach does not consider the relevance the information Wikidata and Reasonator holds. Thanks, GerardM
On 10 December 2014 at 10:06, James Heald j.heald@ucl.ac.uk wrote:
The trouble is that a particular individual may have many memberships and affiliations -- some perhaps to small units like bands; but some to larger groups like clubs, or artistic movements.
It's better to let humans decide where is the best place in a particular language to redirect people looking for information about a particular person or thing.
And that then also covers hatmakers/hatmaking, or Bonnie and Clyde, and every other example which is not just about a member of bands.
This discussion has been going on for two years now, and every time it has come up (which has been many times -- at least a dozen now?), there have been an overwhelming number of people supporting allowing and marking site-links to redirects.
It's now time to move forward.
In particular, what are the parts of the code that assume sitelinks cannot be to redirects (or that update sitelinks if pages are turned into redirects) ? How do these need to be adjusted, if we move to a model of allowing sitelinks to redirects, but only if a user has explicitly confirmed that that is what they want.
There is a longstanding open feature request for this, https://phabricator.wikimedia.org/T54564 and that is perhaps the place to move to a discussion of which parts of the code would need to be reviewed, if sitelinks to redirects are to become mainstream.
-- James.
Hoi, The only reason why Wikidata and Reasonator are not found is because this is not configured.
yes you may think as you like and for how long as you like about Wikipedia but that does not imply anything when it is not about Wikipedia.
Redirects are evil. Thanks, GerardM
On 10 December 2014 at 13:10, James Heald j.heald@ucl.ac.uk wrote:
I think your point is of limited relevance, Gerard.
- If somebody searches on Wikidata or Reasonator, they will be taken to
the Wikidata item we have -- so this proposal will make no difference.
- If somebody searches on xx-Wikipedia, and if there is already a
redirect, they will be taken to the redirected item, just as they are at the moment -- so this proposal will make no difference.
- If somebody is reading an article on yy-Wikipedia, and wonders how the
material is covered on xx-Wikipedia, they will now be able to see that there is not a directly equivalent item, but it is handled by a redirect. That is information we currently do not show them, that may in many cases be useful -- eg it prompts them to look to see whether xx-Wikipedia's existing coverage is adequate, or whether xx-Wikipedia would benefit from a new article being published.
It's worth noting, if they're looking at yy-Wikipedia, they will still be able to see a link to Wikidata (which could/should be made more prominent, by moving it to the "in other projects" part of the sidebar), and from the Wikidata item they can navigate to Reasonator, just as they do at the moment.
- The only real difference is for people searching in xx-Wikipedia, if
that get taken to new redirects that didn't previously exist, but that permitting this has encouraged people to create. Your complaint seems to be that they aren't offered a Wikidata/Reasonator link instead.
But then, they're not offered a Wikidata/Reasonator link at the moment -- so really nothing is being loss. Instead, I take what you're saying as a feature request: if somebody is searching on xx-Wikipedia, and that search would have hits on Reasonator that are different from wherever a redirect would point to, then present those options as well.
But either way, that is a future feature request, because it's not an option that people get presented with at the moment.
Finally, you write that the thinking is "very much Wikipedia oriented". And to an extent that is true, because this *is* about the sidelinks people see when they are browsing Wikipedia, and really it affects Wikidata hardly at all -- very little either way.
But there would be one significant advantage for Wikidata, I think:
If people could accurately link to redirects, I think we would have better hygiene here about what items are instances or subclasses of -- eg whether an item was for a profession/professional -- because there would no longer be such a motivation to something that many people do really quite often now -- namely to lump together articles of different kinds from different Wikipedias, purely for the sake of preserving sitelinks, rather than to much more clearly define an item and its true sublinks to strictly reflect what it is an instance of. That is a current problem that I think facilitating sitelinks to redirects would I hope help ease.
All best,
James.
On 10/12/2014 10:11, Gerard Meijssen wrote:
Hoi, Maybe. At the same time other people are equally opposed to what you favour so much. Your approach is one that is very much Wikipedia oriented. It is not something that makes sense with a more Wikidata oriented approach.
The point is that quite often Wikidata is more informative than what Wikipedia has to say in these redirects. It is also much better to link to Reasonator to inform you about missing information than referring to disambiguation pages or use redirects.
Really your approach does not consider the relevance the information Wikidata and Reasonator holds. Thanks, GerardM
On 10 December 2014 at 10:06, James Heald j.heald@ucl.ac.uk wrote:
The trouble is that a particular individual may have many memberships and
affiliations -- some perhaps to small units like bands; but some to larger groups like clubs, or artistic movements.
It's better to let humans decide where is the best place in a particular language to redirect people looking for information about a particular person or thing.
And that then also covers hatmakers/hatmaking, or Bonnie and Clyde, and every other example which is not just about a member of bands.
This discussion has been going on for two years now, and every time it has come up (which has been many times -- at least a dozen now?), there have been an overwhelming number of people supporting allowing and marking site-links to redirects.
It's now time to move forward.
In particular, what are the parts of the code that assume sitelinks cannot be to redirects (or that update sitelinks if pages are turned into redirects) ? How do these need to be adjusted, if we move to a model of allowing sitelinks to redirects, but only if a user has explicitly confirmed that that is what they want.
There is a longstanding open feature request for this, https://phabricator.wikimedia.org/T54564 and that is perhaps the place to move to a discussion of which parts of the code would need to be reviewed, if sitelinks to redirects are to become mainstream.
-- James.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Redirects are great! They belong locally though and should not be attempted cross-wiki
On Wed, Dec 10, 2014 at 1:50 PM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, The only reason why Wikidata and Reasonator are not found is because this is not configured.
yes you may think as you like and for how long as you like about Wikipedia but that does not imply anything when it is not about Wikipedia.
Redirects are evil. Thanks, GerardM
On 10 December 2014 at 13:10, James Heald j.heald@ucl.ac.uk wrote:
I think your point is of limited relevance, Gerard.
- If somebody searches on Wikidata or Reasonator, they will be taken to
the Wikidata item we have -- so this proposal will make no difference.
- If somebody searches on xx-Wikipedia, and if there is already a
redirect, they will be taken to the redirected item, just as they are at the moment -- so this proposal will make no difference.
- If somebody is reading an article on yy-Wikipedia, and wonders how the
material is covered on xx-Wikipedia, they will now be able to see that there is not a directly equivalent item, but it is handled by a redirect. That is information we currently do not show them, that may in many cases be useful -- eg it prompts them to look to see whether xx-Wikipedia's existing coverage is adequate, or whether xx-Wikipedia would benefit from a new article being published.
It's worth noting, if they're looking at yy-Wikipedia, they will still be able to see a link to Wikidata (which could/should be made more prominent, by moving it to the "in other projects" part of the sidebar), and from the Wikidata item they can navigate to Reasonator, just as they do at the moment.
- The only real difference is for people searching in xx-Wikipedia, if
that get taken to new redirects that didn't previously exist, but that permitting this has encouraged people to create. Your complaint seems to be that they aren't offered a Wikidata/Reasonator link instead.
But then, they're not offered a Wikidata/Reasonator link at the moment -- so really nothing is being loss. Instead, I take what you're saying as a feature request: if somebody is searching on xx-Wikipedia, and that search would have hits on Reasonator that are different from wherever a redirect would point to, then present those options as well.
But either way, that is a future feature request, because it's not an option that people get presented with at the moment.
Finally, you write that the thinking is "very much Wikipedia oriented". And to an extent that is true, because this *is* about the sidelinks people see when they are browsing Wikipedia, and really it affects Wikidata hardly at all -- very little either way.
But there would be one significant advantage for Wikidata, I think:
If people could accurately link to redirects, I think we would have better hygiene here about what items are instances or subclasses of -- eg whether an item was for a profession/professional -- because there would no longer be such a motivation to something that many people do really quite often now -- namely to lump together articles of different kinds from different Wikipedias, purely for the sake of preserving sitelinks, rather than to much more clearly define an item and its true sublinks to strictly reflect what it is an instance of. That is a current problem that I think facilitating sitelinks to redirects would I hope help ease.
All best,
James.
On 10/12/2014 10:11, Gerard Meijssen wrote:
Hoi, Maybe. At the same time other people are equally opposed to what you favour so much. Your approach is one that is very much Wikipedia oriented. It is not something that makes sense with a more Wikidata oriented approach.
The point is that quite often Wikidata is more informative than what Wikipedia has to say in these redirects. It is also much better to link to Reasonator to inform you about missing information than referring to disambiguation pages or use redirects.
Really your approach does not consider the relevance the information Wikidata and Reasonator holds. Thanks, GerardM
On 10 December 2014 at 10:06, James Heald j.heald@ucl.ac.uk wrote:
The trouble is that a particular individual may have many memberships
and affiliations -- some perhaps to small units like bands; but some to larger groups like clubs, or artistic movements.
It's better to let humans decide where is the best place in a particular language to redirect people looking for information about a particular person or thing.
And that then also covers hatmakers/hatmaking, or Bonnie and Clyde, and every other example which is not just about a member of bands.
This discussion has been going on for two years now, and every time it has come up (which has been many times -- at least a dozen now?), there have been an overwhelming number of people supporting allowing and marking site-links to redirects.
It's now time to move forward.
In particular, what are the parts of the code that assume sitelinks cannot be to redirects (or that update sitelinks if pages are turned into redirects) ? How do these need to be adjusted, if we move to a model of allowing sitelinks to redirects, but only if a user has explicitly confirmed that that is what they want.
There is a longstanding open feature request for this, https://phabricator.wikimedia.org/T54564 and that is perhaps the place to move to a discussion of which parts of the code would need to be reviewed, if sitelinks to redirects are to become mainstream.
-- James.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hoi, Some redirects are great... The ones considered in this article are awful. I have blogged [1] about an alternative to the current redirects that does provide better information in a Wikipedia context.
Thank,s GerardM
[1] http://ultimategerardm.blogspot.nl/2014/12/wikipedia-redirects-are-one-trick...
On 10 December 2014 at 14:31, Jane Darnell jane023@gmail.com wrote:
Redirects are great! They belong locally though and should not be attempted cross-wiki
On Wed, Dec 10, 2014 at 1:50 PM, Gerard Meijssen < gerard.meijssen@gmail.com> wrote:
Hoi, The only reason why Wikidata and Reasonator are not found is because this is not configured.
yes you may think as you like and for how long as you like about Wikipedia but that does not imply anything when it is not about Wikipedia.
Redirects are evil. Thanks, GerardM
On 10 December 2014 at 13:10, James Heald j.heald@ucl.ac.uk wrote:
I think your point is of limited relevance, Gerard.
- If somebody searches on Wikidata or Reasonator, they will be taken to
the Wikidata item we have -- so this proposal will make no difference.
- If somebody searches on xx-Wikipedia, and if there is already a
redirect, they will be taken to the redirected item, just as they are at the moment -- so this proposal will make no difference.
- If somebody is reading an article on yy-Wikipedia, and wonders how the
material is covered on xx-Wikipedia, they will now be able to see that there is not a directly equivalent item, but it is handled by a redirect. That is information we currently do not show them, that may in many cases be useful -- eg it prompts them to look to see whether xx-Wikipedia's existing coverage is adequate, or whether xx-Wikipedia would benefit from a new article being published.
It's worth noting, if they're looking at yy-Wikipedia, they will still be able to see a link to Wikidata (which could/should be made more prominent, by moving it to the "in other projects" part of the sidebar), and from the Wikidata item they can navigate to Reasonator, just as they do at the moment.
- The only real difference is for people searching in xx-Wikipedia, if
that get taken to new redirects that didn't previously exist, but that permitting this has encouraged people to create. Your complaint seems to be that they aren't offered a Wikidata/Reasonator link instead.
But then, they're not offered a Wikidata/Reasonator link at the moment -- so really nothing is being loss. Instead, I take what you're saying as a feature request: if somebody is searching on xx-Wikipedia, and that search would have hits on Reasonator that are different from wherever a redirect would point to, then present those options as well.
But either way, that is a future feature request, because it's not an option that people get presented with at the moment.
Finally, you write that the thinking is "very much Wikipedia oriented". And to an extent that is true, because this *is* about the sidelinks people see when they are browsing Wikipedia, and really it affects Wikidata hardly at all -- very little either way.
But there would be one significant advantage for Wikidata, I think:
If people could accurately link to redirects, I think we would have better hygiene here about what items are instances or subclasses of -- eg whether an item was for a profession/professional -- because there would no longer be such a motivation to something that many people do really quite often now -- namely to lump together articles of different kinds from different Wikipedias, purely for the sake of preserving sitelinks, rather than to much more clearly define an item and its true sublinks to strictly reflect what it is an instance of. That is a current problem that I think facilitating sitelinks to redirects would I hope help ease.
All best,
James.
On 10/12/2014 10:11, Gerard Meijssen wrote:
Hoi, Maybe. At the same time other people are equally opposed to what you favour so much. Your approach is one that is very much Wikipedia oriented. It is not something that makes sense with a more Wikidata oriented approach.
The point is that quite often Wikidata is more informative than what Wikipedia has to say in these redirects. It is also much better to link to Reasonator to inform you about missing information than referring to disambiguation pages or use redirects.
Really your approach does not consider the relevance the information Wikidata and Reasonator holds. Thanks, GerardM
On 10 December 2014 at 10:06, James Heald j.heald@ucl.ac.uk wrote:
The trouble is that a particular individual may have many memberships
and affiliations -- some perhaps to small units like bands; but some to larger groups like clubs, or artistic movements.
It's better to let humans decide where is the best place in a particular language to redirect people looking for information about a particular person or thing.
And that then also covers hatmakers/hatmaking, or Bonnie and Clyde, and every other example which is not just about a member of bands.
This discussion has been going on for two years now, and every time it has come up (which has been many times -- at least a dozen now?), there have been an overwhelming number of people supporting allowing and marking site-links to redirects.
It's now time to move forward.
In particular, what are the parts of the code that assume sitelinks cannot be to redirects (or that update sitelinks if pages are turned into redirects) ? How do these need to be adjusted, if we move to a model of allowing sitelinks to redirects, but only if a user has explicitly confirmed that that is what they want.
There is a longstanding open feature request for this, https://phabricator.wikimedia.org/T54564 and that is perhaps the place to move to a discussion of which parts of the code would need to be reviewed, if sitelinks to redirects are to become mainstream.
-- James.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Baking domain knowledge (e.g. about the relationship between bands and members) into the software is not a good thing. In fact, it's pretty horrible. If you can suggest a way to do what you want without hard-coding domain knowledge (e.g. by lettign the software "know" what certain properties "mean"), please do, I'd be very interested.
In general, making the software "smart" requires it to be less flexible for users. If the software is to make assumptions, it also has to enforce these assumptions, taking away freedom. That's the opposite of the wiki principle.
Am 10.12.2014 07:10, schrieb Ricordisamoa:
I think the redirects issue has been raised here to make up for the poor Wikidata-Wikipedia integration we currently have. I imagine Winter showing a list of "related articles in other languages". Reusing one of the examples: when viewing [[en:Rob Bourdon]], the software should infer from [[d:Q19205]] that Rob Bourdon is /member of/ Linkin Park (Q261), for which the German Wikipedia has an article, that will in turn be linked. Very little brain work is needed to understand that the German article about the band is likely to contain information about individual members. While this may sound Reasonator-ish, if correctly implemented in Wikibase it could improve interlanguage and interproject links in a way that just cannot be achieved with redirects. Imagine the Wikipedia entries for "Linkin Park" linking (pun intended) to Wikiquote entries of each member.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
I'm against that, too. Relationships could be inferred by which properties are the most common on similar items, and by which pages have the highest ratio of common links.
Il 10/12/2014 10:12, Daniel Kinzler ha scritto:
Baking domain knowledge (e.g. about the relationship between bands and members) into the software is not a good thing. In fact, it's pretty horrible. If you can suggest a way to do what you want without hard-coding domain knowledge (e.g. by lettign the software "know" what certain properties "mean"), please do, I'd be very interested.
In general, making the software "smart" requires it to be less flexible for users. If the software is to make assumptions, it also has to enforce these assumptions, taking away freedom. That's the opposite of the wiki principle.
Am 10.12.2014 07:10, schrieb Ricordisamoa:
I think the redirects issue has been raised here to make up for the poor Wikidata-Wikipedia integration we currently have. I imagine Winter showing a list of "related articles in other languages". Reusing one of the examples: when viewing [[en:Rob Bourdon]], the software should infer from [[d:Q19205]] that Rob Bourdon is /member of/ Linkin Park (Q261), for which the German Wikipedia has an article, that will in turn be linked. Very little brain work is needed to understand that the German article about the band is likely to contain information about individual members. While this may sound Reasonator-ish, if correctly implemented in Wikibase it could improve interlanguage and interproject links in a way that just cannot be achieved with redirects. Imagine the Wikipedia entries for "Linkin Park" linking (pun intended) to Wikiquote entries of each member.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Am 10.12.2014 13:16, schrieb Ricordisamoa:
I'm against that, too. Relationships could be inferred by which properties are the most common on similar items, and by which pages have the highest ratio of common links.
Statistics-based heuristics could work for this, but they make it hard to do things explicitly. People are used to directly edit content, not to rely on vague heuristics to do roughly what they like.
I'm not saying that it shouldn't be done, I'm just saying that it would mean a departuere from the wiki principle of "everythign is editable, nothing is automatic".
Also, such an approach needs considerable database power and causes some operations & maintenance overhead. Doable, sure, but a cost to be considered. I know the WMF's budget sounds big, but compared to other operations that run a web site on this scale, it's rediculously low. There is little head room for stuff like this.
Again, not saying it shouldn't be done. Just saying it's not going to happen tomorrow, and there's quite a few things to consider.
Hi,
On Wed, Dec 10, 2014 at 11:12 AM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Baking domain knowledge (e.g. about the relationship between bands and members) into the software is not a good thing. In fact, it's pretty horrible. If you can suggest a way to do what you want without hard-coding domain knowledge (e.g. by lettign the software "know" what certain properties "mean"), please do, I'd be very interested.
depends on what you consider ›the software‹. From my point of view, a software is there to solve domain-specific problems, and as such, has to have domain knowledge. Otherwise, it's useless. The question is, which software solves which problem, and which problems are not solved at all or solved by humans. Wikibase generally shouldn't know about Wikidata's content. That doesn't mean that no software may know about it; in fact, some gadgets know a lot about it, and tools do so, too. I think there is a case for having domain knowledge in PHP code on the servers, too.
Bye, Adrian
Am 10.12.2014 13:47, schrieb Adrian Lang:
depends on what you consider ›the software‹. From my point of view, a software is there to solve domain-specific problems, and as such, has to have domain knowledge. Otherwise, it's useless. The question is, which software solves which problem, and which problems are not solved at all or solved by humans. Wikibase generally shouldn't know about Wikidata's content. That doesn't mean that no software may know about it; in fact, some gadgets know a lot about it, and tools do so, too. I think there is a case for having domain knowledge in PHP code on the servers, too.
I agree with your general point: we could have an extension or gadget or whatever on top of Wikibase that holds (some) domain specific knowledge about the properties used on wikidata.org.
If that knowledge is coded into an extension that needs code review and deployments to be updated, we have to be aware that it's not going to be very flexible. The question is then how to manage the configuration and update of that bit of softare.
In general, that kind of thing is more easily done with JS or Lua, since it's under the direct control of the local wiki community. I kind of like the idea of making our Lua integration more powerful, so it could be used to manipulate the skin and talk to the API, not just generate article content.