Including OpenOffice (Open Document Format), Open Office (User Data), Netscape Address Book, Modzilla Address Book, Thunderbird Address Book, WinMail Address Book, Dublin Core (Elements 1.1, Classes, Terms), XML (W3C), XLINK (W3C).
While there is quite a bit of work to be done before the World Wide Web reaches its full potential there is also quite a bit of work to be undone too. Interoperability issues with hardware and software are normally solved in order of commercial importance. No surprise there. One wonders how we got to the point where critical security issues are a work in progress. A retrofit of the web to protect personal privacy must take into account both existing software and also be able to accommodate software not yet written since there are no “Best Practices” to speak of.
The lists below are not identical. Certain information comes with baggage (provenance), whether that fact is accepted and understood by a programer or not. Likewise, the propagation of information is an existential property of the information.
As a tool for handling large Property Sets in existing applications, one can use the Card Data Base.
A provisional list of names is here. Some of the names pre-date the invention of name spaces. Some name spaces and prefixes had to be “created” for the purpose of standardization. If you follow what was said above, you will realize that nothing at all has been “created”, the name space as well as the name itself is just being assigned an approximate, quite generic provenance.
A suggested method of grouping the names is here. A "round trip" between Applications for meta data often results (Convergence per Newton's Method) in a "dumbing down" in both applications. For example, if one Application has no "Publisher" then a round trip will result in neither having a "Publisher".
The RDF file is here, and has considerably more information. However, note two things: 1) each name has a unique ID, we do not want nor need to make judgments about contextual definitions, and 2) nonetheless we can group any of the ID's by the resource type they are allowed to contain. Processing property values (content) on this basis is fundamentally different from comparing names.
This file is not a schema, although it has a Document Type Definition (DTD), for verification of the formatting style.
<!ELEMENT dc:identifier ( #PCDATA ) >
<!ELEMENT dc:source ( #PCDATA ) >
<!ELEMENT dc:subject ( #PCDATA ) >
<!ATTLIST dc:subject xml:lang CDATA #REQUIRED >
<!ELEMENT dc:description ( #PCDATA ) >
<!ATTLIST dc:description xml:lang CDATA #REQUIRED >
<!ELEMENT rdf:Description ( skos:prefLabel, skos:Concept, dc:identifier, dc:source, dc:subject, dc:description, rdf:type* ) >
<!ATTLIST rdf:Description rdf:nodeID ID #REQUIRED >
<!ELEMENT rdf:RDF ( rdf:Description+ ) >
<!ATTLIST rdf:RDF xmlns CDATA #IMPLIED >
<!ATTLIST rdf:RDF xmlns:rdf CDATA #IMPLIED >
<!ATTLIST rdf:RDF xmlns:pii CDATA #IMPLIED >
<!ATTLIST rdf:RDF xmlns:dc CDATA #IMPLIED >
<!ATTLIST rdf:RDF xmlns:skos CDATA #IMPLIED >
<!ELEMENT rdf:type EMPTY >
<!ATTLIST rdf:type rdf:resource CDATA #REQUIRED >
<!ELEMENT skos:Concept ( #PCDATA ) >
<!ELEMENT skos:prefLabel ( #PCDATA ) >
The “resources” defined in this file are meant to be “consumed” by grouping resources (or resource ID's) which appear to contain similar types of Personally Identifiable Information (PII). The RDF file also contains many 'RUST Core' names corresponding to some Concepts which may exist in other applications.
Before purging Personally Identifiable Information (PII) from web documents, it is useful to observe that transporting information is what documents do! It is totally expected that a document of a particular type would carry PII, and that the normal component elements would carry PII. Nor is it expected that a “Core” of elements would carry all the types of PII (11/17) or that all elements are PII carriers – in fact quite a few are a document's “command and control” signals, for lack of a better term, and have no PII content, like the ODF template. For example the Dublin Core Element <dc:type> does not carry any PII, however the child attribute <xml:lang> is a <pii:mark>. The Dublin Core Terms are not defined with a language attribute, so <dct:type> used instead might stop an affinity scam.
Math boffins will note that this explanation of PII is highly non-linear; one cannot separate information into (PII+Other) by element. They are free to flee.
Note that each of the Dublin Core Elements were defined (XSD Schema) with an "xml:lang" attribute, although in some cases this made no sense. This requirement is not present with Dublin Core Terms (RDF Schema aka RDFS). Nonetheless, this means that any XML implementation which uses DC Elements, must allow the attribute. The "xml:lang" is not itself PII free and for this reason, OpenOffice meta data and pseudo-child User Data are included in this list.
Some names are in the specifications for mark-up themselves, and provide a framework of sorts for all web documents. A cross-reference with the types of PII is provided here.