Issue: WikiData functionality like wikimedia/wikipedia

I think I finally understand this functionality.

Basically, articles would have a type of meta-data structure, which could be admin-defined (and we could add permissions for non-admins to add/remove fields). Some might come pre-installed (like person, book, country, etc). Meta-data fields would be stored separately from the page-text, but would also generate a new revision. Then the meta-data could be used to quickly fill cross-referenced fields in other pages. For example, if you mention VaultWiki in another article that isn't the "VaultWiki" article, and you want to mention its release date, you could make a call to the "release-date" meta-data field. This way, if the release date is ever updated on the original article, it would get updated everywhere. An added benefit is making the editor's job easier if they simply don't know the value. Of course this is a simple example...

Ideally the meta-data would also be searchable. XenForo's search system is already designed to allow this.

Perhaps having meta-data auto-generate articles would be an ideal manifestation of the "Default template" request: https://www.vaultwiki.org/issues/1291/
The meta-data structure could have a defined template itself. But I should be clear that meta-data could employ a template, but should not be itself handled by a template (i.e. template parameters). Using the template system to handle meta-data would not be an adequate solution, since it is not possible to pull template parameter values once a page has been compiled, and since values are not stored anywhere particularly usable.

Yes, you've got it!
See www.wikidata.org for more ideas.

The auto generation of article snippets, chapters and infobox is one major benefit.

Another important aspect is that users can go through wiki databases and easily fill in whatever data they have available. For example: if I have a book in my possession which lists all release dates of all volvo cars, then I should be able to quickly go into the database and enter just these data sets.

Another major aspect is that Google in now fetching such metadata from websites and implementing it in their search results on the right as a form of Google-InfoBox. Google can fetch this from websites that us semantic microdata tags. This is definitely something of interest since it adds authority to the website and thus higher Google ranking.

Please move this to VW4.

So after re-reading my "understanding" from 2013 and the confirmation from @Alfa1, it seems that this was completely implemented, as originally outlined, with Custom Fields in 4.1.0 RC 2:
.
(RC 2 added the "field" ability to VAR which allows displaying field values from arbitrary pages).
(admin setting Value Display HTML)
(BB-Code type data fields can invoke templates; fields can be filled by templates, but it's an optional capability -- normally users fill them in)
The other stuff behind the ... is possible too, but would need templating to be auto-.

One thing that was mentioned in a later comment is missing, and that involves using the fields to generate microdata tags. We will have to add a setting to the custom field config allowing you to specify what microdata property it fills, and have a separate field for defining the microdata type of a page overall (what the microdata described). We'll deal with that as an improvement for the next release.

Closing this as implemented in the next release. For now, defining how a microdata property corresponds to a custom field requires that the admin has knowledge of the possible microdata properties and their structure, to enter the relationship manually in a text field in the custom field config.

It is possible to make this easier in the future with some kind of Javascript chooser, but it would take a great deal of work (VaultWiki devs would have to define every possible relationship), and that doesn't seem like the best use of time at the moment. If this is too cumbersome, we may revisit this in the next branch or thereafter.

Now, to get your microdata/custom-field connections to work, the admin must define at least 1 other custom field that has the Microdata field-type. This new field-type allows the admin to set choices for the Microdata-type of each page. The admin can choose a subset of these from a drop-down, and then editors can pick which of that subset is relevant to each wiki page.

Once the current page has a specifically set Microdata-type, the microdata property relationships of other custom fields will be applied, if they are relevant to that Microdata-type. You may set multiple Microdata-types for a page, with multiple custom fields; this results in the 'additionalType' property getting more values. However, properties gained from relationships to custom fields are only possible for 1 Microdata-type at a time.

EDIT: I spent the last two days writing our own compiler/validator for microdata, rather than using the free library we had found. The work wasn't as cumbersome as originally thought, once I found the database files for schema.org. The free library was missing a lot that was needed, such as being able to validate property values, and being able to validate property names without knowing the parent microtype. Our own library will make it much easier to implement a Javascript microdata picker for admins in the near future. For now, though, it is still text-based.