1. as mentioned several times, a standard for us to be considered must be free. Free as in "Everyone can get it without having to pay or register for it. I can give it to anyone legally without any restrictions." Free of patents. Free as in W3C.
2. I have taken another look at your page, and after starting to read it you simply loose me. You use so many terms without defining them. To give just a few examples: * "The NIF ontology is incorporated into the ontology for Wikitopics which shapes API designs." I do not know what the Wikitopics ontology is. The section beneath just lists a few keywords, but does not really explain it. I do not know what it means for ontologies to incorporate one another. I do not know what it means for an ontology to shape API designs. * "Wikipage naming conventions are used to name subobjects in an equally meaningful manner". Equally meaningful? To what? What does this even mean? You completely lost me here. * For the key wikipage transclusions, you do not explain what a "formatted topic presentation" is, a "formatted topic index", or a "formatted infobox". I think I understand the latter, but not the previous two. What are they? And if I indeed understand it right, are you saying that infoboxes have to be completely formatted in Wikidata, as Gregor has asked?
Hello Denny,
1. There are likely several ways to accommodate your process requirements. And btw, I asked last month but received no response for a citation to relevant MWF policy on this issue, to detect whether your statement reflects the team's ELECTIVE policy or a MWF policy. Where's the benefit from imposing expenses magnitudes greater on everyone, to design develop & socialize solutions already known? And please mention how the wikidata community can be assured that the wikidata team's designs themselves don't infringe someone else's patent or copyright, a reassurance that would directly follow from MWF's purchase of rights to use an ISO standard.
2a. Surely you appreciate that Wikidata involves fielding ''some'' ontology, at least as suggested by your intention to include the (SMW) Property namespace. I don't know when you plan to publish wikidata's ontology, but certainly it must be done so overtly and soon, agile or not. I agree the ontology I proposed needs much fleshing out, but chief goals of the proposed ontology are pretty clear -- to provide a wiki-topic index, to support NIF tools directly, to capture provenance data, to reuse existing SMW tools and key international standards, and to establish various best-practices for the wider community.
2b. An ontology that 'shapes/controls API interfaces' means that the APIs' information model must align with the information model represented by the ontology. If the ontology includes an expiration-date as a required property, for instance, then the API needs to include an expiration-date as a required parameter in some fashion.
2c. One ontology incorporating another is perhaps a clumsy way to describe the process of associating a class or property defined in one ontology, to another in a different ontology, either through a subclass/subproperty relation or a documented or implemented transform.
2d."Equally meaningful" as the wiki-page naming conventions are, eg interwiki:lang:ns:pgnm is quite meaningful ... I am proposing SMW subobjects be named similarly, eg scope:lang:type:name, is the proposed structure for SMW subobject names.
2e. A 'formatted topic presentation' is the content displayed on a page for a topic. Wikidata will have a page called (Main:)Thomas Jefferson that displays a formatted topic presentation, showing information harvested from other wikis plus any information developed by the wikidata community itself. Using transclusion, anyone can embed (Main:)Thomas Jefferson into their wiki. A 'formatted topic index' (which certainly can be one part of a topic's formatted presentation) is a snippet that corresponds to the "Thomas Jefferson" heading in a subject index under which are many subtopics eg Jefferson, Thomas [1] [2] [3] -- Early years [4] [5] [6] -- Birth [7] [8] -- Formative influences [9] [10] -- etc
2f. Perhaps you missed my immediate reply [1] to Gregor. Yes all infoboxes (among other non/formatted artifacts) are '''transcluded''' from wikidata, without the nonsense of cross-wiki API calls for individual data-items, as I understand the wikidata team is now gearing to provide.
Best regards - jmc
[1] http://lists.wikimedia.org/pipermail/wikidata-l/2012-May/000588.html , for instance
Hi JMC,
thank you for the explanations, I understand quite better now.
Re 1, I regard it as pretty obvious. But here's the relevant sentence taken fromt he Wikimedia values: "We believe that this mission requires thriving open formats and open standards on the web to allow the creation of content not subject to restrictions on creation, use, and reuse." [1]
Anyway, we *are* building on existing standards - RDF and JSON most prominently - and thus I would disagree that we are reinventing too much.
Re 2a-c: understood.
Re 2d: I am afraid I missed what you mean with scope and type and name in your naming scheme. Can you give an example?
Re 2e: I am not sure if I understand what you mean with index, and where that would be used. Do you mean to replace the "Table of Content" in the local Wikipedia articles with a standardized ToC maintained in Wikidata? This would necessitate the alignment of the Wikipedias in a much stronger sense than it is currently the case and also beyond what Wikidata would incur in its current setting.
Re 2f: as far as I understand your suggestion of using interwiki transclusion right, that would impose much more on the local Wikipedias than our nonsense cross-wiki calls. Have you ever been involved in the discussion which color a certain infobox should have? These are furious enough on the single language Wikipedias, I would prefer not to have these discussions on Wikidata. The current plan for Wikidata assumes that we just provide the data -- but the rendering remains in the authority of the local wiki. Having the whole infobox being created and maintained in Wikidata in an internationalizable way seems to require much more effort than what we have currently planned. You do not have one central place where you decide which properties you want to display for an entity, which sources to select, which color to use for the infobox, which infobox to use (is Schwarzenegger a Politician, an Actor, or something else?), etc. These decisions do not need to be imposed on the local Wikipedias.
On the other hand, you are not the only person thinking that this is a good idea (hello Gerard!), and in the long run Wikidata could be extended to such a system -- but for now I regard this to be out of scope for Wikidata and I will not devote resources for this. It can be added later anyway.
Cheers, Denny
[1] http://wikimediafoundation.org/wiki/Values
2012/6/11 jmcclure@hypergrove.com
**
- as mentioned several times, a standard for us to be considered must be free. Free as in "Everyone can get it without having to pay or register for
it. I can give it to anyone legally without any restrictions." Free of patents. Free as in W3C.
- I have taken another look at your page, and after starting to read it you simply loose me. You use so many terms without defining them. To give
just a few examples:
- "The NIF ontology is incorporated into the ontology for Wikitopics which shapes API designs." I do not know what the Wikitopics ontology is. The
section beneath just lists a few keywords, but does not really explain it. I do not know what it means for ontologies to incorporate one another. I do not know what it means for an ontology to shape API designs.
- "Wikipage naming conventions are used to name subobjects in an equally meaningful manner". Equally meaningful? To what? What does this even mean? You completely lost me here.
- For the key wikipage transclusions, you do not explain what a "formatted topic presentation" is, a "formatted topic index", or a "formatted
infobox". I think I understand the latter, but not the previous two. What are they? And if I indeed understand it right, are you saying that infoboxes have to be completely formatted in Wikidata, as Gregor has asked?
Hello Denny,
- There are likely several ways to accommodate your process requirements.
And btw, I asked last month but received no response for a citation to relevant MWF policy on this issue, to detect whether your statement reflects the team's ELECTIVE policy or a MWF policy. Where's the benefit from imposing expenses magnitudes greater on everyone, to design develop & socialize solutions already known? And please mention how the wikidata community can be assured that the wikidata team's designs themselves don't infringe someone else's patent or copyright, a reassurance that would directly follow from MWF's purchase of rights to use an ISO standard.
2a. Surely you appreciate that Wikidata involves fielding ''some'' ontology, at least as suggested by your intention to include the (SMW) Property namespace. I don't know when you plan to publish wikidata's ontology, but certainly it must be done so overtly and soon, agile or not. I agree the ontology I proposed needs much fleshing out, but chief goals of the proposed ontology are pretty clear -- to provide a wiki-topic index, to support NIF tools directly, to capture provenance data, to reuse existing SMW tools and key international standards, and to establish various best-practices for the wider community.
2b. An ontology that 'shapes/controls API interfaces' means that the APIs' information model must align with the information model represented by the ontology. If the ontology includes an expiration-date as a required property, for instance, then the API needs to include an expiration-date as a required parameter in some fashion.
2c. One ontology incorporating another is perhaps a clumsy way to describe the process of associating a class or property defined in one ontology, to another in a different ontology, either through a subclass/subproperty relation or a documented or implemented transform.
2d."Equally meaningful" as the wiki-page naming conventions are, eg interwiki:lang:ns:pgnm is quite meaningful ... I am proposing SMW subobjects be named similarly, eg scope:lang:type:name, is the proposed structure for SMW subobject names.
2e. A 'formatted topic presentation' is the content displayed on a page for a topic. Wikidata will have a page called (Main:)Thomas Jefferson that displays a formatted topic presentation, showing information harvested from other wikis plus any information developed by the wikidata community itself. Using transclusion, anyone can embed (Main:)Thomas Jefferson into their wiki. A 'formatted topic index' (which certainly can be one part of a topic's formatted presentation) is a snippet that corresponds to the "Thomas Jefferson" heading in a subject index under which are many subtopics eg Jefferson, Thomas [1] [2] [3] -- Early years [4] [5] [6] -- Birth [7] [8] -- Formative influences [9] [10] -- etc
2f. Perhaps you missed my immediate reply [1] to Gregor. Yes all infoboxes (among other non/formatted artifacts) are '''transcluded''' from wikidata, without the nonsense of cross-wiki API calls for individual data-items, as I understand the wikidata team is now gearing to provide.
Best regards - jmc
[1] http://lists.wikimedia.org/pipermail/wikidata-l/2012-May/000588.html
, for instance
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_Hello Denny -_
_re_: 1. You're citing a policy about CONTENT, I see, though I was focusing on data models and technical interface designs. The SNAK architecture is a re-invention of RDF, do you not agree. Why is RDF being reinvented? The only explanation I've seen given on the list or on talk:Data Model, is that its Open World Assumption troubles you all. Because of _that_ we all have to learn a new information architecture?
1a. If you were to identify the datamodel of the system that you're extending, as one might expect, surely you'd eventually point to "topic" as fundamental to wiki structure. Instead, the pseudo-intellectual name "entity" is chosen, which disturbs me and others -- can't you see that using ambiguous words unrelated to accepted subject-matter taxonomies damages the technical credibility of your work? Why are you wasting time & resources to create new terms?
1b. You fail yet to appreciate that as the XTM DTD itself is in the public sphere (as are penultimate drafts of the published ISO standard, and as are many supporting materials), that the wikidata community's need to create & understand each of the elements of the wikidata architecture is already adequately satisfied. And I suspect you've not yet explored with the ISO what accommodations they'd make specifically for the WMF about re-publication, pursuant to their published offer to do so.
1c. You're arguing over CHF 200 -- which extraordinarily-cheaply and fundamentally PROTECTS the MWF from copyright infringement suits? Can the SNAK architecture provide that reassurance to the MWF community?
_re_: 2d. I propose SMW subobjects be named very similarly to how MWF pages are named.
"NorthAmerica:en:USState:Washington" is the name of a subobject representing the English name for the US State Virginia, within the scope of North America. These scopes are user-assigned when the subobject is created and user-specified when the sobobject is queried. "USState" is type selector in the same manner as Help is a namespace-based type selector, i.e., all pages in the Help namespace are typed as help-pages.
_re_: 2e. No an index is not a toc. Subject index, topic index, historical index, whatever -- has entries that can be filtered numerious ways -- a toc has none of this. A toc refers only to the content of a page. An index does not have this constraint. So the concern that massive coordination is necessary among wikipedias under the wikitopics proposal, is not warranted.
_re_:2f. In fact, I believe that the current wikidata design requires lots of forebearance among many wikipedians that sadly is always hard to achieve. Instead of such work concentrated within wikidata where economies can be had, you rearrange the chairs by decentralizing the same work to each wiki. You won't have arguments about colors on wikidata... as the proposal said, en:Infobox:Thomas Jefferson can be a different animal entirely from de:Infobox:Thomas Jefferson. There can be even en:Infobox:Thomas Jefferson/My demo which can be transcluded instead.
_re_: "nonsense" cross-wiki calls. The standard practice when sharing information across wikis is TRANSCLUSION. Please, please let's not resurrect CORBA.
Thanks - jmc
The answer to your question about Schwarzenegger (is he a politician actor or something else? -- I vote for "something else"!) gets into issues about the Schwarzenegger page's topic map, its structure, and which pieces of it are shown in the infobox. Will try to get to that in some future draft of the wikitopics proposal.
On 12.06.2012 02:58, Denny Vrandečić wrote:
Hi JMC, thank you for
the explanations, I understand quite better now. Re 1, I regard it as pretty obvious. But here's the relevant sentence taken fromt he Wikimedia values: "We believe that this mission requires thriving open formats and open standards on the web to allow the creation of content not subject to restrictions on creation, use, and reuse." [1]
Anyway, we *are* building on existing standards - RDF and JSON most prominently - and thus I would disagree that we are reinventing too much.
Re 2a-c: understood.
Re 2d: I am afraid I missed what
you mean with scope and type and name in your naming scheme. Can you give an example?
Re 2e: I am not sure if I understand what you
mean with index, and where that would be used. Do you mean to replace the "Table of Content" in the local Wikipedia articles with a standardized ToC maintained in Wikidata? This would necessitate the alignment of the Wikipedias in a much stronger sense than it is currently the case and also beyond what Wikidata would incur in its current setting.
Re 2f: as far as I understand your suggestion of
using interwiki transclusion right, that would impose much more on the local Wikipedias than our nonsense cross-wiki calls. Have you ever been involved in the discussion which color a certain infobox should have? These are furious enough on the single language Wikipedias, I would prefer not to have these discussions on Wikidata. The current plan for Wikidata assumes that we just provide the data -- but the rendering remains in the authority of the local wiki. Having the whole infobox being created and maintained in Wikidata in an internationalizable way seems to require much more effort than what we have currently planned. You do not have one central place where you decide which properties you want to display for an entity, which sources to select, which color to use for the infobox, which infobox to use (is Schwarzenegger a Politician, an Actor, or something else?), etc. These decisions do not need to be imposed on the local Wikipedias.
On the other hand, you
are not the only person thinking that this is a good idea (hello Gerard!), and in the long run Wikidata could be extended to such a system -- but for now I regard this to be out of scope for Wikidata and I will not devote resources for this. It can be added later anyway.
Cheers, Denny
[4]
2012/6/11 <jmcclure@hypergrove.com [5]>
- as mentioned
several times, a standard for us to be considered must be free. Free as in "Everyone can get it without having to pay or register for
it. I
can give it to anyone legally without any restrictions." Free of patents. Free as in W3C.
- I have taken another look at your
page, and after starting to read it you simply loose me. You use so many terms without defining them. To give
just a few examples:
- "The
NIF ontology is incorporated into the ontology for Wikitopics which shapes API designs." I do not know what the Wikitopics ontology is. The
section beneath just lists a few keywords, but does not really
explain it. I do not know what it means for ontologies to incorporate one another. I do
not know what it means for an ontology to shape API
designs.
- "Wikipage naming conventions are used to name subobjects
in an equally meaningful manner". Equally meaningful? To what? What does this even mean? You completely lost me here.
- For the key wikipage
transclusions, you do not explain what a "formatted topic presentation" is, a "formatted topic index", or a "formatted
infobox". I think I
understand the latter, but not the previous two. What are they? And if I indeed understand it right, are you saying that
infoboxes have to be
completely formatted in Wikidata, as Gregor has asked?
Hello
Denny,
- There are likely several ways to accommodate your
process requirements. And btw, I asked last month but received no response for a citation to relevant MWF policy on this issue, to detect whether your statement reflects the team's ELECTIVE policy or a MWF policy. Where's the benefit from imposing expenses magnitudes greater on everyone, to design develop & socialize solutions already known? And please mention how the wikidata community can be assured that the wikidata team's designs themselves don't infringe someone else's patent or copyright, a reassurance that would directly follow from MWF's purchase of rights to use an ISO standard.
2a. Surely you
appreciate that Wikidata involves fielding ''some'' ontology, at least as suggested by your intention to include the (SMW) Property namespace. I don't know when you plan to publish wikidata's ontology, but certainly it must be done so overtly and soon, agile or not. I agree the ontology I proposed needs much fleshing out, but chief goals of the proposed ontology are pretty clear -- to provide a wiki-topic index, to support NIF tools directly, to capture provenance data, to reuse existing SMW tools and key international standards, and to establish various best-practices for the wider community.
2b. An ontology that
'shapes/controls API interfaces' means that the APIs' information model must align with the information model represented by the ontology. If the ontology includes an expiration-date as a required property, for instance, then the API needs to include an expiration-date as a required parameter in some fashion.
2c. One ontology incorporating
another is perhaps a clumsy way to describe the process of associating a class or property defined in one ontology, to another in a different ontology, either through a subclass/subproperty relation or a documented or implemented transform.
2d."Equally meaningful" as the
wiki-page naming conventions are, eg interwiki:lang:ns:pgnm is quite meaningful ... I am proposing SMW subobjects be named similarly, eg scope:lang:type:name, is the proposed structure for SMW subobject names.
2e. A 'formatted topic presentation' is the content displayed on
a page for a topic. Wikidata will have a page called (Main:)Thomas Jefferson that displays a formatted topic presentation, showing information harvested from other wikis plus any information developed by the wikidata community itself. Using transclusion, anyone can embed (Main:)Thomas Jefferson into their wiki. A 'formatted topic index' (which certainly can be one part of a topic's formatted presentation) is a snippet that corresponds to the "Thomas Jefferson" heading in a subject index under which are many subtopics eg
Jefferson, Thomas
[1] [2] [3]
-- Early years [4] [5] [6]
-- Birth [7] [8]
Formative influences [9] [10]
-- etc
2f. Perhaps you missed
my immediate reply [1] to Gregor. Yes all infoboxes (among other non/formatted artifacts) are '''transcluded''' from wikidata, without the nonsense of cross-wiki API calls for individual data-items, as I understand the wikidata team is now gearing to provide.
Best
regards - jmc
[1]
http://lists.wikimedia.org/pipermail/wikidata-l/2012-May/000588.html [1]
, for instance
_______________________________________________
Wikidata-l mailing
list
Wikidata-l@lists.wikimedia.org [2]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l [3]
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr.
2 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de [6]
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens
e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
obscuring untethered
Links: ------ [1] http://lists.wikimedia.org/pipermail/wikidata-l/2012-May/000588.html [2] mailto:Wikidata-l@lists.wikimedia.org [3] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [4] http://wikimediafoundation.org/wiki/Values [5] mailto:jmcclure@hypergrove.com [6] http://wikimedia.de
Denny said: On the other hand, you are not the only person thinking that this (Wikitopics) is a good idea (hello Gerard!), and in the long run Wikidata could be extended to such a system -- but for now I regard this to be out of scope for Wikidata and I will not devote resources for this. _IT CAN BE ADDED LATER ANYWAY_.
Denny,
I never see the long-run! Anyway, to get real, be aware there are specific concerns about [[wikidata]] within the SMW community in the here and now:
* we worry that our sites are threatened by virtual cessation of SMW development -- this may already be happening a bit as SMW subjectively seems to be encountering quality control issues lately
* we worry that, whenever we install the [[Wikidata]] extension, then the performance of client sites will be affected by the burden of multiple forms, query and format software modules, syntaxes, styles, artifacts etc
* we worry that, since no specific problems experienced by wiki-users have yet been identified that [[Wikidata]] will "fix", in the end, [[wikidata]] is doomed for not creating stakeholders within the wiki-user community that includes SMW developers.
jmc
Hoi, There are several points WHY a centrally administered info box makes sense. The most important one can be found in what the Wikimedia Foundation aims to achieve: Imagine a world in which every single human being can freely share in the sum of all knowledge [1]]. This is what we are about, everything that prevents this from happening are excuses
When you consider the number of articles in most Wikipedias, it is easy to see that the English Wikipedia has more info boxes then many of them have articles. By providing the facility to have centrally maintained info boxes, these info boxes will be extremely light weight as both the information and the labels will be maintained in Wikidata. The result is information that is available for localisation. This localisation consists of translating the labels and possibly the information items. I blogged about this in the past ... [2]
I am an advisor to the Wikidata project and as such it is my job to make these arguments. Denny is the project manager for the Wikidata project and it is his job to ensure that his team will deliver on the agreed deliverables. Having centrally maintained templates is not part of what his team has agreed to or can be expected to deliver in the short term. This is a valid excuse; it is valid for now.
An excuse for the Wikidata development team does not prevent other people from developing this functionality in stead. The basic requirement is for Wikidata to be able to have translatable data items associated with a Wikipedia article. As each of those items are uniquely identified, they can be identified in a template. This template should only refer to the data items.
When this functionality is developed, the basic functionality is ready to consider the use of such templates for real in Wikidata clients.
I am confident that there are plenty people who have the expertise to make a functional prototype. Such a prototype can be reviewed by any MediaWiki reviewer for the usual MediaWiki criteria. When this is done, it is no longer an unreasonable burden for the Wikidata team to consider the functionality of such prototypes. Thanks, Gerard
[1] www.wikimediafoundation.org [2] http://ultimategerardm.blogspot.nl/2012/05/wmdevdays-wikidata.html
On 13 June 2012 00:03, jmcclure@hypergrove.com wrote:
**
Denny said: On the other hand, you are not the only person thinking that this (Wikitopics) is a good idea (hello Gerard!), and in the long run Wikidata could be extended to such a system -- but for now I regard this to be out of scope for Wikidata and I will not devote resources for this. *It can be added later anyway*.
Denny,
I never see the long-run! Anyway, to get real, be aware there are specific concerns about [[wikidata]] within the SMW community in the here and now:
- we worry that our sites are threatened by virtual cessation of SMW
development -- this may already be happening a bit as SMW subjectively seems to be encountering quality control issues lately
- we worry that, whenever we install the [[Wikidata]] extension, then the
performance of client sites will be affected by the burden of multiple forms, query and format software modules, syntaxes, styles, artifacts etc
- we worry that, since no specific problems experienced by wiki-users have
yet been identified that [[Wikidata]] will "fix", in the end, [[wikidata]] is doomed for not creating stakeholders within the wiki-user community that includes SMW developers.
jmc
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Gerard,
Sure there's plenty of people who can build a prototype application of this sort -- most people pay mortgages though so it'd be nice (if not required) to get compensated for such work, as you & the wikidata team are.
re the wikidata excuse: it's wise to change one's heading before one's lost. Personally I think anyone creating an smw-based extension will do so far more swiftly (and cheaply) than what the wikidata team currently has in mind, ie, to rewrite SMW (and various of its extensions) almost from scratch. I have proposed the outline of such an application at [[meta:wikitopics]]. I'm even convinced that the SMW-based application as proposed will be faster operationally.
John
On 13.06.2012 00:52, Gerard Meijssen wrote:
Hoi, There are
several points WHY a centrally administered info box makes sense. The most important one can be found in what the Wikimedia Foundation aims to achieve: Imagine a world in which every single human being can freely share in the sum of all knowledge [1]]. This is what we are about, everything that prevents this from happening are excuses
When you
consider the number of articles in most Wikipedias, it is easy to see that the English Wikipedia has more info boxes then many of them have articles. By providing the facility to have centrally maintained info boxes, these info boxes will be extremely light weight as both the information and the labels will be maintained in Wikidata. The result is information that is available for localisation. This localisation consists of translating the labels and possibly the information items. I blogged about this in the past ... [2]
I am an advisor to the
Wikidata project and as such it is my job to make these arguments. Denny is the project manager for the Wikidata project and it is his job to ensure that his team will deliver on the agreed deliverables. Having centrally maintained templates is not part of what his team has agreed to or can be expected to deliver in the short term. This is a valid excuse; it is valid for now.
An excuse for the Wikidata development
team does not prevent other people from developing this functionality in stead. The basic requirement is for Wikidata to be able to have translatable data items associated with a Wikipedia article. As each of those items are uniquely identified, they can be identified in a template. This template should only refer to the data items.
When
this functionality is developed, the basic functionality is ready to consider the use of such templates for real in Wikidata clients.
I am
confident that there are plenty people who have the expertise to make a functional prototype. Such a prototype can be reviewed by any MediaWiki reviewer for the usual MediaWiki criteria. When this is done, it is no longer an unreasonable burden for the Wikidata team to consider the functionality of such prototypes.
Thanks, Gerard [1]
www.wikimediafoundation.org [3]
[2]
http://ultimategerardm.blogspot.nl/2012/05/wmdevdays-wikidata.html [4]
On 13 June 2012 00:03, <jmcclure@hypergrove.com [5]> wrote:
Denny said: On the other hand, you are not the only person thinking that this (Wikitopics) is a good idea (hello Gerard!), and in the long run Wikidata could be extended to such a system -- but for now I regard this to be out of scope for Wikidata and I will not devote resources for this. _IT CAN BE ADDED LATER ANYWAY_.
Denny,
I never see
the long-run! Anyway, to get real, be aware there are specific concerns about [[wikidata]] within the SMW community in the here and now:
* we worry that our sites are threatened by virtual cessation of SMW development -- this may already be happening a bit as SMW subjectively seems to be encountering quality control issues lately
- we
worry that, whenever we install the [[Wikidata]] extension, then the performance of client sites will be affected by the burden of multiple forms, query and format software modules, syntaxes, styles, artifacts etc
- we worry that, since no specific problems experienced by
wiki-users have yet been identified that [[Wikidata]] will "fix", in the end, [[wikidata]] is doomed for not creating stakeholders within the wiki-user community that includes SMW developers.
jmc
_______________________________________________
Wikidata-l mailing
list
Wikidata-l@lists.wikimedia.org [1]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l [2]
Links: ------ [1] mailto:Wikidata-l@lists.wikimedia.org [2] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [3] http://www.wikimediafoundation.org [4] http://ultimategerardm.blogspot.nl/2012/05/wmdevdays-wikidata.html [5] mailto:jmcclure@hypergrove.com
Hoi, For the record, what I do for the Wikidata project I do in my own time .. Thanks, Gerard
On 13 June 2012 21:34, jmcclure@hypergrove.com wrote:
**
Gerard,
Sure there's plenty of people who can build a prototype application of this sort -- most people pay mortgages though so it'd be nice (if not required) to get compensated for such work, as you & the wikidata team are.
re the wikidata excuse: it's wise to change one's heading before one's lost. Personally I think anyone creating an smw-based extension will do so far more swiftly (and cheaply) than what the wikidata team currently has in mind, ie, to rewrite SMW (and various of its extensions) almost from scratch. I have proposed the outline of such an application at [[meta:wikitopics]]. I'm even convinced that the SMW-based application as proposed will be faster operationally.
John
On 13.06.2012 00:52, Gerard Meijssen wrote:
Hoi, There are several points WHY a centrally administered info box makes sense. The most important one can be found in what the Wikimedia Foundation aims to achieve: Imagine a world in which every single human being can freely share in the sum of all knowledge [1]]. This is what we are about, everything that prevents this from happening are excuses When you consider the number of articles in most Wikipedias, it is easy to see that the English Wikipedia has more info boxes then many of them have articles. By providing the facility to have centrally maintained info boxes, these info boxes will be extremely light weight as both the information and the labels will be maintained in Wikidata. The result is information that is available for localisation. This localisation consists of translating the labels and possibly the information items. I blogged about this in the past ... [2] I am an advisor to the Wikidata project and as such it is my job to make these arguments. Denny is the project manager for the Wikidata project and it is his job to ensure that his team will deliver on the agreed deliverables. Having centrally maintained templates is not part of what his team has agreed to or can be expected to deliver in the short term. This is a valid excuse; it is valid for now. An excuse for the Wikidata development team does not prevent other people from developing this functionality in stead. The basic requirement is for Wikidata to be able to have translatable data items associated with a Wikipedia article. As each of those items are uniquely identified, they can be identified in a template. This template should only refer to the data items. When this functionality is developed, the basic functionality is ready to consider the use of such templates for real in Wikidata clients. I am confident that there are plenty people who have the expertise to make a functional prototype. Such a prototype can be reviewed by any MediaWiki reviewer for the usual MediaWiki criteria. When this is done, it is no longer an unreasonable burden for the Wikidata team to consider the functionality of such prototypes. Thanks, Gerard [1] www.wikimediafoundation.org [2] http://ultimategerardm.blogspot.nl/2012/05/wmdevdays-wikidata.html
On 13 June 2012 00:03, jmcclure@hypergrove.com wrote:
Denny said: On the other hand, you are not the only person thinking that this (Wikitopics) is a good idea (hello Gerard!), and in the long run Wikidata could be extended to such a system -- but for now I regard this to be out of scope for Wikidata and I will not devote resources for this. *It can be added later anyway*.
Denny,
I never see the long-run! Anyway, to get real, be aware there are specific concerns about [[wikidata]] within the SMW community in the here and now:
- we worry that our sites are threatened by virtual cessation of SMW
development -- this may already be happening a bit as SMW subjectively seems to be encountering quality control issues lately
- we worry that, whenever we install the [[Wikidata]] extension, then the
performance of client sites will be affected by the burden of multiple forms, query and format software modules, syntaxes, styles, artifacts etc
- we worry that, since no specific problems experienced by wiki-users
have yet been identified that [[Wikidata]] will "fix", in the end, [[wikidata]] is doomed for not creating stakeholders within the wiki-user community that includes SMW developers.
jmc
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
oh, sigh we all contribute as best we can!
Best - john
On 13.06.2012 15:00, Gerard Meijssen wrote:
Hoi, For the record,
what I do for the Wikidata project I do in my own time ..
Thanks,
Gerard
On 13 June 2012 21:34, <jmcclure@hypergrove.com [8]>
wrote:
Gerard,
Sure there's plenty of people who can build
a prototype application of this sort -- most people pay mortgages though so it'd be nice (if not required) to get compensated for such work, as you & the wikidata team are.
re the wikidata excuse: it's wise
to change one's heading before one's lost. Personally I think anyone creating an smw-based extension will do so far more swiftly (and cheaply) than what the wikidata team currently has in mind, ie, to rewrite SMW (and various of its extensions) almost from scratch. I have proposed the outline of such an application at [[meta:wikitopics]]. I'm even convinced that the SMW-based application as proposed will be faster operationally.
John
On 13.06.2012 00:52, Gerard Meijssen
wrote:
Hoi, There are several points WHY a centrally
administered info box makes sense. The most important one can be found in what the Wikimedia Foundation aims to achieve: Imagine a world in which every single human being can freely share in the sum of all knowledge [1]]. This is what we are about, everything that prevents this from happening are excuses
When you consider the number of articles
in most Wikipedias, it is easy to see that the English Wikipedia has more info boxes then many of them have articles. By providing the facility to have centrally maintained info boxes, these info boxes will be extremely light weight as both the information and the labels will be maintained in Wikidata. The result is information that is available for localisation. This localisation consists of translating the labels and possibly the information items. I blogged about this in the past ... [2]
I am an advisor to the Wikidata project and as such it is my job to
make these arguments. Denny is the project manager for the Wikidata project and it is his job to ensure that his team will deliver on the agreed deliverables. Having centrally maintained templates is not part of what his team has agreed to or can be expected to deliver in the short term. This is a valid excuse; it is valid for now.
An excuse
for the Wikidata development team does not prevent other people from developing this functionality in stead. The basic requirement is for Wikidata to be able to have translatable data items associated with a Wikipedia article. As each of those items are uniquely identified, they can be identified in a template. This template should only refer to the data items.
When this functionality is developed, the basic
functionality is ready to consider the use of such templates for real in Wikidata clients.
I am confident that there are plenty people who
have the expertise to make a functional prototype. Such a prototype can be reviewed by any MediaWiki reviewer for the usual MediaWiki criteria. When this is done, it is no longer an unreasonable burden for the Wikidata team to consider the functionality of such prototypes.
Thanks,
Gerard [1] www.wikimediafoundation.org [3] [2]
http://ultimategerardm.blogspot.nl/2012/05/wmdevdays-wikidata.html [4]
On 13 June 2012 00:03, <jmcclure@hypergrove.com [5]>
wrote:
Denny said: On the other hand, you are not the only
person thinking that this (Wikitopics) is a good idea (hello Gerard!), and in the long run Wikidata could be extended to such a system -- but for now I regard this to be out of scope for Wikidata and I will not devote resources for this. _IT CAN BE ADDED LATER ANYWAY_.
Denny,
I never see the long-run! Anyway, to get real, be
aware there are specific concerns about [[wikidata]] within the SMW community in the here and now:
- we worry that our sites are
threatened by virtual cessation of SMW development -- this may already be happening a bit as SMW subjectively seems to be encountering quality control issues lately
- we worry that, whenever we install
the [[Wikidata]] extension, then the performance of client sites will be affected by the burden of multiple forms, query and format software modules, syntaxes, styles, artifacts etc
- we worry that,
since no specific problems experienced by wiki-users have yet been identified that [[Wikidata]] will "fix", in the end, [[wikidata]] is doomed for not creating stakeholders within the wiki-user community that includes SMW developers.
jmc
_______________________________________________
Wikidata-l mailing
list
Wikidata-l@lists.wikimedia.org [1]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l [2]
_______________________________________________
Wikidata-l mailing
list
Wikidata-l@lists.wikimedia.org [6]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l [7]
Links: ------ [1] mailto:Wikidata-l@lists.wikimedia.org [2] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [3] http://www.wikimediafoundation.org [4] http://ultimategerardm.blogspot.nl/2012/05/wmdevdays-wikidata.html [5] mailto:jmcclure@hypergrove.com [6] mailto:Wikidata-l@lists.wikimedia.org [7] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [8] mailto:jmcclure@hypergrove.com
I base my belief that [[wikitopics]] is operationally faster on a basic difference between the two designs, as I think the wikipedias will operate faster if they merely transclude infoboxes of their choice, at their own speed, from the wikidata central repository.
Transclusion is surely fundamental to wiki application design. The [[wikidata]] proposal by contrast is a client-server API, such things an artifact of the 20th century. What is the point of it here?
Ultimately the problem you're grappling with is not just just about infoboxes, it's about *anything* other than article text that has multilingual requirements. For instance, the same *pie chart* is to be shared among wikipedias, the only difference being the graph's title, key and other labels... [[wikidata]] is today doing format=table, later other formats. That's alot to handle in an API.
So, it's highly advised the client-server API approach be scrapped. At a minimum, it's outdated technology, for good reasons. Instead, wikidata should *publish* infoboxes that are happily cached on wikidata servers. That's the best performance that can possibly be had.
Hi John,
On Thu, Jun 14, 2012 at 12:39 AM, jmcclure@hypergrove.com wrote:
I base my belief that [[wikitopics]] is operationally faster on a basic difference between the two designs, as I think the wikipedias will operate faster if they merely transclude infoboxes of their choice, at their own speed, from the wikidata central repository.
Transclusion is surely fundamental to wiki application design. The [[wikidata]] proposal by contrast is a client-server API, such things an artifact of the 20th century. What is the point of it here?
Ultimately the problem you're grappling with is not just just about infoboxes, it's about *anything* other than article text that has multilingual requirements. For instance, the same *pie chart* is to be shared among wikipedias, the only difference being the graph's title, key and other labels... [[wikidata]] is today doing format=table, later other formats. That's alot to handle in an API.
Other can probably comment more on the rest of your email but here's one thing: It will very very likely not be the same pie chart. The Wikipedias have quite different demands as to what they want to show and what is important to them.
So, it's highly advised the client-server API approach be scrapped. At a minimum, it's outdated technology, for good reasons. Instead, wikidata should *publish* infoboxes that are happily cached on wikidata servers. That's the best performance that can possibly be had.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
I don't understand why it's so unlikely, Lydia. ANY educational article (science, math, engineering) can have graphics whose underlying data is not language-sensitve. How about timelines on a bio article -- that's anothr example. Or a map within a place article? Or financial data within a business article? I think these are more likely than the scenario that concerns you, where the *data itself* used to construct the graphic, is language- or country-sensitive.
On 13.06.2012 16:03, Lydia Pintscher wrote:
Hi John,
On Thu, Jun 14, 2012 at 12:39
AM, jmcclure@hypergrove.com wrote:
I base my belief that
[[wikitopics]] is operationally faster on a basic difference between the two designs, as I think the wikipedias will operate faster if they merely transclude infoboxes of their choice, at their own speed, from the wikidata central repository. Transclusion is surely fundamental to wiki application design. The [[wikidata]] proposal by contrast is a client-server API, such things an artifact of the 20th century. What is the point of it here? Ultimately the problem you're grappling with is not just just about infoboxes, it's about *anything* other than article text that has multilingual requirements. For instance, the same *pie chart* is to be shared among wikipedias, the only difference being the graph's title, key and other labels... [[wikidata]] is today doing format=table, later other formats. That's alot to handle in an API.
Other can probably comment more on the rest of your email but here's
one thing: It will very very likely not be the same pie chart. The
Wikipedias have quite different demands as to what they want to show
and what is important to them.
So, it's highly advised the
client-server API approach be scrapped. At a minimum, it's outdated technology, for good reasons. Instead, wikidata should *publish* infoboxes that are happily cached on wikidata servers. That's the best performance that can possibly be had. _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org [1] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [2]
--
Lydia Pintscher - http://about.me/lydia.pintscher
Community
Communications for Wikidata
Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin www.wikimedia.de
Wikimedia
Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
_______________________________________________
Wikidata-l mailing
list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Links: ------ [1] mailto:Wikidata-l@lists.wikimedia.org [2] https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On Thu, Jun 14, 2012 at 1:13 AM, jmcclure@hypergrove.com wrote:
I don't understand why it's so unlikely, Lydia. ANY educational article (science, math, engineering) can have graphics whose underlying data is not language-sensitve. How about timelines on a bio article -- that's anothr example. Or a map within a place article? Or financial data within a business article? I think these are more likely than the scenario that concerns you, where the *data itself* used to construct the graphic, is language- or country-sensitive.
What I am meant is that the individual Wikipedias are quite different. One Wikipedia might consider it important to show certain data in this way and another one in that way while a third might insist on not showing it at all because it is not important. Having over 280 Wikipedias agree on which and how certain data should be shown seems like a major pain on top of all we're asking for from them already for Wikidata.
Cheers Lydia
Are you sure that Wikipedias will always agree in population and religion charts?
Hi Bináris, I never said Wikipedias will always agree; in fact, I pointed to science articles, not social or religious articles, as a dominant use-case. In any event, whatever [[wikidata]] pages are transcluded is entirely under the whim and control of a wikipedia. If a wikipedia wants its own (unique) infobox or other item like a chart, then someone logs onto the wikidata host, creates their infobox/chart, and then transcludes that infobox/chart into their wikipedia page. If a given installation has installed the wikidata extension itself, there is no need to logon to another wiki, otherwise it's the same process.
Thanks - john
On 13.06.2012 22:20, Bináris wrote:
Are you sure
that Wikipedias will always agree in population and religion charts?
-- Bináris
On 14/06/12 00:39, jmcclure@hypergrove.com wrote:
Transclusion is surely fundamental to wiki application design. The [[wikidata]] proposal by contrast is a client-server API, such things an artifact of the 20th century. What is the point of it here?
Ultimately the problem you're grappling with is not just just about infoboxes, it's about *anything* other than article text that has multilingual requirements. For instance, the same *pie chart* is to be shared among wikipedias, the only difference being the graph's title, key and other labels... [[wikidata]] is today doing format=table, later other formats. That's alot to handle in an API.
I don't think Wikidata will ever do other formats. Wikidata will only export pure data.
So, it's highly advised the client-server API approach be scrapped. At a minimum, it's outdated technology, for good reasons. Instead, wikidata should *publish* infoboxes that are happily cached on wikidata servers. That's the best performance that can possibly be had.
Wikidata publishing infoboxes and Wikipedias using them is again the client-server model. And if Wikidata publishes infoboxes, pie charts and the like, THAT will complicate the API, not the current approach. Not to mention that Wikipedias have and want to have different infobox designs.
"Wikidata publishing infoboxes and Wikipedias using them is again the client-server model."
Not sure where this chestnut is coming from. Transclusion is as close to client-server as my cooking is to being gourmet!
There's NO API. so I don't understand your commenst at all, sorry.
On 13.06.2012 23:48, Nikola Smolenski wrote:
On 14/06/12
00:39, jmcclure@hypergrove.comwrote:
Transclusion is surely
fundamental to wiki application design. The [[wikidata]] proposal by contrast is a client-server API, such things an artifact of the 20th century. What is the point of it here? Ultimately the problem you're grappling with is not just just about infoboxes, it's about *anything* other than article text that has multilingual requirements. For instance, the same *pie chart* is to be shared among wikipedias, the only difference being the graph's title, key and other labels... [[wikidata]] is today doing format=table, later other formats. That's alot to handle in an API.
I don't think Wikidata will ever do other
formats. Wikidata will only
export pure data.
So, it's highly
advised the client-server API approach be scrapped. At a minimum, it's outdated technology, for good reasons. Instead, wikidata should *publish* infoboxes that are happily cached on wikidata servers. That's the best performance that can possibly be had.
Wikidata publishing
infoboxes and Wikipedias using them is again the
client-server model.
And if Wikidata publishes infoboxes, pie charts and
the like, THAT
will complicate the API, not the current approach. Not to
mention
that Wikipedias have and want to have different infobox designs.
On 14/06/12 17:49, jmcclure@hypergrove.com wrote:
"Wikidata publishing infoboxes and Wikipedias using them is again the client-server model."
Not sure where this chestnut is coming from. Transclusion is as close to client-server as my cooking is to being gourmet!
There's NO API. so I don't understand your commenst at all, sorry.
No, you do not. I'm afraid you will have to take my word for it.
OK -- i view wiki page transclusion same as xml text entity inclusion is all it is to me.
On 15.06.2012 00:12, Nikola Smolenski wrote:
On 14/06/12 17:49, jmcclure@hypergrove.comwrote:
"Wikidata publishing infoboxes and Wikipedias using them is again the client-server model." Not sure where this chestnut is coming from. Transclusion is as close to client-server as my cooking is to being gourmet! There's NO API. so I don't understand your commenst at all, sorry.
No, you do not. I'm afraid you will have to take my word for
it.
While I agree that it is desirable to support simple, preformatted Infoboxes that can, with minimal effort be re-used in a large number of language versions of Wikipedia, I strongly disagree with the demand to make this the only choice.
I think the present Wikidata approach to allow local Wikipedias to customize their infoboxes by accessing wikidata properties property-by-property is the right path.
The large Wikipedias with many editors have invested considerable creative energy into making quite a large number of infoboxes elaborate information containers. That includes formatting, images and hand-crafted links in both the "field name" and the "field value" side. Some values are expressed through svg graphics, other values expressed through background color coding, etc.
Limiting the usability of Wikidata to plain vanilla infox boxes could cause considerable resistance in these communities. And although small Wikipedia will profit a lot from Wikidata, without the engagement of editors from the large Wikipedias into curating Wikidata content, the increased synergies will not happen.
Another issue is that (I believe that) Wikidata does not have a notion of ordering properties. Correct? This is no issue for the present Wikidata approach because infoboxes remain curated in each local Wikipedia. However, in a centralized "one size fits all" approach, replacing existing infoboxes where information is presented in a logical order with an alphabetical property order would create huge resistance (and would be a complex issue that Wikidata would have to deal with, allowing property ordering and filtering).
I believe that Wikidata correctly aims to provide a smooth transition path, where it is possible to obtain only part of an infobox from wikidata and inject wikidata content into existing infobox layouts.
That said: I would encourage a third party contributor to try to create a default Wikidata infobox generator in a way (extension installable in multiple Wikipedias) that enables a wikipedia to autocreate a good looking, plain vanilla infobox with minimal effort.
Gregor
Hoi, Technically there is nothing stopping Wikidata from hosting multiple infoboxes on the same subject. The big thing about such infoboxes is that their layout is the same for all subjects in the same category. This does not mean that every one looks the same but it does mean they follow a consistent pattern.
When people talk about things like colours and stuff, it becomes highly emotional but in the final analysis at this stage it is just more bike shedding. It should be obvious that attributes like colour can be overriden.. Given that info boxes will not be supported in the near future ...
The notion that people should curate the info boxes locally is something that I do not subscribe to. Not being able to agree on data and sources is the same as not being able to reach a neutral point of view. This does not mean that multiple sources may not agree but equally it does not mean that different sources cannot be maintained from within Wikidata.
Finally, when Wikidata provides data and info boxes, it does not mean that any project is compelled to use it. As Wikidata matures, it will become increasingly clear that it is not the best practice. Thanks, GerardM
On 14 June 2012 12:11, Gregor Hagedorn g.m.hagedorn@gmail.com wrote:
While I agree that it is desirable to support simple, preformatted Infoboxes that can, with minimal effort be re-used in a large number of language versions of Wikipedia, I strongly disagree with the demand to make this the only choice.
I think the present Wikidata approach to allow local Wikipedias to customize their infoboxes by accessing wikidata properties property-by-property is the right path.
The large Wikipedias with many editors have invested considerable creative energy into making quite a large number of infoboxes elaborate information containers. That includes formatting, images and hand-crafted links in both the "field name" and the "field value" side. Some values are expressed through svg graphics, other values expressed through background color coding, etc.
Limiting the usability of Wikidata to plain vanilla infox boxes could cause considerable resistance in these communities. And although small Wikipedia will profit a lot from Wikidata, without the engagement of editors from the large Wikipedias into curating Wikidata content, the increased synergies will not happen.
Another issue is that (I believe that) Wikidata does not have a notion of ordering properties. Correct? This is no issue for the present Wikidata approach because infoboxes remain curated in each local Wikipedia. However, in a centralized "one size fits all" approach, replacing existing infoboxes where information is presented in a logical order with an alphabetical property order would create huge resistance (and would be a complex issue that Wikidata would have to deal with, allowing property ordering and filtering).
I believe that Wikidata correctly aims to provide a smooth transition path, where it is possible to obtain only part of an infobox from wikidata and inject wikidata content into existing infobox layouts.
That said: I would encourage a third party contributor to try to create a default Wikidata infobox generator in a way (extension installable in multiple Wikipedias) that enables a wikipedia to autocreate a good looking, plain vanilla infobox with minimal effort.
Gregor
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On 14 June 2012 12:33, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Finally, when Wikidata provides data and info boxes, it does not mean that any project is compelled to use it. As Wikidata matures, it will become increasingly clear that it is not the best practice.
that may be, but Wikidata needs a path to get there. I think the ability to integrate wikidata into existing the infobox consensus of a Wikipedia community is essential for adoption. Over time, centrally provided infoboxes with ever increasing customization functionality (order, selection, arrangement, linking properties to Wikipedia pages explaining them, etc.) are desirable and at some point the evolution of wiki data may conclude that this become the preferred method.
Gregor
Hallo,
On 2012-06-14 12:33, Gerard Meijssen wrote:
Hoi, Technically there is nothing stopping Wikidata from hosting multiple infoboxes on the same subject. The big thing about such infoboxes is that their layout is the same for all subjects in the same category. This does not mean that every one looks the same but it does mean they follow a consistent pattern.
Providing multiple infobox templates for the same subject is a very good point, as it is not necessary to override (see below) on each single page of a language version.
When people talk about things like colours and stuff, it becomes highly emotional but in the final analysis at this stage it is just more bike shedding. It should be obvious that attributes like colour can be overriden.. Given that info boxes will not be supported in the near future ...
I agree that overriding attributes should be possible. The pages of different Wikimedia-projects sometimes look very different in colours and so on.
Just think of "acceptable view":
Overriding should be possible on two different positions: # Style-sheet: Example: The box may behave different if we use "Lista de correo electrónico" instead of "Mailing list" as a key word # Rendering: * Value-conversion: different units and languages. ** −459,67 °F = 0 °Ra = −218,52 °R = −273,15 °C = 0 K ** city(48°8′24″N 11°34′30″E) = "Munich" = "München" = "Múnich" = "Monaco di Baviera" ... * Precision: ** π shown as "3.1415926" with precision 7 ** extended to subjects like locations of e.g. shopping malls more or less precision is wanted. For example the location of [[de:Europark_(Einkaufszentrum)]]: *** "Salzburg (City), Austria" (for zh.wikipedia.org) *** "Salzburg, Austria" (for de.wikipedia.org) *** "Taxham, Salzburg" (for http://salzburg.com/wiki)
The notion that people should curate the info boxes locally is something that I do not subscribe to. Not being able to agree on data and sources is the same as not being able to reach a neutral point of view. This does not mean that multiple sources may not agree but equally it does not mean that different sources cannot be maintained from within Wikidata.
Finally, when Wikidata provides data and info boxes, it does not mean that any project is compelled to use it. As Wikidata matures, it will become increasingly clear that it is not the best practice. Thanks,
I'm not a server specialist and not an excellent developer but due to the fact that it should also be possible to use pure data outside of wikimedia, data providing and page rendering should be seperated strict from each other.
Wikidata should therefore only be responsible for retrieving data with correct precision, value conversion and mode as requested. The rendering engine, not part of Wikidata, should be responsible for creating the HTML-code of the whole article including that of the infobox as well.
GerardMOn 14 June 2012 12:11, Gregor Hagedorn <g.m.hagedorn@gmail.com mailto:g.m.hagedorn@gmail.com> wrote:
While I agree that it is desirable to support simple, preformatted Infoboxes that can, with minimal effort be re-used in a large number of language versions of Wikipedia, I strongly disagree with the demand to make this the only choice. I think the present Wikidata approach to allow local Wikipedias to customize their infoboxes by accessing wikidata properties property-by-property is the right path. The large Wikipedias with many editors have invested considerable creative energy into making quite a large number of infoboxes elaborate information containers. That includes formatting, images and hand-crafted links in both the "field name" and the "field value" side. Some values are expressed through svg graphics, other values expressed through background color coding, etc. Limiting the usability of Wikidata to plain vanilla infox boxes could cause considerable resistance in these communities. And although small Wikipedia will profit a lot from Wikidata, without the engagement of editors from the large Wikipedias into curating Wikidata content, the increased synergies will not happen. Another issue is that (I believe that) Wikidata does not have a notion of ordering properties. Correct? This is no issue for the present Wikidata approach because infoboxes remain curated in each local Wikipedia. However, in a centralized "one size fits all" approach, replacing existing infoboxes where information is presented in a logical order with an alphabetical property order would create huge resistance (and would be a complex issue that Wikidata would have to deal with, allowing property ordering and filtering). I believe that Wikidata correctly aims to provide a smooth transition path, where it is possible to obtain only part of an infobox from wikidata and inject wikidata content into existing infobox layouts. That said: I would encourage a third party contributor to try to create a default Wikidata infobox generator in a way (extension installable in multiple Wikipedias) that enables a wikipedia to autocreate a good looking, plain vanilla infobox with minimal effort. Gregor
Marco
Hoi, I absolutely agree that Wikidata should be able to serve data in an unformatted way. I absolutely disagree that there is no need for serving data formatted in info boxes. Consider this use case:
Someone translated the texts associated with all the popes in Xhosa. There are no articles on popes in the Xhosa Wikipedia but because of the information and the info box in Wikidata it is possible to include information in Xhosa on the not found page together with the interwiki data. As this information is well presented, it makes sense for people to volunteer and translate Wikidata texts, as this information is well presented, people do select a language that provides information on the subject.
Consequently being able to serve pure data does not imply that it should not serve formatted data. Technically there is nothing stopping us from doing both. Thanks, Gerard
On 15 June 2012 19:55, Marco Fleckinger marco.fleckinger@gmail.com wrote:
Hallo,
On 2012-06-14 12:33, Gerard Meijssen wrote:
Hoi, Technically there is nothing stopping Wikidata from hosting multiple infoboxes on the same subject. The big thing about such infoboxes is that their layout is the same for all subjects in the same category. This does not mean that every one looks the same but it does mean they follow a consistent pattern.
Providing multiple infobox templates for the same subject is a very good point, as it is not necessary to override (see below) on each single page of a language version.
When people talk about things like colours and stuff, it becomes highly emotional but in the final analysis at this stage it is just more bike shedding. It should be obvious that attributes like colour can be overriden.. Given that info boxes will not be supported in the near future ...
I agree that overriding attributes should be possible. The pages of different Wikimedia-projects sometimes look very different in colours and so on.
Just think of "acceptable view":
Overriding should be possible on two different positions: # Style-sheet: Example: The box may behave different if we use "Lista de correo electrónico" instead of "Mailing list" as a key word # Rendering:
- Value-conversion: different units and languages.
** −459,67 °F = 0 °Ra = −218,52 °R = −273,15 °C = 0 K ** city(48°8′24″N 11°34′30″E) = "Munich" = "München" = "Múnich" = "Monaco di Baviera" ...
- Precision:
** π shown as "3.1415926" with precision 7 ** extended to subjects like locations of e.g. shopping malls more or less precision is wanted. For example the location of [[de:Europark_(**Einkaufszentrum)]]: *** "Salzburg (City), Austria" (for zh.wikipedia.org) *** "Salzburg, Austria" (for de.wikipedia.org) *** "Taxham, Salzburg" (for http://salzburg.com/wiki)
The notion that people should curate the info boxes locally is something that I do not subscribe to. Not being able to agree on data and sources is the same as not being able to reach a neutral point of view. This does not mean that multiple sources may not agree but equally it does not mean that different sources cannot be maintained from within Wikidata.
Finally, when Wikidata provides data and info boxes, it does not mean that any project is compelled to use it. As Wikidata matures, it will become increasingly clear that it is not the best practice. Thanks,
I'm not a server specialist and not an excellent developer but due to the fact that it should also be possible to use pure data outside of wikimedia, data providing and page rendering should be seperated strict from each other.
Wikidata should therefore only be responsible for retrieving data with correct precision, value conversion and mode as requested. The rendering engine, not part of Wikidata, should be responsible for creating the HTML-code of the whole article including that of the infobox as well.
GerardMOn 14 June 2012 12:11, Gregor Hagedorn <g.m.hagedorn@gmail.com mailto:g.m.hagedorn@gmail.com**> wrote:
While I agree that it is desirable to support simple, preformatted Infoboxes that can, with minimal effort be re-used in a large number of language versions of Wikipedia, I strongly disagree with the demand to make this the only choice.
I think the present Wikidata approach to allow local Wikipedias to customize their infoboxes by accessing wikidata properties property-by-property is the right path.
The large Wikipedias with many editors have invested considerable creative energy into making quite a large number of infoboxes elaborate information containers. That includes formatting, images and hand-crafted links in both the "field name" and the "field value" side. Some values are expressed through svg graphics, other values expressed through background color coding, etc.
Limiting the usability of Wikidata to plain vanilla infox boxes could cause considerable resistance in these communities. And although small Wikipedia will profit a lot from Wikidata, without the engagement of editors from the large Wikipedias into curating Wikidata content, the increased synergies will not happen.
Another issue is that (I believe that) Wikidata does not have a notion of ordering properties. Correct? This is no issue for the present Wikidata approach because infoboxes remain curated in each local Wikipedia. However, in a centralized "one size fits all" approach, replacing existing infoboxes where information is presented in a logical order with an alphabetical property order would create huge resistance (and would be a complex issue that Wikidata would have to deal with, allowing property ordering and filtering).
I believe that Wikidata correctly aims to provide a smooth transition path, where it is possible to obtain only part of an infobox from wikidata and inject wikidata content into existing infobox layouts.
That said: I would encourage a third party contributor to try to create a default Wikidata infobox generator in a way (extension installable in multiple Wikipedias) that enables a wikipedia to autocreate a good looking, plain vanilla infobox with minimal effort.
Gregor
Marco
______________________________**_________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikidata-lhttps://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hi,
are we really speaking about the same? - Pure data serving should be possible there is no disagree here as I think. - Should infoboxes be provided?
I was not speaking about the possibility for Wikipedia then. At least I did not meant it. I more likely wanted to point out that we should separate the infrastructure generating those infoboxes from this used for serving the data.
Having this in my mind I was thinking a bit more wide and questioned if creating the templates for the infoboxes itself should really be part of wikidata or if it should be part of the further development of the rendering engine to provide an easy possibility to fill the infoboxes with data.
It will be probably the easiest way to separate this into more steps:
The first should be to provide an easy way to integrate single properties into the article's pure text. Inside the article [[en:Tiger]] we are then able to write sentences like:
"In 1929, the British taxonomist Reginald Innes Pocock subordinated the species under the genus {{wikidata:tiger:genus}} using the scientific name {{wikidata:tiger:bionomial_name}}.<ref>{{wikidata:tiger:ref4646413}}</ref>"
Inside an infobox it should also be possible to use those facts:
{{Taxobox | status = EN
... | regnum = [[{{wikidata:tiger:regnume}}]] | phylum = [[{{wikidata:tiger:phylum}}]] | classis = [[{{wikidata:tiger:classis}}]] | ordo = [[{{wikidata:tiger:ordo}}]] | familia = [[{{wikidata:tiger:familia}}]] | genus = ''[[{{wikidata:tiger:genus}}]]'' ...
}}
I know this looks very silly, but should be possible anyway by providing the possibility to use facts inside flowing text. If somebody likes it, he could use it like this or wait until the next step.
The next step should be to upgrade the infobox templates to teach them to not just use single facts. They should also be able to use "data-structures" as they are called in C/C++. I always thought that this is not part of wikidata, more part of the rendering engine.
This also needs to work in multiple steps for correct rendering of e.g. one of the above wikidata-requests: For a request for "{{wikidata:tiger:regnume}}" "[[Animal]]ia" should be returned. The link location and the shown text are not the same. The birthday of Barack Obama should be anything like "[[4. August]] [[1961]]", as this format is used very often in the German Wikipedia. This example should show that this format is necessary, because of two different links.
So the first part of rendering should be the replacement all occurrences of the wikidata-tags. Here we can also replace the "{{infobox:wikidata:tiger}}" by what is already used inside the source text.
The first step should generate source text in the style we already know. Then we could use the next step to render the article shown in the browser.
Marco
On 2012-06-16 11:09, Gerard Meijssen wrote:
Hoi, I absolutely agree that Wikidata should be able to serve data in an unformatted way. I absolutely disagree that there is no need for serving data formatted in info boxes. Consider this use case:
Someone translated the texts associated with all the popes in Xhosa. There are no articles on popes in the Xhosa Wikipedia but because of the information and the info box in Wikidata it is possible to include information in Xhosa on the not found page together with the interwiki data. As this information is well presented, it makes sense for people to volunteer and translate Wikidata texts, as this information is well presented, people do select a language that provides information on the subject.
Consequently being able to serve pure data does not imply that it should not serve formatted data. Technically there is nothing stopping us from doing both. Thanks, Gerard
On 15 June 2012 19:55, Marco Fleckinger <marco.fleckinger@gmail.com mailto:marco.fleckinger@gmail.com> wrote:
Hallo, On 2012-06-14 12:33, Gerard Meijssen wrote: Hoi, Technically there is nothing stopping Wikidata from hosting multiple infoboxes on the same subject. The big thing about such infoboxes is that their layout is the same for all subjects in the same category. This does not mean that every one looks the same but it does mean they follow a consistent pattern. Providing multiple infobox templates for the same subject is a very good point, as it is not necessary to override (see below) on each single page of a language version. When people talk about things like colours and stuff, it becomes highly emotional but in the final analysis at this stage it is just more bike shedding. It should be obvious that attributes like colour can be overriden.. Given that info boxes will not be supported in the near future ... I agree that overriding attributes should be possible. The pages of different Wikimedia-projects sometimes look very different in colours and so on. Just think of "acceptable view": Overriding should be possible on two different positions: # Style-sheet: Example: The box may behave different if we use "Lista de correo electrónico" instead of "Mailing list" as a key word # Rendering: * Value-conversion: different units and languages. ** −459,67 °F = 0 °Ra = −218,52 °R = −273,15 °C = 0 K ** city(48°8′24″N 11°34′30″E) = "Munich" = "München" = "Múnich" = "Monaco di Baviera" ... * Precision: ** π shown as "3.1415926" with precision 7 ** extended to subjects like locations of e.g. shopping malls more or less precision is wanted. For example the location of [[de:Europark_(__Einkaufszentrum)]]: *** "Salzburg (City), Austria" (for zh.wikipedia.org <http://zh.wikipedia.org>) *** "Salzburg, Austria" (for de.wikipedia.org <http://de.wikipedia.org>) *** "Taxham, Salzburg" (for http://salzburg.com/wiki) The notion that people should curate the info boxes locally is something that I do not subscribe to. Not being able to agree on data and sources is the same as not being able to reach a neutral point of view. This does not mean that multiple sources may not agree but equally it does not mean that different sources cannot be maintained from within Wikidata. Finally, when Wikidata provides data and info boxes, it does not mean that any project is compelled to use it. As Wikidata matures, it will become increasingly clear that it is not the best practice. Thanks, I'm not a server specialist and not an excellent developer but due to the fact that it should also be possible to use pure data outside of wikimedia, data providing and page rendering should be seperated strict from each other. Wikidata should therefore only be responsible for retrieving data with correct precision, value conversion and mode as requested. The rendering engine, not part of Wikidata, should be responsible for creating the HTML-code of the whole article including that of the infobox as well. GerardM On 14 June 2012 12:11, Gregor Hagedorn <g.m.hagedorn@gmail.com <mailto:g.m.hagedorn@gmail.com> <mailto:g.m.hagedorn@gmail.com <mailto:g.m.hagedorn@gmail.com>__>> wrote: While I agree that it is desirable to support simple, preformatted Infoboxes that can, with minimal effort be re-used in a large number of language versions of Wikipedia, I strongly disagree with the demand to make this the only choice. I think the present Wikidata approach to allow local Wikipedias to customize their infoboxes by accessing wikidata properties property-by-property is the right path. The large Wikipedias with many editors have invested considerable creative energy into making quite a large number of infoboxes elaborate information containers. That includes formatting, images and hand-crafted links in both the "field name" and the "field value" side. Some values are expressed through svg graphics, other values expressed through background color coding, etc. Limiting the usability of Wikidata to plain vanilla infox boxes could cause considerable resistance in these communities. And although small Wikipedia will profit a lot from Wikidata, without the engagement of editors from the large Wikipedias into curating Wikidata content, the increased synergies will not happen. Another issue is that (I believe that) Wikidata does not have a notion of ordering properties. Correct? This is no issue for the present Wikidata approach because infoboxes remain curated in each local Wikipedia. However, in a centralized "one size fits all" approach, replacing existing infoboxes where information is presented in a logical order with an alphabetical property order would create huge resistance (and would be a complex issue that Wikidata would have to deal with, allowing property ordering and filtering). I believe that Wikidata correctly aims to provide a smooth transition path, where it is possible to obtain only part of an infobox from wikidata and inject wikidata content into existing infobox layouts. That said: I would encourage a third party contributor to try to create a default Wikidata infobox generator in a way (extension installable in multiple Wikipedias) that enables a wikipedia to autocreate a good looking, plain vanilla infobox with minimal effort. Gregor Marco _________________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org> https://lists.wikimedia.org/__mailman/listinfo/wikidata-l <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, I do not understand why it should be necessary to specify that a specific language is to be used. When a template is used on the English Wikipedia, the choice for English is a function of the Wiki and its text being in English. Another reason why it is not necessary to specify the language is because when you use a value in the free text, you expect it to be formatted in the manner compatible with the language of that text.
Also in the way you indicate the template you leave the labels in Latin. This does not make sense; the labels are part of Wikidata and they can be translated as well. Thanks, Gerard
On 16 June 2012 12:58, Marco Fleckinger marco.fleckinger@gmail.com wrote:
Hi,
are we really speaking about the same?
- Pure data serving should be possible there is no disagree here as I
think.
- Should infoboxes be provided?
I was not speaking about the possibility for Wikipedia then. At least I did not meant it. I more likely wanted to point out that we should separate the infrastructure generating those infoboxes from this used for serving the data.
Having this in my mind I was thinking a bit more wide and questioned if creating the templates for the infoboxes itself should really be part of wikidata or if it should be part of the further development of the rendering engine to provide an easy possibility to fill the infoboxes with data.
It will be probably the easiest way to separate this into more steps:
The first should be to provide an easy way to integrate single properties into the article's pure text. Inside the article [[en:Tiger]] we are then able to write sentences like:
"In 1929, the British taxonomist Reginald Innes Pocock subordinated the species under the genus {{wikidata:tiger:genus}} using the scientific name {{wikidata:tiger:bionomial_**name}}.<ref>{{wikidata:tiger:** ref4646413}}</ref>"
Inside an infobox it should also be possible to use those facts:
{{Taxobox | status = EN
... | regnum = [[{{wikidata:tiger:regnume}}]] | phylum = [[{{wikidata:tiger:phylum}}]] | classis = [[{{wikidata:tiger:classis}}]] | ordo = [[{{wikidata:tiger:ordo}}]] | familia = [[{{wikidata:tiger:familia}}]] | genus = ''[[{{wikidata:tiger:genus}}]]**'' ...
}}
I know this looks very silly, but should be possible anyway by providing the possibility to use facts inside flowing text. If somebody likes it, he could use it like this or wait until the next step.
The next step should be to upgrade the infobox templates to teach them to not just use single facts. They should also be able to use "data-structures" as they are called in C/C++. I always thought that this is not part of wikidata, more part of the rendering engine.
This also needs to work in multiple steps for correct rendering of e.g. one of the above wikidata-requests: For a request for "{{wikidata:tiger:regnume}}" "[[Animal]]ia" should be returned. The link location and the shown text are not the same. The birthday of Barack Obama should be anything like "[[4. August]] [[1961]]", as this format is used very often in the German Wikipedia. This example should show that this format is necessary, because of two different links.
So the first part of rendering should be the replacement all occurrences of the wikidata-tags. Here we can also replace the "{{infobox:wikidata:tiger}}" by what is already used inside the source text.
The first step should generate source text in the style we already know. Then we could use the next step to render the article shown in the browser.
Marco
On 2012-06-16 11:09, Gerard Meijssen wrote:
Hoi, I absolutely agree that Wikidata should be able to serve data in an unformatted way. I absolutely disagree that there is no need for serving data formatted in info boxes. Consider this use case:
Someone translated the texts associated with all the popes in Xhosa. There are no articles on popes in the Xhosa Wikipedia but because of the information and the info box in Wikidata it is possible to include information in Xhosa on the not found page together with the interwiki data. As this information is well presented, it makes sense for people to volunteer and translate Wikidata texts, as this information is well presented, people do select a language that provides information on the subject.
Consequently being able to serve pure data does not imply that it should not serve formatted data. Technically there is nothing stopping us from doing both. Thanks, Gerard
On 15 June 2012 19:55, Marco Fleckinger <marco.fleckinger@gmail.com <mailto:marco.fleckinger@**gmail.com marco.fleckinger@gmail.com>> wrote:
Hallo,
On 2012-06-14 12:33, Gerard Meijssen wrote:
Hoi, Technically there is nothing stopping Wikidata from hostingmultiple infoboxes on the same subject. The big thing about such infoboxes is that their layout is the same for all subjects in the same category. This does not mean that every one looks the same but it does mean they follow a consistent pattern.
Providing multiple infobox templates for the same subject is a very good point, as it is not necessary to override (see below) on each single page of a language version.
When people talk about things like colours and stuff, it becomes highly emotional but in the final analysis at this stage it is just more bike shedding. It should be obvious that attributes like colour can be overriden.. Given that info boxes will not be supported in the near future ...I agree that overriding attributes should be possible. The pages of different Wikimedia-projects sometimes look very different in colours and so on.
Just think of "acceptable view":
Overriding should be possible on two different positions: # Style-sheet: Example: The box may behave different if we use "Lista de correo electrónico" instead of "Mailing list" as a key word # Rendering: * Value-conversion: different units and languages. ** −459,67 °F = 0 °Ra = −218,52 °R = −273,15 °C = 0 K ** city(48°8′24″N 11°34′30″E) = "Munich" = "München" = "Múnich" = "Monaco di Baviera" ... * Precision: ** π shown as "3.1415926" with precision 7 ** extended to subjects like locations of e.g. shopping malls more or less precision is wanted. For example the location of [[de:Europark_(__**Einkaufszentrum)]]:
*** "Salzburg (City), Austria" (for zh.wikipedia.orghttp://zh.wikipedia.org) *** "Salzburg, Austria" (for de.wikipedia.org http://de.wikipedia.org)
*** "Taxham, Salzburg" (for http://salzburg.com/wiki) The notion that people should curate the info boxes locally is something that I do not subscribe to. Not being able to agree on data and sources is the same as not being able to reach a neutral point of view.This does not mean that multiple sources may not agree but equally it does not mean that different sources cannot be maintained from within Wikidata.
Finally, when Wikidata provides data and info boxes, it does not mean that any project is compelled to use it. As Wikidata matures, it will become increasingly clear that it is not the best practice. Thanks,I'm not a server specialist and not an excellent developer but due to the fact that it should also be possible to use pure data outside of wikimedia, data providing and page rendering should be seperated strict from each other.
Wikidata should therefore only be responsible for retrieving data with correct precision, value conversion and mode as requested. The rendering engine, not part of Wikidata, should be responsible for creating the HTML-code of the whole article including that of the infobox as well.
GerardM On 14 June 2012 12:11, Gregor Hagedorn <g.m.hagedorn@gmail.com <mailto:g.m.hagedorn@gmail.com**> <mailto:g.m.hagedorn@gmail.com <mailto:g.m.hagedorn@gmail.com**>__>> wrote: While I agree that it is desirable to support simple, preformatted Infoboxes that can, with minimal effort be re-used in a large number of language versions of Wikipedia, I strongly disagree with the demand to make this the only choice. I think the present Wikidata approach to allow local Wikipedias to customize their infoboxes by accessing wikidata properties property-by-property is the right path. The large Wikipedias with many editors have invested considerable creative energy into making quite a large number of infoboxes elaborate information containers. That includes formatting, images and hand-crafted links in both the "field name" and the "field value" side. Some values are expressed through svg graphics, other values expressed through background color coding, etc. Limiting the usability of Wikidata to plain vanilla infox boxes could cause considerable resistance in these communities. And although small Wikipedia will profit a lot from Wikidata, without the engagement of editors from the large Wikipedias into curating Wikidata content, the increased synergies will not happen. Another issue is that (I believe that) Wikidata does not have a notion of ordering properties. Correct? This is no issue for the present Wikidata approach because infoboxes remain curated in eachlocal Wikipedia. However, in a centralized "one size fits all" approach, replacing existing infoboxes where information is presented in a logical order with an alphabetical property order would create huge resistance (and would be a complex issue that Wikidata would have to deal with, allowing property ordering and filtering).
I believe that Wikidata correctly aims to provide a smooth transition path, where it is possible to obtain only part of an infobox from wikidata and inject wikidata content into existing infobox layouts. That said: I would encourage a third party contributor to tryto create a default Wikidata infobox generator in a way (extension installable in multiple Wikipedias) that enables a wikipedia to autocreate a good looking, plain vanilla infobox with minimal effort.
GregorMarco
______________________________**___________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.** wikimedia.org Wikidata-l@lists.wikimedia.org> https://lists.wikimedia.org/__**mailman/listinfo/wikidata-lhttps://lists.wikimedia.org/__mailman/listinfo/wikidata-l <https://lists.wikimedia.org/**mailman/listinfo/wikidata-lhttps://lists.wikimedia.org/mailman/listinfo/wikidata-l
______________________________**_________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikidata-lhttps://lists.wikimedia.org/mailman/listinfo/wikidata-l
______________________________**_________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikidata-lhttps://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hi,
The line:
| status = EN
is copied out of the source of the English article "tiger" with the other lines of wikicode as well. That's the reason why the identifiers are left latin.
All what I wanted to show is, that it is still possible to use the actual infoboxes and fill them with data of wiki-data, as it is also possible to use the wiki-data facts in continuous text. This is not a try of a draft for new info-boxes.
Of course it is nonsense to specify a language or identifiers in a future infobox except for overriding. For example, if you want to make a howto-page for wikipedia and show that the same infobox can use in different languages on one single page this should be possible as well. Or -- as I already pointed out -- the "precision" may vary on different language versions.
Marco
On 2012-06-16 16:01, Gerard Meijssen wrote:
Hoi, I do not understand why it should be necessary to specify that a specific language is to be used. When a template is used on the English Wikipedia, the choice for English is a function of the Wiki and its text being in English. Another reason why it is not necessary to specify the language is because when you use a value in the free text, you expect it to be formatted in the manner compatible with the language of that text.
Also in the way you indicate the template you leave the labels in Latin. This does not make sense; the labels are part of Wikidata and they can be translated as well. Thanks, Gerard
On 16 June 2012 12:58, Marco Fleckinger <marco.fleckinger@gmail.com mailto:marco.fleckinger@gmail.com> wrote:
Hi, are we really speaking about the same? - Pure data serving should be possible there is no disagree here as I think. - Should infoboxes be provided? I was not speaking about the possibility for Wikipedia then. At least I did not meant it. I more likely wanted to point out that we should separate the infrastructure generating those infoboxes from this used for serving the data. Having this in my mind I was thinking a bit more wide and questioned if creating the templates for the infoboxes itself should really be part of wikidata or if it should be part of the further development of the rendering engine to provide an easy possibility to fill the infoboxes with data. It will be probably the easiest way to separate this into more steps: The first should be to provide an easy way to integrate single properties into the article's pure text. Inside the article [[en:Tiger]] we are then able to write sentences like: "In 1929, the British taxonomist Reginald Innes Pocock subordinated the species under the genus {{wikidata:tiger:genus}} using the scientific name {{wikidata:tiger:bionomial___name}}.<ref>{{wikidata:tiger:__ref4646413}}</ref>" Inside an infobox it should also be possible to use those facts: {{Taxobox | status = EN ... | regnum = [[{{wikidata:tiger:regnume}}]] | phylum = [[{{wikidata:tiger:phylum}}]] | classis = [[{{wikidata:tiger:classis}}]] | ordo = [[{{wikidata:tiger:ordo}}]] | familia = [[{{wikidata:tiger:familia}}]] | genus = ''[[{{wikidata:tiger:genus}}]]__'' ... }} I know this looks very silly, but should be possible anyway by providing the possibility to use facts inside flowing text. If somebody likes it, he could use it like this or wait until the next step. The next step should be to upgrade the infobox templates to teach them to not just use single facts. They should also be able to use "data-structures" as they are called in C/C++. I always thought that this is not part of wikidata, more part of the rendering engine. This also needs to work in multiple steps for correct rendering of e.g. one of the above wikidata-requests: For a request for "{{wikidata:tiger:regnume}}" "[[Animal]]ia" should be returned. The link location and the shown text are not the same. The birthday of Barack Obama should be anything like "[[4. August]] [[1961]]", as this format is used very often in the German Wikipedia. This example should show that this format is necessary, because of two different links. So the first part of rendering should be the replacement all occurrences of the wikidata-tags. Here we can also replace the "{{infobox:wikidata:tiger}}" by what is already used inside the source text. The first step should generate source text in the style we already know. Then we could use the next step to render the article shown in the browser. Marco On 2012-06-16 11:09, Gerard Meijssen wrote: Hoi, I absolutely agree that Wikidata should be able to serve data in an unformatted way. I absolutely disagree that there is no need for serving data formatted in info boxes. Consider this use case: Someone translated the texts associated with all the popes in Xhosa. There are no articles on popes in the Xhosa Wikipedia but because of the information and the info box in Wikidata it is possible to include information in Xhosa on the not found page together with the interwiki data. As this information is well presented, it makes sense for people to volunteer and translate Wikidata texts, as this information is well presented, people do select a language that provides information on the subject. Consequently being able to serve pure data does not imply that it should not serve formatted data. Technically there is nothing stopping us from doing both. Thanks, Gerard On 15 June 2012 19:55, Marco Fleckinger <marco.fleckinger@gmail.com <mailto:marco.fleckinger@gmail.com> <mailto:marco.fleckinger@__gmail.com <mailto:marco.fleckinger@gmail.com>>> wrote: Hallo, On 2012-06-14 12:33, Gerard Meijssen wrote: Hoi, Technically there is nothing stopping Wikidata from hosting multiple infoboxes on the same subject. The big thing about such infoboxes is that their layout is the same for all subjects in the same category. This does not mean that every one looks the same but it does mean they follow a consistent pattern. Providing multiple infobox templates for the same subject is a very good point, as it is not necessary to override (see below) on each single page of a language version. When people talk about things like colours and stuff, it becomes highly emotional but in the final analysis at this stage it is just more bike shedding. It should be obvious that attributes like colour can be overriden.. Given that info boxes will not be supported in the near future ... I agree that overriding attributes should be possible. The pages of different Wikimedia-projects sometimes look very different in colours and so on. Just think of "acceptable view": Overriding should be possible on two different positions: # Style-sheet: Example: The box may behave different if we use "Lista de correo electrónico" instead of "Mailing list" as a key word # Rendering: * Value-conversion: different units and languages. ** −459,67 °F = 0 °Ra = −218,52 °R = −273,15 °C = 0 K ** city(48°8′24″N 11°34′30″E) = "Munich" = "München" = "Múnich" = "Monaco di Baviera" ... * Precision: ** π shown as "3.1415926" with precision 7 ** extended to subjects like locations of e.g. shopping malls more or less precision is wanted. For example the location of [[de:Europark_(____Einkaufszentrum)]]: *** "Salzburg (City), Austria" (for zh.wikipedia.org <http://zh.wikipedia.org> <http://zh.wikipedia.org>) *** "Salzburg, Austria" (for de.wikipedia.org <http://de.wikipedia.org> <http://de.wikipedia.org>) *** "Taxham, Salzburg" (for http://salzburg.com/wiki) The notion that people should curate the info boxes locally is something that I do not subscribe to. Not being able to agree on data and sources is the same as not being able to reach a neutral point of view. This does not mean that multiple sources may not agree but equally it does not mean that different sources cannot be maintained from within Wikidata. Finally, when Wikidata provides data and info boxes, it does not mean that any project is compelled to use it. As Wikidata matures, it will become increasingly clear that it is not the best practice. Thanks, I'm not a server specialist and not an excellent developer but due to the fact that it should also be possible to use pure data outside of wikimedia, data providing and page rendering should be seperated strict from each other. Wikidata should therefore only be responsible for retrieving data with correct precision, value conversion and mode as requested. The rendering engine, not part of Wikidata, should be responsible for creating the HTML-code of the whole article including that of the infobox as well. GerardM On 14 June 2012 12:11, Gregor Hagedorn <g.m.hagedorn@gmail.com <mailto:g.m.hagedorn@gmail.com> <mailto:g.m.hagedorn@gmail.com <mailto:g.m.hagedorn@gmail.com>__> <mailto:g.m.hagedorn@gmail.com <mailto:g.m.hagedorn@gmail.com> <mailto:g.m.hagedorn@gmail.com <mailto:g.m.hagedorn@gmail.com>__>__>> wrote: While I agree that it is desirable to support simple, preformatted Infoboxes that can, with minimal effort be re-used in a large number of language versions of Wikipedia, I strongly disagree with the demand to make this the only choice. I think the present Wikidata approach to allow local Wikipedias to customize their infoboxes by accessing wikidata properties property-by-property is the right path. The large Wikipedias with many editors have invested considerable creative energy into making quite a large number of infoboxes elaborate information containers. That includes formatting, images and hand-crafted links in both the "field name" and the "field value" side. Some values are expressed through svg graphics, other values expressed through background color coding, etc. Limiting the usability of Wikidata to plain vanilla infox boxes could cause considerable resistance in these communities. And although small Wikipedia will profit a lot from Wikidata, without the engagement of editors from the large Wikipedias into curating Wikidata content, the increased synergies will not happen. Another issue is that (I believe that) Wikidata does not have a notion of ordering properties. Correct? This is no issue for the present Wikidata approach because infoboxes remain curated in each local Wikipedia. However, in a centralized "one size fits all" approach, replacing existing infoboxes where information is presented in a logical order with an alphabetical property order would create huge resistance (and would be a complex issue that Wikidata would have to deal with, allowing property ordering and filtering). I believe that Wikidata correctly aims to provide a smooth transition path, where it is possible to obtain only part of an infobox from wikidata and inject wikidata content into existing infobox layouts. That said: I would encourage a third party contributor to try to create a default Wikidata infobox generator in a way (extension installable in multiple Wikipedias) that enables a wikipedia to autocreate a good looking, plain vanilla infobox with minimal effort. Gregor Marco ___________________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org> <mailto:Wikidata-l@lists.__wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org>> https://lists.wikimedia.org/____mailman/listinfo/wikidata-l <https://lists.wikimedia.org/__mailman/listinfo/wikidata-l> <https://lists.wikimedia.org/__mailman/listinfo/wikidata-l <https://lists.wikimedia.org/mailman/listinfo/wikidata-l>> _________________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org> https://lists.wikimedia.org/__mailman/listinfo/wikidata-l <https://lists.wikimedia.org/mailman/listinfo/wikidata-l> _________________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org> https://lists.wikimedia.org/__mailman/listinfo/wikidata-l <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 strongly disagree with the demand to make this the only choice." -
Gregor, I'm a bit confused -- are you talking about the transclusion design approach in this statement? because, if so, I'd think there'd be a number of infobox "styles" that can be selected by an author on the wikidata platform when 'building' the infobox page. The author can transclude any number/any specific infobox(es) on their wikipedia page, eg
{{wikidata:en:Infobox:Some topic/some custom imfobox}}
On 14.06.2012 03:11, Gregor Hagedorn wrote:
While I agree that it is
desirable to support simple, preformatted
Infoboxes that can, with
minimal effort be re-used in a large number
of language versions of
Wikipedia, I strongly disagree with the demand
to make this the only
choice.
I think the present Wikidata approach to allow local
Wikipedias to
customize their infoboxes by accessing wikidata
properties
property-by-property is the right path.
The large
Wikipedias with many editors have invested considerable
creative
energy into making quite a large number of infoboxes
elaborate
information containers. That includes formatting, images and
hand-crafted links in both the "field name" and the "field value"
side. Some values are expressed through svg graphics, other values
expressed through background color coding, etc.
Limiting the
usability of Wikidata to plain vanilla infox boxes could
cause
considerable resistance in these communities. And although small
Wikipedia will profit a lot from Wikidata, without the engagement of
editors from the large Wikipedias into curating Wikidata content, the
increased synergies will not happen.
Another issue is that (I
believe that) Wikidata does not have a notion
of ordering properties.
Correct? This is no issue for the present
Wikidata approach because
infoboxes remain curated in each local
Wikipedia. However, in a
centralized "one size fits all" approach,
replacing existing infoboxes
where information is presented in a
logical order with an alphabetical
property order would create huge
resistance (and would be a complex
issue that Wikidata would have to
deal with, allowing property
ordering and filtering).
I believe that Wikidata correctly aims to
provide a smooth transition
path, where it is possible to obtain only
part of an infobox from
wikidata and inject wikidata content into
existing infobox layouts.
That said: I would encourage a third
party contributor to try to
create a default Wikidata infobox
generator in a way (extension
installable in multiple Wikipedias) that
enables a wikipedia to
autocreate a good looking, plain vanilla
infobox with minimal effort.
Gregor
_______________________________________________
Wikidata-l mailing
list
Wikidata-l@lists.wikimedia.org
Gregor, I'm a bit confused -- are you talking about the transclusion design approach in this statement?
Yes, in the sense that it demands to be the only access to wiki data content in a Wikipedia.
because, if so, I'd think there'd be a number of infobox "styles" that can be selected by an author on the wikidata platform when 'building' the infobox page. The author can transclude any number/any specific infobox(es) on their wikipedia page, eg
{{wikidata:en:Infobox:Some topic/some custom imfobox}}
As I say, I look forward to see an infobox builder being developed, but this is a serious challenge.
See, e.g. http://en.wikipedia.org/wiki/Tiger and take a look at the hierarchical arrangement of properties, formatting of them, linking of them (Headings link to concept explanations on the same-language Wikipedia, with the link being different than the display text, "Early Pleistocene – Recent" may be a time range, but the value is "Early Pleistocene" and the link is "Pleistocene"; similarly each taxonomic author - here only ony present, Linnaeus - should link on en.wikipedia to en.wikipedia and de.wikipedia to de.wikipedia), expressing some information with graphics, see Endangered (IUCN 3.1)[1], properties or property values containing footnotes, the fact that a subspecies is extinct being abbreviated with a symbol (†P. t. virgata) etc. Note that the latter case is actually a nesting: it is a list of subspecies, with each subspecies having multiple properties like Scientific Name, Wikipedia Page name, extinction status - I am not sure Wikidata plans to model such data in Phase 2 already.
My bottomline: Keep the wikidata project manageable and doable with the available resources. Offer a method for Wikipedians to pick up Wikidata content within the existing template infrastrukture.
But, desirable: ask a white paper which additional work would be required to create centralized, plain vanilla infobox rendering as well.
Would you be willing to create such a whitepaper? How much of the above-shown Tiger example can be created centrally with a limited set of facilities? How feature rich must the customization become?
Or are you proposing to simply use the existing template programming with the only the difference that wikidata is the only mediawiki where the properties can be accessed within templates? Much of my argument assumes that you are looking for a non-template based infobox renderer, I may be wrong there.
Gregor
Gregor says> Or are you proposing to simply use the existing template programming with the only the difference that wikidata is the only mediawiki where the properties can be accessed within templates? Much of my argument assumes that you are looking for a non-template based infobox renderer, I may be wrong there.
I am proposing that, from the perspective of the Tiger article author, I would log on to wikidata and create a page called Infobox:Tiger using a Semantic Form named "Taxobox" whose fields track to the args for the Taxobox template. On the form, one would select whether a genus, familia, ordo, ... regnum is represented by the page... assume "genus" was selected, so..... {{Taxobox | status = EN (DUBLIN CORE PROPERTY: LANGUAGE) | fossil_range = Early [[Pleistocene]] - Recent (DUBLIN CORE: COVERAGE) | status_system = iucn3.1 (DUBLIN CORE: FORMAT) | trend = down (DUBLIN CORE: FORMAT) | status_ref =<ref name=IUCN/> (DUBLIN CORE: IDENTIFIER) | image = Tiger in Ranthambhore.jpg (EMBEDDED {{IMAGE}} TEMPLATE CALL) | image_caption = A [[Bengal tiger]] (''P. tigris tigris'') in India's [[Ranthambhore National Park]]. (PART OF {{IMAGE}} TEMPLATE CALL) | image_width = (PART OF {{IMAGE}} TEMPLATE CALL) | regnum = [[Animal]]ia (UNNECESSARY - LOOK IT UP VIA #ASK) | phylum = [[Chordate|Chordata]] (UNNECESSARY - LOOK IT UP VIA #ASK)) | classis = [[Mammal]]ia (UNNECESSARY - LOOK IT UP VIA #ASK)) | ordo = [[Carnivora]] (UNNECESSARY - LOOK IT UP VIA #ASK)) | familia = [[Felidae]] (UNNECESSARY - LOOK IT UP VIA #ASK)) | genus = ''[[Panthera]]'' (DUBLIN CORE PROPERTY: RELATION) | species = '''''P. tigris''''' (DUBLIN CORE PROPERTY: TITLE) | binomial = ''Panthera tigris'' (EMBEDDED {{BINOMIAL}} TEMPLATE CALL) | binomial_authority = ([[Carl Linnaeus|Linnaeus]], 1758) (PART OF EMBEDDED {{BINOMIAL}} TEMPLATE CALL) | synonyms = (DUBLIN CORE PROPERTY: TITLE) <center>'''''Felis tigris''''' <small>[[Carl Linnaeus|Linnaeus]], 1758</small><ref name="Linn1758" /> <br /> '''''Tigris striatus''''' <small>[[Nikolai Severtzov|Severtzov]], 1858</small><br /> '''''Tigris regalis''''' <small>[[John Edward Gray|Gray]], 1867</center> | range_map = Tiger_map.jpg (EMBEDDED {{IMAGE}} TEMPLATE CALL) | range_map_width = (PART OF EMBEDDED {{IMAGE}} TEMPLATE CALL) | range_map_caption = Tiger's historic range in ca. 1850 (pale yellow) and range in 2006 (in green).<ref name="dinerstein07" /> | subdivision_ranks = [[Subspecies]] | subdivision = (UNNECESSARY - LOOK IT UP VIA #ASK) ''[[Bengal tiger|P. t. tigris]]''<br/> ''[[Indochinese tiger|P. t. corbetti]]''<br /> ''[[Malayan tiger|P. t. jacksoni]]''<br /> ''[[Sumatran tiger|P. t. sumatrae]]''<br /> ''[[Siberian tiger|P. t. altaica]]''<br /> ''[[South China tiger|P. t. amoyensis]]''<br /> †''[[Caspian tiger|P. t. virgata]]''<br /> †''[[Bali tiger|P. t. balica]]''<br /> †''[[Javan tiger|P. t. sondaica]]'' }}
One could create [[en:Infobox:Tiger]] and [[de:Infobox:Tiger]] to handle language differences. Alternatively there'd be only [[Infobox:Tiger]] that has language-qualified string properties, e.g, Title^en contains english title for the page vs Title^de that contains the German title, with the #ask pulling the correct one given the wiki's language eg |?Title^{{CONTENTLANG}}
For links, use the same magic word eg
|genus={{CONTENTLANG}}:Panthera
To be a bit fancier:
|genus={{#ifexist:{{CONTENTLANG}}:Panthera|{{CONTENTLANG}}:Panthera|en:Panthera}}
Now, the above is a traditional non-topicmap treatment without provenance. Let's add provenance first:
|genus={{Dublin Core|value=Panthera|creator={{USERNAME}}|date={{TODAY}}|language=}}
Now lets add the topicmap orientation
|genus={{Topic|name=Panthera|creator={{USERNAME}}|date={{TODAY}}|language=}}
So there's certainly alternatives to look at. The basic theme though is NOT to create a specialized "factbox editor" but rather is to use Semantic Forms to capture the values of template args - values that can be links, text, or template calls. And you're right, Gregor, the primary way to access wikidata's triples for purposes of regular template programming is to logon to wikidata. imho, that establishes wikidata as a black-box, with no additional mechanisms/extensions loaded onto any 'transcluding' wikipedia, which I think is the ideal posture for integrating wikidata resources into the wikipedias.
re: the whitepaper. Sure I'd be happy to put together a real "demo". But as a strugglin' contractor doing opensource dev since 1998, it'd be nice if.....
Gotta run - john
On 14.06.2012 09:29, Gregor Hagedorn wrote:
Gregor, I'm a bit confused -- are you talking about the transclusion design approach in this statement?
Yes, in the sense that it demands to be the only access to wiki data content in a Wikipedia.
because, if so, I'd think there'd be a number of infobox "styles" that can be selected by an author on the wikidata platform when 'building' the infobox page. The author can transclude any number/any specific infobox(es) on their wikipedia page, eg {{wikidata:en:Infobox:Some topic/some custom imfobox}}
As I say, I look forward to see an infobox builder being developed, but this is a serious challenge.
See, e.g. http://en.wikipedia.org/wiki/Tiger and take a look at the hierarchical arrangement of properties, formatting of them, linking of them (Headings link to concept explanations on the same-language Wikipedia, with the link being different than the display text, "Early Pleistocene - Recent" may be a time range, but the value is "Early Pleistocene" and the link is "Pleistocene"; similarly each taxonomic author - here only ony present, Linnaeus - should link on en.wikipedia to en.wikipedia and de.wikipedia to de.wikipedia), expressing some information with graphics, see Endangered (IUCN 3.1)[1], properties or property values containing footnotes, the fact that a subspecies is extinct being abbreviated with a symbol (†P. t. virgata) etc. Note that the latter case is actually a nesting: it is a list of subspecies, with each subspecies having multiple properties like Scientific Name, Wikipedia Page name, extinction status - I am not sure Wikidata plans to model such data in Phase 2 already.
My bottomline: Keep the wikidata project manageable and doable with the available resources. Offer a method for Wikipedians to pick up Wikidata content within the existing template infrastrukture.
But, desirable: ask a white paper which additional work would be required to create centralized, plain vanilla infobox rendering as well.
Would you be willing to create such a whitepaper? How much of the above-shown Tiger example can be created centrally with a limited set of facilities? How feature rich must the customization become?
Or are you proposing to simply use the existing template programming with the only the difference that wikidata is the only mediawiki where the properties can be accessed within templates? Much of my argument assumes that you are looking for a non-template based infobox renderer, I may be wrong there.
Gregor
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org
Dear all,
With regard to the whitepaper/demo Gregor asked for, if there's some real interest expressed by the wikidata team in this, that'd be good to hear. So far little/no comment has been offered about the wikitopics approach or transclusion. It's hard to get excited about investing my time and energy if it's being met with a collective yawn by the wikidata team. Seriously, I have no interest in academic exercises nor talking to walls. I sincerely think that a transclusion-based design is a strategic & tactical improvement that merits debate against the client-server API the wikidata team is now creating.
thanks - john
On Wed, Jun 13, 2012 at 12:03 AM, jmcclure@hypergrove.com wrote:
Denny said: On the other hand, you are not the only person thinking that this (Wikitopics) is a good idea (hello Gerard!), and in the long run Wikidata could be extended to such a system -- but for now I regard this to be out of scope for Wikidata and I will not devote resources for this. It can be added later anyway.
Denny,
I never see the long-run! Anyway, to get real, be aware there are specific concerns about [[wikidata]] within the SMW community in the here and now:
Hey John,
It'd be great if you could say who "we" is specifically. I am happy to discuss issues and find ways to fix them. "We" is making it seem like it is the whole SMW community which I know isn't true ;-)
- we worry that our sites are threatened by virtual cessation of SMW
development -- this may already be happening a bit as SMW subjectively seems to be encountering quality control issues lately
Ok. What can we do to fix this? SMW shouldn't be threatened by Wikidata nor the other way around. They have different target groups for one and can co-exist. We are of course trying to share things like result formats in the future.
- we worry that, whenever we install the [[Wikidata]] extension, then the
performance of client sites will be affected by the burden of multiple forms, query and format software modules, syntaxes, styles, artifacts etc
Wikidata will have to run on Wikipedia. A lot of work is being put into performance and scalability. The performance impact on smaller wikis should be bearable because of this.
- we worry that, since no specific problems experienced by wiki-users have
yet been identified that [[Wikidata]] will "fix", in the end, [[wikidata]] is doomed for not creating stakeholders within the wiki-user community that includes SMW developers.
Wikidata will concentrate on Wikipedia and the problems it is trying to solve have been laid out. SMW has its own target audience and that is fine.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata
Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Hi Lydia,
'We' are people who committed professionally to the SMW (and Halo) approach to enterprise computing and 'we' are clients who have invested in this approach. We'll _want_ to install wikidata-client along with smw to get at infobox data (if such is the ultimate design). We'll _want_ to install wikidata-host to stay current with where all the investment dollars, the technical interest, etc, are flowing.
Yet you assert that smw & wikidata have different target groups (without defining either). However, I believe they are the SAME because their objectives are the same: to integrate structured data into the MW editing/display environment. There's not room for multiple implementations of tools with the same objective.
In short, my whole push is that, to be most successful, wikidata must consider the already-available or -installed base of technologies and tools. That's what reinventing the wheel is all about. It's why God took only 6 days to create the world -- there was no installed base to "accommodate".
john
On 13.06.2012 03:00, Lydia Pintscher wrote:
On Wed, Jun 13,
2012 at 12:03 AM, jmcclure@hypergrove.com wrote:
Denny said: On
the other hand, you are not the only person thinking that this (Wikitopics) is a good idea (hello Gerard!), and in the long run Wikidata could be extended to such a system -- but for now I regard this to be out of scope for Wikidata and I will not devote resources for this. It can be added later anyway. Denny, I never see the long-run! Anyway, to get real, be aware there are specific concerns about [[wikidata]] within the SMW community in the here and now:
Hey
John,
It'd be great if you could say who "we" is specifically. I am
happy to
discuss issues and find ways to fix them. "We" is making it
seem like
it is the whole SMW community which I know isn't true ;-)
- we worry that our sites are threatened by virtual cessation of SMW
development -- this may already be happening a bit as SMW subjectively seems to be encountering quality control issues lately
Ok. What can
we do to fix this? SMW shouldn't be threatened by
Wikidata nor the
other way around. They have different target groups
for one and can
co-exist.
We are of course trying to share things like result formats
in the future.
http://about.me/lydia.pintscher Community
Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de [1] Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org [2] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [3]
Links: ------ [1] http://www.wikimedia.de [2] mailto:Wikidata-l@lists.wikimedia.org [3] https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On Wed, Jun 13, 2012 at 5:36 PM, jmcclure@hypergrove.com wrote:
Hi Lydia,
'We' are people who committed professionally to the SMW (and Halo) approach to enterprise computing and 'we' are clients who have invested in this approach. We'll want to install wikidata-client along with smw to get at infobox data (if such is the ultimate design). We'll want to install wikidata-host to stay current with where all the investment dollars, the technical interest, etc, are flowing.
Yet you assert that smw & wikidata have different target groups (without defining either).
Ok then let me define it more clearly. Wikidata's clear goal is to serve the Wikipedias. Use in other contexts will also be possible and encouraged but Wikipedia is the main target. It is for a project that values references for all the structured data and it is supposed to serve a multi-language audience. SMW is well established and used in professional and non-professional projects outside of Wikipedia. It usually serves smaller wikis and has quite some use in companies for their internal knowledge management. Obviously there is overlap but in the end the projects are distinct enough to co-exist just fine. Markus wrote a long email about this here: http://www.mail-archive.com/semediawiki-devel@lists.sourceforge.net/msg03369...
However, I believe they are the SAME because their objectives are the same: to integrate structured data into the MW editing/display environment. There's not room for multiple implementations of tools with the same objective.
If you define the goal that broadly then yes it might be the same for both. But this is actually too broad. See above.
In short, my whole push is that, to be most successful, wikidata must consider the already-available or -installed base of technologies and tools.
We are considering them. People like Denny, Jeroen and Markus know SMW and related technology very well and are using this knowledge to influence Wikidata.
That's what reinventing the wheel is all about. It's why God took only 6 days to create the world -- there was no installed base to "accommodate".
john
Cheers Lydia
On 13.06.2012 18:04, Lydia Pintscher wrote:
Ok then let me define it more clearly. Wikidata's clear goal is to serve the Wikipedias. Use in other contexts will also be possible and encouraged but Wikipedia is the main target. It is for a project that values references for all the structured data and it is supposed to serve a multi-language audience. SMW is well established and used in professional and non-professional projects outside of Wikipedia. It usually serves smaller wikis and has quite some use in companies for their internal knowledge management. Obviously there is overlap but in the end the projects are distinct enough to co-exist just fine. Markus wrote a long email about this here: http://www.mail-archive.com/semediawiki-devel@lists.sourceforge.net/msg03369...
I'd like to expand on that a bit. Basically, the main difference to me is:
* SMW is for managing primary data, i.e. *facts*: "server X is located in room 123"
* Wikidata is for managing *claims* as we find them on Wikipedia: "according to report X published in 2005, the population of China in 2004 was 12345678, +/- 1000, including Taiwan"
So, Wikidata's data model is much more complex, and aimed at the type of information we typically see on Wikipedia. This allows is to provide extremely fine grained provenance data, but makes reasoning and querying a lot harder. It also means that mapping it to RDF is complex and awkward, not nearly as straight forward as it is with SMW.
So, if you are working with factual data and want to do complex queries, use SMW. If you have data which requires deep provenance information and are content with simple queries, use Wikidata (resp Wikibase).
However, we are working to make SMW and Wikibase (the Wikidata software) compatible where it makes sense: we want to share code for unit conversion, result formatting, etc. And I could imagine (but that's just a vague idea) that SMW one day could utilize our new method of storing structured data directly, without wikitext, but using it's own, simpler data model.
Anyway, keep in mind that Wikidata is build by the same people who initiated SMW! They are very well aware of the similarities and the differences. And we believe that the target audience for SMW and Wikidata *is* quite different.
-- daniel
Daniel - this distinction between facts vs claims -- is happy bullshit merely meant to calm the masses. A claim is a fact and a fact is a claim. It is the existence of PROVENANCE data in the Wikidata data model that distinguishes the two tools. Provenance data is at the heart of the web-of-trust, the top rung of the Internet architecture promulgated by the W3. So, if your view is that SMW is not for provenance data, while Wikidata is for provenance data, then how can I NOT conclude SMW is down-version? Why would I not TOSS SMW for Wikidata since they BOTH handle structured data? BOTH share a property: namespace? BOTH share code modules? BOTH have data-input (cf Semantic Form Inputs)? BOTH have formatted output (cf Semantic Result Formats).
:(this is what I was trying to communicate to Lydia in another note)
Provenance data certainly is important! It should be built in to an environment that rationalizes & integrates SMW, Dublin Core, and Topic Maps. See the [[meta:Wikitopics]] proposal for my first cut.
You make an interesting statement, "SMW one day could utilize _OUR NEW METHOD_ of storing structured data directly, without wikitext, but using it's own, simpler data model." -- friend, this is messianic at best if not confirmation of my dark concerns
John
On 13.06.2012 09:31, Daniel Kinzler wrote:
On 13.06.2012 18:04, Lydia Pintscher wrote:
Ok
then let me define it more clearly. Wikidata's clear goal is to serve the Wikipedias. Use in other contexts will also be possible and encouraged but Wikipedia is the main target. It is for a project that values references for all the structured data and it is supposed to serve a multi-language audience. SMW is well established and used in professional and non-professional projects outside of Wikipedia. It usually serves smaller wikis and has quite some use in companies for their internal knowledge management. Obviously there is overlap but in the end the projects are distinct enough to co-exist just fine. Markus wrote a long email about this here: http://www.mail-archive.com/semediawiki-devel@lists.sourceforge.net/msg03369... [1]
I'd like to expand on that a bit. Basically, the main
difference to me is:
- SMW is for managing primary data, i.e.
*facts*: "server X is located in room 123"
- Wikidata is for
managing *claims* as we find them on Wikipedia: "according to
report X
published in 2005, the population of China in 2004 was 12345678, +/-
1000, including Taiwan"
So, Wikidata's data model is much more
complex, and aimed at the type of
information we typically see on
Wikipedia. This allows is to provide extremely
fine grained provenance
data, but makes reasoning and querying a lot harder. It
also means
that mapping it to RDF is complex and awkward, not nearly as straight
forward as it is with SMW.
So, if you are working with factual data
and want to do complex queries, use
SMW. If you have data which
requires deep provenance information and are content
with simple
queries, use Wikidata (resp Wikibase).
However, we are working to
make SMW and Wikibase (the Wikidata software)
compatible where it
makes sense: we want to share code for unit conversion,
result
formatting, etc. And I could imagine (but that's just a vague idea) that
SMW one day could utilize our new method of storing structured
data directly,
without wikitext, but using it's own, simpler data
model.
Anyway, keep in mind that Wikidata is build by the same
people who initiated
SMW! They are very well aware of the similarities
and the differences. And we
believe that the target audience for SMW
and Wikidata *is* quite different.
-- daniel
-- Daniel
Kinzler, Softwarearchitekt
Wikimedia Deutschland e.V. | Eisenacher
Straße 2 | 10777 Berlin
http://wikimedia.de | Tel. (030) 219 158 260
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens
e.V.
Eingetragen im Vereinsregister des Amtsgerichts
Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig
anerkannt durch das Finanzamt
für Körperschaften I Berlin,
Steuernummer 27/681/51985.
_______________________________________________
Wikidata-l mailing
list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Links: ------ [1] http://www.mail-archive.com/semediawiki-devel@lists.sourceforge.net/msg03369...
On Wed, Jun 13, 2012 at 7:41 PM, jmcclure@hypergrove.com wrote:
Daniel - this distinction between facts vs claims -- is happy bullshit merely meant to calm the masses. A claim is a fact and a fact is a claim. It
It is not happy bullshit.
is the existence of PROVENANCE data in the Wikidata data model that distinguishes the two tools. Provenance data is at the heart of the web-of-trust, the top rung of the Internet architecture promulgated by the W3. So, if your view is that SMW is not for provenance data, while Wikidata is for provenance data, then how can I not conclude SMW is down-version? Why would I not toss SMW for Wikidata since they BOTH handle structured data?
I am not sure what you want to hear really. You seem to have made up your mind. If you need provenance data for a specific use-case and SMW doesn't give that to you then it might indeed not be a good fit for that particular use-case. That doesn't make SMW useless in any way however ;-)
BOTH share a property: namespace? BOTH share code modules? BOTH have data-input (cf Semantic Form Inputs)? BOTH have formatted output (cf Semantic Result Formats). :(this is what I was trying to communicate to Lydia in another note)
Provenance data certainly is important! It should be built in to an environment that rationalizes & integrates SMW, Dublin Core, and Topic Maps. See the [[meta:Wikitopics]] proposal for my first cut.
You make an interesting statement, "SMW one day could utilize our new method of storing structured data directly, without wikitext, but using it's own, simpler data model." -- friend, this is messianic at best if not confirmation of my dark concerns
I think Daniel was talking about http://meta.wikimedia.org/wiki/Wikidata/Notes/ContentHandler by the way. And if I remember correctly some of the SMW devs even said that this would be useful to have for SMW. It isn't something we're imposing on anyone but that can be very useful once done. It's one of the ways were SMW can benefit from groundwork done for Wikidata. More will probably come up.
Cheers Lydia
sorry daniel for saying that, lydia is right on.
collegially yours - john
On 13.06.2012 16:15, Lydia Pintscher wrote:
On Wed, Jun 13,
2012 at 7:41 PM, jmcclure@hypergrove.com wrote:
Daniel - this
distinction between facts vs claims -- is happy bullshit merely meant to calm the masses. A claim is a fact and a fact is a claim. It
It is
not happy bullshit.
is the existence of PROVENANCE data in the
Wikidata data model that distinguishes the two tools. Provenance data is at the heart of the web-of-trust, the top rung of the Internet architecture promulgated by the W3. So, if your view is that SMW is not for provenance data, while Wikidata is for provenance data, then how can I not conclude SMW is down-version? Why would I not toss SMW for Wikidata since they BOTH handle structured data?
I am not sure what
you want to hear really. You seem to have made up
your mind. If you
need provenance data for a specific use-case and SMW
doesn't give that
to you then it might indeed not be a good fit for
that particular
use-case. That doesn't make SMW useless in any way
however ;-)
http://meta.wikimedia.org/wiki/Wikidata/Notes/ContentHandler by the way. And if I remember correctly some of the SMW devs even said that this would be useful to have for SMW. It isn't something we're imposing on anyone but that can be very useful once done. It's one of the ways were SMW can benefit from groundwork done for Wikidata. More will probably come up. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher [1] Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de [2] Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org [3] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [4]
Links: ------ [1] http://about.me/lydia.pintscher [2] http://www.wikimedia.de [3] mailto:Wikidata-l@lists.wikimedia.org [4] https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hi Lydia,
Specifically I'm keen to understand that
* [[wikidata]] is committed to build-out smw for provenance data (and ContentHandler, per SRF formats); * [[wikidata]] is establishing a base grammar for everyone to share via Type, Tag, Subject and other namespaces; * [[wikidata]]'s multi-language labels rquirement is met via TopicMaps, whose focus is scoping topic-names; * [[wikidata]] is a transcludable repository of infoboxes, SRF graphics, indexes, etc. relevant to any topic.
thanks - john
On 13.06.2012 16:15, Lydia Pintscher wrote:
On Wed, Jun 13, 2012 at 7:41 PM,
jmcclure@hypergrove.com wrote:
is the existence of PROVENANCE
data in the Wikidata data model that distinguishes the two tools. Provenance data is at the heart of the web-of-trust, the top rung of the Internet architecture promulgated by the W3. So, if your view is that SMW is not for provenance data, while Wikidata is for provenance data, then how can I not conclude SMW is down-version? Why would I not toss SMW for Wikidata since they BOTH handle structured data?
I am not
sure what you want to hear really.
I do appreciate that Denny Jeroen and Markus cross-fertilize. But the money is flowing now towards _REWRITING SMW FROM SCRATCH_, which worries me as I am fairly sure there will be no good migration path at the inevitable time SMW support is terminated. The fact that one (is said) to be only for small wikis (which I dispute) and the other is not, is hardly a functional difference that will prevent confusion overlap inefficiency. As I've said elsewhere, saying one is capable of multi-lingual support while implying the other is not, is simply wrong -- smw is fine for multilingual support if the implemented data model has appropriate language tags. (note: I am creating a multi-lingual wiki now, based on smw, for a client).
My point is that for maximum success, wikidata should strive to welcome the smw community (back) into the mw community, to have support from those who put their professional faith in smw. By your own admission that there is substantial overlap, Wikidata will consequently and permanently split the SMW community, and this sickens me.
John
On 13.06.2012 09:04, Lydia Pintscher wrote:
On Wed, Jun 13, 2012 at 5:36 PM, jmcclure@hypergrove.com wrote:
Hi Lydia, 'We' are people who committed professionally to the SMW
(and Halo) approach to enterprise computing and 'we' are clients who have invested in this approach. We'll want to install wikidata-client along with smw to get at infobox data (if such is the ultimate design). We'll want to install wikidata-host to stay current with where all the investment dollars, the technical interest, etc, are flowing. Yet you assert that smw & wikidata have different target groups (without defining either).
Ok then let me define it more clearly. Wikidata's
clear goal is to
serve the Wikipedias. Use in other contexts will also
be possible and
encouraged but Wikipedia is the main target. It is for
a project that
values references for all the structured data and it is
supposed to
serve a multi-language audience. SMW is well established
and used in professional and non-professional
projects outside of
Wikipedia. It usually serves smaller wikis and has
quite some use in
companies for their internal knowledge management.
Obviously there is
overlap but in the end the projects are distinct
enough to co-exist
just fine. Markus wrote a long email about this
here:
http://www.mail-archive.com/semediawiki-devel@lists.sourceforge.net/msg03369...
However, I believe they are the SAME because their objectives are
the same: to integrate structured data into the MW editing/display environment. There's not room for multiple implementations of tools with the same objective.
If you define the goal that broadly then yes it
might be the same for
both. But this is actually too broad. See
above.
Links: ------ [1] http://www.wikimedia.de [2] mailto:Wikidata-l@lists.wikimedia.org [3] https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On Wed, Jun 13, 2012 at 9:13 PM, jmcclure@hypergrove.com wrote:
I do appreciate that Denny Jeroen and Markus cross-fertilize. But the money is flowing now towards rewriting SMW from scratch, which worries me as I am fairly sure there will be no good migration path at the inevitable time SMW support is terminated. The fact that one (is said) to be only for small
I don't see SMW going away anytime soon if people like you continue to support and push it.
wikis (which I dispute) and the other is not, is hardly a functional difference that will prevent confusion overlap inefficiency. As I've said elsewhere, saying one is capable of multi-lingual support while implying the other is not, is simply wrong -- smw is fine for multilingual support if the implemented data model has appropriate language tags. (note: I am creating a multi-lingual wiki now, based on smw, for a client).
Yes but the point was that it is not an integral part of SMW while it is very much so one of Wikidata.
My point is that for maximum success, wikidata should strive to welcome the smw community (back) into the mw community, to have support from those who put their professional faith in smw. By your own admission that there is substantial overlap, Wikidata will consequently and permanently split the SMW community, and this sickens me.
It is obviously not our goal and intention to split the SMW community. I hope you know that. We are actually doing our part of what you are asking for. We are bringing the ideas and some of the code of SMW closer to the MW community again imho. We are however not using SMW for this completely and shoe-horning it into something that it is not. That being said things can always be improved and I will do my best to make suggestions how to do that reality with you all.
Cheers Lydia
Hi John,
Being only a "minor" member of the SMW community, I'd like to respond to some of your assumptions you made about the SMW community as whole.
... cessation of SMW development
"Some of us" where worried at beginning of the wikidata project but I think Markus tried to ease those fears a bit in his email from 01 May 2012 (see [1]).
SMW subjectively seems to be encountering quality control issues lately
SMW as a community relies on its members to ensure quality control and if you look at the commit/review statistics than you can see that only a handful of people have actively committed work for SMW 1.7/SMW 1.8 which means to exercise quality control the community is relying on those actively involved.
... performance of client sites will be affected
I can't talk about performance in relation to wikidata but I can see from a SMW perspective that several efforts are being considered to cease unnecessary overhead (see [3] [4] [5]). Of course some extensions that use SMW as basis such as Semantic Drilldown have yet to come up with an intelligent caching strategy to minimize its impact on performance. (For example in our case we have nearly 1.5M triplets and we can feel when Semantic Drilldown is doing a database select with a large filter set).
... [[wikidata]] is doomed for not creating stakeholders within the wiki-user community that includes SMW developers
Some of the SMW core developers are actively involved in the wikidata project therefore this fear might be less suited but as a member of the SMW community I'd like to see that SMW and wikidata share "some" common code base as it would help to ensure quality control in future and those who know the wikidata code base may feel encouraged to commit to SMW as well.
SMW and wikidata certainly have a divergent target audiences but as a community member I hope to see a symbiotic relationship between SMW and wikidata without having to refute neither of both.
[1] http://wikimedia.7.n6.nabble.com/SMW-and-Wikidata-Was-SMW-devel-Semantic-Med...
[2] http://meta.wikimedia.org/wiki/Wikidata/Notes/SMW_and_Wikidata
[3] http://www.semantic-mediawiki.org/wiki/GSoC_2012#Accepted_proposal
[4] http://www.semantic-mediawiki.org/wiki/Roadmap#JavaScript_base_for_dynamic_r...
[5] http://www.semantic-mediawiki.org/wiki/GSoC_2012#SMW_query_management_and_sm...
Cheers,
mwjames
On Wed, Jun 13, 2012 at 7:03 AM, jmcclure@hypergrove.com wrote:
Denny said: On the other hand, you are not the only person thinking that this (Wikitopics) is a good idea (hello Gerard!), and in the long run Wikidata could be extended to such a system -- but for now I regard this to be out of scope for Wikidata and I will not devote resources for this. It can be added later anyway.
Denny,
I never see the long-run! Anyway, to get real, be aware there are specific concerns about [[wikidata]] within the SMW community in the here and now:
we worry that our sites are threatened by virtual cessation of SMW development -- this may already be happening a bit as SMW subjectively seems to be encountering quality control issues lately
we worry that, whenever we install the [[Wikidata]] extension, then the performance of client sites will be affected by the burden of multiple forms, query and format software modules, syntaxes, styles, artifacts etc
we worry that, since no specific problems experienced by wiki-users have yet been identified that [[Wikidata]] will "fix", in the end, [[wikidata]] is doomed for not creating stakeholders within the wiki-user community that includes SMW developers.
jmc
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hey,
As a SMW developer I am hoping that Wikidata will make people more aware of the advantages of structuring data in their wikis and thus end up with more users of SMW. Similarly I'm hoping that more developers will get interest, and that we'll have people working on both projects, exchanging ideas and code.
SMW subjectively seems to be encountering quality control issues lately
The latest release ought to be quite stable, and definitely not less stable then earlier releases. The qualify control could be a lot better though, but as it is, we simply do not have the resources for this. Most SMW development is done by either people that are creating additional features for their own or clients use-cases or by volunteers. If you want to help increasing the qualify and can throw developer time or other resources at it, then I'm more then willing to point out the places where we could use help.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
Hi James,
thanks for the pointer to [1].
1. "The main use case of Wikidata (a centralised, multi-lingual site that serves as a data repository) is different from that of SMW (a data-enhanced MediaWiki)" OK, SMW installations can be centralized repositories (try DSMW) and obviously can be multilingual too. So what's the difference between these use cases? The distinction of "data repository" vs "data-enhanced" is too fine for me to understand.
2. "Also, the more complex structures in Wikidata could be captured in SMW using internal objects." Exactly, my, point. So build-out SMW don't trivialize SMW don't harm the SMW community. See [[meta:wikitopics]] for my first cut at capturing the "more complex structures" in SMW: storing Dublin Core records as subobjects, containing (pointer-to) values-of the property. Hardly rocket science!
3. "The user interface of Wikibase Repository will be based on input forms, and thus quite different from SMW. " From this I conclude that Wikidata forms will not populate any template (eg {{{for template|Infobox}}}) - but invocation of the same machinery is being done under the covers. From this I conclude that the entire approach of Semantic Forms is being tossed away. It is saying that noone can use wikidata to maintain structured data attached to a page via templates nor use wikidata forms to implement their own forms -- so highly specialized to what end I cannot fathom.
4. "It is not defined yet what kind of query language Wikidata will support in Phase 3 (or thereafter)" -- yet another tack that makes SMW irrelevant in a wikidata-world. Why not build-out SMW to more efficiently handle multilingual values? SMW installations want that too!
In summary about [1], SMW installations want provenance data too, you know. We want to keep using SMW, not install a new functionally highly similar extension that can only lead to overlap confusion inefficiency. The operative presumption of [1] is that SMW cannot/will not ever support provenance data... surely the author should give more credit to creative SMW developers.
_re_: performance - I am referring to duplicated functionality between wikidata & smw... (I also am very thankful for recent performance work going on)... See #5 in [1] for specific examples of such duplication... and with that fact now documented, how can anyone say that the audiences diverge?
- jmc
On 13.06.2012 09:41, James HK wrote:
Hi John,
Being only a "minor" member of the SMW
community, I'd like to respond
to some of your assumptions you made
about the SMW community as whole.
... cessation of SMW
development
"Some of us" where worried at beginning of the wikidata
project but I
think Markus tried to ease those fears a bit in his
email from 01 May
2012 (see [1]).
SMW subjectively seems to be
encountering quality control issues lately
SMW as a community
relies on its members to ensure quality control and
if you look at the
commit/review statistics than you can see that only
a handful of
people have actively committed work for SMW 1.7/SMW 1.8
which means to
exercise quality control the community is relying on
those actively
involved.
... performan
ion to wikidata but I can see from a SMW
perspective that several efforts are being considered to cease unnecessary overhead (see [3] [4] [5]). Of course some extensions t
s
basis such as Semantic Drilldown have yet to come up with an intelligent caching strategy to minimize its impact on performance. (For example in our case we have nearly 1.5M triplets and we can feel when Semantic Drilldown is doing a database select with a large filter set). ... [[wikidata]] is doomed for not creating stakeholders within the wiki-user community that includes SMW developers
Some of the SMW
core developers are actively involved in the wikidata
project
therefore this fear mi> common code base as it would help to ensure quality control in future and those who know the wikidata code base may feel encouraged to commit to SMW as well. SMW and wikidata certainly have a divergent target audiences but as a communit
pe to see a
symbiotic relationship between SMW and wikidata without having to refute neither of both. [1] http://wikimedia.7.n6.nabble.com/SMW-and-Wikidata-Was-SMW-devel-Semantic-Med... [3] [2] http://meta.wikimedia.org/wiki/Wikidata/Notes/SMW_and_Wikidata [4] [3] http://www.semantic-mediawiki.org/wiki/GSoC_2012#Accepted_proposal [5] [4] http://www.semantic-mediawiki.org/wiki/Roadmap#JavaScript_base_for_dynamic_r... [6] [5] http://www.semantic-mediawiki.org/wiki/GSoC_2012#SMW_query_management_and_sm... [7] Cheers, mwjames On Wed, Jun 13, 2012 at 7:03 AM, <jmcclure@hypergrove.com [8]> wrote: Denny said: On the other hand, you are not the only person thinking that this (Wikitopics) is a good idea (hello Gerard!), and in the long run Wikidata could be extended to such a system -- but for now I regard this to be out of scope for Wikidata and I will not devote resources for this. It can be added later anyway. Denny, I never see the long-run! Anyway, to get real, be aware there are specific concerns about [[wikidata]] within the SMW community in the here and n
appening a bit as SMW subjectively seems to be
encountering quality control issues lately * we worry that, whenever we install the [[Wikidata]] extension, then the performance of client sites will be affected by the burden of multiple forms, query and format software modules, syntaxes, styles, artifacts etc * we worry that, since no specific problems experienced by wiki-users have yet been identified that [[Wikidata]] will "fix", in the end, [[wikidata]] is doomed for not creating stakeholders within the wiki-user community that includes SMW developers. jmc _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org [1] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [2]
_______________________________________________
Wikidata-l mailing
list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Links: ------ [1] mailto:Wikidata-l@lists.wikimedia.org [2] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [3] http://wikimedia.7.n6.nabble.com/SMW-and-Wikidata-Was-SMW-devel-Semantic-Med... [4] http://meta.wikimedia.org/wiki/Wikidata/Notes/SMW_and_Wikidata [5] http://www.semantic-mediawiki.org/wiki/GSoC_2012#Accepted_proposal [6] http://www.semantic-mediawiki.org/wiki/Roadmap#JavaScript_base_for_dynamic_r... [7] http://www.semantic-mediawiki.org/wiki/GSoC_2012#SMW_query_management_and_sm... [8] mailto:jmcclure@hypergrove.com