I have updated the page [1] I started containing requirements and design notes for a topicmap-based wikidata repository. Comments are welcomed and I'll continue to rationalize the material I have to offer.
Thanks, John McClure Belltower Wikis
[1] https://meta.wikimedia.org/wiki/Wikitopics [1]
Links: ------ [1] https://meta.wikimedia.org/wiki/Wikitopics
Not only are comments welcome but, everyone is invited to update the text however they see fit. Please do not be argumentative - save that for its talk page. At a minimum, the proposal suggests that wiki transclusion of content from the wikidata repository is an interesting alternative to the display inclusion parser functions. This approach keeps development of wikidata resources within the wikidata community, which is perfectly appropriate.
On 30.05.2012 12:21, jmcclure@hypergrove.com wrote:
I have updated the page [1] I started
containing requirements and design notes for a topicmap-based wikidata repository. Comments are welcomed and I'll continue to rationalize the material I have to offer.
Thanks, John McClure Belltower
Wikis
Links: ------ [1] https://meta.wikimedia.org/wiki/Wikitopics
talk page. At a minimum, the proposal suggests that wiki transclusion of content from the wikidata repository is an interesting alternative to the display inclusion parser functions. This approach keeps development of wikidata resources within the wikidata community, which is perfectly appropriate.
Please elaborate this, I am not sure I understand the difference. thanks!
It appears to me the parser functions are intended to be executed by the client. I suggest instead interwiki transclusions, meaning all content is built on the wikidata host. Specialized facilities & data models implemented by the host are a black box to everyone else. If a specialized infobox is wanted by a client, then the person needs to develop it on the wikidata host, and request it by name in her transclusion. The host could then offer a page-layout user interface, appropriate for more advanced users than the typical.
On 30.05.2012 12:44, jmcclure@hypergrove.com wrote:
Not only are comments welcome
but, everyone is invited to update the text however they see fit. Please do not be argumentative - save that for its talk page. At a minimum, the proposal suggests that wiki transclusion of content from the wikidata repository is an interesting alternative to the display inclusion parser functions. This approach keeps development of wikidata resources within the wikidata community, which is perfectly appropriate.
On
30.05.2012 12:21, jmcclure@hypergrove.com wrote:
I have updated
the page [1] I started containing requirements and design notes for a topicmap-based wikidata repository. Comments are welcomed and I'll continue to rationalize the material I have to offer.
Thanks,
John McClure Belltower Wikis
[1]
https://meta.wikimedia.org/wiki/Wikitopics [1]
Links: ------ [1] https://meta.wikimedia.org/wiki/Wikitopics
On 30 May 2012 22:58, jmcclure@hypergrove.com wrote:
It appears to me the parser functions are intended to be executed by the client.
With client you mean the wikipedia servers?
I suggest instead interwiki transclusions, meaning all content is built on the wikidata host. Specialized facilities & data models implemented by the host are a black box to everyone else. If a specialized infobox is wanted by a client, then the person needs to develop it on the wikidata host, and request it by name in her transclusion. The host could then offer a page-layout user interface, appropriate for more advanced users than the typical.
I think this needs further study. In practice, many infoboxes are mixtures of language-neutral data, language dependent text, and media items. But even if limited to data only display, a complete wikidata rendering would not only have to provide full translations of the property names, but also the links to Wikipedia-specific pages and tooltips for many infoboxes and properties.
Thus, wikidata needs separate rendering definition for each client-wikipedia.
What is the convincing advantage to centralize this in wikidata rather than letting the wikipedia communities handle this independently?
Gregor
On 30.05.2012 12:44, jmcclure@hypergrove.com wrote:
Not only are comments welcome but, everyone is invited to update the text however they see fit. Please do not be argumentative - save that for its talk page. At a minimum, the proposal suggests that wiki transclusion of content from the wikidata repository is an interesting alternative to the display inclusion parser functions. This approach keeps development of wikidata resources within the wikidata community, which is perfectly appropriate.
On 30.05.2012 12:21, jmcclure@hypergrove.com wrote:
I have updated the page [1] I started containing requirements and design notes for a topicmap-based wikidata repository. Comments are welcomed and I'll continue to rationalize the material I have to offer.
Thanks, John McClure Belltower Wikis
[1] https://meta.wikimedia.org/wiki/Wikitopics
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
What is the convincing advantage to centralize this in wikidata
rather than letting the wikipedia communities handle this independently?
The objective is to create an extension that manages all structured data associated with any page, in a timely manner. There is already the SMW extension that does specifically this, but it has encountered puzzling technical resistance in the broad wiki administrator community I know from experience. From a social view, their resistance is explained by their sense of what their (normal) wiki users will tolerate, and it likely doesn't include managing structured data.
But more to the point is that NO extension need be installed for ANY wiki to directly benefit from the sheer existence of Wikidata - via simple transclusion of its resources. That cannot be said for the current proposal by which it indeed requires wiki administrator concurrence.
Hi all!
Am a bit mystified here! about the radio-silence to this thread or, for that matter, to the [[meta:wikitopics]] [1] document itself.
From wikipedia: [2]
REINVENTING THE SQUARE WHEEL is the practice of unnecessarily engineering artifacts that provide functionality already provided by existing standard artifacts (reinventing the wheel) and ending up with a worse result than the standard (a square wheel [3]). This is an anti-pattern [4] which occurs when the engineer is unaware or contemptuous of the standard solution or does not understand the problem or the standard solution sufficiently to avoid problems overcome by the standard.
Thanks !
-jmc
Links: ------ [1] https://meta.wikimedia.org/wiki/Wikitopics [2] http://en.wikipedia.org/wiki/Reinvent_the_wheel#Related_phrases [3] http://en.wikipedia.org/wiki/Square_wheel [4] http://en.wikipedia.org/wiki/Anti-pattern
I was silent on this thread mostly due to the following two points:
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?
In short, speaking for myself, I did not answer because I still fail to understand you.
I hope that helps, Denny
2012/6/8 jmcclure@hypergrove.com
**
Hi all!
Am a bit mystified here! about the radio-silence to this thread or, for that matter, to the [[meta:wikitopics]]https://meta.wikimedia.org/wiki/Wikitopicsdocument itself.
From wikipedia:http://en.wikipedia.org/wiki/Reinvent_the_wheel#Related_phrases
*Reinventing the square wheel* is the practice of unnecessarily engineering artifacts that provide functionality already provided by existing standard artifacts (reinventing the wheel) and ending up with a worse result than the standard (a square wheelhttp://en.wikipedia.org/wiki/Square_wheel). This is an anti-pattern http://en.wikipedia.org/wiki/Anti-pattern which occurs when the engineer is unaware or contemptuous of the standard solution or does not understand the problem or the standard solution sufficiently to avoid problems overcome by the standard.
Thanks !
-jmc
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l