On 02/02/2012 07:52 PM, Trevor Parscal wrote: Normally we would wrap the text into a span, and mark this span as being a wrapper in an attribute. The span would then hold all metadata. The extra wrapper might break some CSS selectors unfortunately, but that is a problem with any wrapper and hard to avoid (without those handy range annotations..). In the parser, wrapping into a span by inserting tokens should be safe in any case (ignoring the potential CSS issues), but there might be a case for propagating that information to a surrounding paragraph if the span is later wrapped into a paragraph at the DOM level. Also, any trailing text tokens in a template expansion will need to be wrapped as well to mark the end of the expansion. At the token level, all non-text tokens from an expansion are marked as coming from a template, so that the full expansion can be identified in the resulting DOM. This catches any text in between, but not normally plain text before or after the last non-text token. Hence the need for wrapping this too. Gabriel

On 02/02/2012 08:36 PM, Daniel Friesen wrote: Hmm- from the data modeling aspect, the template really determines the vocabulary used in the content. It would be hard to specify a common schema for http://www.mediawiki.org/microdata/wikitext/Transclusion, unless the vocabulary is reduced to a purely syntactical level. Gabriel

Template arguments, and especially the named variant, tend to have some loosely defined semantics apart from their syntactic identifier. These semantics are often explained in the template's documentation section, and can be mapped to a more formal ontology as in dbpedia [1]. A general schema for all templates could only reference things like the argument position or the argument name in an abstract way, but could not generally provide semantics for them. Note that this is different for things like images, where we can either define our own global schema, or directly reuse one from schema.org (e.g. http://schema.org/MediaObject), possibly with an additional extension for disambiguation purposes (/MW) as described in http://schema.org/docs/extension.html. Microdata items can be nested, so I don't see a problem with users or templates providing a mapping to more specific schemas like those of schema.org. Clashes of user-provided itemtypes with those used for editing purposes need to be prevented in the parser, but that is doable. Consumers are free to ignore itemtypes they don't know about, which is what Google etc are doing afaik- and what also motivated them to set up schema.org in the first place. There might be ways to use schema information from the template documentation to add an additional, more general itemtype to the rendered template, but that is both still under development at WhatWG and not our highest priority right now. Gabriel [1]: http://mappings.dbpedia.org/index.php/How_to_edit_the_DBpedia_Ontology

On 02/13/2012 03:27 AM, Daniel Friesen wrote: I considered the case where users manually add a microdata item in a template or page. The itemtype in that case can be anything, but would most likely be a standard type. Could you elaborate why you consider one use of itemtype an abuse, while the other would be fine? We are trying to address all three with the same mechanism. In particular, we are trying to aid the discover of semantics associated with (many) template parameters for the benefit of search engines or projects like DBPedia and WikiData. Gabriel

