Difference between revisions of "Universal abstraction"
| (74 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
The | Universal abstraction is a logical construct to help broaden the scope representability in general. It can be related to certain universal data types, or data formats, so that thinkers, software engineers, or philosophers can do more with less. One of the strongests proponent of universal abstraction is [[Gottfried Wilhelm Leibniz]], who wrote a short book on [[Monadology]], which is a strategy to perform universal abstraction with [[simple substance]], yet [[universal component|possesses universal expressiveness]]. Simplicity allows for automation and scalability. | ||
=The Ultimate Abstraction according to John Shutt= | |||
Please read this paper:[[Thesis/Fexprs as the basis of Lisp function application or $vau : the ultimate abstraction|Thesis/Fexprs as the basis of Lisp function application or $vau : the ultimate abstraction]]<ref>{{:Thesis/Fexprs as the basis of Lisp function application or $vau : the ultimate abstraction }}</ref> | |||
==Page, Services, Files== | |||
First，see [[Page/File/Service]]. From an Information Technology (IT) point of view, there are really just three kinds of generic/universal abstractions. For end users, information must be presented as [[page]]s of text, images, sounds or videos. For networked environments, including web-based applications, everything is considered as some kind of [[service]]s, sending bytes of data from and to each other. For operating systems, it has historically defined all data receiving and sending devices as [[file]]s, including your keyboards and monitors are always considered as some form of files. Considering information content in a singular type of object is an important strategy to ensure consistency and maintain simplicity while dealing with complex and evolving systems. | |||
==Universal Data Abstractions in Namespaces== | |||
While owning or operating a [[PKC|Personal Knowledge Container (PKC)]], it is likely for the person who switch roles or one's point of view in dealing with data assets. For example, when just viewing and editing data, the data owner is just a regular user. When managing one's data service, the same person becomes a system administrator. When working with computing procedures, it would be convenient to think of data units in terms of individual files. Therefore, the three terms, Page, Service, and Files are three kinds of Universal Abstraction for engaging users, system administrators, and programmers in three different linguistic convention. | |||
To unite all three namespaces, page, service, file in one unifying abstraction, MediaWiki's namespace convention comes handy. All objects can have unique names in a MediaWiki database. When a page refers to a service, one can simply attach a prefix, say '''Service:(service name)'''. Similarly, in one needs to refer to a particularly file, one can attache the '''File:(file name)''' to the unique string that represents a file. One can consider the absence of prefix being the entire namespace of all strings refer to some '''Pages''', including the prefixed strings. | |||
== | ==Category Theory in Hyperlinks== | ||
[[Category Theory]]<ref>{{:Book:Conceptual Mathematics}}</ref> is the foundational reasoning mechanism to represent and infer decisions from data. It was developed to offer a universal foundation to denote and reason about mathematical ideas. It is a formal language based on one type of symbols, using a singular type symbol, the [[arrow]], or [[hyperlink]]. It is well-articulated by [[Dana Scott]]<ref>{{:Paper/Outline of a Mathematical Theory of Computation}}</ref> that all data types can be represented using [[Partially ordered set]]. | |||
It should be rather trivial to think of a hyperlink as an arrow. A hyperlink is a data type, namely a 2-tuple with a starting object and an ending object. In the world of web pages, the starting and ending objects are just pages. | |||
==Wiki's Hyperlink in two directions== | ==Wiki's Hyperlink in two directions== | ||
MediaWiki has two types of built-in hyperlink syntax. One is the curly braces <nowiki>{{}}</nowiki> and the other one is square brackets <nowiki>[]</nowiki>. One can think of curly braces being the hyperlink for '''pulling''' information, and square brackets being the hyperlink for '''pushing''' information<ref>This idea is due to Jared Cordon's observation in a conversation with Ben Koo on June 23, 2021</ref>. The notion of [[pulling]] comes from that fact that this annotated link will trigger a computing procedure in MediaWiki to produce some content and to be '''pulled'' into the location where the '''curly braces''' (<nowiki>{{}}</nowiki>), shows up in the page. The notion of [[pushing]] comes from that fact that this annotated link in the page where the '''square brackets''' (<nowiki>[]</nowiki>) can be pushed by a mouse button, and lead user to another page. | MediaWiki has two types of built-in hyperlink syntax. One is the curly braces <nowiki>{{}}</nowiki> and the other one is square brackets <nowiki>[]</nowiki>. One can think of curly braces being the hyperlink for '''pulling''' information, and square brackets being the hyperlink for '''pushing''' information<ref>This idea is due to Jared Cordon's observation in a conversation with Ben Koo on June 23, 2021, last viewed:{{CURRENTTIMESTAMP}}</ref>. The notion of '''[[pulling]]''' comes from that fact that this annotated link will trigger a computing procedure in MediaWiki to produce some content and to be '''pulled'' into the location where the '''curly braces''' (<nowiki>{{}}</nowiki>), shows up in the page. The notion of '''[[pushing]]''' comes from that fact that this annotated link in the page where the '''square brackets''' (<nowiki>[]</nowiki>) can be pushed by a mouse button, and lead user to another page. | ||
===Pulling | ===Pulling with Magic Words=== | ||
The pulling navigation feature is accomplished by using the curly brackets. All types of commands that are intended to pull in or alter the object page are found inside these brackets. | The pulling navigation feature is accomplished by using the curly brackets, often known as [[MW:Manual:Magic words|Magic Words]]<ref>Please refer to MediaWiki.org Website:[[MW:Manual:Magic words|Magic Words]]</ref>. All types of commands that are intended to pull in or alter the object page are found inside these brackets. For example, if you want to display the current time, you can use this statement <code><nowiki>{{CURRENTTIMESTAMP}}</nowiki></code>, and it should be rendered as: | ||
<nowiki>{{CURRENTTIMESTAMP}}</nowiki> to be rendered as: {{CURRENTTIMESTAMP}} | |||
The simplest and most common method of pulling information is known as transclusion, which simply means to pull information from one page to another, created a fixed relationship between the two pages. | The simplest and most common method of pulling information is known as transclusion, which simply means to pull information from one page to another, created a fixed relationship between the two pages. | ||
| Line 17: | Line 27: | ||
Typically Template pages are specifically designed for transclusion purposes, but its not limited to templates, any and all pages within Mediawiki are able to be transcluded, unless specifically restricted. In order to transclude a page simply follow the command below. | Typically Template pages are specifically designed for transclusion purposes, but its not limited to templates, any and all pages within Mediawiki are able to be transcluded, unless specifically restricted. In order to transclude a page simply follow the command below. | ||
{ { page name } } | <nowiki>{{page name}}</nowiki> | ||
In-line queries are another powerful tool for using pulling commands. Typically in-line queries are either an #ask or a #show request. | |||
Ask queries allow you to dynamically pull data and display it in the form of graphs, charts and tables under certain defined parameters. In order to query data it must be defined by either categories or properties, since it’s these tagging methods that allow data to be machine readable; therefore we recommend that as much as possible you keep content stored on category pages, which is the basic manager of page level data abstractions, and then for content stored within category pages as much as possible limit yourself to only using properties to input any value into the pages. By limiting yourself to only categories and properties you will ensure that your database is lean and most importantly machine readable. | |||
{{#Ask}} | |||
===Pushing | Show queries are a form of transclusion; while transclusion typically deals with content on the page level of data abstraction, #Show queries deal with transclusion on the value level of abstraction. Therefore if you would simply like to pull a specific value input from one page to another #show is an ideal candidate. | ||
{{#Show}} | |||
===Pushing with Internal and External Links=== | |||
The pushing navigation feature is accomplished by using square brackets. All types of commands that are intended to push you out of a page are found inside these brackets. When pushing to a page outside the same domain you use one set of brackets and simply input the url inside the brackets, to push to pages within the same domain, or pages found in wikipedia, you use two sets of brackets and simply input the page name. | The pushing navigation feature is accomplished by using square brackets. All types of commands that are intended to push you out of a page are found inside these brackets. When pushing to a page outside the same domain you use one set of brackets and simply input the url inside the brackets, to push to pages within the same domain, or pages found in wikipedia, you use two sets of brackets and simply input the page name. | ||
[ [ Property name : : Property value ] ] = [ [ predicate : : subject ] ] | <nowiki>[[Property name::Property value]] = [[predicate::subject]]</nowiki> | ||
Properties can assign varying [https://www.semantic-mediawiki.org/wiki/Help:List_of_datatypes datatypes] | Properties can assign varying [https://www.semantic-mediawiki.org/wiki/Help:List_of_datatypes datatypes] | ||
[ [ Category : page name ] ] = [ [ hierarchy : classification ] ] | <nowiki>[[Category:page name]] = [[hierarchy:classification]]</nowiki> | ||
===General Hyperlink Usage=== | ===General Hyperlink Usage=== | ||
| Line 34: | Line 54: | ||
Understanding this simple and fundamental use of mediawiki features is what allows this tool to be a perfect candidate for demonstrating Category Theory's ordering and computation methods. | Understanding this simple and fundamental use of mediawiki features is what allows this tool to be a perfect candidate for demonstrating Category Theory's ordering and computation methods. | ||
==Namespace Management== | |||
For the principles of how to manage data universally, it would be useful to read [[Thomas Khun]]'s [[The Structure of Scientific Revolutions]]<ref>{{:Book:The Structure of Scientific Revolutions}}</ref>, and [[Bruno Latour]]'s [[Science in Action]]<ref>{{:Book:Science in Action}}</ref>. | |||
Naming of pages is one of the most important things you will do when interacting with your PKC. Proper namespace management will make or break the successful function of your knowledge base. Its important to keep a universal scope when it comes to naming. When your name dictionary can be lean and minimal then it will be easier for you to remember and use each namespace to its fullest potential. | |||
This is why beginning with the naming of properties that Semantic Mediawiki provides a tool for checking the similarities between properties. This tool is a good way for you to check whether or not you have created potentially redundant properties. | |||
[[Special:PropertyLabelSimilarity]] | |||
=References= | =References= | ||
<references /> | |||
[[Category:Universal abstraction]] [[Category:Universal data abstraction]] [[Category:Universal property]] [[Category:Universal construction]] | |||
{{PagePostfix | |||
|category_csd=Universal Construction,Universal Data Abstraction,Abstraction | |||
|semantic_labels=[[Page created by date::{{#invoke:CurrentDate|getDate|{{REVISIONMONTH}}|{{REVISIONDAY}}|{{REVISIONYEAR}}|}}]] | |||
[[Start datetime::{{#invoke:CurrentDate|getDate|{{REVISIONMONTH}}|{{REVISIONDAY}}|{{REVISIONYEAR}}|}}]] | |||
[[End datetime::{{#invoke:CurrentDate|getDate|{{CURRENTMONTH}}|{{CURRENTDAY}}|{{CURRENTYEAR}}|}}]] | |||
}} | |||
Latest revision as of 05:12, 20 July 2022
Universal abstraction is a logical construct to help broaden the scope representability in general. It can be related to certain universal data types, or data formats, so that thinkers, software engineers, or philosophers can do more with less. One of the strongests proponent of universal abstraction is Gottfried Wilhelm Leibniz, who wrote a short book on Monadology, which is a strategy to perform universal abstraction with simple substance, yet possesses universal expressiveness. Simplicity allows for automation and scalability.
The Ultimate Abstraction according to John Shutt
Please read this paper:Thesis/Fexprs as the basis of Lisp function application or $vau : the ultimate abstraction[1]
Page, Services, Files
First，see Page/File/Service. From an Information Technology (IT) point of view, there are really just three kinds of generic/universal abstractions. For end users, information must be presented as pages of text, images, sounds or videos. For networked environments, including web-based applications, everything is considered as some kind of services, sending bytes of data from and to each other. For operating systems, it has historically defined all data receiving and sending devices as files, including your keyboards and monitors are always considered as some form of files. Considering information content in a singular type of object is an important strategy to ensure consistency and maintain simplicity while dealing with complex and evolving systems.
Universal Data Abstractions in Namespaces
While owning or operating a Personal Knowledge Container (PKC), it is likely for the person who switch roles or one's point of view in dealing with data assets. For example, when just viewing and editing data, the data owner is just a regular user. When managing one's data service, the same person becomes a system administrator. When working with computing procedures, it would be convenient to think of data units in terms of individual files. Therefore, the three terms, Page, Service, and Files are three kinds of Universal Abstraction for engaging users, system administrators, and programmers in three different linguistic convention.
To unite all three namespaces, page, service, file in one unifying abstraction, MediaWiki's namespace convention comes handy. All objects can have unique names in a MediaWiki database. When a page refers to a service, one can simply attach a prefix, say Service:(service name). Similarly, in one needs to refer to a particularly file, one can attache the File:(file name) to the unique string that represents a file. One can consider the absence of prefix being the entire namespace of all strings refer to some Pages, including the prefixed strings.
Category Theory in Hyperlinks
Category Theory[2] is the foundational reasoning mechanism to represent and infer decisions from data. It was developed to offer a universal foundation to denote and reason about mathematical ideas. It is a formal language based on one type of symbols, using a singular type symbol, the arrow, or hyperlink. It is well-articulated by Dana Scott[3] that all data types can be represented using Partially ordered set.
It should be rather trivial to think of a hyperlink as an arrow. A hyperlink is a data type, namely a 2-tuple with a starting object and an ending object. In the world of web pages, the starting and ending objects are just pages.
Wiki's Hyperlink in two directions
MediaWiki has two types of built-in hyperlink syntax. One is the curly braces {{}} and the other one is square brackets []. One can think of curly braces being the hyperlink for pulling' information, and square brackets being the hyperlink for pushing information[4]. The notion of pulling comes from that fact that this annotated link will trigger a computing procedure in MediaWiki to produce some content and to be pulled into the location where the curly braces ({{}}), shows up in the page. The notion of pushing comes from that fact that this annotated link in the page where the square brackets ([]) can be pushed by a mouse button, and lead user to another page.
Pulling with Magic Words
The pulling navigation feature is accomplished by using the curly brackets, often known as Magic Words[5]. All types of commands that are intended to pull in or alter the object page are found inside these brackets. For example, if you want to display the current time, you can use this statement {{CURRENTTIMESTAMP}}, and it should be rendered as:
{{CURRENTTIMESTAMP}} to be rendered as: 20241125050141
The simplest and most common method of pulling information is known as transclusion, which simply means to pull information from one page to another, created a fixed relationship between the two pages.
Typically Template pages are specifically designed for transclusion purposes, but its not limited to templates, any and all pages within Mediawiki are able to be transcluded, unless specifically restricted. In order to transclude a page simply follow the command below.
{{page name}}
In-line queries are another powerful tool for using pulling commands. Typically in-line queries are either an #ask or a #show request.
Ask queries allow you to dynamically pull data and display it in the form of graphs, charts and tables under certain defined parameters. In order to query data it must be defined by either categories or properties, since it’s these tagging methods that allow data to be machine readable; therefore we recommend that as much as possible you keep content stored on category pages, which is the basic manager of page level data abstractions, and then for content stored within category pages as much as possible limit yourself to only using properties to input any value into the pages. By limiting yourself to only categories and properties you will ensure that your database is lean and most importantly machine readable.
{{#Ask}}
Show queries are a form of transclusion; while transclusion typically deals with content on the page level of data abstraction, #Show queries deal with transclusion on the value level of abstraction. Therefore if you would simply like to pull a specific value input from one page to another #show is an ideal candidate.
{{#Show}}
Pushing with Internal and External Links
The pushing navigation feature is accomplished by using square brackets. All types of commands that are intended to push you out of a page are found inside these brackets. When pushing to a page outside the same domain you use one set of brackets and simply input the url inside the brackets, to push to pages within the same domain, or pages found in wikipedia, you use two sets of brackets and simply input the page name.
[[Property name::Property value]] = [[predicate::subject]]
Properties can assign varying datatypes
[[Category:page name]] = [[hierarchy:classification]]
General Hyperlink Usage
When simply ordering and building the database you will create pushing hyperlink relationships, following an adding directional flow in the form of categories, and properties. If you want to compute or compile information then you will create pulling hyperlink relationships in the form of transclusion, magicwords, pasarfunctions, or other special commands.
Understanding this simple and fundamental use of mediawiki features is what allows this tool to be a perfect candidate for demonstrating Category Theory's ordering and computation methods.
Namespace Management
For the principles of how to manage data universally, it would be useful to read Thomas Khun's The Structure of Scientific Revolutions[6], and Bruno Latour's Science in Action[7].
Naming of pages is one of the most important things you will do when interacting with your PKC. Proper namespace management will make or break the successful function of your knowledge base. Its important to keep a universal scope when it comes to naming. When your name dictionary can be lean and minimal then it will be easier for you to remember and use each namespace to its fullest potential.
This is why beginning with the naming of properties that Semantic Mediawiki provides a tool for checking the similarities between properties. This tool is a good way for you to check whether or not you have created potentially redundant properties.
Special:PropertyLabelSimilarity
References
- ↑ Shutt, John (August 23, 2010). Fexprs as the basis of Lisp function application or $vau : the ultimate abstraction (PDF) (Ph.D.). local page: WORCESTER POLYTECHNIC INSTITUTE. Retrieved July 14, 2022.
- ↑ Book:Conceptual Mathematics
- ↑ Scott, Dana (January 1, 1970). "Outline of a Mathematical Theory of Computation". local page: Oxford University Computing Laboratory Programming Research Group.
- ↑ This idea is due to Jared Cordon's observation in a conversation with Ben Koo on June 23, 2021, last viewed:20241125050141
- ↑ Please refer to MediaWiki.org Website:Magic Words
- ↑ Book:The Structure of Scientific Revolutions
- ↑ Book:Science in Action
References
Related Pages
07 20, 2022 07 20, 2022 11 25, 2024