Difference between revisions of "Service"

From PKC
Jump to navigation Jump to search
Line 3: Line 3:
<noinclude>
<noinclude>
[[Category:Service]]
[[Category:Service]]
[[Differentiate with::API|Differentialte with API]] https://www.youtube.com/watch?v=qGFRbOq4fmQ
[[Differentiate with::API|Differentialte with API]] : https://www.youtube.com/watch?v=qGFRbOq4fmQ
</noinclude>
</noinclude>

Revision as of 06:15, 29 August 2021

Universal Data Abstraction is a digital native skill that will enable people to use any repeatable representational[1] approach to encode information content. As long as the representational approach is object and repeatable, any amount of information can be encoded in "data", that is why data abstraction can be considered to be "Universal". The concept of universality is counter intuitive, and can be partially explained by the famous talk[2] by Eugene Wigner.

In data asset management practices, the physical size of data, is often measured in terms of the time and space required to transfer or replicate the asset. Therefore, we created the asset classification in terms of Page/File/Service, each adheres to a broad type of asset management functional category. In the case of Page/File/Service classification, they each relates to data presentation, data storage, and data provisioning.


Three Examples of Universal Data Abstraction

The universal context of interest in Meta University is about organizing data in namespaces and temporal contexts. To define a namespace, a pre-defined set of symbols or vocabulary must be formulated, so that it becomes possible to use the symbol set to recursively represent the possibilities of data points. When it comes to representing temporal contexts. There are three generic types of relative temporal positioning, past, present, and future. We related each temporal positioning with one kind of data:

  1. File for data in the Past: since we will subscribe to the immutability of past events given causal belief. To make it more concrete, PKC follows MediaWiki's convention to define a unique namespace, called File, for every file. In computer operating systems, all data sets, devices, and communicating channels are considered to be Files.
  2. Page for data in the Present: In other words, pages are data interfacing with its consumer at the current stage. Similarly, PKC also utilizes MediaWiki's convention to define a namespace for all pages. In MediaWiki, page namespace is called: Main. We will follow this convention in PKC. In a web browser environment, all data are being presented through Page-based" representation.
  3. Service for data into the Future: A set of computing services will be provisioned to continuously render new data into the future. As of 2022, MedaWiki has not had a namespace dedicated to Service, but it does define an explicit service APIs. To provide a consistent abstraction framework, MU-compliant PKCs will explicitly reserve a namespace, called Service namespace. This namespace will be defined in PKC's MediaWiki LocalSettings.php configuration file. We will likely use the metaNamespace as defined in MediaWiki.org, to explicitly reserve the namespace:Service. In network-connected computing systems, recently considered to be the computing cloud, all data sets, devices, and communicating channels are considered to be Services.

What are the differences between APIs and Services

One can think of APIs as computing services. The differences can be articulated in the following way[3], Differentiate with API : https://www.youtube.com/watch?v=qGFRbOq4fmQ.

MediaWiki's API

The most direct way to learn about API, is to use them with your browser.

A group of infrastructure that enables to interpretation of Files

Other than HTML/JavaScript/CSS enabled browsers, a set of legacy-compatible services can be run remotely to guarantee all tested versions of Files can be run and served into the future.

A very unique kind of File for PKC

Data content stored in PKC, will be packaged with a timestamp, to be certified by a series of security tools, to guarantee that the data content can be played back with relevant PKC-related docker images. On the hand, this is a way to guarantee that all files are playable overtime, because we can run test cases to ensure that these file formats are readable even after certain operating systems are deprecated.

Mountpoint Directory as a File

This is the conceptual model for storing all data in a single file for PKC. Moreover, it needs to also specify the docker images and the docker and virtual machine simulation environments that are needed to playback the file. One should also note that in Fossil, the repository file is also just a single file, which is encoded in SQLite file format. This encoding and allowing one to use SQLite to manipulate the data content in this single file repository, can be an excellent reference design for data management for PKC.

A demo showing that one instruction can be used to perform universal computation. Differentialte with API : https://www.youtube.com/watch?v=qGFRbOq4fmQ