Data 3.0 (a Manifesto for Platform Agnostic Structured Data) Update 5

After a long period of trying to demystify and unravel the wonders of standards compliant structured data access, combined with protocols (e.g., HTTP) that separate:

1. Identity,
2. Access,
3. Storage,
4. Representation, and
5. Presentation.

I ended up with what I can best describe as the Data 3.0 Manifesto. A manifesto for standards complaint access to structured data object (or entity) descriptors.

Some Related Work

Alex James (Program Manager Entity Frameworks at Microsoft), put together something quite similar to this via his Base4 blog (around the Web 2.0 bootstrap time), sadly -- quoting Alex -- that post has gone where discontinued blogs and their host platforms go (deep deep irony here).

It's also important to note that this manifesto is also a variant of the TimBL's Linked Data Design Issues meme re. Linked Data, but totally decoupled from RDF (data representation formats aspect) and SPARQL which -- in my world view -- remain implementation details.

Data 3.0 manifesto

• An "Entity" is the "Referent" of an "Identifier."
• An "Identifier" SHOULD provide a global, unambiguous, and unchanging (though it MAY be opaque!) "Name" for its "Referent".
• A "Referent" MAY have many "Identifiers" (Names), but each "Identifier" MUST have only one "Referent".
• Structured Entity Descriptions SHOULD be based on the Entity-Attribute-Value (EAV) Data Model, and SHOULD therefore take the form of one or more 3-tuples (triples), each comprised of:

  • an "Identifier" that names an "Entity" (i.e., Entity Name),
  • an "Identifier" that names an "Attribute" (i.e., Attribute Name), and
  • an "Attribute Value", which may be an "Identifier" or a "Literal".

• Structured Descriptions SHOULD be CARRIED by "Descriptor Documents" (i.e., purpose specific documents where Entity Identifiers, Attribute Identifiers, and Attribute Values are clearly discernible by the document's intended consumers, e.g., humans or machines).
• Structured Descriptor Documents can contain (carry) several Structured Entity Descriptions
• Stuctured Descriptor Documents SHOULD be network accessible via network addresses (e.g., HTTP URLs when dealing with HTTP-based Networks).
• An Identifier SHOULD resolve (de-reference) to a Structured Representation of the Referent's Structured Description.

Related

• Referent, Identifier, and Descriptor/Sense (The Data Perception Trinity) illustration

• Referent, Identifier, and Descriptor/Sense Trinity (as exploited in FOAF+SSL based Secure WebIDs) illustration

• Demystifying Linked Data via EAV Model based Structured Descriptions

• What do people have against URIs and URLs?

• The URI, URL, and Linked Data Meme's Generic HTTP URI

• Simple Explanation of RDF and Linked Data Dynamics

• Linked Data and Identity

• FOAF+SSL FAQ

• LOD Community Thread (showing evolution of this manifesto based on feedback from members such as Richard Cyganiak).

• 
  Googlebase Data API Docs
  
• 
  Google Data Protocol (GData)
• 
  Microsoft's OData Protocol
  

• Magic of De-referencable Names and actual Data via Binky Video



• 
  Social Objects Presentation (aka. Social Linked Data Objects) - by Jyri Engeström
  
• 
  What's a Reference?
  

webservicesweb2.0web20gdatardflinked_datasemanticwebfoafsparqlsocialnetworkingDataSpace