Re: [Wikidata-l] Wikidata Transclusions
On 14/06/12 00:39, jmccl...@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. smime.p7s Description: S/MIME Cryptographic Signature ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
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
Re: [Wikidata-l] Wikidata Transclusions
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.haged...@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 ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
On 14 June 2012 12:33, Gerard Meijssen gerard.meijs...@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 ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
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. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
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
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
Re: [Wikidata-l] Wikidata Transclusions
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
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
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/smallref name=Linn1758 / br
/
'Tigris striatus' small[[Nikolai Severtzov|Severtzov]],
1858/smallbr /
'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
Re: [Wikidata-l] Wikidata test wikis are getting spammed
On Thu, Jun 14, 2012 at 7:57 PM, Erik Moeller e...@wikimedia.org wrote: http://wikidata-test-client.wikimedia.de/wiki/Special:RecentChanges It might be best to limit editing, or try to rope stewards into running their anti-spambots there ... Uff of course it could only be so long until spammers find the demo too. We'll look into some measures against them tomorrow. One possibility would of course be to just reset the wiki every night to a pre-defined state. 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. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [[meta:wikitopics]] updated
John McClure wrote: Of course, thanks for the pointer. Yes, I'd agree that 19788's ontology be closely reviewed for inclusion. 19788:2 standardizes the Dublin Core properties, the same I recommend for [[wikidata]] provenance data, the same slated for the [[wikidata]] ontology. But more to your point is that the entire ISO corpus would fit really well if it were viewed as a topic map whose topics and sub-topics can be referenced from [[wikidata]] artifacts such as property definitions. Hello John Frankly speaking I don't see why one would want to use topic maps. That is RDF triples are after an identification (canonical: elements with the same URI are identified) a labeled graph, here to be called the RDF graph. (I know that some people call the triples themselves the RDF graph, but why use a second word (namely graph) for triples? Triples are very trivial highly disconnected graph.). If I want to connect certain nodes of that graph to a topic I only need to supply these nodes with an extra triple which says (this node belongs to this topic, i.e. something like (node, belongsto,thistopic) ) or modify the canonical identification map and the RDF graph will be a topic map or one has the case that the triples are already set out in topics that is for example if I have a set of triples with the same resource URI then upon canonical identification these are a kind of topic map (with all legs pointing in one direction) or am I missing out something crucial? However if you start with topics, you have no canonical information about the internal structure of a topic and in some cases you would need to artificially impose this in retrospect onto the datastructure. Like if your topic is members of a society , you have all the members and you would need some internal structure like a hierarchy then you would need to supply each member with a hierarchy classification (i.e. with extra data, which is usually different for each member). For the RDF case the person who gave you the triples could have made a choice of order which could be given upon canonical identification. I.e. in principle the internal structure depends on your identification map but there is a canonical one. You can of course mimick a RDF triple with a topic map by choosing the topic to be the ressource and one leg of your topic as a property and the topic which is connected with this leg as the object, but the choice of a leg is not canonical if there is more than one leg. Only if you would make all legs of a topic map into triples you would have something like a canonical assignment. I find these differences important. But may be I have overseen something or misunderstood about topic maps (I read about this issue what I found scattered around in the internet so this is not so unprobable). I had this kind of discussion with people from deepa mehta http://www.deepamehta.de/ because they used topic maps, but sofar nobody there could convince me about the distinguished advantages of topic maps. But the discussion was sofar rather brief. The discussion was because we discussed to what extend it would be possible to merge a student project we had at HTW Berlin ( a collaboration platform for visualizing RDF data called Mimirix http://www.daytar.de/art/MIMIRIX/) with deepa mehta, like for example one could use at least the backend, which has already a layout for access control (the deepa mehta people told me that they haven't yet really attacked the issue of access control) or one could use at lease the carefully designed client. May be you have other arguments for topic maps, as said I might have missed out something. I understand that there are other issues like the speed of adressability or direct access issues but these are then rather an issue of the serialization I find. So I didn't understand why for example the pregiven JSON structure of an JSONarray http://www.json.org/javadoc/org/json/JSONArray.html is not used in JSON-LD http://json-ld.org/spec/latest/json-ld-syntax/#sets-and-lists but thats another topic. In the context of applications of ISO metadata you may want to read: http://www.azimuthproject.org/azimuth/show/Examples+of+semantic+web+applications+and+environment ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
