minimal-vocabulary: Difference between revisions
(added a grouping section as a reminder to avoid renaming when reusing) |
(→renaming example org: added Microsoft VCARD_NAME schema as yet another unnecessary renamer from vCard) |
||
| Line 22: | Line 22: | ||
=== renaming example org === | === renaming example org === | ||
[[hCard]] deliberately re-uses the literal <code>org</code> property name from [[vCard]]. | * '''org'''. [[hCard]] deliberately re-uses the literal <code>org</code> property name from [[vCard]]. | ||
On the other hand, the following apparently simple / intended to be helpful renamings have been found: | On the other hand, the following apparently simple / intended to be helpful renamings have been found: | ||
* '''vCard.Company''' ([http://msdn.microsoft.com/en-us/library/ms535130(VS.85).aspx Microsoft VCARD_NAME schema for AutoComplete functionality])- which can be optimistically interpreted as just "Company" | |||
* | * '''company/name''' ([[OpenID]] [http://www.axschema.org/types/ attribute exchange] - might also be a renaming of <code>organization-name</code>, see below - how can we be sure?) | ||
* | * '''organization''' (both [http://www.w3.org/2006/vcard/ An Ontology for vCards] and [http://portablecontacts.net/draft-spec.html#organization_element Portable Contacts]) | ||
* | * '''affiliation''' ([http://google.com/support/webmasters/bin/answer.py?answer=146646 Google contact information properties]) | ||
=== renaming example organization name === | === renaming example organization name === | ||
Revision as of 06:25, 12 June 2009
<entry-title>minimal vocabulary</entry-title> One aspect of the start-simple microformats principle, and one of several naming-principles.
One way of keeping a solution simple is to minimize the vocabulary that the solution uses, and certainly of those, minimize any new vocabulary that are introduced.
benefits
Minimizing the vocabulary used for properties (and values) of a microformat helps make and keep microformats easier to understand.
Minimizing the introduction of new vocabulary is particularly important. Doing so:
- Keeps microformats as a whole easier to understand (the smaller the total vocabulary of all microformats).
- Reduces confusion with the re-use of existing technologies.
preserve literal vocabulary when reusing meaning
When reusing the schema or meaning from an existing format, when possible re-use the respective vocabulary as well.
This is particularly important to illustrate, given how often the opposite has occurred (unnecessary renaming/tweaking/abbreviating of existing terms).
avoid renaming when reusing
The renaming of terms when reusing the semantics of an existing format happens often enough to merit labeling as an anti-pattern to be avoided.
Here are some examples:
renaming example org
On the other hand, the following apparently simple / intended to be helpful renamings have been found:
- vCard.Company (Microsoft VCARD_NAME schema for AutoComplete functionality)- which can be optimistically interpreted as just "Company"
- company/name (OpenID attribute exchange - might also be a renaming of
organization-name, see below - how can we be sure?) - organization (both An Ontology for vCards and Portable Contacts)
- affiliation (Google contact information properties)
renaming example organization name
hCard also deliberately re-uses organization-name from vCard per the semantic-xhtml-design-principles.
The unfortunate "clean-up" efforts:
- "company/name" (OpenID attribute exchange - might also be a renaming of
org, see above - how can we be sure?) - "Orgname" (Representing vCard Objects in RDF/XML)
the Anglo centric renaming anti pattern
All of these renamings/expansions/abbreviations may seem (semi-)obvious to English-centric readers, but cause unnecessary confusion when a non-native-English developer encounters different terms that mean the same thing from vCard to these other technologies.
To a non-native-English developer, "org" and "affiliation" are two different sequences of characters, and look as different as "bet" and "nssvyvngvba" do to a non-native-ROT13 developer.
The unnecessary English renaming of English word properties from earlier standards is an Anglo-centric (specifically English-speaking designer) design mistake that needs to be more thoroughly written up as a design anti-pattern to be avoided.
For now we can refer to this problem as the "Anglo-centric renaming anti-pattern" or just "renaming anti-pattern" for short.
more examples
- See other variants of RFC2426 for more examples of unnecessary property renamings.