is, by, on, at, do, cx, id - Generalized relations as prefixes

2017-feb-1 - add: possible "be"

Keywords and tags help to enhance information in an easy way, but may also lead to misinterpretations if the relation between a keyword to a topic is not given. For making relations explicit while keeping things simple, relations must be generalized so that you do not need topic dependent relation descriptors like e.g. "author" vs. "manufacturer" for generally the same relation, here something like "causer". The total number of generalized relations should be as small as possible, achievable by a semantic minimalism that leaves details of a certain topic keyword relation open to further interpretation based on additional information which may be given by other stated or missing relations (combination of relations / relation calculus) or by information beyond keywords that is specifically defined on a certain topic. Next, the names for generalized relations should be very short and should have the same length to make it easier to identify and memorize them. An intuitive way to attach generalized relations is like in forms as "label: value", i.e. "relation: keyword". Since colons may cause trouble in some contexts where no "punctuations marks" allowed, a more general usable way is prefix like with Camel Case to highlight a prefix keyword compound, e.g. "atMonday".

The following list could be some maximally generalized relations as prefixes:

• is = "is a" / type of
• by = causer, source
• on = theme, target
• at = location in space or time
• do = action that is realised or implemented by a topic
• cx = context or simple "see"; the weakest relation, possibly expressing nothing more than the existence of a relation whose kind cannot be stated clearer
• id = ID / identity

It is not accidental that the given relations resemble "what - who - where - when" questions, "what" separated as "is" and "on", and "where" and "when" simultaniously collapsed into "at" and separated as "at" vs. "cx". A special case is "id" as a relation to a keyword that can and should exist only once, being rather an unambigous replacement for a possibly ambigous name or title, but clearly a relation, in fact the technically most important one, i.e. identity. Note that keyword-like IDs allow using topics (by their IDs) as keywords, directly depicting relations between topics and allowing for explicit keyword definitions instead of rather vague and ad hoc "self explaining" keywords which also tend to be ambigious.

Maybe "be"

For future purposes the opposite of "is" could be helpful, i.e. depicting tokens or subtypes that may help to understand their (super-) type, e.g. as definition by example or pointing to more specific variants of a topic. Without going into details, a prefix that fits that requirement for minimal length should be suggested, namely be.

Previous Versions

• 2017-feb-1 - add: id allowing topic as keyword
• 2017-feb-1 - add: "id"
• 2017-jan-31 - create

LISON - LIstStyleObjectNotation

2017-feb-1 - Typo

Pretty printed JSON / JavaScript objects already look like nested lists. Why not get, Python-like, rid of brackets and stuff, relying solely on line breaks, identation and (maybe optionally) colons for a representation that should be readable and writeable for anyone who is able to read and write at all? While JSON is good for machine to machine communication, LISON (list style object notation) might be better for machine to human communication. Note that, ideally, LISON should be just a syntactical alternative to JSON, so that a translation between both should require not more than a regular expression. Note also that LISON is not meant for huge or complex data, which is generally not adequate for direct machine to human communication, but the other way round for small and simple data where JSON includes to much buzz, e.g. for configurations or tiny data records. MSON shares some ideas, but LISON should be more natural language like.

Previous versions

• 2017-jan-31 - create