Knowledge talk:Requests for comment/infobox template coherence

1984:

structure and standardization, and making relationships explicit. Ultimately, I think we should go very far in this direct--so far that people could even choose at display-time the format and structure and size of articles: that we would have a true data base of information for articles and ways of assembling it. This may not be possible as a gradual change in the present Knowledge--it may instead be the basis for the sort of encyclopedia that will supersede Knowledge. At present, dbpedia and other projects are talking only about the sort of simple numerical or allied data that can be easily handled that way, but I see it as a basis for the organization, including both the writing and the presentation, of what we think of as the free text of articles and abstracts. I note that in the field familiar to me, the writing of biomedical research articles, there's a good deal of this being incorporated: indeed, pubmedcentral's versions of articles are constructed on the fly. (I would approach this by first working with the article types that can be totally structured in this way. Eventually, we will get to ways to deal with such amorphous subjects as historical and political events. Some of this might be developed more rapidly than one might at first think, as for types of biographies. It would at the least require the rewriting of all existing articles, which would in my mind be a very good thing indeed.

823:

it look better from the outside. (This is the essence of your thoughts as I understand them. If I'm wrong, let me know.) It is a bit different here: First, the approach is only a simple mapping, which does not interfere with any existing functionality. Secondly, modifying all template definitions is not easy: Most template definitions are edit protected and require consensus on changing them, so you would have a hard time justifying all the changes. There is no process to align infobox definitions, no hierarchies of infobox templates etc. While our approach works within days, fixing everything will take forever. (My personal opinion: Without any software or process like this proposal supporting it, it will never happen.) If you take your thoughts further, you will probably realise that even fixing the infoboxes is not the appropriate thing to do, but you would have to place proper knowledge representation, most likely RDF, at the core of MediaWiki infoboxes. There have been tremendous efforts in this direction for years, which will hopefully succeed eventually. What we present here, is a simple intermediate step, which helps to get it right. It allows to show people some benefits of semantics without the need for dramatic changes in Knowledge. If I didn't understand you correctly, please ask further questions. --

2379:

comes to dates, length measurements etc. We rather apply heuristics to parse values correctly. In many cases, the values can be parsed correctly, but sometimes they are a bit cluttered (for instance a date is sometimes a link to a wiki page and sometimes not; sometimes references are added to the date or markup is added which is only used to modify the layout but not the actual content). Standardising value formats for certain infobox attributes (you call them parameters) would be very welcome, but - at least from a DBpedia perspective - we do not need to force a specific value format for an infobox attribute, but it would usually be sufficient to say that the value can have one of several accepted formats. The core of the proposal is, however, to align different spellings of an attribute, which actually mean the same, and (in rarer cases) to disambiguate between attributes, which are spelled in the same way, but mean different things. Your idea of having a central documentation page for attributes is not far from what we propose. The difference is that we suggest to have one documentation page per property on MetaWiki and that we add more formal information as well. Here is a draft page for

2812:... despite it not being a vote. Overly complex, ugly, and almost hilariously over-engineered solution to a problem that would require significant effort for marginal benefit - something it shares in common with almost everything else associated with the "semantic web". For me, there's a right way and a wrong way of going about solving this issue, and this is definitely the wrong way. The right way is the simple "obvious" solution - make templates consistent (both in terms of names and values) and to put them in categories. This fixes the underlying problem of inconsistent templates instead of building a dirty hack to work around it, improves both machine and human readability, and is more likely to catch-on and actually be sustainable in the long-term, instead of the idea of creating meta-templates as a paper-thin abstraction layer solely for bots (or, more honestly, the idea of creating a meta-template solely to slightly ease implementation of dbpedia). Yes, effort and co-operation would be required in the community to standardise infoboxes, possibly including a bot to fix broken infoboxes, but it'd be a singular one-off effort for a significant real benefit to the project. - 1659:. If we consider the minimum goal of this proposal, i.e. collect information about content in template infoboxes, what is so bad about that (except taking up a line of space)? We just want to create a resource that can be exploited either by Semantic Web people like us, other extraction approaches or maybe by a script (not a built in template function) written to help Knowledge editors. This is a strict Wiki process: Start something, other people see it, if they like it or have benefits, they will join and contribute. Now here, the discussion is drifting towards a very large scale such as improving underlying software, extending template functionalities and cleaning all infoboxes, where it should only be about a table in doc subpage. This drift in the topic is of course our fault, too, as we wanted to show the large scale benefits. I agree with you that it might not be the perfect method for this global kind of achievement. But what about starting out small, i.e. collect annotation information with a better-than-nothing mentality? A completely independent layer has the great advantage, that it does not break anything. 2383:, which contains information about the property (infobox attributes are mapped to RDF properties). It is a draft, quite ugly, and we may remove the "DBpedia" in the URL and elsewhere (we stopped those efforts until consensus emerges here), so hopefully you can ignore all that for the moment. The intention is to document the property there. One can discuss it there, add information about all attributes, which are mapped to this property (can be done automatically), add information about how values should like, pointers to discussion about this etc. This offers more benefits (for extractors like DBpedia and for achieving consensus) compared to "only" fixing the spelling of infobox attributes, although this would be a good thing to do anyway (and the mapping templates make it easy to see in which infobox templates corrections should/may be made). Are those explanations clear/helpful? Maybe the RFC can be updated to provide clearer explanations (and I may be too professionally blinkered to do it, although I'm happy to help). -- 1740:

decisions here because we don't have a common language. We need an interpreter. Perhaps you can get Daniel Kinzler to restart the RFC. The English and German Wikipedias are quite different beasts (the German Knowledge having an unwritten principle: "Don't mention the English Knowledge") and judging from Daniel's account it seems editing is a low priority for him, so there is no guarantee it would be successful. But it's one thing that might be worth trying. Or Brion VIBBER, although like Daniel he has a WP edit count that's as low as mine, and I started only 2 years ago. The reason I once suggested you try it on the German Knowledge first is that there you are more likely to find an experienced volunteer who you can meet in real life and show what your software does etc. Such a user could then translate what they have seen in a language that the community understands. (I wasn't trying to tell you to get lost and bother a sister project, although I now realise it probably sounded as if I did. Sorry for that.)

1769:" I agree with this assessment. To be able to database certain types of Knowledge information is a nice concept, but to alter Knowledge in order to accomplish this is not feasible, will probably not be enforceable long term. As Sebastian said, this is a place where people freely edit, and are you going to guard these templates when editors change these new parameters? Make another new rule for templates? There is no guarantee these new parameters will remain as you put them in. When you have to add another artificial layer to input to derive information from that input, it just never works longterm - unless you have a small controlled input base. Knowledge is not a small controlled input base. What I would suggest is for this group of computer scientists to help the Knowledge volunteers to find a solution for the problem of finding another programming macro language that will fit the constraints of Knowledge (security problems, etc. 1553:

there any looping capability. There is no way to test for a global variable - something that could be very useful to Knowledge (example, a global variable to say whether a page is part of an archive or it is live, which could be tested by a template on the page). What happens is in order for a template to handle any level of complexity, you end up with either many transclusions of other templates within a template, or repetition of code.. in essence, what should be a simple process in most programming languages becomes a huge, complex template on Knowledge. To create "duplicates" of templates with minor variations is a necessity in an environment where there are such constraints in programming capabilities that coding a template to cover every situation creates a template that is too difficult to use. Creating similar templates with minor variations allows the templates to remain comprehensible to the editors that try to use them.

615:

to curate the structured information and then only adjust the representation, but this would be a massive change and would require immense resources. It is much easier on the other hand to just put some extra templates somewhere. Contribution to these is easy and meta data can accumulate and it does not interfere with anything. I guess, there should not be a guideline for Wikipedians to adjust the templates to the mapping annotations, but the information accumulated in the mapping annotations can be useful in several ways, i.e. Data Extraction (once again, we made this proposal to generalize the approach, otherwise we would keep it locked), maybe create RDFa out of them and embed it in the page. If there is a functionality of MediaWiki that allows to include the metadata in the software, there would already be a semantic mapping and an ontology and it can be reused, converted and the mapping annotations deleted.

1134: 972:. You can plan as much as you want for a year if you wish, advertising the fact in the most populated locations until you are getting on everybody's nerves. But you can only fully carry out the result if there is a consensus to do so, and you will not find out before you implement it. That's because most stakeholders won't notice before they see your edits on their watchlist because you touch an article they are interested in. Of course due diligence requires that you make an effort to gauge consensus before large scale changes. But it can still happen that you only learn that there isn't in fact a consensus after you have started the implementation. That's why we only do incremental development here. The waterfall method is even more ineffective here than in software development. 1006:

year on this already... What you find on Knowledge is that once you harness the power of the community things happen incredibly swiftly. If we had a consensus on what to change, it could be coded into AWB and it would happen relative;ly quickly as part of every AWB users editing pattenrs, or a bot could do it. I'm not going to challenge your data about 49k attributes and 2k properties, but that really doesn't sound right to me. It might be you have a specific goal that Wikipedians don't, and you're mapping attributes to properties that we on WIkipedia wouldn;t. I'd probably just engage my brain to know whether/how? the canadian senator infobox template represents persons or what unit for an attribute is used in a particular template. I find that easiest.

607:

users where we considered the following alternatives: Create a GUI for the database, not so much work for us, we would have been able to check consistency, etc. Another alternative now is to install our own MediaWiki load the template annotations, we already have, into it, lock the template definitions and only allow registered users to edit it. Both approaches allow us to control exactly what is going on, we can block users, control parse hints, etc. Nevertheless, we think that Wikipedians should have full control, which we give away in this proposal. We are not admins here, our vote does not count much, if somebody wants to change the templates or the parsehints, we would have to adjust our code to Knowledge, exactly as any other extraction approach.

2852:

consistent names in templates is just a 'would be nice' item but not very important. The 'dirty hack' as you call it is the whole point and is what gives the benefits, besides being much less work than standardizing the names. The current templates are a great big dirty hack and one advantage of this is it would give a way of putting a bit of structure on the parameter side of them. As to your feelings about being able to extract structured data from Knowledge you're entitled to your opinion but lots of other people think differently. The point is would you be affected by the work to support the people who want semantic data out? As far as I can see there is nothing but benefits even for people who'll never go anywhere near a database.

2459:

outside user, dbPedia, who wants to mine Wiki data and wants Wiki to change so they can do it easier? I don't really care about number 2; they're the ones who decided to mine Knowledge, so it's up to them to make their site comply with Knowledge. If this is a number 1 issue, I wonder how true it is. Where is this new user getting that template? I have seen new users copy and paste templates from other articles like it and then use that template, which means that the template parameters are fine. Or new users will go to the template page and copy/paste it, which also means the template parameters are fine. The only problem I see is if the user is changing a template to a more specific one (like changing

1290:

mapping templates contain a fraction of the infobox attributes (those which should be mapped to the vocabulary on MetaWiki), but I'm not sure whether this is as bad as think. Often, the doc pages contain syntax + example of a template, which is also duplicate information. So any change to a template usually implies modifying its documentation as well. So, I do not see a very high risk of annotation rod (it could also be checked automatically). Another point is that it is a pretty hard requirement on editors to modify template definitions to enable this kind of mapping, in particular since this might require complex syntactical constructs. Maybe, we should invite a template expert into the discussion. --

1164:

decided to use wiki software to facilitate the writing of an encyclopedia anyone can edit. Everyone said it couldn't happen, yet here you are asking for a way to mine the data that shouldn't exist. Don't worry about the amount of edits that need to be made, don't worry about the things that can go wrong. If you engage the communtiy, you will quickly discover how trivial those concerns are. And the way to engage the community is to keep it simple and fix a problem everyone can identify with. The community will engage, and some of them will really engage and drive the standardisation on to your desired end. It really is that simple, if you can adopt the right approach.

1395:

wikipedia it would enable the parameters to be checked and errors found automatically - a person could write a template expecting a date and uses could be checked by a bot or directly if it simple enough without anyone else having to do anything special. Robots could also be used to check corresponding infoboxes in linked pages on other sites though that would probably be better left to dbpedia. Overall it would advance the aim of making information freely available with little effort on the part of most editors - and it would automate some of the bot efforts. I can see very little wrong with it and a great deal of gain.

2024:

can see. One has to have a long term goal and an idea how to get there otherwise the evolutionary strategy will lead to weird constructions and slow development. You get things like the eye which works but has a blind spot which a lot of other strange mechanisms deal with. The evolutionary nature means that each step in the path much show appreciable benefits such that the costs will be endured. And the costs must be fairly small. It can't be implemented without using Knowledge editors as there's so many templates and new ones are being continually being made up - they are the ones that have to be shown a benefit.

1840:"Guard" is perhaps not the right term, but you would have to make changes in your inner templates if a property was added or changed - right? To keep the mapping accurate and up-to-date. So, you would have to watch all the infoboxes for any changes that might affect your mapping. My question is why can't you do this on your end? Keep information on each infobox and what the different parameters mean and what they map to in your system, and build your database on that? Interpret the properties on your end, instead of adding information that probably most people will not understand or use in Knowledge? 1938:, information from different Knowledge infoboxes is mixed (all mapped to the class Person or a sub class of it) with different attributes (born, birth_place, ...). So the template allow you to control how the data is extracted and presented in such tools. The RFC seems to be badly written and extremely hard to understand. Maybe, you can point me/us to particular sentences/parts, which are confusing/unclear. We could extend the RFC to be much longer and detailed, but then most people won't read it. (To be honest, my impression is that some people seem to stop reading before the "Alternatives" section.) -- 1355: 1864:

when they are kept up-to-date in a closed separate system. Wikipedians have no control over how the data is extracted, so they cannot influence how external tools use it. The approach is a relatively light weight way to have semantic support in Knowledge. Also, as Dmcq mentioned, it should also be the case that the mappings do have some immediate use for Wikipedians. (I also disagree that they are very difficult to understand for technical users, which are able to edit infobox template definitions.) I added a paragraph to the Alternatives section of the RFC with this information. --

413:

anything (like template definitions). Wikipedians would have the direct possibility to influence the data in DBpedia and other extraction approaches. Since DBpedia pretty much contains the data included in Knowledge, just in a structured format, we could spot inconsistencies in Knowledge with some tool support and users could fix them. So in the long run DBpedia and Knowledge will improve, likewise. So in a nutshell: the templates take up a small line in the doc pages, interested Wikipedians, who use the extracted data, gain influence and tools can be created that help editors.

1719:

out issues? Can't we learn ourselves about the potential problems while applying the approach? (It's not like we are not willing to understand how Knowledge works, although in my opinion Knowledge is very diverse, so everything you learn can only serve as a guide, but not a rule. Common sense should prevail, at least in the long term.) Realistically speaking, what are the alternatives apart from abandoning the RFC? Shall we hire someone for covering the social aspect of adding templates to doc subpages of infobox templates? Or wait for someone to jump in and fill the gap? --

2398:

parameters of a particular template. I guess the database editors will patrol wikimedia fixing up problems and sometimes looking at template interfaces in individual wikipedias if they don't seem to be delivering what they said they would. I think I'm happy with that if that's the idea. Looking at that birthplace I must admit "rdfs:subPropertyOf place or location" sounds all wrong so the terminology isn't very obvious, subClassOf would be more what I'd have thought so it looks like they will need specialist skills there which would be out of place in any of the wikipedias.

1464:- Using birhdate/deathdate in biography 'boxes as an example. There are at least two ways to generate the date that shows up in the "Born" field. The most common are to either type out the entire date or to use a specific template that converts numbers into formatted text along with an age. If the schema is looking for only the "day month, year" format (and it would have to be 9 or so variations of that) it would hang on the use of the templates. Aside from dates there s also a question of what this would do to links in the text entered at a parameter. 91:

of microformats). The basic idea to add metadata is the same. Furthermore they are also complementary. With the help of the annotations for coherence more microformats can be created and embedded once they are stable. Lets say there were microformats for everything, then this might (not clear) be achieved with microformats. But who is going to create them? Who is going to embed them? Who is to decide what the correct microformat is for each content type (as I mentioned e.g. medical drugs, etc.)

2110:

the aim of wikipedia but there needs to be something editors can see in wikipedia that is of advantage to them without going off to some database. Automated type checking of uses of templates is one clear advantage that people writing templates would be able to see fairly easily, it doesn't have to be wonderful just find any instances of date which don't parse well so they can check them. Then later on database aspects can be brought in to check that place names really are places for instance.

1765:

templating language was written with the intent that it was for text presentation only, and therefore should not be a programming language. I think that this "guideline" has created a lot of problems down the road, with Knowledge growing so rapidly and needing more programming capability in templates to be able to create more consistency in so many variations of presentation in so many different types of articles. Hans said earlier that it sounded to him as if the proposed solution was to "

1934:"How are your changes going to help Knowledge control what data is extracted?" It doesn't help Knowledge to control "what" data is extracted, but "how" it is extracted. For instance, the template provides information that birth_place and born both stand for "birthplace" (in more general terms it provides semantics to infoboxes), so it is quite obvious for me that this controls how data is extracted by DBpedia and others who will likely follow. If you then look at tools building on this, e.g. 2125:

usually transcluded in the template definition page, so they are visible when looking at a template. The mappings are, in some sense, documenting the template, because they add meaning to its attributes. That said, I'm also happy with adding them directly to the template definition, although I fear a bit that there could be a lot of of additional discussion with admins to temporarily unblock the templates. So an initial version, which could be done in a day, could take quite long instead. --

1227:(Response to Jens Lehmann) Well, I totally disagree about the part starting "If you take your thoughts further". "Proper knowledge representation" such as RDF isn't any more appropriate in Knowledge (mind you, I am talking about the wiki including most of the templates, not about the underlying software) than CORBA, DOM or similar systems would be for Linux or BSD kernels. These things don't fit into the overall culture. "Wiki" is Hawaiian for "quick", and that's very close to the 946:. The first row is the property we mapped to (still in camelCase, all lowercase would be better), the second is the property as it occurs in the template, the third row is the template name (cave: it is all lower case, we have a script that corrects that, I will let it run over it, soon). We have a lot of data, which we can give to support cleaning Knowledge, so if you think about cleaning everything, let us help, tell us what you would like to have. 861:

is easier in the future to extract and check data and compare it with other sources. Once you have a template doing something useful for people on wikipedia like automatically doing simple checks on the data the rest can follow easily. It does have to be set whilst considering databases and other wikipedias though or it will be much less useful than it might be. Wouldn't it be nice to be told you'd entered 12th Nob 2009 instead of Nov?

1820:). Increasing expressivity of the template language is not a solution imho as only experts can join in modelling the vocabulary and it is also a security issue as you pointed out. Two easy extensions would be to create RDFa based on the template mappings (which is an easy script, maybe half a week in developing time) or to anchor the mapping table in the software (also half a week). Semantic Web data is spreading very far: 651:

