Difference between revisions of "PKC/Design Principle"

From PKC
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Design Principle==
==Design Principle==
[[PKC]] models data assets in terms of [[function]]s, which is a kind of [[scale-free]] data representation. These functional data representation are in turn categorized into [[Page]], [[File]], and [[Service]]. Each category of [[function]] is treated as the [[primitive form of data]], and can be recursively referenced to perform both computation and carry computational results. All pages in [[PKC]] are conceptualized as hyperlinked data points in a [[functional style]]. All data points or pages have their unique names. These names can be thought of as function names, and each function may have many key-value-pairs as its arguments.  
[[PKC]] models data assets in terms of [[function]]s, which is a kind of [[scale-free]] data representation. These functional data representation are in turn categorized into [[Page]], [[File]], and [[Service]]. Each category of [[function]] is treated as the [[primitive form of data]], and can be recursively referenced to perform both computation and carry computational results. All pages in [[PKC]] are conceptualized as hyperlinked data points in a functional style. All data points or pages have their unique names. These names can be thought of as function names, and each function may have many key-value-pairs as its arguments.  
=Data Architecture=
{{:Data Architecture}}


Thinking about functions at all times in this primitive, yet generic construct, allows users to think of all functions as [[hyperlink]]s or [[fiber bundle]]s that relates objects from one to the other, revealing the [[Topology|topological structures]], or the systematic structures of anything. Most importantly, users of [[PKC]] can think of writing down notes in various [[Page|pages]] are effectively construction functions or conducting computational work in parallel and in an explicit functionally designed [[data]] storage. The storage packages are managed in terms of [[file]]s. The availability and reliability of providing these [[page]]s and [[files]] are called [[service]]s. This completes the three categories of [[scale-free]] data representation. The design principle that differentiate [[PKC]] from other [[hyperlink]]/[[hypermedia]] systems is that [[PKC]] considers data content within the system as an integral part of the system. Since every instance of [[PKC]] is tightly bound with its own content, all [[PKC]] must allow maximum freedom to all instances of [[PKC]]s. To accomplish this design principle, it needs to give full ownership and power to conduct changes to the owners of individual instances. In the most egalitarian scenario, we must reduce the barrier to entry, so [[PKC]]s should be convenient and cheap to be replicated or allowing for the creation of new instances that are independent from other instances of [[PKC]], so that the functionality of [[PKC]]s can be easily shared across many application domains.
=Represent Knowledge in Functions=
Thinking about functions at all times in this primitive, yet generic construct, allows users to think of all functions as [[hyperlink]]s that relate objects from one to the other, revealing the [[Topology|topological structures]], or the systematic structures of anything. Most importantly, users of [[PKC]] can think of writing down notes in various [[Page|pages]] are effectively construction functions or conducting computational work in parallel and in an explicit functionally designed [[data]] storage. The storage packages are managed in terms of [[file]]s. The availability and reliability of providing these [[page]]s and [[file]]s are called [[service]]s. This completes the three categories of [[scale-free]] data representation. The design principle that differentiate [[PKC]] from other [[hyperlink]]/[[hypermedia]] systems is that [[PKC]] considers data content within the system as an integral part of the system. Since every instance of [[PKC]] is tightly bound with its own content, all [[PKC]] must allow maximum freedom to all instances of [[PKC]]s. To accomplish this design principle, it needs to give full ownership and power to conduct changes to the owners of individual instances. In the most egalitarian scenario, we must reduce the barrier to entry, so [[PKC]]s should be convenient and cheap to be replicated or allowing for the creation of new instances that are independent from other instances of [[PKC]], so that the functionality of [[PKC]]s can be easily shared across many application domains.

Latest revision as of 19:22, 20 February 2022

Design Principle

PKC models data assets in terms of functions, which is a kind of scale-free data representation. These functional data representation are in turn categorized into Page, File, and Service. Each category of function is treated as the primitive form of data, and can be recursively referenced to perform both computation and carry computational results. All pages in PKC are conceptualized as hyperlinked data points in a functional style. All data points or pages have their unique names. These names can be thought of as function names, and each function may have many key-value-pairs as its arguments.

Data Architecture

In PKC, data is consistently represented using one universal construct, directed relation. This also means that we can always use the same data type, directed relation to interpret and manipulate data.

Architecture = Invariant Properties

It is important to note that the word Architecture implies elements of a system that doesn't change. Therefore, this section will talk about the data elements of PKC that don't change over space and time.


Logic Model (Data Architecture) Template:LogicModel 02 20, 2022
Abstract Specification
Context Data Architecture/Context
Goal Data Architecture/Goal
Success Criteria Data Architecture/Criteria
Concrete Implementation
Given Inputs When Process is executed... Then, we get Outputs
Data Architecture/Input Data Architecture/Process Data Architecture/Output
Boundary/Safety Conditions of Data Architecture
Data Architecture/Boundary

References

Related Pages

Represent Knowledge in Functions

Thinking about functions at all times in this primitive, yet generic construct, allows users to think of all functions as hyperlinks that relate objects from one to the other, revealing the topological structures, or the systematic structures of anything. Most importantly, users of PKC can think of writing down notes in various pages are effectively construction functions or conducting computational work in parallel and in an explicit functionally designed data storage. The storage packages are managed in terms of files. The availability and reliability of providing these pages and files are called services. This completes the three categories of scale-free data representation. The design principle that differentiate PKC from other hyperlink/hypermedia systems is that PKC considers data content within the system as an integral part of the system. Since every instance of PKC is tightly bound with its own content, all PKC must allow maximum freedom to all instances of PKCs. To accomplish this design principle, it needs to give full ownership and power to conduct changes to the owners of individual instances. In the most egalitarian scenario, we must reduce the barrier to entry, so PKCs should be convenient and cheap to be replicated or allowing for the creation of new instances that are independent from other instances of PKC, so that the functionality of PKCs can be easily shared across many application domains.