Adopt precedence rules in baptism and interpretation

[ppKrauss]

(this is an extension of hierarchical principle #852)

To avoid conflics and long discussions during cration of new "terms": Frictionlessdata datatype names or, in a specific dataset, column names, and the best choice for URL of rdfType.

Illustrating motivations:

• during tests of implementation at frictionlessdata/goodtables.io I perceived the problem with "gyear vs year"... In fact, there are a lot of discussions about. How to "reduce frictionless"?

• during construction of datasets at Brazilian datasets (example) I need clues to column name definitions, some "best practices guide for column names"... But looking at Core Datasets I see "the caos", no clues.

• The rdfType will be welcomed in all projects, but the URL choice can't be random... We need some "best practices guide for URL choice in rdfType descriptors".

Suggesting simple rules

1. All derivative inherits from its partents assumptions and interpretations.
   Example-1 (structural derivative): in the case of year, it is a derivative of date that already have a datatype, datetime, an ISO format year-mm-dd. So, by ISO8601 interpretation, year is a "gregorian year", and it is a syntatic component of datetime (we can suppose precedence from the components with relation from another external standards). Same with yearmonth, is a YYYY-MM syntatic component. As "gregorian" is inherited, we not need repeat as "g"; so "year" is prefered from "gyear"; etc.
   Example-2 (semantic derivative): person's full-name is a property of person, so if the "adopted standard" was SchemaOrg's class Person, the SchemaOrg's recommendation is name (not ex. "fullName"). For split name into parts, there are also reference standards, as familyName, givenName, etc. Syntax and interpretation can be inherit.

2. Adopt precedence order and "reference vocabularies" for rdfType and semantics.
   Example: adopt SchemaOrg class-property when it exist, else (when exist stable one) Wikidata, else... LOV sequence.

[pwalsh]

Hi @ppKrauss I'm not ignoring this, but I'm focused on finalising v1 before I address potential changes for subsequent versions. Thanks for your patience.