developer community. The infobox annotation templates are pretty concise - you just need few lines to establish a mapping. Please also bear in mind, that not ever author has to interact with the template annotations and in many cases (e.g. when attributes are unique) they are not even required at all. Also, the proposed approach can be later supported by a MediaWiki extension, to make the mapping generation even easier.--

611:

Our basic design principle was to create a lightweight process of Ontology Engineering. The question here is how much technical knowhow do you need to contribute to the Ontology and the property scheme. The domain knowledge, i.e. English literature, Linguistics, Medicine lies with people, whose skills normally end at using infoboxes in an article. Only technical experts can edit template definitions.

1891:

be deleted until you are through using them. This is what I do when I've made changes to templates and want to test the changes without affecting anyone. Also, imo, you need to explain this more clearly - "Wikipedians have no control over how the data is extracted, so they cannot influence how external tools use it. " - How are your changes going to help Knowledge control what data is extracted?

1590:

include more in them (given that they allow only very simple structures). I agree with you on this, which is why I dislike alternative 2. In case you are opposing the RFC itself, one should consider that the templates are quite simple and that they do not completely duplicate infobox attributes (only those which should be mapped to the vocabulary on MetaWiki - see the drawbacks section above). --

311:: "Microformats are not Infinitely extensible and open-ended A panacea for all taxonomies, ontologies, and other such abstractions Defining the whole world, or even just boiling the ocean". Please note that our approach is also lightweight and could be running within days (depending on what will finally be decided), but we want consensus on the usage of the above described templates first. 584:- so that when enough data has been gained in the listitem it can be launched into an article with an Infobox. Ie Zero keystrokes to copy data across. I am suspicious that this compliance thing; would rename parameters and thus break the link. Quite simple: if that happens- the Infobox goes and Iĺl code up something that looks like an infobox. One definition of a computer geek is 394:

infoboxes could be checked for reasonableness and translated into a standard form easily for database use. All sorts of things like peoples names, place names, numbers of storeys in buildings, whether being still alive is reasonable given date of birth, professions, colours etc could all be checked but practically all would need language specific modules associated with them.

1655:). We were met with hostility, because of our logo, which really seemed like spam (which we did remove now). Basically, now it is just one line in the doc subpage to collect information, which is useful for any extraction approach. Knowledge is for everyone and it should be easy to contribute without first reading hundreds of pages and becoming a standing member for years 1824:. Note the suggested edit links of the BBC back to Musicbrainz and Knowledge (in small font size). This is already good practice and gets adopted by many sites. So there is a need to act and provide guidelines and tool assistance. These guidelines should not be strictly enforced, but rather tools should make suggestions, based on the annotations. This will help. 536:

extractors will use them as well, i.e. there is no commitment to DBpedia. (Of course DBpedia examples are used as demonstrators otherwise some people may not see the point in the RFC.) Apart from that, the changes should not be done for the satisfaction of any specific party, but to increase the value of the information contributed by Wikipedians.

685:

standardization of names or parameters. I guess there would be standardization eventually because of better communication and I';m quite happy with such unforced standardization. My main problem is the hows of the template name and parameter name mappings if only portuguese is used in the portuguese wikipedia and only english in the english one.

2083:

referring to is tagged as having several issues, because of a recent heated discussion (which I do not want to go into). I am not sure about the "two nearly compatible standards". Can you help me out by providing a link? Feel free to ask about other confusing/complex sentences such that I can fix them (or edit the RFC directly if you like). --

148:. The use case is the data contained in Knowledge, not one domain, but every domain (possibly also other language versions). It is preparing the deployment of Semantic MediaWiki and will be used by DBpedia right away. Is there a generic microformat that potentially covers everything, from almamater to contra-indication to oscar nominations ? 1988:

resembling an encyclopedia, and we may eventually develop our own. But I am quite aware of how my own profession's attempt at this ended in the total mess of MARC formats--which, like Knowledge , will probably need to be worked out from scratch all over again. Whether we will want to incorporate subschemes is another unclear question.

2363:

information is fundamentally different and so DBpedia handles it differently.) Let's write a central documentation page with the most common standard parameters. That's going to simplify editing for those of us who regularly deal with many different infoboxes. Let's even make it as compatible as possible with the citation templates.

514:

