_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 > > [1] http://wikimediafoundation.org/wiki/Values [4] > > 2012/6/11 <[email protected] [5]> > >> 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 [1] >> , for instance >> _______________________________________________ >> Wikidata-l mailing list >> [email protected] [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:[email protected] [3] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [4] http://wikimediafoundation.org/wiki/Values [5] mailto:[email protected] [6] http://wikimedia.de
_______________________________________________ Wikidata-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-l