On Mon, 13 Feb 2012 00:13:21 -0800, Gabriel Wicke &lt;wicke(a)wikidev.net&gt; wrote: An itemtype is supposed to be a proper type of what the data is. Something expected, well-known, predefined. If possible there is should be only one for some type of thing. And one should be able to query for it already knowing what that type is, like one would with an xmlns. itemtype="http://en.wikipedia.org/wiki/Template:Cite" is not something pre-defined. It practically appears dynamically out of no-where with no forethought. And if someone copies the template then that exact same set of data has a completely different itemtype despite being the same thing. Another point in this example. Template:Cite is actually a good example here. In a normal itemtype you generally stick to one name for something. You have a citation type, and you have a "firstname" prop. And you can have multiples of them. ie: <span itemprop="firstname">Arnold</span> <span itemprop="firstname">Harold</span> (though in a real good type you'd likely have a separate itemtype to group all the info of a name into one itemprop="name" itemscope ...). However in a template we get this: |first=Arnold |first2=Harold Resulting in what you'd say would be: <span itemprop="first">Arnold</span> <span itemprop="first2">Harold</span> That's nothing close to a properly defined itemtype that actually allows 3rd parties to extract data in any sane way. Nor is it something a Visual Editor would make use of without a wildcard hack where it examines every itemtype and decides that any url pointing back to the wiki is something it can edit. Anything that actually manages to extract data from that kind of thing is a hack at it's very core. While when we use `itemtype="http://www.mediawiki.org/microdata/wikitext/Transclusion"` and `itemprop="Argument" itemscope itemtype="http://www.mediawiki.org/microdata/wikitext/Argument"` we have a predefined type. We're formally describing a transclusion of a template into another page, and the arguments used. The format of this is defined beforehand. We can add in extra data that would have been a hack before. Like the canonical pagename of the template. Perhaps even some metadata that is stored inside the template itself. For example say SemanticForms implemented some embedded editor form code. A template could add extra metadata saying that the template's content should be edited using a defined Semantic Forms. The Visual Editor would then use that information to embed a small area that allows Semantic Forms to be used to edit the template inline. Allowing editing of things that could potentially be to complex for the Visual Editor to understand how to make editable. Though that's really just an example off the top of my head, there are probably other things that could use metadata from the template to improve the Visual Editor's ability to make templates editable as intuitively as possible. For those projects like DBPedia which already hack around trying to extract data from the parameters passed to a template using tricks to associate some sort of meaning to template parameters without getting that information from the wiki itself using a itemtype="http://www.mediawiki.org/microdata/wikitext/Transclusion&quo… is basically a formal way to extract the parameters of a template without having to do the unreliable work of attempting to parse the WikiText themselves. So it's still a usable improvement. For search engines and other 3rd parties, I don't believe any of them are going to want to go around to every wiki and start hardcoding into their code things like itemtype="http://mywiki.com/wiki/Template:Event" and itemtype="http://yourwiki.com/wiki/Template:OurEvent" both describing an event they would extract. I don't think we're going to get good metadata for general 3rd parties without actually embedding proper formal microdata into templates themselves. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On Tue, 14 Feb 2012 03:21:56 -0800, Gabriel Wicke &lt;wicke(a)wikidev.net&gt; wrote: I don't think we can include this stuff in general page data anyways. Adding any level of additional implicit markup to something as absolutely basic as {{{1|}}} could completely destroy things. The css targeting changes, js targeting changes, and if the template author happens to have gone to the effort of nicely adding Microdata of their own, we destroy it. # Template:Movie <div itemscope itemtype="http://schema.org/Movie"> '''Title:''' <span itemprop="name">{{{title}}}</span> </div> # Page content {{Movie|title=Avatar}} # Result <div itemscope itemtype="http://en.wikipedia.org/wiki/Template:Movie"> <div itemscope itemtype="http://schema.org/Movie"> '''Title:''' <span itemprop="name"><span itemprop="title">Avatar</span></span> </div> </div> The result is absolute nonsense. The and the only real action that can be taken to retain the ability for the Visual Editor to keep the template's editability is to hide the schema.org metadata in another layer of metadata describing it resulting in the metadata the author wrote becoming useless. Hence given that 3rd parties that are aware of templates and explicitly want to extract data from their parameters can use an alternate method of querying for the mixed dom, the fact that generic 3rd parties are unlikely to want to hardcode anything to do with the unstable and nonsensical meanings of transclusion parameters, and the fact that we can easily destroy good valid metadata and user styles I don't think including this extra dom in general page views is a good idea anyways. They have to do the hardcoding either way. I'm saying that generic 3rd parties aren't going to do any hardcoding of domain-specific-schemas at all whatever the syntax we use, and hence generic 3rd parties are a complete moot point for discussing whether we use template-url as itemtype or a formally defined itemtype. And the goal of metadata formats like Microdata is not simple extraction, it's having formally defined metadata which can be extracted reliably with an intuitive and consistent format. That's not what itemprop="last2" is. If we just wanted simply extracted data, we wouldn't be using Microdata at all, we'd just shove everything into something simple like: <div data-wt-transclusion="/wiki/Template:Movie"> '''Title:''' <span data-wt-param="title">Avatar</span> </div> Those are completely different levels of wildcarding. With schema.org they're simply saying that every http://schema.org/Person/Subtype matched by http://schema.org/Person/* is treated as a http://schema.org/Person type. And itemprop="email/work" is treated as itemprop="email" is. There's still a perfectly good formal schema there. What we're saying with itemtype="{templateurl}" is that every itemtype="http://en.wikipedia.org/wiki/*" is a itemtype="" of, well we don't even have a formal definition of what it is. We're just saying that if it matches that wildcard it's a template transclusion. And there's nothing to define what that is. We're also saying that every itemprop="*" inside of it is a template parameter. Absolutely no formal definition saying what kind of data goes there, how it should be treated etc. And we're also saying that you'll get things like itemprop="first" itemprop="last" itemprop="first2" itemprop="last2". And you're supposed to take "first" and "last" and combine them conceptually as one "name", and likewise you also have to explicitly take "first2" and "last2" and combine these conceptually, but they aren't of type "name2", they are also of type "name". This is not Microdata, this is a mess. The only relation it has to Microdata is the fact that Microdata's syntax is being abused as a container for it. It's like encoding a video with H.264, the audio with AAC, putting it into a Matroska container, changing the file extension to .webm. And then saying it's .webm because the file extension says .webm and the container format looks like .webm's container format. Changing: Foo To: <span itemprop="foo">Foo</span> Is already an absolutely destroying change for anything that it would effect. Using: <span itemprop="Argument" itemtype="http://www.mediawiki.org/microdata/wikitext/Argument" itemscope> <meta itemprop="name" content="foo"> <span itemprop="value">Foo</span> </span> Will not destroy things in a way any worse than the other change will. And it's the only way you'll be able to convey something like: <div itemtype="http://www.mediawiki.org/microdata/wikitext/Transclusion&quo… itemscope> <meta itemprop="PageName" content="Template:Foo"> <meta itemprop="RawText" content="Foo#This is some discarded data"> <b>Bar:</b> <span itemprop="argument" itemtype="http://www.mediawiki.org/microdata/wikitext/Argument" itemscope><!-- --><meta itemprop="name" content="bar"><!-- --><meta itemprop="default" content="Baz"><!-- --><span itemprop="value">Foo</span><!-- --></span> </div> Which will allow the Visual Editor to restore the original WikiText and also have intuitive ques in the editor that will make it visually restore the default of "Baz" to the param text "Foo" when the user does something to indicate to the Visual Editor that it the user would probably want the Visual Editor to drop the param and show the default if they had actually known about things at the source level. And like I said before there are probably more things that would require extra metadata beyond what itemtype and itemprop hacks can provide which I can't even think up right now. One thing I still don't get. In WikiText a <h2>Foo</h2> (normal extra markup omitted) can be expressed by both == Foo == and ==Foo==. I thought one of the key goals of the Visual Editor was that the Visual Editor would not get in the way of source level editors by mucking up content changing a ==Foo== to a == Foo == or a == Foo == to a ==Foo== when the Visual Editor user hasn't even touched that section, like just about every previous WYSIWYG editor has done. How is the Visual Editor supposed to do that when the dom we're talking about is lossy and doesn't contain any extra metadata giving that information. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

Gabriel Wicke wrote: I was noting that the editing would be changing both lines. Yes, but a could be present in an editable form and an uneditable one. If the parser can't show the change in the uneditable one, it shouldn't allow its edition.