Wikis are using embedded images in the infobox header, something there has been limited discussion on here; and 3) language of use for accessibility. Bluntly I'd expect a template on the Portuguese Wiki to either be in Portuguese or be moving towards it. So a term in English is not necessarily going to be identical in Portuguese.

2586:

line very carefully and idiosyncratically, so that the editors who fill those boxes are entering comparable items. The problems this variation would cause for databases (especially query-oriented ones) are a reflection of differences, anomalies and incongruities in the real world as much as those in editors' styles and habits.

1323:

properly you need the support of one or more of our template experts. You can find them in the editing histories of the more difficult templates. I am sure they will find a way to create self-documenting templates that "know" the "types" of their parameters and can have an optional outer layer that can present the parameter

1772:) Then there will be a natural movement to convert existing heavily used templates to better address Knowledge needs, and with that conversion, standards for uniformity of parameters will be a more natural progression at that point. Help fix the basic underlying problem, don't just add another artificial layer on top. 2729:), so please read it before casting your vote. Please note that the vote should not depend on the page where the mapping is stored (doc subpage, along with the template, extra mapping subpage). You can leave a comment about what you consider the best place to store them in your vote. The vote should also 1133:. If you project that into the future, when would you reach the more special domains like Soccer or Medicine? How many edits will it totally require until most of the infoboxes are cleaned up? Categorys are great, if you have fixed dimensions and only one set of articles you look at. Look at this here: 2585:

have an enormous range of purposes and structures, as of course do trade unions and churches. The lines in these information boxes just aren't going to match each other very well all the time, but they have to be edited to fit the underlying subject matter. Sometimes this means phrasing the name of a

2470:

So what exactly is the problem that needs to be addressed? Why do things need to be absolutely standardized in templates when the parameters can be mapped together "behind the scenes" so that birthplace = birth_place = placeofbirth? I don't see why all the templates on wikipedia have to change, which

2002:

I see a discussion above about other language Wikipedias. I think this in fact might be the immediate focus, not just an additional product. Using the precedent of the multilanguage descriptors in Commons, If the ralationships are properly worked out, they should be appropriate for all languages, and

1983:

Writing as a librarian with a moderate amount of Information science background, I certainly would be a strong supporter of using structured data as much as possible, and even generating complete article content from them. Though I'm not an expert in what is fashionably terms ontology, it's basically

1930:

We have been creating templates in our user spaces for many months before we started to add them to Knowledge. We also own installations of MediaWiki. Our initial effort was certainly not the best way to do it - we had a DBpedia logo in there and the rendered template took a lot of space. If you need

1718:

There were discussions (and support) with Daniel Kinzler (active since 2004 in the German Knowledge, MetaWiki, Commons; software developed paid by Wikimedia Germany) and Brion Vibber (former CTO of the Wikimedia foundation and lead developer of MediaWiki). But isn't it also one aim of an RFC to point

1552:

One of the reasons that there is duplication of templates with variances in setup, etc., is because of the quite limited functions allowed in templates. Unlike almost any programming macro language anywhere else, there is no capability to do something as simple as store a value in a variable, nor is

1163:

It's almost deinite that someone will change things back. Welcome to Knowledge. Look, as a Wikipedian with a lot of experience as to how these things go, I'd ask you just to accept that it will happen. It works in a similar way to the way an encyclopedia was built after Jimmy Wales and Larry Sanger

1120:

Hm, it seems we still misunderstand each other. So you start standardizing the 20 most common attributes, maybe with a couple ten thousand edits in templates and articles, what then? Do more? How would you reach convergence? At a certain point somebody might think an attribute should have a different

614:

Templates are normally used for representational purposes and this will probably not change and also shouldn't change as it should stay easy to create them. Now the annotations just add another dimension to them, i.e. structured information. A much better way as Hans Adler proposed would of course be

114:

The lack of existence for a given microformat is not reason to cook up our own standard which does the same thing. If there are common use cases (such as your "medical drugs" example) which could be covered by a microformat-type markup then we should just go with that. It's lightweight, requires very

90:

I just checked the microformats page. You are right microformats have a similar purpose, but the proposed approach goes further. There are about 10 specified microformats and ten more drafts, which do not cover a lot of domains, but only the most common and most simple ones(which is the intended goal

2610:

You're right. In a number of cases, the complex real world is hard to fit into infoboxes. Our experience in the DBpedia project has been that the Knowledge infoboxes are still a very useful source of information for querying purposes. The proposed mappings would essentially cover the cases, where it

2548:

in American professional baseball have different structures, purposes, and relations with their minor leagues, from those of other leagues in other nations and other sports. The structures of local government in the United States and United Kingdom may look logical from the outside, but are full of

2539:

As a technically-ignorant editor who's never created an infobox and isn't clear about what's being proposed, let me say what I see as a possible problem with standardizing some parameters or characteristics. Sometimes parallel or analogous lines in information boxes refer to things that are slightly

2458:

What exactly is the problem here that needs to be solved? I'm not sure I understand this issue. Is this 1) a problem for new users who are trying to use an infobox and get confused when they put "birthplace" and it doesn't work because the template wants "birth_place", or, 2) is this an issue for an

2023:

I'm basically in favour of making the data more easily available and easier to check and working together with other languages. However any goal in Knowledge has to be achieved by an evolutionary strategy and in line with the skills and desires of its editors. That has a few consequences as far as I

1890:

Jens, when I look at the examples, the original templates are missing. When I look at the history, I see they were deleted. If you wish to demo how this works, I would suggest setting up the Dbpedia template(s?) in your User space, and calling them from there in your examples. That way, thy won't

1863:

We currently do have our own internal database with many mappings, otherwise the demos would not work (for instance the Knowledge facet based browser). The goal of the RFC is to move away from that. An internal database has some disadvantages: Long term maintenance of mappings is probably difficult,

1699:

and get into difficulties for bold moves such as creating English stubs for all articles on German politicians that exist on the German Knowledge. Before you have seen these things you don't know enough to do large scale changes on your own. As I said, you really need someone who feels like a member

1604:

As a minor sidenote, I think that discussion titles like "Suggested Reading for DBpedia project members" imply that we know less than most readers here about the subject. However, some DBpedia members know templates very well and aware of their limitations, while other non-DBpedians participating in

1196:

What do you mean by standardising attributes/fields? Do you mean aligning the spelling of an attribute (rename birth_place, born, placeOfBirth to birthPlace etc.) or the integration of the mapping in the template definition? Would you go for point 1 or 2 mentioned in the Alternatives section of the

1024:

