Metaformat

+2  

The basic idea is that we can create a header ("metaheader") to bind format and schema specifications to data, and a single polycontext metasymbol (a map that specifies in which context what metasymbol is to be used) to bind it to data, and link them with global namespaces of ontologies, schemas, and user identities. For example, the polycontext metasymbol may be defined by providing a map:

Where, C₁...C_N are format or language contexts, and S₁...S_N are metasymbols, and N ∈ ℕ.

For example if we want to introduce a metasymbol in multiple languages and formats, which may be in conflict with the already-defined symbols and reserved words within the languages and formats, we can introduce a polycontext metasymbol with domain in those languages and formats, for example, XML, RDF, JSON, YAML, Python, JavaScript, Scheme , and codomain with our chosen values for S, for example __, _, *, *, #*, {/*S*/}, #|*|#, etc., and then use it for arbitrary semantic or syntactic purposes.

Universal Finger ☝️

Think of polycontext metasymbol as a universal pointer, that can point to anything, and acquires context-neutral form to go to point and ask questions about the things that monocontext metasymbols cannot. You may also think of polycontext metasymbol as an operator with domain spanning across the data specified in different languages, and thus enables us to talk about or operate on them all at once.

Metaformat

A metaformat, is a set of rules that specify, how the parsing (interpretation) rules are to be embedded within different contexts (data chunks). This is done via the polycontext metasymbol and a few standards, like URLs for referencing, and the serialization languages for schema specification within that URL. Many specific metaformats can be defined, by choosing different polycontext metasymbols, URL formats, and schema specification styles. The below example relies on what I call MFT-1 specification.

Usage Example

Suppose that we use polycontext metasymbol * in all contexts, except those where it is a reserved word, and use key-value pairs to provide formats via URLs as their values, with the format (schema) data in machine-human readable key-value specifications. Then here is how it may look as follows.

In JSON As * key, with value pointing to URL of specifications.

{"*": "https://github.com/infamily/_/wiki/example#test1", "field1": "Haiz", "field2": { "properties": { "field3": 12}}}

In XML As <?_ *=""> attribute at any level, with value pointing to URL of specification.

```

Haiz 12 ```

Specifying the value for the symbol, allows to link schema and data formats directly to the data instances, and have data self-normalizable, and ontologically automatically combine-able, and understand the above record as:

Simpler than JSON-LD

The LinkedData format, such as JSON-LD, we may have:

{ "@context": "https://json-ld.org/contexts/person.jsonld", "@id": "http://dbpedia.org/resource/John_Lennon", "name": "John Lennon", "born": "1940-10-09", "spouse": "http://dbpedia.org/resource/Cynthia_Lennon" }

We can write the same thing using the above metaformat, as:

{ '*': 'https://github.com/mindey/terms/wiki/person#foaf', 'url': 'http://dbpedia.org/resource/John_Lennon', 'fullname': 'John Lennon', 'birthdate': '1940-10-09', 'spouse': 'http://dbpedia.org/resource/Cynthia_Lennon' }

This way, we do not require the standardization of @id field, because the mapping of the field specifying it can be described in the format specification itself, provided via the polycontext metasymbol. This adds additional degree of freedom for data authors, and less burden for data analysts.

Hypothesis -- the reason of small adoption of semantic web technologies is because of the overcomplexification of metastandards. This simplifies it, deconstrains, and reduces burden to stick with any particular vocabulary.