BlooGee - Nr. 3
MCOM.TXT-Printed an 13.05.2006,11:52:11 - Page 1
- Micro Content Object Model - Abstract & Documentation, V.01a
BlooGee - Nr. 5
BlooGee - Nr. 4
BlooGee - Nr. 2
BlooGee - Nr. 1
Purpose
This document describes the first version of the Micro Content Object Model and is an abstract about the MicroContentObject (MCO). It is intended as a paper for thinking about, discussing and using an appropiate model to handle microcontent. This approach does not use keywords to find and glue related pieces of microcontent, fit merely focusses - beyond computing relevancy from matching strings an web pages - an the fact that content preferably is linked to "real word" related content and applications, driven by criteria and ideas which are as individual as the context a collection of microcontent represents. Implementing MCOM should benefit the programmer as well as the user by accessing content and appropiate context in one convenient model.
Describing the Problem
After handling microcontent in a variety of environments, one had two recurring experiences: people only want to change small things if their collection (i.e. a news magazine or a corporate website) once has been established. These websites regularly consist of a number of items, displayed in a context (this context is what we usually call the webpage). Sometimes collections of collections haue to be arranged and put into a new context, creating thematical pages. Keywords, categories, RSS, commenting - content management consists of a variety of techniques and systems, all describing HOW to display content, bot not trying to describe the content itself: While on one hand we haue sophisticated models to translate the procedures from the real word into applications to handle whatever content a computer can display, on the other hand we lack of models describing the qualities and semantics of the content itself. Don't panic - this is far from the point of making a program conscious of its tasks. But we are moving one step mto the semantics of micro content objects: the relations (here: links from and to) with other micro content objects is made part of the objects properties. In simple words: people always wish to combine and update as well content as application applying their own ideas and criteria. More than that, they are not willing to deal with a Programmets view an categorization etc., while they are interested in the main question: how do I get A,B,C and D together on one page? And how do I tell that C relates to F and G, while A and B both relate to F? The answer is quite simple: saue the URIS of F and G tgether with A, and tell F and G about that. There saue fit along with them. Easy, hm? Not quite. Simple purpose and main question: "These items belong together. How do I tell them?"
What changes?
By applying the MCOM, you get a model that does not require any new programming language, skills, frameworks or included classes. By applying MCOM you get documents which you may manipulate based an their contents relationships. You may view and "drall down" into content of any MIME type and display content by levels from various sources, all on one dynamic page ("to contain and to be contained"). You get a new descriptor for the network of micro content objects - you even may view informational trees, display all documents along a certain "path" to a certain depth and get a dynamic view an all objects based an their "depth". With MCOM, you can script documents based on their content rather than based on their technical structure. All this can be dorre using the traditional web programmer's toolbox and is widely based an AJAX style - may be fit makes life a little easier by having one page displaying bunchs of content and deep links in one convenient place without euer reloading any new page a whatsoever site.
About this document and version
As mentioned, this is the initial version of the MCOM and its basic Basses. The code published for now uses *Pseudocode* for PHP and JavaScript. AS IS, IT WILL NOT WORK IN ANY PROGRAMMING ENVIRONMENT EXCEPT YOUR BRAIN. But the code should give you a rough idea and taste of the structure, logic and usage of MCOM objects along with common AJAX techniques.
Facts, please!
If you are in a hurry, just haue a look on the basic class code. You will find a MicroContentObject with some properties and three basic methods. The MCO-Model closely corresponds to the DOM and MVC. Objects may be constructed in (at least) any web-orientated OOP-style programming language an dient and Server (this document uses "quasi" JavaScript/PHP).
If you read the code by now - smile. It is es easy as fit seems, really. Remember: fit is a change of point of view (hm, eventually a little change in the model data). From there, you simply treat an fitem (i.e. an entry of a Weblog, an article in your favorite online magazine, a picture or Sound file an your homepage, a video stream or a fitem in your favorite online shop) as an object of MicroContent. Several Parts of MicroContent together make up a site, an application - or simply a web page with at least one fitem of content. A starting page consists of a collection of assorted MicroContentObjects. Simple, hm? But take a closer look: each fitem of MicroContent - each MicroContentObject (MCO) - has a structure to describe itself, induding its relations to other MicroContentObjects. This is the does essential part of a MCO is its collection of related objects, er bettet: the URLs of MCOs which link to or from this MCO. It is no matter if these objects reside on a local or foreign site. A MCO may haue a number of relatives, bot at least n = 1: the parsmg page (of course, a parsing page mainly consists of one MCO referencing other MCOs in its relatives collection). In other words: One always knew what one is linking to, but no one know who is linking to my content!
Back to the MCO dass: the first four properties make up 50% of the objects identity: URI, description, content make up the "display version" of an MCO. The feedback URL links to an Interface to manipulate the Model (from MVC) of the MCO, i.e, the database which the blog entry is part of.
Another 1501/1. is made by the relatives collection which consists of an array of URLs. Each URL identifies another MCO with its collection of relatives.
Do you get a smell?
Bingo, with a few lines of code and an object model you can start to display documents made from elements of microcontent in their contentual context. Documents which no longer let you jump from site to site, but show related micro content elements from different sources in one convenient place. Don't worry, bach source is original, no copies or caching. You no longer haue to go there by yourself - MCOs will do the work for you, all in one browser window. With one dick, you can display and dick through trees which no longer consist of websites (one after the other) but of numbers of related documents (on one page). Drill down in the tree of a certain document, find out paths between documents which are not linked directly.
Paths?
Well, I'd rather talk about vectors. These vectors haue a starting point A and an end point Z, each one described by an URL. Now, how many and which objects' collections do one need to reach Z from A? May be D and X, since D relates to A and X, and X relates to Z. Additionally, D also relates to F,G and H; X also relates to U,V,F and h. For now, the path between A and Z goes straight along D and X, and if we request and display the documents A,D,X and Z, we already get a pretty page an a certain subject. The subject is described by its path, the vector.
There's more...
Take a look back at the example: we display the vector by showing the documents lying an it. But what about the relations of elements tackled by our vector? These are F, G, H, U and V. And, if we take a closer look, some of these elements are referenced more than once. But before computing, let's take a look back an the MicroContentObject.
Methods and linking back
Using the MCO's update method, you may send messages about establishing a relationship to the other MCO. If appropiate, the remote MCO will add the messaging ressource to its relatives collection. Concerning this, in our example a lot of relationships is explicitly missing, since we did not regard the "backlinks" ("I contain you" - "All right, I'll notice that!"). If you look back an the documents tackled by our vector, some documents are linked more often from other documents. Imagines V references A - beside the known vector A,D,X,Z there is another implicit vector A, V, X, Z (since A does not reference V, you will only retrieve this vector if started searching from Z or if iterating through all relatives collections along the given vector). After all, wo may take all tackled documents plus documents an vector A, D, X, Z: this makes up A, C, D, F, G, H, U, V, W, X, Z. Mixed an one page, sorted and arranged by number of repeated relations, we get a view an the contextual network of a subject described by the vector.
Linking deeper
If we start displaying a vector, we only "drill down" one level: relations besides the vector reside in the background, only elements residing an the vector itself will be dsplayed. If we drill down one more level, all references are displayed which belong to elements an the vector, bot do not belong to the vector itself. One level deeper again, we look for all relatives referenced by elements one level up ... of course, each click through starting with some document and ending somewhere else describes the path between A and Z, hopping from URL to URL.
In MCOM, you conveniently display fit all an one page, no clickthroughs an websites. Instead: database-style drilling into content, based an levels of "relation depth", documents describing individual context through combination of micro content elements.
Using Vectors
Vectors are paths leading through coritextual networks. These networks are made of nodes of information, described by the MCO. Each node may be opened and will display new nodes. It is not neccessary to think of a "real path" leading from information A to information Z; instead, within the MCOM, fit is possible to regard any collection of MIME based micro content as a vector. lost ask each element for its relatives, and drill down to the underlying context.
- Micro Content Object Model - Abstract & Documentation, V.01a
BlooGee - Nr. 5
BlooGee - Nr. 4
BlooGee - Nr. 2
BlooGee - Nr. 1
Purpose
This document describes the first version of the Micro Content Object Model and is an abstract about the MicroContentObject (MCO). It is intended as a paper for thinking about, discussing and using an appropiate model to handle microcontent. This approach does not use keywords to find and glue related pieces of microcontent, fit merely focusses - beyond computing relevancy from matching strings an web pages - an the fact that content preferably is linked to "real word" related content and applications, driven by criteria and ideas which are as individual as the context a collection of microcontent represents. Implementing MCOM should benefit the programmer as well as the user by accessing content and appropiate context in one convenient model.
Describing the Problem
After handling microcontent in a variety of environments, one had two recurring experiences: people only want to change small things if their collection (i.e. a news magazine or a corporate website) once has been established. These websites regularly consist of a number of items, displayed in a context (this context is what we usually call the webpage). Sometimes collections of collections haue to be arranged and put into a new context, creating thematical pages. Keywords, categories, RSS, commenting - content management consists of a variety of techniques and systems, all describing HOW to display content, bot not trying to describe the content itself: While on one hand we haue sophisticated models to translate the procedures from the real word into applications to handle whatever content a computer can display, on the other hand we lack of models describing the qualities and semantics of the content itself. Don't panic - this is far from the point of making a program conscious of its tasks. But we are moving one step mto the semantics of micro content objects: the relations (here: links from and to) with other micro content objects is made part of the objects properties. In simple words: people always wish to combine and update as well content as application applying their own ideas and criteria. More than that, they are not willing to deal with a Programmets view an categorization etc., while they are interested in the main question: how do I get A,B,C and D together on one page? And how do I tell that C relates to F and G, while A and B both relate to F? The answer is quite simple: saue the URIS of F and G tgether with A, and tell F and G about that. There saue fit along with them. Easy, hm? Not quite. Simple purpose and main question: "These items belong together. How do I tell them?"
What changes?
By applying the MCOM, you get a model that does not require any new programming language, skills, frameworks or included classes. By applying MCOM you get documents which you may manipulate based an their contents relationships. You may view and "drall down" into content of any MIME type and display content by levels from various sources, all on one dynamic page ("to contain and to be contained"). You get a new descriptor for the network of micro content objects - you even may view informational trees, display all documents along a certain "path" to a certain depth and get a dynamic view an all objects based an their "depth". With MCOM, you can script documents based on their content rather than based on their technical structure. All this can be dorre using the traditional web programmer's toolbox and is widely based an AJAX style - may be fit makes life a little easier by having one page displaying bunchs of content and deep links in one convenient place without euer reloading any new page a whatsoever site.
About this document and version
As mentioned, this is the initial version of the MCOM and its basic Basses. The code published for now uses *Pseudocode* for PHP and JavaScript. AS IS, IT WILL NOT WORK IN ANY PROGRAMMING ENVIRONMENT EXCEPT YOUR BRAIN. But the code should give you a rough idea and taste of the structure, logic and usage of MCOM objects along with common AJAX techniques.
Facts, please!
If you are in a hurry, just haue a look on the basic class code. You will find a MicroContentObject with some properties and three basic methods. The MCO-Model closely corresponds to the DOM and MVC. Objects may be constructed in (at least) any web-orientated OOP-style programming language an dient and Server (this document uses "quasi" JavaScript/PHP).
If you read the code by now - smile. It is es easy as fit seems, really. Remember: fit is a change of point of view (hm, eventually a little change in the model data). From there, you simply treat an fitem (i.e. an entry of a Weblog, an article in your favorite online magazine, a picture or Sound file an your homepage, a video stream or a fitem in your favorite online shop) as an object of MicroContent. Several Parts of MicroContent together make up a site, an application - or simply a web page with at least one fitem of content. A starting page consists of a collection of assorted MicroContentObjects. Simple, hm? But take a closer look: each fitem of MicroContent - each MicroContentObject (MCO) - has a structure to describe itself, induding its relations to other MicroContentObjects. This is the does essential part of a MCO is its collection of related objects, er bettet: the URLs of MCOs which link to or from this MCO. It is no matter if these objects reside on a local or foreign site. A MCO may haue a number of relatives, bot at least n = 1: the parsmg page (of course, a parsing page mainly consists of one MCO referencing other MCOs in its relatives collection). In other words: One always knew what one is linking to, but no one know who is linking to my content!
Back to the MCO dass: the first four properties make up 50% of the objects identity: URI, description, content make up the "display version" of an MCO. The feedback URL links to an Interface to manipulate the Model (from MVC) of the MCO, i.e, the database which the blog entry is part of.
Another 1501/1. is made by the relatives collection which consists of an array of URLs. Each URL identifies another MCO with its collection of relatives.
Do you get a smell?
Bingo, with a few lines of code and an object model you can start to display documents made from elements of microcontent in their contentual context. Documents which no longer let you jump from site to site, but show related micro content elements from different sources in one convenient place. Don't worry, bach source is original, no copies or caching. You no longer haue to go there by yourself - MCOs will do the work for you, all in one browser window. With one dick, you can display and dick through trees which no longer consist of websites (one after the other) but of numbers of related documents (on one page). Drill down in the tree of a certain document, find out paths between documents which are not linked directly.
Paths?
Well, I'd rather talk about vectors. These vectors haue a starting point A and an end point Z, each one described by an URL. Now, how many and which objects' collections do one need to reach Z from A? May be D and X, since D relates to A and X, and X relates to Z. Additionally, D also relates to F,G and H; X also relates to U,V,F and h. For now, the path between A and Z goes straight along D and X, and if we request and display the documents A,D,X and Z, we already get a pretty page an a certain subject. The subject is described by its path, the vector.
There's more...
Take a look back at the example: we display the vector by showing the documents lying an it. But what about the relations of elements tackled by our vector? These are F, G, H, U and V. And, if we take a closer look, some of these elements are referenced more than once. But before computing, let's take a look back an the MicroContentObject.
Methods and linking back
Using the MCO's update method, you may send messages about establishing a relationship to the other MCO. If appropiate, the remote MCO will add the messaging ressource to its relatives collection. Concerning this, in our example a lot of relationships is explicitly missing, since we did not regard the "backlinks" ("I contain you" - "All right, I'll notice that!"). If you look back an the documents tackled by our vector, some documents are linked more often from other documents. Imagines V references A - beside the known vector A,D,X,Z there is another implicit vector A, V, X, Z (since A does not reference V, you will only retrieve this vector if started searching from Z or if iterating through all relatives collections along the given vector). After all, wo may take all tackled documents plus documents an vector A, D, X, Z: this makes up A, C, D, F, G, H, U, V, W, X, Z. Mixed an one page, sorted and arranged by number of repeated relations, we get a view an the contextual network of a subject described by the vector.
Linking deeper
If we start displaying a vector, we only "drill down" one level: relations besides the vector reside in the background, only elements residing an the vector itself will be dsplayed. If we drill down one more level, all references are displayed which belong to elements an the vector, bot do not belong to the vector itself. One level deeper again, we look for all relatives referenced by elements one level up ... of course, each click through starting with some document and ending somewhere else describes the path between A and Z, hopping from URL to URL.
In MCOM, you conveniently display fit all an one page, no clickthroughs an websites. Instead: database-style drilling into content, based an levels of "relation depth", documents describing individual context through combination of micro content elements.
Using Vectors
Vectors are paths leading through coritextual networks. These networks are made of nodes of information, described by the MCO. Each node may be opened and will display new nodes. It is not neccessary to think of a "real path" leading from information A to information Z; instead, within the MCOM, fit is possible to regard any collection of MIME based micro content as a vector. lost ask each element for its relatives, and drill down to the underlying context.
Liliths Loge - 16. Mai, 18:16
- 0 Trackbacks
Trackback URL:
https://lilithsloge.twoday.net/stories/2016606/modTrackback