What we mean is: currently there are about 49111 different infobox parameters. Now, lets say you rename birth_place, birthPlace and placeOfBirth to birthplace, you will only have 49108 different infobox attributes. We estimate, that if you put everything together that belongs together (which has the

684:

I have practically the opposite reaction. I like the idea of templates being able to state the expected format of parameters or values expected in them, and give a mapping for template and parameter names so they can be correlated between wikipedias and for database. However I wouldn't want a forced

665:

Looks like I have misunderstood something. What I'm then not clear on is whether you propose to first standardise the common parameters and then do this mapping. That is, if I understand you and this mapping won't affect the way I use an infobox template in an article or build an infobox template?

610:

We really think that metadata should be kept in and provided by Knowledge directly. It would be nice, if MediaWiki would have that feature or if Semantic MediaWiki would be deployed, but both is not the case and it is unclear, whether it will happen in the near future. Scalability is important here.

535:

The point about "satisfaction of a 3rd party" was already made in the previous discussion. The conclusion was to create this RFC with non-DBpedia-specific templates. Looking at the examples, you can see that they do not mention DBpedia and only map to RDF/OWL (W3C standards). It is likely that other

2510:

The RFC is about making it easier to reuse information in Knowledge infoboxes (both internally and externally; see demonstration section on what can be achieved) and it suggests to do this by mapping infoboxes and their attributes to descriptions on MetaWiki. This means that not every article needs

2306:

Put all mappings on a separate wikipedia website, with a dedicated interface for maintaining the mappings. Should be Interwiki aware. Mark infoboxes with a template+link leading to their registry of their entry on this mapping website. Basically, the current dbPedia approach, but with the wikipedia

1806:

namespace? Well, software has to be slightly adapted, changes might not occur so often and there could be new versions, of course, we would welcome that. We just want to contribute our initial mapping, then it is intended that it should be freely changed to include new mappings and improve the old

1739:

Perhaps I am too pessimistic, but I don't think the RFC is going to have any useful result. That's because most of what you are saying sounds very abstract to me. I simply don't understand where you are coming from. And I guess it's the same for the other participants. We can't come to any informed

1507:

The problem of template use in parameters could be deal with by expanding parameters before checking them so only the visible text was checked. I would have though any checking would best be done for starters by a bot patrolling things rather than when editing, that would have the least impact till

1289:

You're right. "infoboxes" didn't make too much sense in that phrase. I can also understand your other points (after all constructive criticism may help the discussion), but my impression is that the above proposal is not an "unintelligent" way to do it. There is duplicate code in the sense that the

1070:

This is actually a proposal where and how to discuss standardization. With birthplace it's probably obvious, but with other attributes it's not so clear. We just propose to put the above table at the doc page to have a place to talk about standardization and gather information required for cleaning

1051:

What I am disputing is the idea that everyone would agree that the 49000 can be condensed to 20000. I'd also dispute your method for finding all musicians from Canada, since not all articles have infoboxes. I'd likely mine the categories, but that wouldn't be perfect either. I really think the way

986:

I refered to the time required to align all infoboxes (not a particular property). We estimate that 49k attributes need to be mapped to 2k properties, e.g. there are more then 10 used spellings of birth place and it might be hard to detect those. (Even if those are fixed, you still do not know that

860:

I'm more for doing changes to parameter names on an ongoing basis as desired, after all the same sort of thing can be done in the database, its either effort in one place or in another. The main thing I'd like to see is the templates with their semantic information becoming a standard feature so it

822:

Hello Hans and sorry for not replying earlier. I understand your point and why you are against the proposal. Usually, if you build e.g. a piece of software and find out that it is broken in some way, you just fix it directly. Usually, you should not create an additional layer of abstraction to make

797:

Hello Dmcq. What you are describing is what the RFC says: relatesToClass refers to a page in MetaWiki (not Commons - we discussed about the appropriate place some time ago and we already have permission from MetaWiki; we were also allowed to use a bot there to create the initial version). This way,

721:

My problem is with the portuguese 'relatesToClass = Musician' and it referring to a template in english with names like 'birthdate' in it. I can't see a decent way round that problem and it would be referring outside of the portuguese wikipedia to somewhere else. I suppose that information wouldn't

633:

I like the proposal to standardise the names of common parameters, but I don't like the proposal outlined above regarding template mapping which seems incredibly involved and convoluted and seems to be taking what should be simple tasks away from the comfort zone of all editors. Yes, there is some

561:

the proposed solution as (1) addressing the problem in a place where it is inefficient to do so, and (2) addressing only the third-party concerns, unlike the natural solution, that would directly address the Knowledge concerns as well. Wiki text is not ossified source code that shouldn't be touched

2514:

I should add that the RFC is not specific to any particular extractor (like DBpedia) and relies on standards, so it can be used by other extractors and internal Knowledge tools as well. I'm not particular in favour of your attitude of not caring about anything happening "outside" (we do not really

2397:

So there would be a central database of template or infobox types in wikimedia along with standardized parameters names and their types which the individual wikipedias can refer to. Databases can then use that together with any template interface in an individual wikipedia to try and interpret the

2109:

Standardizing the names in infoboxes is not something I see as conferring great value to editors in wikipedia. Skulking around putting in subpages or being bold and changing all parameters in sight are two opposite ends of the spectrum from cooperative editing. I acknowledge all this work furthers

2082:

It doesn't break anything and the additions to the doc subpage of a template definition can safely be ignored. In order to clean up the mess you mentioned, I moved the discussion part of the RFC to the discussion page and removed unnecessary parts of the article. The "Semantic Web" article you are

1522:

Things are never easy. It struck me that expanding the templates has a little problem if they are ever used to give different data according to user preferences. If I wanted as many dates as possible to have the day of the week output as well as the date then one really couldn't expect a parameter

459:

Problem: Infoboxes are not standardised. Basically the same information is present in different templates, but using different parameters. Sometimes the same parameter is used for substantially different information in different infoboxes. And sometimes the same information is encoded in different

412:

Yes, that is what the proposal is about. We had an iterative strategy in mind. First the templates are created here in Knowledge. DBpedia uses these templates to extract cleaner data (maybe also other extraction approaches like Freebase). They do not take up so much space and do not interfer with

353:

The goal and reasoning behind the suggested approach is not to revamp the entire system. One of the primary motivations is to be minimally invasive in the sense of not having a negative impact on the way Knowledge works. The approach only requires to add the templates to the infobox documentation,

2378:

Yes, we extract the information from Knowledge articles. Since recently we obtain the information from a live update stream, i.e. when a Knowledge article changes, the DBpedia framework is notified, parses the wiki markup and updates the RDF output. DBpedia does not have hard requirements when it

2337:

I don't follow all of the above but I think the consensus is that each wiki should be free to adopt their own approach. I also don't see why the timetable has to be a year nor why it isn't achievable to do it through standardising templates and then letting other people mine the data from there.

1764:

Hans Adler has much more experience with Knowledge policies than I do and I have no problem deferring to his knowledge of Knowledge's way of doing things. I did not intend to hijack his title/response, and have changed the title of my section after reading the responses. I did want to note that

1589:

Thanks for your post. As mentioned above, I think it is good to have a neutral template expert joining the discussion. Just to clarify: Are you against alternative 2 in the alternatives section above or against the RFC itself? Your line of argumentation is that templates would become a mess if we

1394:

If editors annotate templates with this extra information then they make the information more accessible and easier to check. There would be no extra effort on the part of people using the templates. The facilities wouldn't affect the body of templates, only the parameters would be annotated. For

1005:

I don't quite follow you. It'll be relatively easy to do just by looking at each infobox and working forwards from there. There's a project underway that's standardising banner templates, they're nearly finished now and I think they've been rolling through for about a year, so if you've spent a

841:

I don't actually think it would be that hard to get Knowledge wide consensus to standardise infobox parameters like birth_name, birthname and birth name, and I reject the idea that it would take forever to do. I doubt it would take more than a week for a bot to run through. We've handled harder

740:

In fact if we simply put classes into wikipedia commons as text that would be a way to make the job independent of dbpedia and acceptable to the different language versions. The relatesToClass then would simply refer to a file in commons which would look a bit similar to a template but could deal

606:

As we designed this solution, we had two other alternatives. We already created a mapping like the above proposed template annotations would produce. It is held in a database, which means we - for our purposes - can very well access it with SQL. Now, we thought about opening this database to more

393:

I don't think requiring microformats would work, however I think having types associated with fields would be a very good idea and help with checking the encyclopaedia. For instance a date type would look different in different language versions, having a date format check would mean all dates in

237:

for this, but then other people might disagree. So there can really be a lot of disagreement about it until it gets stable. (As a rough estimate: the 49k attributes currently used in templates may be mapped to approximately 2k properties). So RDFa would be a sound way of including the information

1624:

I think the first title of this kind was justified since it addressed the social side of Knowledge, and the communication problems that have led to deletion of your project's first efforts seem to indicate a general unfamiliarity with that. In my opinion you need at least one person who has been

1488:

This isn't part of the current proposal, but what could be done with the information, after the proposal would be implemented. And even then it wouldn't have to be implemented for all parameters (so the output of some special parameters wouldn't be limited). It would limit input options for some

759:

Ah, I may have misunderstood a little. I hadn't realised the proposal was looking at standardising across all language Wikipedias. I don't think I could support that, each Knowledge should be free to do as they wish, I should think. And wouldn;t this need far wider input is that were the case?

513:

And with the non-English Wiki template in the examples... at a minimum there are two or three problems there: 1) Different material being acceptable for inclusion in different languages - do we use their criteria, force ours on them, or go for a "lowest common denominator"?; 2) Some of the other

216:

There are two problems we need to tackle. The first one is the technical implementation and yes RDFa might be absolutely fine for this, also. It is the same standard. The second problem is the consensus about the meaning and interpretation of properties. As you see above each instance of Musical

2412:

The "rdfs:subPropertyOf place or location" was wrong and I removed it. It could still be that mostly people with some Semantic Web knowledge will edit such definitions. On the other hand, one can explain things like "label", "domain", "range", "sub property", "equivalent property" in one or two

2362:

Now the inconsistency of the infoboxes is a bug, not a feature. Let's standardise the parameters with an eye to DBpedia's needs. (I.e. in a few cases we will need two parameters that mean almost the same thing, only one of which may be used, and that display in exactly the same way. Because the

2124:

I agree with what your write (was it intended as reply to my post?) except that I think the doc subpages could also be a good place. They often already exist for popular templates, are freely editable (infobox template definitions are sometimes blocked or semi-blocked), and the doc subpages are

1987:

I am not really convinced that any of the current formulation of this--whether SMW or RDF--are really optimal, or what will be the ultimate generally used formulation. Much of the discussion of ontologies is so general as to encompass a wide range of purposes besides that of producing something

1322:

in the templates themselves and formed an additional incentive for uniformisation of parameter names. But what you did there leads to duplicate code and invites annotation rot. It looks as if based on a philosophy of minimising the cooperation with Knowledge editors. Instead, to do these things

1052:

things don't work at the minute is that there are no standard terms for infobox parameters that could quite easily have them, and which people in this debate concede is a problem. I think the place to start is talking about standardising the most popular infobox parameters. From tiny acorns...

2851:

It does sound like it would be better to rewrite the proposal to make it more understandable. What's said here seems to totally miss the point of the proposal and misunderstand how it would be implemented, who would do any work, or what the benefits would be, in fact the whole kaboodle. Having

2101:

I think you are going about this in the wrong manner. There is absolutely no need to change infobox attribute names as a template interface can handle any mapping. There's no need to go around saying everything in Knowledge needs to be standardized, that will just go up peoples noses. Having a

1962:

I vote for the alternative of having the interface definition on the same page as the template definition. It seems silly to me to separate them, it is just asking for trouble with changes being out of step. The idea of guarding is very bad if anyone was seriously proposing that. The wikipedia

897:

Writing such a bot might be indeed possible (although I think its much harder than you assume if you think e.g. about how cumbersome parsing of template rendering can be). However, for the bot to work it has to know how to map attributes - this is exactly the purpose of this RFC to establish a

2358:

I have exactly the same problem. We have been told (I believe) that DBpedia gets the data from reading our wiki pages. That it needs to know for each parameter of each infobox of what type it is (e.g. date, and more precisely date of birth; or colour as text; or colour in RGB form). That this

778:

Of course each Knowledge should do as they wish. This discussion here is only about the English Knowledge. However, if Wikipedians from other language chapters want to include the mechanism as well, then this is a very easy thing to do. We are not asking permission to create such templates on

579:

My initial reaction is suspicion, while I can see theoretical value in removing anomalies it does seem like we are building a steam hammer to crack an egg. Yes I use infoboxes to assist in the task of writing articles, but before I can comment sensibly it seems I have to leave my articles and

650:

Is there something specific what you don't like? We were actually investigating the matter for quite a while (more than a year) and this RFC represents the easiest, simplest and most flexible solution we could come up with. It was also discussed with quite some people e.g. from the MediaWiki

926:

I totally agree that this is easy. This wiki has a huge number of very active editors who would help. We don't do perfect solutions that do everything at once with no human help. (That might be hard, I admit.) We would do it separately for relatively homogeneous classes of infoboxes, and an

307:

are not our own standards (we were not involved in their creation) and not the same as microformats. They both offer their own benefits and the existence of one of them does not remove the need for the other. Furthermore, RDF and OWL are widely used and established. You suggest creating new

1448:

I've noticed an example in the discussion that implies that the proposed schema would flag/warn an editor if the content entered at a parameter does not fit with an "acceptable" set (the example was that it would trigger if an editor entered "Nob 19, 2009" instead of Nov in a date field).

2737:. This is made easier through the mappings, but it is not strictly necessary to do it and can still be discussed after the mappings are in place (if accepted). Note that a later migration from the proposed RFC to other solutions (e.g. Semantic MediaWiki, solutions proposed by 2003:

we might do well to think of working this way from the very start. A date of birth in one language Knowledge is immediately usable in another, and the microformat code can deal with the way it is expressed. The database behind the individual Wikipedias can be a single one.

1334:

As a practical matter, since yours seems to be mainly a German project, you might want to consider developing it at de.wikipedia first, taking into account what you learned here. I guess they are more open to such things, and once it works over there you can roll it out here.

2065:! I sure it is all very clever- and the intention is noble, but what it is- I couldn't tell you. Could we simplify the sentences, bringing them back to a SUBJECT verb OBJECT format, removing all the subsidary clauses and modifiers, so other editors can join the debate. -- 2515:

view ourselves as being outside). If Knowledge can be made even more useful by enabling queries over it, improve browsing and searching etc., it is very well worth to allow this simple addition of a few lines to each template definition (it doesn't break anything). --

1097:

alone. I get what you are trying to do, what i am trying to explain is the best way to engage the Knowledge community on the issue. I won't lose any sleep if you fail to do it, because the cost to me is low. But the way to do it is to propose standardising the

2573:. Political parties, coalitions and election systems also vary greatly not only from country to country, but within countries, so that standard U.S. election information boxes fit poorly for elections in New York, infoboxes have to make adjustments for the 2788:: I believe the 'Include the mapping directly in the infobox template definition' is best. I think having parse hints for parameters and access and checks via databases would help the aims of wikipedia while causing very little in the way of problems. 494:

degree of standardization being needed. This is something that is seen with "general to specific" infoboxes where there is a generic, bare bones base 'box that can, and should, be replaced with a more specialized one by changing the template title and

1679:

You can't learn about the workings of Knowledge merely by reading policies and guidelines. These are merely incomplete and often faulty attempts to write down actual practice, and that's why they are being revised all the time. The main reason for

2691:, this template has 11 parameters that are optionally inclusive and default when excluded. Parameters are: Border color, size, and pattern; Background colors; Directionality; Text for each section, text color, and text size. Please see this page: 562:

so as not to break things. The way we address lack of uniformity here is by building a consensus for uniformisation and then executing it (by refactoring the wiki text). This only breaks down in exceptional cases such as the one that led to the

1354:. We also have a synchronized version of Knowledge in RDF. We can provide lists and data that could exactly tell you, where inconsistencies are in Knowledge infoboxes (like languages that are not links, but plain text in infobox_language, see 2830:

While I'm at it, I'd also like to criticise the proposal for being almost uniquely unreadable, and this is from someone who actually understands the issues involved - I bet it's completely impenetrable to others who aren't quite so geeky.

2540:

but significantly different, so editors should be (as I hope they would be) free to create the lines that fit the topic of the articles for which the information box is designed. To give a couple of examples off the top of my head: the

2764:

Just a note to say that we don't use voting to decide things on Knowledge. I've retitled the section. Whether or not a motion is carried forward is decided by the consensus as determined by weight of argument, rather than head count.

539:

Can you give a specific example for one of the three problems you mention? I do not really see why e.g. a template in Portugese in a Portugese wiki is a problem in this approach or how it relates to material being acceptable or not.

270:

I included some more examples above. Consider the trivial problem, that both infoboxes for musical artists and marching bands have a member property, but in the first it is a list of members and in the second case a count of members

308:

microformats for each kind of information. This is clearly not feasible, since a meaningful microformat needs community and tool support. It is also very unlikely that the microformat community wants to achieve this. Quoting

2712:

The discussion has been going on for a while now and we would like to come to a conclusion. Please give your "support" or "oppose" vote here with a short explanation (which should not turn into a discussion). We adapted the

580:

research something called microformats which quite frankly have little relevance in my 18th century Oldham. Yes I have added some wonderful parameters to an infobox template, that will be used in four or five months time.

69:

How do you create a global scheme with microformats? What properties do you use for examples to describe medical drugs or languages families? As far as I know, Microformats have a limited set of standardized datatypes.

2645:. This is a relatively easy thing to implement for most templates, exposes the data for those interested and has little impact for everybody else. Those interested just need to keep the templates on their watchlists. -- 1430:

After reading a substantial part of this poll on a very divisive topic you should have a better understanding of the scepticism that you are facing, the underlying reasons, and the disruption potential of such matters.

2485:

This is an issue for experienced Wikipedians who can;t remember which infobox uses which field, and if we standardised, it would simplify things. Can't see why that would be a problem. Perhaps you could explain why?

1251:", which is the software underlying Knowledge, whereas you wrote "I am talking about the wiki including most of the templates, not about the underlying software". That might be the reason for disagreement. (See also: 1470:- Right now there are 'boxes that take information entered into them as plain text and converts it to a specific link. If the schema limits what is shown in the 'box, this could be seen as damaging to those boxes. 1331:

to the user. Test it with a few minor templates, get a separate local consensus for applying it to each of the most frequently used templates, and then get a global consensus for applying it basically everywhere.

2471:

would require editing every article, say, with a biographical template in the case of birthplace vs. birth_place. Do it behind the scenes. Unless this is some real big emergency, I don't honestly see the point.

1931:

a template definition for the template we propose, we can add it. (I don't know how this helps you though, since the RFC page already contains examples and a mockup showing what it looks like when rendered.)

2105:

The idea of having a separate subpage of a template definition is I feel also wrong headed. The template interface should be up front with the template definition. Otherwise it won't be seen and updated as

2467:). And even then, I really don't see what the problem is, because any serious template change requires the introduction of enough new parameters to make one parameter name change essentially irrelevant. 1815:

vocabulary. Normally, the core of such a vocabulary tends to become stable very fast. It is also easy to reach a good coverage. Tool assistance can be easily created with the help of a User Script (see

2061:

I have tried to follow the argument- I have followed the explanatory links to a page that is hat tagged as having multiple issues- and then looking to a page to explain a standard- found the line

432: 987:

e.g. the canadian senator infobox template represents persons or what unit for an attribute is used in a particular template.) Do you think this can be done easily and how would you do it? --

779:

Wikipedian language editions other than the English one. I will edit the RFC to make this clearer. (In my opinion, it is an advantage that multi-language support is not an afterthought.) --

2726: 2722: 2718: 2714: 1605:

the discussion might be less knowledgeable in the area. I would appreciate it a lot if the discussion titles would refer to their content (e.g. "Limitations of Templates" in this case). --

1523:

expecting a date to cope with getting a day of the week as well. Nt sure how one would go round a problem like this - having an internal format annotation added to the expanded template?

2443:

I'd like to float the idea that we standardise common infobox terms and look at guiding editors on those standard terms. So we standardise birth_place and birthplace etc. to one term.

1025:

same meaning), then there will only be 2000 different infobox attributes left. If you want to find all Musicians from Canada, then you can check all articles for an infobox attribute

382:

for example...). Microformats would help in some areas, but others are just a matter of deleting redundant infoboxes, and getting rid of redundant parameters in current infoboxes.--

1382:

Sorry, but I have no idea how we could use this information. It doesn't strike me as particularly helpful, although I might simply be lacking in imagination or relevant experience.

703:

I'm not sure I understand the languages point, but I'd like to see us standardise something like birth_name, birthname and birth name. Standardising those seems intuitive to me.

1273:

Ah, sorry, it "MediaWiki infoboxes" didn't make much sense to me since we implement infoboxes as MediaWiki templates, so I just ignored it. I withdraw that part of my comment.

1684:

is that we want to do small changes efficiently. This doesn't apply in your case, and the guideline warns about the problem in at least one other, marginally related, case.

912:

Um, I could set up an AWB run now to convert all instances of birth_name to birthname (chosen at random) in articles which transclude "Infobox Foo". It's not hard at all.

592:- I need to be convinced that the proposed bot will have the intelligence to recognise when it is out of its depth- but the more I think of it the more worried I become. -- 1995:

standardization of terminologies for data elements in infoboxes --and I am not convinced that a formal ontology-based model will be the most productive at the start, and

1135:

All soccer players, who played as goalkeeper for a club that has a stadium with more than 40.000 seats and who are born in a country with more than 10 million inhabitants

798:

the approach is language independent and the templates on each Knowledge language edition are kept simple (they only contain the pointer to MetaWiki and a parse hint). --

1556:

There have been efforts to change this, but so far nothing has come out of it. I don't think adding another layer on top of this mess is a good move for Knowledge.

879:

Totally. But wouldn't it also be nice to be able to enter birthdate and not have to go look at the docs when it doesn;t work in the particular infobox you are using?

1358:). How should we make that data useful then. What process should there be to decide, which datatype to put in which field for example? Please tell us your opinion. 506:

With DBpedia I'm not 100% sure that we should be adding a layer of rigidity/bureaucracy to satisfy a 3rd party (Or have I missed something stating that DBpedia is

2310:

The current proposal of putting the mapping on enwp, but either use dedicated and protected subpages, or make a new noinclude section in the template page itself.

333:

This seems like a fairly easy fix to be honest. You're right in that infoboxes are often inconsistent, but this doesn't require revamping the entire system... –

2637:

I'm abit confused by this discussion and whether the micro-formats solution has been explored. However there is good support for some micro-format especially

898:

mechanism for mapping attributes. In an later stage this can be used to materialize this mapping by physically renaming template attributes as you suggest. --

2307:

userdatabase. We basically separate dbPedia into an RDF mapping database under the auspicien of WMF and the webinterface dbPedia. (or fully usurp of course)

722:

actually be used in the portuguese wikipedia, only when extracting data using whereever that class is stored, but where it is stored is a bit of a problem.

466:

Disadvantage for Knowledge: The more active editors get confused and always have to look up the documentation when the introduce an infobox into an article.

2611:

is quite clear that two attributes in different infoboxes mean the same thing. (This alone already provides much added value for querying and browsing.) --

1424: 238:

after the Ontology engineering has happened. Otherwise it will possibly result in a lot of template changes (which should also only be done by experts)

1811:

properties (basically reach convergence, so that attributes with the same meaning and value are mapped to the same string). It is a process to create a

1802:

these templates? One small risk is, that editors do syntax errors, which can be detected and corrected. Did you mean the template definition in the

2694:

for information on how to implement this template, as well as many examples and 3 variants. I wish you the best of luck deciding in this matter. --

2244:

I think our timetable is "within a year". This already excludes most of the implementations and basically only leaves one of the dbPedia solutions

1374: 2733:

be about whether or not infobox attributes should be standardised (e.g. different spellings of "birth place" unified) afterwards as suggested by

557:

I take the lack of response to my description of the problem and proposed solution as confirmation that the description was correct. Therefore I

2303:

Keep everything as is, but add links to infobox documentation towards the maintenance spot for the specific mapping for that template in dbPedia

2059:

Is the proposal to break something, or just plonk a extra bit of meaningless text on the doc page of each template- which can be safely ignored?

2151:

I was reading this debate, and I needed to order my thoughts. I think others might like this list as well, so I'm just adding it to the pile.

1625:

fairly active in many areas of Knowledge (preferably the English one) for about half a year, and who is similarly familiar with your project.

2180:

Will probably require significant engineering work before it can be deployed in Knowledge. Likely requiring significant monetary investment.

2574: 1489:

parameters, but that's the point of this checking and if some template is used commonly, I'm sure it would be among the allowed variants.

741:

with some variation, for instance one wikipedia might like a list for one parameter and another might just want a number or leave it out.

469:

Proposed solution: Build a layer of abstraction over the mess, Knowledge-side, which requires individual coding for the infobox templates.

2549:

all kinds of oddities and anomalies that would fit poorly into infoboxes that are good for other nations: e.g. the relation between the

2359:

knowledge is currently hosted by DBpedia. That it is hard to maintain because Knowledge's infoboxes are so inconsistent with each other.

17: 354:

i.e. the doc subpages of infobox templates (many of which we prepared already). It is a fairly small change with significant benefits.

33: 1695:

for some context that may help you understand why it can't be used for large-scale changes. All the time people are being dragged to

2578: 1094: 2861: 2840: 2821: 2797: 2773: 2758: 2702: 2671: 2654: 2620: 2595: 2524: 2495: 2480: 2452: 2422: 2407: 2392: 2373: 2347: 2331: 2134: 2119: 2092: 2074: 2044: 2017: 1972: 1947: 1909: 1873: 1858: 1833: 1790: 1747: 1728: 1707: 1668: 1632: 1614: 1599: 1583: 1532: 1517: 1498: 1482: 1438: 1404: 1389: 1342: 1299: 1280: 1264: 1238: 1206: 1187: 1173: 1154: 1111: 1084: 1061: 1042: 1015: 996: 979: 955: 934: 921: 907: 888: 870: 851: 832: 807: 788: 769: 750: 731: 712: 694: 675: 660: 643: 624: 601: 573: 549: 526: 484: 444: 422: 403: 386: 363: 344: 320: 280: 247: 191: 157: 123: 100: 79: 60: 45: 1231:. You can't introduce frameworks with a relatively steep learning curve directly into such an environment. You must hide them. 1963:

editors are the ones that will have to be shown the benefits and convinced to write interfaces definitions for the templates.

586:

someone who sits down and spends a fortnight coding an automatic procedure for task that would have taken 10 minutes manually.

1999:

the use of microformats for the data within them. This is the first step towards any rational continuation and expansion.

300: 178:

This might be a stupid question, as I don't know much about either Knowledge templates or the Semantic Web, but could we use

141: 1072: 2413:

sentences, so it is not hard to understand what they mean. (The template on MetaWiki needs to be improved of course.) --

1767:

Build a layer of abstraction over the mess, Knowledge-side, which requires individual coding for the infobox templates.

2754: 2464: 2327: 1829: 1664: 1370: 1150: 1080: 1038: 951: 620: 418: 276: 243: 153: 96: 75: 41: 2194:

Not allowed by MediaWiki atm. Though I heard that someone was working on making them valid output for the software.

2040: 1347:

We have a lot of data, which can help improve Knowledge (english only), such as these template property mappings (

2511:

to be edited. A standardisation of common infobox attributes can still take place after the mappings are created.

455:

I find it very hard to believe that I have understood what the perceived problem and the proposed solution are:

115:

little effort to implement and can easily be pushed out to the wider microformats community if it's successful.

1935: 1656: 1560: 2460: 376: 2102:

template interface wil tend to get people to use standardized names over time and that's quite good enough.

1821: 2750: 2667: 2616: 2520: 2418: 2388: 2130: 2088: 1943: 1869: 1825: 1724: 1660: 1610: 1595: 1366: 1295: 1260: 1202: 1183: 1146: 1076: 1034: 992: 947: 828: 803: 784: 616: 545: 414: 372:

Infoboxes (infoboxen?) are definitely inconsistent, and some have way too many redundant parameters (take

359: 342: 316: 272: 239: 149: 92: 71: 37: 510:

of Knowledge or that they will be a contributor and not just extracting/using the data editors provide?).

2770: 304: 145: 120: 57: 927:

occasional mistake by the conversion script would be no more dramatic than an average vandalism edit.

2650: 2591: 2370: 2367: 2070: 2028: 1807:

ones. So we do not intend to lock anything in this respect. The aim is to map template attributes to

1744: 1741: 1704: 1701: 1692: 1629: 1626: 1435: 1432: 1386: 1383: 1362: 1339: 1336: 1277: 1274: 1235: 1232: 976: 973: 931: 928: 903: 656: 597: 570: 567: 481: 478: 2057:

This is a RFC- but is ending up as a conversation. I still don´t understand what is being proposed.

939:

Hm, here let us contribute our mapping so the replacement is easier. I dumped it from our database:

2476: 1252: 187: 1770: 1564: 634:

sort of issue here, but I think the proposed solution loses the baby along with the bath water.

590:

This template employed intricate coding don't try to edit it unless you know what you are doing

2746: 2663: 2642: 2612: 2582: 2516: 2414: 2384: 2126: 2084: 1939: 1900: 1865: 1849: 1781: 1720: 1606: 1591: 1574: 1291: 1256: 1198: 1179: 988: 824: 799: 780: 541: 440: 355: 335: 312: 2766: 2570: 2491: 2448: 2343: 1691:

correctly is a very difficult art that even some very experienced editors don't master. See

1478: 1169: 1107: 1057: 1011: 917: 884: 847: 765: 708: 671: 639: 563: 522: 116: 53: 52:

Umm, this is the purpose of microformats. I don't see any need for further discussion here.

2646: 2587: 2545: 2541: 2323: 2066: 1562: 1494: 899: 652: 593: 2006:

I hope i am not expressing things in too naïve and informal a way for the specialists.

1651:. We thought it was a good step and an iterative, easy improvement (after your doctrine 2857: 2836: 2817: 2793: 2566: 2554: 2550: 2472: 2403: 2169:

Standard has a too limited domain, and is stated to never encompass all infobox options

2115: 2036: 1968: 1681: 1644: 1528: 1513: 1400: 1228: 866: 746: 727: 690: 399: 383: 2562: 2558: 2013: 1696: 1688: 1648: 183: 2249:

Do we think that any progress is better than standing still and waiting for magic ?

2158:

I think it is pretty clear that everyone would really like to do more with this data

1178:

One should add that "all" refers to those things available in the knowledge base. --

431:

Any chance we can get the CENT wording changed? It currently reads like a plank on

2695: 1892: 1841: 1817: 1812: 1773: 1566: 1348: 940: 436: 582:

They were named to be consistent to parameters in a related list building template

2688: 2685: 2734: 2487: 2444: 2339: 1474: 1165: 1103: 1053: 1007: 913: 880: 843: 761: 704: 667: 635: 518: 2662:

See the top of this discussion and the alternatives section of the RFC page. --

1314:

kind of thing serves any purpose that benefits Knowledge in any way. Knowledge

221:

property. But if we go to the Infobox Prime Minister, then there is a property

2738: 2692: 2315: 2263:

Less easy to share with other parties. We might risk showing a bias to 1 party

1490: 1351: 943: 2277:

Still requires people to navigate away from en.wp when they change an infobox

1559:

Here is some reading on these limitations/problems of templates on Knowledge

2853: 2832: 2813: 2789: 2399: 2111: 2032: 1964: 1524: 1509: 1396: 1248: 1075:, infoboxes do not cover everything, but it really helps to assign classes. 862: 742: 723: 686: 395: 2380: 2008: 1700:

of both projects to translate and make sure you avoid misunderstandings.

566:

compromise. I am confident that this is not such an exceptional case.

2314:

In my opinion, those are our best options, and I'd prefer number 2. —

2638: 1548:

Knowledge templates severe limitations - solve this problem first

1685: 309: 179: 2680:

A Really Well-Thought-Out Standardized Userbox/Infobox Template

32:

Please give feedback here and add votes (support, oppose etc.)

1808: 1029:

for Canada, where the infobox template is annotated as class

463:

Disadvantage for DBpedia: It's harder to extract information.

1543:=== More suggested reading for DBpedia project members === 140:

The standard we are refering to is Semantic Web including

2155:

Do we want to be able to do more with the infobox data ?

1121:

name and starts changing it back, because he thinks that

1455:

Also, does this mean that the schema will force output?

964:

Soeren, that's not at all how Knowledge works. We don't

1979:

longer than "long term" goal and very short range steps

1311: 2299:

So after all this, I personally am left with 3 ideas.

2257:

So what is the best process to do the dbPedia mapping

2063:

that this can refer to two nearly compatible standards

490:

In a way I have to echo parts of that. Yes, I can see

2266:

Less contributors to keep the infobox options in sync

2338:

Perhaps someone can clue me in "in layman's terms".

2366:Why is that not the cleanest solution for DBpedia? 2569:, and the overlapping counties and districts of 1991:The immediate practical goal, though, would be 1419:Suggested reading for DBpedia project members 8: 2717:during the above discussion (provision of a 2274:More potential contributors than on dbPedia. 2188:Requires changes to all infoboxes templates. 1318:benefit if such information were integrated 1093:Um...there's way more than 620, there's 896 2439:Proposal to stadardise common infobox terms 2222:Full Semantic support in the core software 2205:Either on meta or on all template doc pages 588:. Isn't there a warning template that says 1508:everything was working nice and cleanly. 225:. Now, you could say that in this case 1071:the infoboxes someday. BTW there are 2723:description of suggested alternatives 477:hope that I misunderstood something. 7: 2208:Easier to change, simpler to deploy 1425:WP:Date formatting and linking poll 18:Knowledge talk:Requests for comment 24: 2291:Probably more prone to vandalism 2217:Potentially disruptive to deploy 2197:Potentially disruptive to deploy 1643:Our edits were legit respective 2687:for the template. Developed by 1102:fields. The rest will follow. 2767:Chris Cunningham (not at work) 2581:alliance in Germany, and even 2177:Problematic due to load issues 1310:(continued) I fail to see how 117:Chris Cunningham (not at work) 54:Chris Cunningham (not at work) 1: 2672:07:58, 29 November 2009 (UTC) 2655:20:03, 27 November 2009 (UTC) 2621:07:37, 27 November 2009 (UTC) 2596:06:53, 27 November 2009 (UTC) 2525:07:10, 27 November 2009 (UTC) 2496:19:18, 29 November 2009 (UTC) 2481:22:07, 26 November 2009 (UTC) 2453:17:38, 23 November 2009 (UTC) 2423:15:27, 24 November 2009 (UTC) 2408:13:21, 24 November 2009 (UTC) 2393:09:02, 24 November 2009 (UTC) 2374:18:48, 23 November 2009 (UTC) 2348:17:36, 23 November 2009 (UTC) 2332:15:58, 23 November 2009 (UTC) 2135:06:51, 25 November 2009 (UTC) 2120:12:54, 24 November 2009 (UTC) 2093:16:20, 23 November 2009 (UTC) 2075:13:25, 23 November 2009 (UTC) 2053:Can we just simplify all this 2045:14:19, 22 November 2009 (UTC) 2018:04:30, 22 November 2009 (UTC) 1973:15:04, 23 November 2009 (UTC) 1948:07:57, 29 November 2009 (UTC) 1910:01:35, 28 November 2009 (UTC) 1874:06:41, 25 November 2009 (UTC) 1859:04:17, 25 November 2009 (UTC) 1834:08:16, 23 November 2009 (UTC) 1791:20:36, 22 November 2009 (UTC) 1748:12:20, 23 November 2009 (UTC) 1729:10:35, 23 November 2009 (UTC) 1708:13:26, 22 November 2009 (UTC) 1669:13:08, 22 November 2009 (UTC) 1633:08:44, 22 November 2009 (UTC) 1615:07:59, 22 November 2009 (UTC) 1600:07:59, 22 November 2009 (UTC) 1584:04:24, 22 November 2009 (UTC) 1533:13:15, 20 November 2009 (UTC) 1518:01:38, 20 November 2009 (UTC) 1499:01:17, 20 November 2009 (UTC) 1483:23:34, 19 November 2009 (UTC) 1439:15:31, 19 November 2009 (UTC) 1405:18:46, 19 November 2009 (UTC) 1390:17:40, 19 November 2009 (UTC) 1343:15:22, 19 November 2009 (UTC) 1300:19:26, 19 November 2009 (UTC) 1281:17:01, 19 November 2009 (UTC) 1265:16:02, 19 November 2009 (UTC) 1239:15:22, 19 November 2009 (UTC) 1207:18:40, 21 November 2009 (UTC) 1188:18:40, 21 November 2009 (UTC) 1174:17:32, 23 November 2009 (UTC) 1155:14:58, 21 November 2009 (UTC) 1112:18:36, 20 November 2009 (UTC) 1085:07:58, 20 November 2009 (UTC) 1062:20:52, 19 November 2009 (UTC) 1043:19:34, 19 November 2009 (UTC) 1016:18:11, 19 November 2009 (UTC) 997:15:48, 19 November 2009 (UTC) 980:15:39, 19 November 2009 (UTC) 956:16:59, 19 November 2009 (UTC) 935:15:26, 19 November 2009 (UTC) 922:15:06, 19 November 2009 (UTC) 908:14:57, 19 November 2009 (UTC) 889:15:04, 19 November 2009 (UTC) 871:14:55, 19 November 2009 (UTC) 852:14:35, 19 November 2009 (UTC) 833:14:19, 19 November 2009 (UTC) 808:14:35, 19 November 2009 (UTC) 789:14:25, 19 November 2009 (UTC) 770:14:15, 19 November 2009 (UTC) 751:13:40, 19 November 2009 (UTC) 732:13:19, 19 November 2009 (UTC) 713:12:48, 19 November 2009 (UTC) 695:12:13, 19 November 2009 (UTC) 676:15:02, 19 November 2009 (UTC) 661:14:44, 19 November 2009 (UTC) 644:11:01, 19 November 2009 (UTC) 625:14:53, 19 November 2009 (UTC) 602:09:47, 19 November 2009 (UTC) 574:09:25, 19 November 2009 (UTC) 550:08:26, 19 November 2009 (UTC) 527:23:37, 17 November 2009 (UTC) 485:22:58, 17 November 2009 (UTC) 445:22:32, 17 November 2009 (UTC) 423:12:12, 17 November 2009 (UTC) 404:20:53, 16 November 2009 (UTC) 387:18:58, 16 November 2009 (UTC) 364:22:32, 16 November 2009 (UTC) 345:17:50, 16 November 2009 (UTC) 321:09:53, 16 November 2009 (UTC) 281:09:47, 16 November 2009 (UTC) 248:15:47, 16 November 2009 (UTC) 192:13:12, 16 November 2009 (UTC) 158:09:19, 16 November 2009 (UTC) 124:09:05, 16 November 2009 (UTC) 101:10:02, 16 November 2009 (UTC) 80:06:46, 16 November 2009 (UTC) 61:02:14, 16 November 2009 (UTC) 46:14:59, 15 November 2009 (UTC) 2862:13:08, 6 December 2009 (UTC) 2841:10:11, 6 December 2009 (UTC) 2822:09:56, 6 December 2009 (UTC) 2798:00:00, 2 December 2009 (UTC) 2774:12:26, 2 December 2009 (UTC) 2759:09:12, 1 December 2009 (UTC) 2703:02:55, 5 December 2009 (UTC) 2147:A summary: The big questions 2745:) is definitely possible. 2465:template:infobox politician 2191:RDFa is also not valid HTML 1125:is probably different from 2880: 2565:which overlap counties of 2202:dbPedia parameter mapping 451:Can someone help me please 233:and use the same property 2214:Easier to get out-of-sync 2163:Implementation methods ? 1458:The reason I'm asking... 1452:Am I reading this right? 1073:620 musicians from Canada 2288:Simplest to keep in sync 2241:What is our timetable ? 1145:. What about the rest? 842:stuff than this before. 299:As Sebastian mentioned, 2461:template:infobox person 2285:Biggest pool of editors 1352:total as tar.gz (15198) 944:total as tar.gz (15198) 2684:Please see this page: 2211:Not a "clean" approach 2282:On wiki's themselves 1653:We don't plan, we act 1462:Limited input options 1247:I wrote (and meant) " 2557:, the non-executive 1798:What do you mean by 1444:Flexability question 1349:Preview (first 1000) 941:Preview (first 1000) 2234:Most work/expensive 2174:Semantic MediaWiki 1137:. I agree that the 499:parameters but not 2643:citation templates 2633:Microformats/Coins 1253:Semantic_MediaWiki 1131:populationEstimate 503:parameters. But... 433:the five year plan 2751:SebastianHellmann 2583:Communist Parties 2494: 2451: 2346: 2228:Cleanest solution 2048: 2031:comment added by 1826:SebastianHellmann 1750: 1731: 1710: 1671: 1661:SebastianHellmann 1657:WP:NOTBUREAUCRACY 1635: 1379: 1367:SebastianHellmann 1365:comment added by 1172: 1147:SebastianHellmann 1110: 1077:SebastianHellmann 1060: 1035:SebastianHellmann 1014: 948:SebastianHellmann 920: 887: 850: 768: 711: 674: 642: 617:SebastianHellmann 415:SebastianHellmann 273:SebastianHellmann 240:SebastianHellmann 150:SebastianHellmann 93:SebastianHellmann 72:SebastianHellmann 38:SebastianHellmann 2871: 2742: 2700: 2571:Northern Ireland 2490: 2447: 2342: 2319: 2225:Highly desirable 2047: 2025: 1907: 1897: 1856: 1846: 1788: 1778: 1738: 1717: 1678: 1642: 1623: 1581: 1571: 1378: 1359: 1168: 1123:populationCensus 1106: 1056: 1010: 916: 883: 846: 764: 707: 670: 638: 381: 375: 338: 2879: 2878: 2874: 2873: 2872: 2870: 2869: 2868: 2806: 2782: 2740: 2719:running example 2710: 2696: 2682: 2635: 2546:National League 2542:American League 2441: 2317: 2149: 2055: 2026: 1981: 1901: 1893: 1850: 1842: 1782: 1774: 1687:Also, applying 1575: 1567: 1550: 1446: 1421: 1360: 1127:populationTotal 559:strongly reject 379: 373: 336: 29: 22: 21: 20: 12: 11: 5: 2877: 2875: 2867: 2866: 2865: 2864: 2846: 2845: 2844: 2843: 2825: 2824: 2805: 2802: 2801: 2800: 2781: 2778: 2777: 2776: 2709: 2706: 2681: 2678: 2677: 2676: 2675: 2674: 2634: 2631: 2630: 2629: 2628: 2627: 2626: 2625: 2624: 2623: 2601: 2600: 2599: 2598: 2567:New York State 2555:Greater London 2551:City of London 2534: 2533: 2532: 2531: 2530: 2529: 2528: 2527: 2512: 2501: 2500: 2499: 2498: 2468: 2440: 2437: 2436: 2435: 2434: 2433: 2432: 2431: 2430: 2429: 2428: 2427: 2426: 2425: 2364: 2360: 2351: 2350: 2312: 2311: 2308: 2304: 2297: 2296: 2295: 2294: 2293: 2292: 2289: 2286: 2280: 2279: 2278: 2275: 2269: 2268: 2267: 2264: 2255: 2254: 2253: 2247: 2246: 2245: 2239: 2238: 2237: 2236: 2235: 2232: 2229: 2226: 2220: 2219: 2218: 2215: 2212: 2209: 2206: 2200: 2199: 2198: 2195: 2192: 2189: 2183: 2182: 2181: 2178: 2172: 2171: 2170: 2161: 2160: 2159: 2148: 2145: 2144: 2143: 2142: 2141: 2140: 2139: 2138: 2137: 2107: 2103: 2096: 2095: 2054: 2051: 2050: 2049: 1980: 1977: 1976: 1975: 1959: 1958: 1957: 1956: 1955: 1954: 1953: 1952: 1951: 1950: 1932: 1919: 1918: 1917: 1916: 1915: 1914: 1913: 1912: 1881: 1880: 1879: 1878: 1877: 1876: 1837: 1836: 1762: 1761: 1760: 1759: 1758: 1757: 1756: 1755: 1754: 1753: 1752: 1751: 1733: 1732: 1712: 1711: 1673: 1672: 1637: 1636: 1618: 1617: 1602: 1549: 1546: 1540: 1539: 1538: 1537: 1536: 1535: 1502: 1501: 1468:Limited output 1445: 1442: 1428: 1427: 1420: 1417: 1416: 1415: 1414: 1413: 1412: 1411: 1410: 1409: 1408: 1407: 1332: 1308: 1307: 1306: 1305: 1304: 1303: 1302: 1284: 1283: 1268: 1267: 1242: 1241: 1229:KISS principle 1224: 1223: 1222: 1221: 1220: 1219: 1218: 1217: 1216: 1215: 1214: 1213: 1212: 1211: 1210: 1209: 1193: 1192: 1191: 1190: 1176: 1158: 1157: 1115: 1114: 1088: 1087: 1065: 1064: 1046: 1045: 1019: 1018: 1000: 999: 983: 982: 962: 961: 960: 959: 958: 895: 894: 893: 892: 891: 874: 873: 855: 854: 836: 835: 819: 818: 817: 816: 815: 814: 813: 812: 811: 810: 794: 793: 792: 791: 773: 772: 754: 753: 735: 734: 716: 715: 698: 697: 681: 680: 679: 678: 647: 646: 630: 629: 628: 627: 612: 608: 555: 554: 553: 552: 537: 530: 529: 515: 511: 504: 471: 470: 467: 464: 461: 453: 452: 448: 447: 428: 427: 426: 425: 407: 406: 390: 389: 377:Infobox school 369: 368: 367: 366: 348: 347: 330: 329: 328: 327: 326: 325: 324: 323: 290: 289: 288: 287: 286: 285: 284: 283: 261: 260: 259: 258: 257: 256: 255: 254: 253: 252: 251: 250: 217:Artist has an 203: 202: 201: 200: 199: 198: 197: 196: 195: 194: 167: 166: 165: 164: 163: 162: 161: 160: 131: 130: 129: 128: 127: 126: 107: 106: 105: 104: 85: 84: 83: 82: 64: 63: 49: 48: 28: 27:RFC Discussion 25: 23: 15: 14: 13: 10: 9: 6: 4: 3: 2: 2876: 2863: 2859: 2855: 2850: 2849: 2848: 2847: 2842: 2838: 2834: 2829: 2828: 2827: 2826: 2823: 2819: 2815: 2811: 2810:Strong Oppose 2808: 2807: 2803: 2799: 2795: 2791: 2787: 2784: 2783: 2779: 2775: 2772: 2768: 2763: 2762: 2761: 2760: 2756: 2752: 2748: 2744: 2736: 2732: 2728: 2727:demos updated 2724: 2720: 2716: 2707: 2705: 2704: 2701: 2699: 2693: 2690: 2686: 2679: 2673: 2669: 2665: 2661: 2660: 2659: 2658: 2657: 2656: 2652: 2648: 2644: 2640: 2632: 2622: 2618: 2614: 2609: 2608: 2607: 2606: 2605: 2604: 2603: 2602: 2597: 2593: 2589: 2588:—— Shakescene 2584: 2580: 2576: 2572: 2568: 2564: 2563:New York City 2560: 2559:Five Boroughs 2556: 2552: 2547: 2543: 2538: 2537: 2536: 2535: 2526: 2522: 2518: 2513: 2509: 2508: 2507: 2506: 2505: 2504: 2503: 2502: 2497: 2493: 2489: 2484: 2483: 2482: 2478: 2474: 2469: 2466: 2462: 2457: 2456: 2455: 2454: 2450: 2446: 2438: 2424: 2420: 2416: 2411: 2410: 2409: 2405: 2401: 2396: 2395: 2394: 2390: 2386: 2382: 2377: 2376: 2375: 2372: 2369: 2365: 2361: 2357: 2356: 2355: 2354: 2353: 2352: 2349: 2345: 2341: 2336: 2335: 2334: 2333: 2329: 2325: 2321: 2309: 2305: 2302: 2301: 2300: 2290: 2287: 2284: 2283: 2281: 2276: 2273: 2272: 2270: 2265: 2262: 2261: 2259: 2258: 2256: 2251: 2250: 2248: 2243: 2242: 2240: 2233: 2231:Most flexible 2230: 2227: 2224: 2223: 2221: 2216: 2213: 2210: 2207: 2204: 2203: 2201: 2196: 2193: 2190: 2187: 2186: 2184: 2179: 2176: 2175: 2173: 2168: 2167: 2166:Microformats 2165: 2164: 2162: 2157: 2156: 2154: 2153: 2152: 2146: 2136: 2132: 2128: 2123: 2122: 2121: 2117: 2113: 2108: 2104: 2100: 2099: 2098: 2097: 2094: 2090: 2086: 2081: 2080: 2079: 2078: 2077: 2076: 2072: 2068: 2064: 2060: 2052: 2046: 2042: 2038: 2034: 2030: 2022: 2021: 2020: 2019: 2015: 2011: 2010: 2004: 2000: 1998: 1994: 1989: 1985: 1978: 1974: 1970: 1966: 1961: 1960: 1949: 1945: 1941: 1937: 1933: 1929: 1928: 1927: 1926: 1925: 1924: 1923: 1922: 1921: 1920: 1911: 1908: 1906: 1905: 1898: 1896: 1889: 1888: 1887: 1886: 1885: 1884: 1883: 1882: 1875: 1871: 1867: 1862: 1861: 1860: 1857: 1855: 1854: 1847: 1845: 1839: 1838: 1835: 1831: 1827: 1823: 1819: 1814: 1810: 1805: 1801: 1797: 1796: 1795: 1794: 1793: 1792: 1789: 1787: 1786: 1779: 1777: 1771: 1768: 1749: 1746: 1743: 1737: 1736: 1735: 1734: 1730: 1726: 1722: 1716: 1715: 1714: 1713: 1709: 1706: 1703: 1698: 1694: 1693:WP:EXCEPTIONS 1690: 1686: 1683: 1677: 1676: 1675: 1674: 1670: 1666: 1662: 1658: 1654: 1650: 1646: 1641: 1640: 1639: 1638: 1634: 1631: 1628: 1622: 1621: 1620: 1619: 1616: 1612: 1608: 1603: 1601: 1597: 1593: 1588: 1587: 1586: 1585: 1582: 1580: 1579: 1572: 1570: 1565: 1563: 1561: 1557: 1554: 1547: 1545: 1544: 1534: 1530: 1526: 1521: 1520: 1519: 1515: 1511: 1506: 1505: 1504: 1503: 1500: 1496: 1492: 1487: 1486: 1485: 1484: 1480: 1476: 1471: 1469: 1465: 1463: 1459: 1456: 1453: 1450: 1443: 1441: 1440: 1437: 1434: 1426: 1423: 1422: 1418: 1406: 1402: 1398: 1393: 1392: 1391: 1388: 1385: 1381: 1380: 1376: 1372: 1368: 1364: 1357: 1353: 1350: 1346: 1345: 1344: 1341: 1338: 1333: 1330: 1326: 1321: 1320:intelligently 1317: 1313: 1309: 1301: 1297: 1293: 1288: 1287: 1286: 1285: 1282: 1279: 1276: 1272: 1271: 1270: 1269: 1266: 1262: 1258: 1254: 1250: 1246: 1245: 1244: 1243: 1240: 1237: 1234: 1230: 1226: 1225: 1208: 1204: 1200: 1197:RFC above? -- 1195: 1194: 1189: 1185: 1181: 1177: 1175: 1171: 1167: 1162: 1161: 1160: 1159: 1156: 1152: 1148: 1144: 1140: 1136: 1132: 1128: 1124: 1119: 1118: 1117: 1116: 1113: 1109: 1105: 1101: 1096: 1092: 1091: 1090: 1089: 1086: 1082: 1078: 1074: 1069: 1068: 1067: 1066: 1063: 1059: 1055: 1050: 1049: 1048: 1047: 1044: 1040: 1036: 1032: 1028: 1023: 1022: 1021: 1020: 1017: 1013: 1009: 1004: 1003: 1002: 1001: 998: 994: 990: 985: 984: 981: 978: 975: 971: 967: 963: 957: 953: 949: 945: 942: 938: 937: 936: 933: 930: 925: 924: 923: 919: 915: 911: 910: 909: 905: 901: 896: 890: 886: 882: 878: 877: 876: 875: 872: 868: 864: 859: 858: 857: 856: 853: 849: 845: 840: 839: 838: 837: 834: 830: 826: 821: 820: 809: 805: 801: 796: 795: 790: 786: 782: 777: 776: 775: 774: 771: 767: 763: 758: 757: 756: 755: 752: 748: 744: 739: 738: 737: 736: 733: 729: 725: 720: 719: 718: 717: 714: 710: 706: 702: 701: 700: 699: 696: 692: 688: 683: 682: 677: 673: 669: 664: 663: 662: 658: 654: 649: 648: 645: 641: 637: 632: 631: 626: 622: 618: 613: 609: 605: 604: 603: 599: 595: 591: 587: 583: 578: 577: 576: 575: 572: 569: 565: 560: 551: 547: 543: 538: 534: 533: 532: 531: 528: 524: 520: 516: 512: 509: 505: 502: 498: 493: 489: 488: 487: 486: 483: 480: 476: 468: 465: 462: 458: 457: 456: 450: 449: 446: 442: 438: 434: 430: 429: 424: 420: 416: 411: 410: 409: 408: 405: 401: 397: 392: 391: 388: 385: 378: 371: 370: 365: 361: 357: 352: 351: 350: 349: 346: 343: 340: 339: 332: 331: 322: 318: 314: 310: 306: 302: 298: 297: 296: 295: 294: 293: 292: 291: 282: 278: 274: 269: 268: 267: 266: 265: 264: 263: 262: 249: 245: 241: 236: 232: 228: 224: 220: 215: 214: 213: 212: 211: 210: 209: 208: 207: 206: 205: 204: 193: 189: 185: 184:Chris Johnson 181: 177: 176: 175: 174: 173: 172: 171: 170: 169: 168: 159: 155: 151: 147: 143: 139: 138: 137: 136: 135: 134: 133: 132: 125: 122: 118: 113: 112: 111: 110: 109: 108: 102: 98: 94: 89: 88: 87: 86: 81: 77: 73: 68: 67: 66: 65: 62: 59: 55: 51: 50: 47: 43: 39: 35: 31: 30: 26: 19: 2809: 2785: 2747:Jens Lehmann 2730: 2711: 2697: 2683: 2664:Jens Lehmann 2636: 2613:Jens Lehmann 2517:Jens Lehmann 2442: 2415:Jens Lehmann 2385:Jens Lehmann 2313: 2298: 2150: 2127:Jens Lehmann 2085:Jens Lehmann 2062: 2058: 2056: 2027:— Preceding 2007: 2005: 2001: 1996: 1992: 1990: 1986: 1982: 1940:Jens Lehmann 1903: 1902: 1894: 1866:Jens Lehmann 1852: 1851: 1843: 1818:Greasemonkey 1813:Semantic Web 1803: 1799: 1784: 1783: 1775: 1766: 1763: 1721:Jens Lehmann 1652: 1607:Jens Lehmann 1592:Jens Lehmann 1577: 1576: 1568: 1558: 1555: 1551: 1542: 1541: 1472: 1467: 1466: 1461: 1460: 1457: 1454: 1451: 1447: 1429: 1361:— Preceding 1328: 1324: 1319: 1315: 1292:Jens Lehmann 1257:Jens Lehmann 1199:Jens Lehmann 1180:Jens Lehmann 1142: 1138: 1130: 1126: 1122: 1099: 1030: 1026: 989:Jens Lehmann 969: 965: 825:Jens Lehmann 800:Jens Lehmann 781:Jens Lehmann 589: 585: 581: 558: 556: 542:Jens Lehmann 507: 500: 496: 491: 474: 472: 454: 356:Jens Lehmann 337:Juliancolton 334: 313:Jens Lehmann 234: 230: 226: 222: 218: 2260:On dbPedia 2252:Definitely. 1822:Madonna@BBC 1141:fields are 2708:Conclusion 2381:birthPlace 2106:necessary. 2067:ClemRutter 1329:playername 1027:birthplace 900:Soeren1611 653:Soeren1611 594:ClemRutter 235:occupation 231:occupation 219:occupation 2689:Super Sam 2473:Kolindigo 1804:Template: 1249:MediaWiki 564:WP:ENGVAR 384:Unionhawk 2328:contribs 2271:On Meta 2041:contribs 2029:unsigned 1375:contribs 1363:unsigned 1031:Musician 501:changing 229:is like 2786:Support 2780:Support 2698:Homfrog 2641:in the 1895:stmrlbs 1844:stmrlbs 1776:stmrlbs 1682:WP:BOLD 1645:WP:BOLD 1569:stmrlbs 437:Protonk 2804:Oppose 2735:Hiding 2488:Hiding 2445:Hiding 2340:Hiding 1997:second 1993:first' 1697:WP:ANI 1689:WP:IAR 1649:WP:IAR 1475:J Greb 1166:Hiding 1104:Hiding 1054:Hiding 1008:Hiding 914:Hiding 881:Hiding 844:Hiding 762:Hiding 705:Hiding 668:Hiding 636:Hiding 519:J Greb 497:adding 475:really 227:office 223:office 2647:Salix 2639:COinS 2371:Adler 2185:RDFa 2014:talk 1800:guard 1745:Adler 1705:Adler 1630:Adler 1491:Svick 1436:Adler 1387:Adler 1340:Adler 1316:could 1278:Adler 1236:Adler 1095:stubs 977:Adler 968:, we 932:Adler 571:Adler 482:Adler 460:ways. 16:< 2858:talk 2854:Dmcq 2837:talk 2833:Halo 2818:talk 2814:Halo 2794:talk 2790:Dmcq 2771:talk 2755:talk 2668:talk 2651:talk 2617:talk 2592:talk 2553:and 2544:and 2521:talk 2477:talk 2419:talk 2404:talk 2400:Dmcq 2389:talk 2368:Hans 2324:talk 2131:talk 2116:talk 2112:Dmcq 2089:talk 2071:talk 2037:talk 2033:Dmcq 1969:talk 1965:Dmcq 1944:talk 1936:here 1904:talk 1870:talk 1853:talk 1830:talk 1785:talk 1742:Hans 1725:talk 1702:Hans 1665:talk 1647:and 1627:Hans 1611:talk 1596:talk 1578:talk 1529:talk 1525:Dmcq 1514:talk 1510:Dmcq 1495:talk 1479:talk 1433:Hans 1401:talk 1397:Dmcq 1384:Hans 1371:talk 1356:here 1337:Hans 1325:name 1312:this 1296:talk 1275:Hans 1261:talk 1255:) -- 1233:Hans 1203:talk 1184:talk 1151:talk 1143:easy 1139:easy 1100:easy 1081:talk 1039:talk 1033:. 993:talk 974:Hans 966:plan 952:talk 929:Hans 904:talk 867:talk 863:Dmcq 829:talk 804:talk 785:talk 747:talk 743:Dmcq 728:talk 724:Dmcq 691:talk 687:Dmcq 657:talk 621:talk 598:talk 568:Hans 546:talk 523:talk 508:part 492:some 479:Hans 441:talk 419:talk 400:talk 396:Dmcq 360:talk 317:talk 303:and 277:talk 244:talk 188:talk 182:? -- 180:RDFa 154:talk 144:and 121:talk 97:talk 76:talk 58:talk 42:talk 34:here 2731:not 2715:RFC 2653:): 2579:CSU 2575:CDU 2561:in 2463:to 2009:DGG 1809:OWL 1327:as 1129:or 970:act 305:OWL 301:RDF 146:OWL 142:RDF 2860:) 2839:) 2820:) 2796:) 2769:- 2757:) 2749:, 2743:DJ 2739:Th 2725:, 2721:, 2670:) 2619:) 2594:) 2523:) 2479:) 2421:) 2406:) 2391:) 2330:) 2326:• 2320:DJ 2316:Th 2133:) 2118:) 2091:) 2073:) 2043:) 2039:• 2016:) 1971:) 1946:) 1872:) 1832:) 1727:) 1667:) 1613:) 1598:) 1531:) 1516:) 1497:) 1481:) 1473:- 1403:) 1377:) 1373:• 1298:) 1263:) 1205:) 1186:) 1153:) 1083:) 1041:) 995:) 954:) 906:) 869:) 831:) 806:) 787:) 749:) 730:) 693:) 659:) 623:) 600:) 548:) 540:-- 525:) 517:- 473:I 443:) 435:. 421:) 402:) 380:}} 374:{{ 362:) 341:| 319:) 279:) 246:) 190:) 156:) 119:- 99:) 78:) 56:- 44:) 36:. 2856:( 2835:( 2831:- 2816:( 2792:( 2753:( 2741:e 2666:( 2649:( 2615:( 2590:( 2577:- 2519:( 2492:T 2475:( 2449:T 2417:( 2402:( 2387:( 2344:T 2322:( 2318:e 2129:( 2114:( 2087:( 2069:( 2035:( 2012:( 1967:( 1942:( 1899:| 1868:( 1848:| 1828:( 1780:| 1723:( 1663:( 1609:( 1594:( 1573:| 1527:( 1512:( 1493:( 1477:( 1399:( 1369:( 1294:( 1259:( 1201:( 1182:( 1170:T 1149:( 1108:T 1079:( 1058:T 1037:( 1012:T 991:( 950:( 918:T 902:( 885:T 865:( 848:T 827:( 802:( 783:( 766:T 745:( 726:( 709:T 689:( 672:T 655:( 640:T 619:( 596:( 544:( 521:( 439:( 417:( 398:( 358:( 315:( 275:( 242:( 186:( 152:( 103:) 95:( 74:( 40:(

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.

Knowledge

talk:Requests for comment/infobox template coherence - Knowledge

Index