What to fill in the Microdata property field?

[Alfa1]

Its clear to me that this field is to define the microdata from schema.org
I know which microdata schema I want to use, but it's unclear to me what I need to fill in exactly. The text can use some clarification.
For example if I want to use:
https://schema.org/Taxon
Do I fill in:
Taxon

or
Thing>Taxon

Or something else?

[pegasus]

If you want to use Taxon, what property of Taxon does your custom field satisfy?
By choosing Taxon, when a page has a value for your custom field, the page will have an additionalType of Taxon added to its Article type.

Taxon has a field called hasDefinedTerm that takes a DefinedTerm type as its value. Your custom field could say:
hasDefinedTerm:DefinedTerm > termCode

This means that when your custom field has a value set, the article becomes a Taxon, and the custom field value is used as the termCode of its hasDefinedTerm property.

[Alfa1]

To elaborate: If we have a page about a Person and a field for Birthdate, then these would be suitable Schema's:
https://schema.org/Person
https://schema.org/birthDate

So should the field state:
birthDate:Date > Person
Or
birthDate:Date > termcode

[pegasus]

When looking into this more deeply, I see I may have oversimplified things. Since you need to first define that the wiki page is a Person, you will need 2 custom fields. 1 that says the page is a Person, and then another to set Person's birthDate.

Create the Person custom field, assuming the area will only contain "Person" pages:

1. Set "Field type" to "Schema.org microdata container". Under "Available microdata choices", select "Person".

If the area will contain other microdata types, you can multi-select from that box to give your users a choice.

Create the birthDate custom field.

1. Set "Field type" to "Date".
2. In the "General Options", set "Microdata property" to:
   

   birthDate

Since the microdata property is directly filled by the custom field, and the property does not have a sub-property tree, you should not have to include its Date type in this field. You would only have to do something like that, for example, if you were using the field to set the Person's spouse's birthDate:

spouse:Person > birthDate

In the case where the area allows multiple microdata types (not just Person), the birthDate field should automatically only be applied if the type is Person. VaultWiki maintains a copy of schema.org types to validate against, and tries to only generate the microdata output when the chain validates.

[Alfa1]

Its becoming a little clearer.
So if I will add a custom field with Person microdata to the area.

Then we have various custom fields for this area:
* BirthDate https://schema.org/birthDate
* deathDate https://schema.org/deathDate
* Affiliation https://schema.org/affiliation
* knowsAbout https://schema.org/knowsAbout

Could you please explain these?

[pegasus]

Okay, so for birthDate / deathDate, you can directly set this with a "Microdata property" value of "birthDate" or "deathDate" on a custom field that accepts dates.

However, schema.org defines that affiliation has a type of Organization, so you can't set it with a scalar value that the user can pick. Instead, you have to drill down to one of its other values, like "name" which is a generic property. So to set the name of the affiliation, your "Microdata property" value would be:

affiliation:Organization > name

This tells VaultWiki that we need to use the custom field to fill "name". And to put name underneath the "affiliation" property of the page, if it exists (if the page is a "Person", then it will). When validating / generating, we need to include that "affiliation" is supposed to be an "Organization", because it's not a scalar schema.org type.

For "knowsAbout", this is a little tricky because it accepts various values. Basically, for the purposes of your custom field, you need to choose. If you're going to use the Text or URL schema, then it's pretty straightforward:

knowsAbout

But you may want to use "knowsAbout" to point to another "Thing". Again, since Thing is a type, you need to specify a sub-property. For simple discussion, we'll choose the generic "name" again, (although in the real world that would be redundant and unnecessarily complicated since "knowsAbout" already takes Text as a value)

knowsAbout:Thing > name

For more complex use... since "knowsAbout" can take a Thing, it can really be used for anything, like:

knowsAbout:Movie > actor:Person > name

In this case, you would be saying the Person the wiki page is about, "knowsAbout" a Movie. In that movie, there is an "actor" (who is a Person) and their "name" is the value of the custom field.

You can do a lot with this, but it can get a little overwhelming for your wiki editors if you put too many fields, so try to keep it to the ones you actually need.