Open Console — Data Sharing Specification

Read the Data Sharing explanation to understand why Consumers of Open Console information need Meshy Space Concept (MSC) to implement the transport of facts between Producers and Consumers; between systems which do know facts about a website, and systems which want to use that information.

Producers publish Collections of Units, which each contain one (structured) fact. Automagically, MSC will make the Consumer aware of the additions and changes in the Collection, which will trigger processing.

Implementation !!Under construction!!

Namespaces

MSC depends on name-spaces: publications use them to explain which definition set is used. Each Producer declares its own name-space(s), but there is also a set which is describing Open Console specifics. Namespaces are represented by prefixes (XML-style), and used in the payload of distributed Units of data.

The following namespaces are used:

  • ms: (Meshy Space Base, MS) defines very basic components of Units, like "document". Base schema;
  • msc: (Meshy Space Concept, MSC) specifies Collections of Units. Some collected Units will have Concept supporting content. Concept schema;
  • oc: (Open Console Base, OC) defines components which are required to make Producers and Consumers work together;
  • ocf: (Open Console Forms, OCF) defines types and constants which implement the powerful web-forms offered by the Open Console project. Read the Forms specification.

Specification

Identities and Licenses are standard components of MSC. This layer also implements access restrictions, data distribution, and data retention.

The Hierarchy in website structure is reflected in separate OC Units.

Have a look at the Forms specification. This might end-up is a totally separate project, usable independent of Open Console and Meshy Space. However, the design follows the same strategy and namespaces.

Of course, this is not all: per producer, you will need to have a specification for its contribution.

Example of a Website-describing Unit

The example below shows the Open Console specific structures which describe website data inserted by the website's owner.

<!-- in Collection web: -->
<ms:unit ms:id="Site.https.markov.solutions">
  ...
  <oc:website>                         <!-- is a ms:Native payload -->
    <oc:domain>web:Domain.markov.solutions      <!-- is a ms:Href -->
    <oc:canonical-url>https://markov.solutions  <!-- is a ms:Url  -->
    <oc:alternative-url>https://solutions.overmeer.net
    <oc:alternative-url>http://solutions.overmeer.net
    <oc:owner>ids:/user/MarkOv         <!-- is a msc:Identity, ms:Href -->
    <oc:owner-proof status="oc:OwnerProof.SUCCESS" date="..." />
    <oc:page-set>
      <oc:language>ms:Lang.nl-NL       <!-- is a ms:Language -->
      <oc:url-pattern>/nl/             <!-- is a ms:Pattern -->
      <oc:sitemap>/sitemaps/nl.sitemap <!-- is a ms:Url -->
    <oc:page-set>
      <oc:language>ms:Lang.en-US
      <oc:url-pattern>/en/

In above case, "web:" is the namespace of the Collection the publisher of this knowledge defined. It uses "ids:" to refer to an identity managing archive. Both prefixes intended as example prefixes only.

Collections per Producer

A Producer can create as many Collections of knowledge as it wants. In the simplest case, it publishes only Collection with various kinds of data. However, from the organizational point of view, working with multiple Collections improves maintainability.

At least the following (payloads for) Units will get distributed:

  • oc:domain, oc:website, oc:network, and oc:url to let the data refer to WWW elements in the Hierarchy;
  • ocf:field-set which contains form template fragments to present and update Producer specific Unit content in Forms;
  • The public parts of msc:license keys and Producer msc:identities;
  • Units referring to msc:collections which are used as sources for the produced data, containing the reference to the Licenses which is permitted.
  • And, of course, the Units which the Producer publishes.