Identification, abstracting, meaning

ABSTRACT

Growth of information volumes becomes one of main problems of contemporary computer world. This article considers the way in the past to this situation, but also proposes the solution. Key feature of this solution is to solve problems of identifying, abstracting, and meaning. The solution implies creation of new level of abstraction over user level, and of semantic protocol over HTTP. Such measures should hide computer-dependent information (file names, menu, dialogs, URLs) and converts such information into identifiers (natural language words, numbers, symbols, etc), which could be recognized by humans. Given approach is necessary, because an user should search for information (not for files), utilize application functions (not menus and dialogs), use words and clauses (not URLs).

INTRODUCTION

Internet is big information dump. Though, with constant attempts to sort and order it. But even the most successfull sorting machine for the simplest queries dumps million references (which, evidently should be considered as a sign of successfull sorting, as if a librarian would tell you "yes, we have million books on this topic, please search there..."). Well, we should rely on own abilities and additionally sort out what was proposed by a search engine. Quite naturally, usually we process of dozens, hundreds references, and if nothing found, a search is considered as failed. Of course, sorting machines are doing enormous job: calculations show that now there is about 1 trillion (10^12) unique pages, general query usually gives about 100 millions (10^8) pages, less general query gives dozen millions, etc. But, in real life similar queries should give not more than dozens, hundreds, or even only one reference. For example, "the host of Olympic games 2012" query has to result in only one answer, "cats" query has to give sites and pages, which dedicated to cats, but not all pages, where they mentioned somehow. No surprise that search engines try to guess what you want, to propose better filtering, to rely on human-enabled sorting, which assumes humans are the best in sorting of small information dumps.

The situation with personal computers is different. It contains from hundreds thousands up to several millions files, however, unlike Internet, where we can predict where content is located, searching through local files can be easily restricted: at least, it is not worthy to look for personal information in applications directories. Hereto, if information identification for somebody's else files is just meaningless, because it is more probable we won't use them again, then identification for our own files is more appropriate, because we use them often, therefore precise identification will find them quicker, than repetitive full search. But once identification is provided, abstracting (which involves approximated identification, ie comparing by similarity) should be granted too. But then also we should think about semantics (ie, relations between identified information). And if this will work locally, then we need single identification mechanism, which will allow to jointly use already classified information. Unfortunately, contemporary computers do not provide such possibilities.

In the beginning nobody even thought about such problems. The first computers were quite awkward, therefore information accumulated quite slow. Fortunately or not, but computer technologies gradually advanced more and more. Text interface, operating systems, high-level programming languages, data formats, graphical interface, Internet, at last. Each of these enhancements (even not considering hardware enhancements) facilitated input and processing of information, which lead to its volume and made searches more difficult. Internet made things even worse: when computers were not linked in one big net, rare bird took pleasure to dump own thoughts and emotions on hard drive, but emergence for thousands and even millions of readers became the trigger of exponential information growth.

Could we resolve the problem of overflowing information? Now we have a lot of promising technologies, which intend to tame information volumes: collaboration, social network services, Semantic Web, but also virtual reality, augmented reality, 3D interface, image and language recognition, etc. Some of them are not enough mature, some of them are quite effective esthetically, but not so useful in practice. Unfortunately, none proposed overall solution which would satisfy everyone. Could we understand what at least theoretically could cope with this problem? At first, we can browse through revolutions of the past and understand why this or that invention became breakthrough.

REVOLUTIONS OF THE PAST

* Text (console, command-line) interface. Appeared because of necessity to communicate with computer with human-recognizable language. Conditions which required for that: (1) possibility to identify computer entities (eg, a disk or a copying operation), (2) possibility of abstracting (ie, expressing of a set of objects or actions with one identifier, eg usage of copying operation as an abstraction of copying bytes from one place of hard drive to another). Side-effect: (3) possibility of reusing of identifiers. There were a lot of attempts to use natural language for the same goal, but they failed not only because full analysis of syntax and grammar is quite complex operation (though simplified analysis is quite possible), but also because special language is more suitable for operating with computer entities. In fact, any human activity uses own slang or specific abstract language (as mathematics), which abstract entities of the activity area better than natural language.
* High-level programming languages, programming interfaces, data formats. The same situation as with text interface, but with richer possibilities, because of available additional abstractions, which could compose more complex solutions. Data formats are, in fact, abstract languages (which is not so evident as binary, but more evident as text) for ordering and restricting information.
* Operating system. Environment, which helps software and an user to use hardware. It provides an abstraction layer which hides low-level entities of hardware, also allows software to build own abstraction layer which provides a set of entities, which could be recognized by an user.
* File system. It provides atomic element of information storage (file) and directory hierarchy to order files. File contents theoretically should abstract into its names and a restricted set of attributes. File lists theoretically should abstract into a directory name. But, in fact, abstracting principles often violated, because file names transforms into a meaningless set of letters, and a directory chosen arbitrarily. Moreover, information on directory (which theoretically should classify a file) is lost when a file is copied. File contents often is hidden by a processing application, therefore information inside file could not be reused (unless provided by the processing application).
* Applications. They are abstract layer between operating system and an user. Provide determinated set of actions for predefined user reactions. Encode original meaning (how an user sees a domain) as abstractions (by architects, then by developers), to decode eventually these abstractions into meaning, which could be understood by an user in UI. Naturally, in many cases, meaning becomes distorted just because passed through several transformations.
* Graphical interface. Its advantages come not only from the fact a human absorbs visual information better (a human mind processes space abstractions quicker than logic or language ones, possibly the very abstracting originates namely in visual perception). But it also represents and restrict information (eg, you see all commands at once, but not recall them; possible values are represented as a list, etc), and links it (one element correspond to another elements, like in the case when there is a linke between some objects and actions, provided by a menu). However, big amount of elements makes us again to use natural language (with manuals, instructions, etc). Moreover, some elements needed to be hidden with ordering them into hierarchies (menu, trees, nested dialogs, etc). This restricts context (which is better for understanding a separate area, but many nested levels hide application features, which results in these features are rarely used and difficult to be found. At last, one more problem is GUI elements and data are linked implicitly (for an user), which disallows to reuse such interface (ie, to refer to GUI elements). Graphical interface, even though considered better than text one, is always supported by natural language. The root of the problem is the fact visual elements are not always could be easily understood, but humans learn natural language during many years. You should notice that icons do not differ from letters (which are icons too), but when composing of complex actions is required, this could be done easier either with natural language (eg, as an instruction), or with abstract language of scripting, but not using graphical interface. In general, though GUI is very efficient, it could not represent any information (eg, sound or complex abstraction), therefore only symbol interface could be universal.
* Internet. Its benefits come from the indivisible joint of two unions: of computers into global net and of information inside hypertext (which represents a container with text and other medias). Both factors taken separately could not make a revolution: you can just realize Internet without hypertext (with only ftp) or you can imagine existence of only some advanced format, which allows links texts, but only at your hard drive. Naturally, one comes from another, and appearance of global net led to appearance of all Internet technologies.
* Hypertext, Web, Web 2.0, domain system. In own turn, they represent a symbiosis of following factors: resource linking, data formatting, and resource dynamics (both client with JavaScript, plugins, and server with forms, GUI elements). Later, formatting and dynamics were considered more attentively, than linking. Therefore, many still miss its shortcomings: hypertext linking allows a link only one-to-one, which makes sense, when you refer to an unique resource or to a part of the whole (like inside boundaries of one site). But if we refer to arbitrary resource of arbitrary site (eg, to news which duplicated at many other resources), then such reference is restricted and subjective. Web 2.0 advances dynamics of resources, adding more features for client side (but here we again face shortcomings of GUI in general). Domain system is an analogue of Internet "file system", where domain and its components theoretically should identify an information provider and meaning. Practically, domain names often misused (intentionally or not) like file names, which encourages corruption around domain names.
* Personal pages, email, chat, instant messaging, blogs, microblogs, social networks, commenting, collaboration sites. Internet became a trigger for information accumulating. In pre-Internent time, personal information usually distributed only as a curriculum vitae. After we see again symbiosis of two factors: information publishing and distributing. "Personal page" was the first buzzword. Blogs make personal pages obsolete, because they provide almost the same features with less efforts for design and support, adding embedded ability of message exchanging (which could be saved and which exposed globally). Microblogs is simplified development of the same tendency. Additionally, today many sites provide commenting, which for many visitors is a sort of microblogs (because their comments often could drift away of the a site topic). The same concerns social networks. Collaboration sites (unlike social networks of subjective information exchange) deal with objective information (where a role of person ideally should be minimal). Though having many shortcomings, Wikipedia became de-facto a standard of reference on different subjects.
* Portals, search engines. Initiallly, portals considered as a solution for ordering Internet. But they have certain shortcomings: (a) any hierarchy is partially subjective, therefore it is not always evident where concerned subject is located inside it, (b) any hierarchy though orders information with branching but also hides information this way, (c) they used manual update of references, though many portals could be updated by everyone, which makes them similar to collaboration sites. Though portals have also searching, but standalone search engines eventually made portals obsolete. Search line (like command line of OS) is the entry point for any information in Internet, with constant updating. Of course, search engines as any artificial thing made by humans have own shortcomings. The main one is their benefit too: representing of all information in Internet as one big "flat" database. We can consider the world in similar way, then continents, cities, humans, animals could be represented as "flat" database of atoms. Naturally, such representation is partially absurd (because it matters which structures formed by atoms). Creators of search engines understand this quite well, therefore they provide additional tools: relevancy/ranking of words/queries, collaboration tools to increase relevancy, etc. Search engine has the best result only when a word or a group of words completely corresponds to a meaning behind them.
* XML, Semantic Web. The idea of linking everything and representing in one universal format was the base of HTML, looking further, but even of SGML (though if look even more further, this idea was discussed by many thinkers many centuries ago). XML came to the solution closer, because it had the consensus on universal format. But it missed meaning. Semantic Web is going to add meaning (and is a potential candidate for new revolution) but it has certain shortcomings. The main is it is oriented for processing by automated agents, not by ordinary users. And this processing concerns mainly data, which already ordered. Moreover, there are doubts if ubiquitous usage of "subject-predicate-object" triple is expedient for abstracting everything with it. Of course, there is no doubts you could represent everything with this format, but is it expedient? This triple is similar to natural language constructs, where such triples symbolizes dualism of space-time and the fact, that any action occurs between two things. But triple is not obligatory in natural language (object could be missed), and it is complemented with adverbial modifiers, etc. Of course, adverbial modifiers could be represented as triples too, but it could be expedient only if subject, predicate, and object are roles, but not meaning. For example, in this case, verb-action and verb-relation could have a role of predicate, both noun and adjective could have a role of an object (but an adjective rarely is an object, but usually is an attribute of an object). Favorite example of Semantic Web: "sky is blue", where subject is "sky", predicate is "has color", and object is "blue". We see there is no action by meaning, but only relation (or attribute). Given example shows that original dualism of space-time (like in "I go") represented in an abstract form, where a predicate and an object are only roles (that is, abstractions isolated from reality). Moreover, evident shortcoming of obligatory ternary representation is the most of data is organized as N-ary (this is especially evident in computer world, where data could be linked by many arbitrary references, but it is true for natural language too). Ontologies of Semantic Web introduces new level of complexity and are the continuation of data formats and XML schemas, which allow to represent metadata. In general, we see that Semantic Web (at least, now) is oriented of experts, which restricts collaboration on the base of it. There is no doubts that Semantic Web is useful for certain tasks, but as any tool it is restricted which is even fixed in its specification which states that "Much of this meaning will be inaccessible to machine processing and is mentioned here only to emphasize that the formal semantics described in this document is not intended to provide a full analysis of 'meaning' in this broad sense; that would be a large research topic." [RDF Semantics, Patrick Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210]

IDENTIFYING, ABSTRACTING, MEANING (SINE QUA NON)

Thus, a work with computer is the work with abstractions, which expressed with abstract, graphical, and natural languages, formats, protocols, representations. Which, in own turn, are sets of identifiers, linked between each other with rules and relations (in particular, with separators expressed either by specific symbol or by empty identifier of boundary or linking relation). Before Internet, all revolutions were intended to build higher levels of abstractions over hardware and machine code. The highest peak of it is graphical interace (which theoretically should be closer to an user). Internet revolution gave linking between computers and of information inside hypertexts. All other innovations are either consequences of these causes (social networks as one more way for communicating), or shortcomings of original standards (as dynamics of hypertext), or ways for overcoming of certain problems (search engines and Semantic Web). In general, we see that each step related to three main aspects: identifying, abstracting, and meaning.

* Identifying
Identifying problem is ideally solved in programming. No surprise, because this is condition sine qua non of the process (because everything should be identified to be reused later). For the rest of the world, identifying problem is still actual (though this problem exists in programming too, when we need identifying of objects which is not included into an application directly). Text interface made identifying more difficult by introducing thousands of abbreviations to be remembered or to be found. Graphical interface alleviated the problem by showing some identifiers explicitly, but which are not available for reusage anyway (for example, to refer to some GUI element or change its state). File system introduces one more level of identifying, because it is necessary to remember file names and pathes. Domain system forces us to remember domain names and URLs. In general, any remembering is good memory traning, but in the result we have a big dump of million meaningless identifiers. Such situation is explainable when using identifiers of other people, but even our own identifiers lose meaning with the course of time.

* Abstracting
Abstracting problem is more or less solved in programming. No surprise, because it is sufficient condition of the process (because programming constantly deals with abstractions which corresponds to other abstractions or real world objects). There is small problem: when passed through several stages of abstracting (eg, "user-architect-developer-user" chain) abstraction does not always correspond to original abstraction. Discarded information either implied (by architect, developer, etc) or just ignored. The problem looks different outside of programming world: there is abstracting is absent at all. Why? Mainly, because there is no formal algorithm of abstracting. However, abstracting is available partially with identifying (contents corresponds to an identifier, which abstracts; it is especially evident when identifier uses natural language). No surprise here, because identifying is "ideal" abstracting, when similarity of a source and a result of abstracting is full.

* Meaning
Meaning problem is partially solved in programming. What is meaning? The simplest definition is: a set of identifiers are similar by meaning, if corresponding objects, actions, and relations are similar too. For example, a set of identifiers could include: (1) a picture of reality where grass is green and the sun is shining, (2) a prose about this part of reality, (3) just "grass is green, the sun is shining" sentence, (4) "spring comes, plants revived, warm and dry again" sentence. Of course, there is no full equivalency between these sets, because (1) is the result of camera abstracting (or by a human eye), (2), (3), and (4) are results of a human mind abstracting, and (3), (4) could be an abstraction of (2). Full identical abstracting of various abstracting tools (human mind, eye, camera, etc) is achievable only in ideal conditions. Therefore, we should set boundaries, inside of which such sets considered as similar. In our case, meaning is abstracted in objects of grass and sun, which are green and shining correspondingly (actions, relations). Abstracting allows us to ignore that the grass is not fully green, and the sun is not shining always. Such restrictions allow eventually considering sets as similar. In programming, each object of real world corresponds to either a variable, or an object, or a set of objects, etc. What is missed in programming is: (a) classification of meaning elements (objects, actions, relations, etc), (b) linking with real world objects. The same concerns Semantic Web, which tries to order information with new standards, but does not solve neither the problem of classification (though tries with ontologies, etc), nor the problem of linking with real world (though tries with URI/URN).

It is necessary to underline that identifying, abstracting and meaning problems are resolved in natural language. It refers to things, actions, and conceptions with simple (words) and complex identifiers (sentences, paragraphs, texts). A reference could concrete (the simplest case when we have 1:1 relation, eg "Everest") and abstract (when we have N:M relation, eg "favorite activity"). However, all identifiers balanced (with the help of abstracting) between concrete and abstract, thus, "Everest" could refer to an organization or a metaphor of big achievement, and "favorite activity", already pronounced by a person and linked with his or her favorite activity, becomes more concrete. Meaning, in this case, is what we referred to.

CHALLENGES OF THE PRESENT

These three aspects are conditions sine qua non of solving of big volumes of information. Identifying allows to accelerate sorting, abstracting decreases volume of needed sorting, whereas meaning can make sorting more precise. But except of that, we have many other challenges, which needed to be solved too (some of them were already mentioned above):

* Numerous computer identifiers (file and directory names, site and domain names, long instructions for opening GUI elements) which impossible to remember.
* Computer identifiers is not natural (words of natural language often represented as not recognizable abbreviations, separators are either missed or replaced by other separators) and difficult to remember (URL). For example, equalsIgnoreCase is used for comparing equality ingoring letter case, it is equivalent to "equals ingoring case" in natural language, or to computer identifier "equals(boolean ignoreCase)". As we see, computer identifiers changed mainly because of ignoring separators of natural language (which is used for other purposes), and because a part of meaning becomes statis not dynamic (as a parameter).
* Usual identifiers (eg, of natural language) used for GUI elements, but are unseparable from these elements (ie, unavailable for reuse).
* Elements of interface, file, document, application and site are unseparable from each other, which makes reuse more difficult.
* Contents and a list of contents of an archive or a file is hidden by managing application (therefore, sometimes it is impossible understand what is inside of file without opening it).
* Hypertext fixedly integrates information, which leads to "content hell", which means (a) not clear boundary between content and non-content, (b) content is only sequences of symbols/words, but not meaning, (c) subjective and objective are mixed, etc.
* Hypertext link refers a word (abstract) to a resource (concrete)
* It is impossible to create and classify information without mediator between information and an user (eg, to create a note, which relates to some aspect of a project, you should either to create a separate document or to use a separate application for creating notes)
* It is impossible to markup information with identifiers or meaning, without intrusion into file contents or application
* It is impossible to use jointly classification of files (eg, an author classifies a file as "document of project A" and this classification automatically available for everyone), use jointly information without mediator (eg, to transfer files to a friend, you should use either email application, or browser, etc), to request information without mediator (eg, to ask some project document without asking this in message exchange, searching the documents, and explicit transferring).
* There is almost no possiblity to save "snapshots" of information, which you worked with (eg, the last query to a database or a site) and be able to update it later.
* It is impossible to receive precise answer for search (instead, you receive millions references)
* It is almost impossible to guide application by goals (though we represent them when working), but only by instructions (eg, instead of setting "send documents to Mr. N" as a goal, we should divide our goal into separate commands, which includes selection of documents, searching for Mr. N in address book, and sending with the help of some application)
* Some actions should be done manually (eg, to change files after installation, or change some options) only because there is no method of information identification inside containers and for GUI elements, but methods of identification inside programming interface is too difficult (therefore not implemented)
* It is almost no time relations (possibility, necessity, etc) but they often implied
* There is principal restriction of any graphical interface. It is better suited for conditions, when a human could remember the whole set of necessary action to automatically reproduce it later. Unfortunately, it badly represents complex actions, because a human "optimized" for graphical system of natural language and it is difficult for him or her to remember all details of graphical systems, provided by applications and operating systems. To build simple GUI is possible for simple tasks (it is the good example that everything should be simple but not simpler than necessary), many interfaces intentionally simplified to achieve esthetical effect but deteriorating their possibilities.
* Problems of unordered interface or content shifted to an user ("read the manual" or "search in Internet"), which partially relates to the problem of any hierarchy (by filtering it hides a part of information), eg, to look for information in several levels of menu and dialogs or in several levels of site map is the task which requires not so much skills as time, but sometimes even just luck.
* Associations (keywords, tags, etc) often replace abtractions (reduced or generalized information). Though, in general, information can have many associations, but only one abstraction.
* Applications are determinated and could not work with unforeseen situations.
* While there is no filtering, which could restrict a searching area.
* Abstracting during application or content development usually implies or ignores a part of meaning, which leads to not corresponding of desirable and real.
* Semantic Web proposes to use URI for identifying any objects, but there is no way to separate identifiers of real world objects from ones of http objects.
* Semantic Web proposes to define semantics as ontologies, without linking ontologies between each other.
* Already created taxonomies and ontologies use numerous relations for defining own elements, which makes difficult their usage (and often could be understood only by semantics experts). But any definition is only one of answers for the question "what is x?", identifying of an object is more important (which could be done by a human which is domain not semantics expert).
* This is paradox but computer world is not ready to recognize natural language, ie even if such recognition would work tomorrow, then recognition of separate words could accelerate information input, but not revolutionize a work with computer. There is no general scheme how to link natural language phrases to GUI, therefore contemporary applications are not ready to work even with simple phrases. Meaning recognition is even impossible, because there is no general understand what it is.

SOLUTION

What approach could confront all these challenges? Today, there is a lot of partial solutions for each of them, but if general approach is possible? Ideally such approach should solve problems of image and language recognition, abstracting, storing, processing, and retrieving of information, undeterminated behavior (like intellect). Unfortunately, such ideal is unreachable technically (by these or those reasons). But could we at least be prepared for the moment when such approach starts to work? At this moment, we have no even possibility to define approximately meaning of phrases or abstraction of some information. Considering it in more general aspect, we have no abstraction level, at which we could operate only with terms which used in real life, but not with files, menus, dialogs, browsers, addresses, etc. Of course, usage of computer terms is explainable, because any domain uses own dictionary (because any new term saves time for explaining some additional meaning comparing with full explanation, eg "browser" instead "application, which allows to work in Web", etc). But if computer terms are necessary to work with information? Is it possible to make an user to be unaware about low-level computer abilities (like today we unaware about sectors of hard drive)? Should we know which button or menu allows to launch necessary function?

In general, we work with computer with following steps:
1. We have some representation on some thing or conception.
2. Transformation into computer form is transformation into identifiers of natural language (words) or into data, using application identifiers. That is, we encode information.
3. When necessary, we transform identifiers of natural language or data back into some representation. That is, we decode information.
4. When searching, we should guess which identifiers were used on encoding.

Problems:
* Each encoding and decoding changes information.
* We should guess which identifiers were used.

Possible solution is new level of abstraction which can hide computer related details. This can alleviate side effect of encoding-decoding, because information integrity will be supported at this new level, and integration violation can be easily traced, prevented, or avoided as soon as possible. This new level should be a link between usage of computer and real-world identifiers. Unfortunately, natural language could not be used fully today. But we can use its identifiers. This tendency is evident in GUI (its elements uses natural language words as labels), but it does not use own potential fully. Let's consider the whole solution in details:

* General approach: loose integration
- Minimum intrusion in status quo. We should use a form, which will obey to data (not to the contrary). Using "wrappers" for files, which will provide additional information (identifiers, abstracting, meaning) on files, this additional markup will be visible for all applications and globally (eg, information which is marked as "project document" goes to this project context at other machines too). Also such "wrapper" could be used as container, which can unite files and some other elements (like hypertext, but without formatting). It is required to have composite union of identifiers, abstracting, and meaning.
- Define new semantic protocol (possibly with usage of URN) over http, which uses computer identifiers for resources; instead of that, semantic protocol should make correspondences between information and identifiers (of natural language, of database, of URL, etc), eg, any word in html could be a semantic link which refers to multiple corresponding resources; in fact, such protocol already used verbally, maybe you have heard a phrase "type in search engine ..."?
- Information space should be "transparent" for an user, ie, information could be requested from both global and local sources (see delegation below).
- Soft concretization, ie, possibility to set not fully detailed relations, because an user has no expert knowledge and because full detailization is not always required (eg, a car engine is a car attribute or should be a subobject inside a car? instead, we can simply define that engine is inside of car, that's all), also we could not use a system of base relations for other relations (because there is no consensus if we can define them in principle).
- Possiblity to work with identifiers, linked in arbitrary graphs (as the alternative to triples, ontologies, etc of Semantib Web), which will make semantics accessible for non-experts and will be closer to natural language.

* Identifying
- Identifying of all meaning elements and translation of identifiers (eg, "plane" and "avion" should have one language-independent identifier in general case; in particular "plane" could be translate to both specific plane and plane as conception), such identifier could translate to local identifier of database for specifying vehicles, or to GUI element, which used for editing vehicles (it could allow user-defined application compatibility).
- Identification should be done preferrably on information creating (it is assumed a information creator is acquaint with related domain, and contexts are used, which can facilitate identification). Once identified, there is no need in complex calculations required for recognition (which done today by applications, whose results are not always correct).
- Identification of application elements should include not all elements, but only meaningful ones (otherwise, we can confront "identifiers hell").
- Translation of identifiers and abstractions (with similarity criteria), eg, a car model could be different in other country, with some modifications, in this case, identifier translation is impossible, therefore identifier can be only "approximately" translated into other. Opposite to keywords, tags, associations, "related" topics, such translation implies evident definition of similarity (abstracting) criteria, ie, typization.
- Translation of identifiers into resources (hypertext links, files, etc), unlike hypertext reference which links a word and a resource, such translation should link a word with an identifier(s) which would have links to resources.
- Translation of identifiers can lead to calls of actions/services/methods (with parameters), like natural language sentences (eg, "I write a letter to my friend by pen" implies a call of "write" with "a letter", "my fried", and "pen" parameters, or of "writeLetter" with two parameters, or "writeByPen"). Such translation allows (1) to refer to different identifiers, resources, depending on parameters, (2) to link actions more flexible (eg, a page can have "write a letter" identifier, without linkin with specific service or application), (3) to use identifiers for help (eg, an instruction like "go to menu, check radio button, press OK" can be represented as executable identifiers), etc.
- Translation of identifiers should be delegated implicitly of explicitly (eg, at first to an user computer, then to higher network levels: project, departament, company, city, country, globally; or to higher application levels: library, application, suite, OS, etc; or to higher context levels, ie using abstracting). Thus, (1) translation is done at the level which able to do this, (2) translation can provide different understanding from various levels, (3) server networks could be used for specific identifier sets (eg, only of biology or sports, etc), (4) it can simplify information exchange (eg, you send "project document" identifier to your colleague, he or she try to open it, because a document is not available locally, corresponding level process a request and provides a document).

* Abstracting
- Explicit representation of abstracting results (eg, an article about production of model A of car B should be abstracted to "productin of model A or car B" phrase, which consists of "production", "model A", and "car B" identifiers, which linked into one phrase, where "model A" is a part of "car B"). Typical example of "identifier + abstraction" representation is "ID + name" pair which used in many applications, where ID is computer identifier, and name is identifier in natural language.
- Abstraction of language forms (some of them are historical or used for join different forms in a sentence), eg "sun rises" or "rising sun" could be represented with two the same identifiers, because "rising" is used only when we need to use one more verb like "rising sun shines".
- Any search should use at first abstraction (eg, if "model A" word occurs in "production of model A of car B" phrase, it is more important, than if such word occurs in an article about all products of a company, in own turn, this is more important if this word occurs in a book on cars, but only if a book not about "model A").
- Any search should abstract results, grouping them based on abstract comparing (eg, searching by "model A" should result in "problems with model A" and "shops selling model A" groups), which is done already by some search engines but not always regularly. Such grouping is similar to hierarchy, but is more arbitrary which is more natural. Similar grouping used in texts, when we group text into chapters, paragraphs, lists, etc, which underlines that meaning of such groups is different, also it allows to concentrate similar meaning in one place.
- Any search should use importance criteria, which based on the way of information abstracting and filtering (contemporary GUI uses sorting and filtering for this purpose; bold text is another example of importance usage).

* Meaning
- Semantics should be explicit and compatible for different applications (which is supported by identifier compatibility and translation). Information can be ordered into structures like lists, tables, graphs, hierarchies. It can use different relations 1:1, 1:N, M:1, M:N (which corresponds to different structures). It can use objects, actions, and relations (space ones, time ones, possibility, planning, goals, etc), which used in natural language, but not always explicitly in computer world.
- Association of information with attributes, categories, etc (today it is done with tags and keywords) should be replaced by linking with identifiers which behind curtains could be linked with other identifiers (eg, if you link a picture with "vacation" identifier, you should not link it with "rest" identifier, because it will be done implicitly). Such link implies only itself (eg, "vacation picture" relates only to vacation pictures, but to documents which mention vacation and/or pictures).
- Any identifier is the result of abstracting, an abstract identifier uses similarity and usually corresponds to a type (eg, "car" relates to multiple things), a concrete one uses identity and usually corresponds to a variable or a value (eg, "my machine" is an unique identifier). That is, unlike in programming, there is no strict boundary between a type and a variable, we can consider only a balance between abstract and concrete (usually, the more identifiers used the more conrete is contents).
- Any exception should use either additional identifiers ("car but with two wheels"), or more abstract identifier ("this is not car, but just transportation"). Such additional definitions and even redefinitions express a balance between determined and possible, which could occur to any information.
- Any thing is static and dynamic simultaneously, only abstraction can change a balance to one of two sides. This could be explicitly defined for any identifier (eg, "model A prices" could be a request to dealer site, which returns current prices, or a fixed data, which were received in some moment of time; both forms could be linked between each other, to update information or receive notifications on updates; for documents such dualism could be expressed in a composite form, which developed through time, and versions, which fix "snapshots" of a document; version should be one of base property of "wrapper" described above).
- Any information is both subjective and objective. Objective character is a criterion of bigger abstracting (ie, the more subjective consensus, the more objectivity; even more precise criterion of objectivity is verifiability, but it can't be applied always, especially to information which relates to not precise areas or pure abstractions). A subject (a person or a site) considers own opinion as "objective", therefore it is important not only to separate objective and subjective (eg, an article and comments), but also to indicate who's author of opinion (then objective information could be classified as subjective, when it goes out of boundaries of a subject).
- Any information can be atomic (eg, separation by files) or closed (eg, all necessary values are available inside an application or a site), but also consistent with other information. More important, that information should be ready to break own links, when going outside of closed system, and be ready to be a part of the whole and acquire links when being a part of other closed system.

* Interface
- Any interface is an abstraction which hides implementation (actions, data, etc). Therefore, everything said about abstraction could be applied to it too. It is necessary to use mixed approach, which will unite advantages of both text and graphical interfaces, and will add something new, which will unite advantages of hierarchies (like in GUI and portals) and one entry point (like in command line and search engines).
- Identification is one of the most imporant element of interface, which should provide identifiers not globally (eg, contemporary search engines provides all identifiers availalbe), but restricted with contexts. Context for information filtering, which defined by a set of identifiers, will restrict information visibility (eg, graphical context will show only graphical applications and files). Similar restrictions now done by file types, and by applications and sites themselves, which implicitly restricts visibility. Contexts should replace contemporary desktop, providing multiple entry points to a system. Contexts should be provide ability to increase/decrease visibility, to intersect them, etc.
- Information should be available with meaningful identifiers (eg, instead of 124.sub file, information should be vislble as "subtitles of movie A", where "subtitles" and "movie A" are separate identifiers, which could be reused for further searching/filtering).
- Application elements should be linked in one entity (files, settings, etc). This would facilitate recognition of file application ownership and manipulating with application (eg, saving settings to move them to another computer).
- Access to interface with meaningful identifiers (eg, access to "car model" field could be done with "car model" identifier, which could be reused; you could save a form of all car fields, fill it outside of an aplication, and then load it when an application will be available; we can create "shortcuts" for some dialogs are used multiple times with the same values, such "shortcuts" are similar to "macros", but they will be available in all applications; also, this could help with remote and virtual machines, when operating with GUI will be operating with identifiers, which is quicker in such cases).
- Options/parameters should be linked with functionality (eg, on activation of this function, we can see which options affect it).
- Any interface element can be represented in following aspects: (1) declarative (identifiers), (2) imperative (related to actions or changes), (3) referring, (4) interrogative. These aspects can help how given element can (1) be used and reused, (2) change and be changed, (3) linked with other elements, (4) can be linked with other elements (necessary when information is incomplete).
- A sort of command line (but not for OS, but for applications and sites) with meaning restrictions, hints, linking, etc. (eg, if a product list can be defined only after an order created, then on typing of "add product", such command line should show that an action is possible only when an order is defined, therefore it should propose either "add to order" or "create order"). Possibility to operate with interface not only with fixed forms (like in contemporary GUI) but also with dynamic forms (an action is represented as an identifire with relating parameters as placeholders, which marked as necessary or not, restricted with visibility, etc).
- Context filtering can be a security tool, restricting application visibility and declaring what is could be affected by an application (which is simpler than when it is done by users, because application visibility declared once by an application creator).
- Possibility to manipulate with non-linear text (which additionally to linear text, has references to other information). Non-linear text is a further development of hypertext idea (which has no simple way to create text, add links or comments, without formatting). Such task could be done today with text editors, but they do not use identifiers, relations, etc.

EXAMPLES

Thus, how this will work together? Of course, not only identification, abstracting, and meaning which matter, but also interface, which facilitate the solution.

Example 1. Pictures from vacation

1. Open picture context (where only graphical applications and picture files available).
2. Load pictures from camera. Classification inside this context is proposed on load. You type "vacation", but you already have "vacation 2009 seashore" identifier, therefore new identifier is proposed (because file attributes belong to 2010 year, and geotags is far away from seashore), proposed name is "vacation 2010 Paris" (because you use only year for specifying time, and geotags are abstracted into the largest geographical entity, ie into Paris, if you have more geotags for Versailles, then they are abstracted into Ile-de-France). Further classification could use "I" and "wife" identifiers (which means specific persons at this computer), "best" (which applied only for certain pcitures).
3. Classification is ready. "Best pcitures from Paris" now imply only best pictures, not all documents which has these words. "me at pictures" returns all my pictures, including pictures from Paris.
4. You need to send best pictures from Paris to your friend. For that you need just apply "send" to "best pictures from Paris", also you may (or may not) choose a type of transfer. Further actions depends on different factors: (a) if your friend is available, then he or she should confirm transferring (if it is not always allowed), your computers establish available connection (email, http, ftp, IM, p2p, etc) and copy pictures. (b) if you friend is not available, then he or she is just notified about transfer, which should be confirmed, your computer receives confirmation when your computer is turned on, after that files transferred to some relaying server, and when your friend will turn on computer again, relaying server will copy files. After that, files available in the same context (which you defined) at your friend computer (though it could be changed).

How it differs from today situation? (1) Identifiers mean what they should mean, seashore is not just word but can include coordinates, "Paris" is France capital, 2009 is not just a number but an year (because you defined it). (2) Identifiers available not only for the application which created them (like EXIF information), but globally (including file transferring). (3) You haven't to know where pictures stored at your hard drive, usage of contexts, classifying, and abstracting guarantee you can find them (file libraries are restricted, because they are only a list of files without identifying and meaning, which means they could not be created automatically). (4) You work with computer with goals (send), not with instructrions (open application, find pictures, attach them, send). (5) Identifiers translated into each other, therefore "I" means you for you, and it would "my friend" for your friend, therefore you can use different identifiers for the same person. (6) Identifiers are abstracted, therefore "Louvre" is inside "Paris", which can be calculated (not necessary at your machine, which could not have all facts).

Example 2. Screen locking
You want to disable screen locking. Today, you have to find an answer in Internet and modify registry. Could such task be simplified? It is also interesting what percentage of users know screen can be locked manually? How many know it could be done with keyboard shortcut? How many know this locking can be disabled? And why such knowledge is not available for all?

Usage of locking can be described by following items: (1) locking is necessary to prevent access to computer, when an user is absent, (2) locking is turned on after inactivity period, (3) locking can be turned on manually, (4) locking can be used to set not available status in IM. To describe such facts in meaningful way we need necessary relations: (a) goal (to prevent access..., to set status....), (b) possibility (can be turned on manually or after inactivity period; or disabled at all), (c) cause-result (turned on after inactivity period), (d) after (in this case "after" coincides with "cause-result", but generally "after" does not mean "because of").

Why an user does not know screen can be locked manually? Screen locking dialog should notify about it. The same concerns keyboard shortcut. Goal relation can be used in security notification, to inform that screen can be locked to prevent access. Also IM can inform about relation with screen locking. Possibility relation can be used when locking was turned on automatically, but an user should be also informed about ability to turn on manually and about disabling. Cause-result relation can be used after inactivity period, which did not result in locking, to inform such locking is possible. All listed cases do not mean additional implementation, but only linkage between GUI elements and meaning.

The situation with disabling is a little more difficult: manual modifying of registry does not warn that screen locking disabling is not quite secure. But how an user can use such ability even ignoring warnings? Today, he or she has to follow instructions or modify registry manually, or launch .reg file (which without understanding the contents is unsafe operation), or to use some utility (but which should be installed, and where you need to find concerned item in dump of settings and menus). But there is an alternative way: for example, OS could provide a service with "add registry key", "change value" identifiers, etc. "Wrapper" which links disabling/enabling of screen locking with such identifiers should be loaded to some certified site. You can find it directly from screen locking dialog, because here context is restricted with screen locking. Also, you should link "disable" namely with "screen locking", which prevents from finding pages, which have "screen locking", but "disable" relates to control panel.

Comparing with the current situation, we significantly decrease time, required for developers to implement some features, which are not included into regular utilities, and which does not require complex design and implementation.

Example 3. Orders
You work with orders (which have some identifiers inside registring application, which unfortunately has no web access). During work you need to discuss orders with colleagues, and sometimes with clients. In communication, you usually refer to identifier of an order, or copy-paste its contents, etc.

Similar routine can be and should be improved with the help of more flexible operations with identifiers and order forms. Order identifier should be available for reference which means: (1) you can directly access an order data (ie, referring to an identifier can open corresponding application, and follow to informatin which corresponds to an identifier), (2) you can receive data "snapshot" for an order and store it locally (though data is outdated, but you know "version" or date of fixing), which could be updated when necessary, (3) an order components are available for referring, ie, you can add back-references and markup which entities refer to an order (eg, discussion of availability of products, included into an order, can refer to this order), (4) if an order has not some field/attribute in the system (eg, you need own classification by custom attribute), you can create your own, referring to orders by an identifier (which will guarantee data integrity).

You can notice that similar tasks can be solved with programming even now. But they require addtional effort, resources, and time. Identification, support of static and dynamic forms, and other features can make them a routine with additional effort at user-side.

Example 4. Application
You develop an application which sums numbers.

1. An user sets the task in simple phrase: "sum numbers" (which consists of two separable identifiers).
2. An architect specify the task more precisely: numbers are restricted with two 2-byte integers, which is input, sum operation process them, and there is one 2-byte integer as output. An user can check that such model corresponds to his or her expectations (that is, checks for correspondence between "number" and "integer", etc).
3. A developer builds an user interface and links "integer" identifiers with two text fields, and "sum" with "+" button, and "result" with the third text field (also he or she links identifiers with code). An architect can check correspondence with own model, and an user with own understanding.

Of course, this is simplified example, but which shows that semantic links are not broken, meaning integrity is supported when information transferred between different persons, in the case of problem you can check correspondence, an user comments can be instantly available in corresponding places of model, specification, code and interface.

Example 5. Discussion
Everyone are familiar with the situation when a dicussion accumulates details, quotes, sub-topics, sometimes generates parallel topics. Management of such discussions is quite difficult. How proposed solution can cope with it?

Let's consider an example with orders:
- What's happened with order #12345? (this question refers to indicated order, possibly, an order linked with this discussion too; as soon as discussion starts we can automatically switch to this order context)
- I've talked with Mr. N and see no problem (this answer refers to discussion with Mr. N)
- Well, what with #12346? (this question refers to different order; so context can switch automatically to other order context, which even hide previous questions as unrelated)
- I will request company C (this answer at once can have linked TODO note, or unfilled request, which will launch corresponding application and will process it)
- I've looked at your discussion with Mr. N and see we have problems (this statement can refere to a part of the discussion with Mr. N where problems found)
- You know him, he asks for impossible, but after rolls back everything, if explained. Do you need a reference to his whims of the past?
- No, thanks, this cannot be attached to an order. Which means, discuss with him again, prove him everything needed.
- Yep. Have you seen pictures of the last corporate event?
- No, not yet.
...

As we see we can refer to everything: (1) questions-answers inside this discussion (this is evident and made in almost all communication applications), (2) other discussion (this is done in email, but usually absent in other communicating or available with web reference), (3) data inside applications (available today only with web-access, which should be created), (4) from data inside applications, (5) application interface. The very discussion flows from one subtopic to another, but parts of discussion remain linked with specific contexts, therefore context of order #12345 include two parts of discussion (in the beginning and in the middle). Subjective opinion on Mr. N is not included into an order context (but theoretically, a company can have context of clients to be available for new employees or which worked with other clients). Today, all such references are present in discussion too, but not available for reuse.

Example 6. Search
There is one example of Semantic Web critics (which given to show Semantic Web cannot cope with such query): "Is the Pope Catholic?" (question is rhetoric, but taken literally the only answer is "yes")

Proposed solution on typing "Is the Pope Catholic?" can solve this way:
a. "Pope" can be identified as either the Catholic Pope or a part of name (eg, Alexander Pope) or other meanings.
b. Adding of "catholic" already could resolve the ambiguity and concentrate on the first meaning. Though it could happen even automatically, being in context of church or theology, etc.
c. Further, a link between "Pope" and "Catholic" should be found (by delegating this query), which should return "yes".

Contemporary search engines on "pope" query dump pages with possible definitions of the word (but which are unorderd and duplicates themselves several times), "pope catholic" naturally gives pages on the Catholic Pope, but slightly different "church pope" gives "Lake Tahoe's Santa Claus slams Catholic Church..." as the fourth result, "pope catholic rome" gives "The World Seen From Rome" as the fourth result. Of course, "is the pope catholic" gives exact matches for pages on this phrase though not answers to the question. Which proves that contemporary search engines give correct answers only when natural language identifiers coincide with meaning. A little different query and results are already far from correct, which shows that identification of words and relation identification is required.

Example 7. Semantics
This example is considered in Semantic Web OWL specification): wine agent. This example shows how Semantic Web works, when choosing wines and meals.

What do we need if using the proposed solution? We can use already available information and markup it with identifiers, recognizing specific wine or meal. We don't need to specify full set of relations. It could be done by applications or specialized sites, which would return delegated answers for wine details or matching with meal.

Semantic Web makes the task more complext (no surprise, because it is assumed it would be solved by experts). For that, we need to define ontology, which will be used by a reasoner. In the process, ontology:
- uses computer identifiers like "pasta-with-spicy-sauce", which meaningless for natural language and make reuse of its parts impossible (unless parsed);
- uses fixed hierarchy, which assumes, for example, that "wine" is "potted liquid", but wine could classified in hundreds ways ;
- defines which fields and restrictions wine should have (which is good, because it does the same what GUI does when disallow input of meaningless values); however, a field set is determined and concrete, though, in particular cases, fields can be undetermined and abstract;
- queries to reasoner do not look as easily recognizable by a human;
- etc.

That is, in general, Semantic Web has similar shortcomings as contemporary applications have.

CONCLUSION

What we have in result? This is a sort of a compromise between areas of "ordinary user" and areas which usually belongs to experts only (they were just unavailable for users, and detached from reality for professionals). Could such compromise cope with information garbage? At least, identification, abstracting, and meaning can alleviate sorting significantly. Quite naturally, we can confront with another problem of huge number of references. But this problem of not sorting, but rather of performance. This requires possible different approaches to computer architecture, a sort of cloud-computers (do not confuse with cloud-calculations). Could proposed solution be implemented? In particular, similar approaches are implemented long ago. But also we need global consensus on semantic protocol and globally available identifiers. Is it possible? Hopefully yes, because proposed approach can save efforts, time, and resources both globally and locally.

Идентификация, абстрагирование, смысл

ABSTRACT

Рост объемов информации стала одной из главнейших проблем современного компьютерного мира. Данная статья рассматривает то, как мы пришли к подобной ситуации, а также предлагает решение. Ключевая особенность решения: решить проблему идентификации, абстрагирования и семантики информации. Решение предполагает создание нового слоя абстракции над уровнем пользователя и семантического протокола над гипертекстовым. Что в итоге спрячет всю компьютерно-зависимую информацию (имена файлов, меню, диалоги, URL), а новый слой будет абстрагировать эту информацию в идентификаторы (слова естественного языка, числа, символы, и т.п.), понятные человеку. Данный подход необходим, так как пользователь должен искать информацию, а не файлы, вызывать нужные функции приложения, а не путаться в меню и диалогах, использовать слова и предложения, а не URL.

ВВЕДЕНИЕ

Интернет - это большая свалка информации. Впрочем, не без попыток отсортировать и упорядочить. Но даже самые успешные сортироворочные машины на простейшие запросы вываливают на вас миллион ссылок (что, по видимому, должно считаться символом успешности сортировки, как если бы вы попали в библиотеку, а вам сказали: "да, у нас есть миллион книжек на эту тему, поищите там..."). Что ж, приходится полагаться на собственные умения и досортировывать то, что уже предложено. Вполне естественно, что обычно мы ограничиваемся сортировкой десятка, максимум, сотни ссылок, если ничего не находим - поиск можно считать провалившимся. Конечно, сортировочные машины проделывают огромную работу: по расчетам, на данный момент, в Интернете существует около 1 триллиона (10 в 12 степени) уникальных страниц, запросы на общие слова обычно дают около сотни миллионов страниц (10 в 8 степени), на менее общие мы уже получаем десятки миллионов, и так далее. Но ведь, в реальной жизни, поиск должен давать от десятка-сотни до одной ссылки. Например, на запрос "чемпион мира по футболу 2010 года" существует ровно один ответ, на запрос "кошки", наверное, все же ожидается ответ с сайтами и страницами, посвященным только им, а не все ссылки, где они так или иначе упоминаются. Поэтому неудивительно, что современные поисковики пытаются угадать то, что вам нужно, предложить лучшую фильтрацию, полагаются на человеческую досортировку, логично полагая, что уж люди лучше разберутся в информационном хламе.

Иная ситуация с персональным компьютером. Он содержит от сотни тысяч до нескольких миллионов файлов, однако в отличие от Интернета, где мы не можем предугадать, где нужно искать контент, поиск по локальным файлам можно легко ограничить: по крайней мере, недавно написанное письмо не стоит искать среди приложений, к тому же, если для чужих файлов идентификация информации просто бессмысленна, т.к. нет гарантии, что мы ими воспользуемся вновь, то идентификация для собственных файлов более уместна, т.к. они требуются чаще, а значит точная идентификация найдет их быстрее, чем повторяющийся полный поиск. Но, если уж предоставлять идентификацию, то нужно задуматься и об абстрагировании, которая представляет собой примерную идентификацию (то есть сравнение по схожести), а также о семантике (то есть, об отношениях между похожей информацией). А если это всё будет работать локально, то необходим и единый механизм идентификации, чтобы можно было совместно пользоваться уже отклассифицированной информацией. К сожалению, современные компьютеры не предоставляют таких возможностей.

А ведь вначале о подобных проблемах никто и не думал. Первые компьютеры были весьма неудобны в использовании (относительно современных, конечно), поэтому информация накапливалась очень медленно. Но, к счастью или сожалению, прогресс не стоял на месте. Появился текстовый интерфейс, операционные системы, высокоуровневые языки программирования, форматы данных, графический интерфейс, Интернет, наконец. Каждое из последующих нововведений (не считая прогресса аппаратного обеспечения) облегчало ввод и обработку информации, что вело к росту ее объемов и затрудняло поиск. С появлением Интернета ситуация еще больше усугубилась: покуда компьютеры не были связаны в единую сеть не каждый находил удовольствие в выплескивании своих мыслей и эмоций на жесткий диск, но появление тысяч и даже миллионов благодарных (а пусть даже и неблагодарных) читателей, стало спусковым крючком для экспоненциального роста информации.

Можно ли решить проблему больших объемов информации? Сейчас существует много технологий, направленных на укрощение объемов информации: это и коллаборация, и разного рода социальные сети, и Семантический Веб, а также виртуальная реальность, дополненная реальность, 3-мерный интерфейс, распознавание образов и языка. Некоторые из них еще недостаточно развиты, другие же весьма эффектны эстетически, но не так полезны практически. Но, к сожалению, пока ни одна из них не предложила устраивающего всех решения. А можно ли вообще понять, что хотя бы теоретически могло бы решить эту проблему? Для начала можно посмотреть на революции прошлого и попробовать понять, почему то или иное изобретение оказалось прорывом.

РЕВОЛЮЦИИ ПРОШЛОГО

* Текстовый (консольный) интерфейс. Возник, т.к. человеку было необходимо общаться с компьютером на понятном языке. Для подобного общения были неоходимы два условия: возможность идентифицировать ту или иную компьютерную сущность (например, диск или операцию копирования) и возможность абстрагирования (т.е. выражения множества действий или объектов при помощи одного идентификатора). Как побочный эффект: возможность переиспользования уже имеющихся идентификаторов. Долгое время проводились попытки использовать естественный язык для этих же целей, но они провалились не только из-за того, что анализ полного набора грамматических конструкций затруднен (хотя анализ упрощенного подмножества вполне реален), но также из-за того, что для оперирования компьютерными сущностями лучше подходит специальный язык. Ведь, любая область человеческой деятельности рано или поздно приходит либо к своему жаргону (арго), либо к специфическому абстрактному языку (как в математике), которые лучше абстрагируют объекты и действия этой области.
* Высокоуровневые языки программирования, программные интерфейсы, форматы данных. По сути, ситуация такая же как и с текстовым интерфейсом, но с большими возможностями (которые заключается в наборе дополнительных абстракций, помогающих компоновать гораздо более сложные решения). Форматы данных, по сути, являются абстрактным языком (что неявно в двоичном виде, но явно в текстовом) для упорядочивания и ограничения информации.
* Операционная система. Среда, помогающая программному обеспечению и пользователю использовать аппаратное обеспечение. По сути же, предоставляет слой абстракции, который скрывает низкоуровневые сущности аппаратного обеспечения, а также позволяет программному обеспечению выстраивать свой слой абстракции, предоставляя набор сущностей, понятных пользователю.
* Файловая система. Предоставляет атомарный элемент хранения информации (файл) и иерархию каталогов, для упорядочивания файлов. Содержимое файла, теоретически, должно абстрагироваться в его имя и атрибуты (хотя их набор ограничен). Списки файлов, опять же теоретически, должны абстрагироваться (отображаться) в имя каталога. На практике же, принципы абстрагирования часто нарушаются, так имена файлов превращаются в бессмысленный набор символов, а каталог выбирается произвольным образом. Более того, информация о каталоге (которая теоретически должна классифицировать файл) теряется при копировании файла. Содержимое файлов часто спрятано обслуживающим приложением, поэтому информация внутри файла не может переиспользоваться (если это не предусмотрено в соответствующем приложении).
* Приложения. Являются слоем абстракции между операционной системой и пользователем. Предоставляют детерминированный набор действий на предопределенные реакции пользователя. Кодируют первоначальный смысл (то, как систему видят пользователи) в виде абстракций (сначала архитекторами, а потом и разработчиками), чтобы в итоге декодировать абстракции в смысл, понятный пользователем (естественно, во многих случаях, уже хоть немного, но искаженный, т.к. смысл проходит через несколько преобразований).
* Графический интерфейс. Его преимущества связаны не только с тем, что человек лучше воспринимают информацию визуально (человек быстрее обрабатывает пространственные абстракции, чем логические или языковые, к тому же само абстрагирование возможно является порождением именно визуального восприятия информации). Не менее важно и то, что он явно предоставляет и ограничивает информацию (т.е. вы видите все команды сразу, а не вспоминаете их, а их возможные значения ограничены в списке и т.п.) и связывает ее (одному элементу соответствуют другие элементы информации или действия, например, связь между объектом и действиями, предоставляемыми в меню). Однако, при большом количестве элементов мы опять возвращаемся к необходимости использования поддержки естественного языка (в виде руководств и т.п.). К тому же, что часть элементов приходится скрывать, упорядочивая их в иерархии (меню, деревья, вложенные окна и т.п.), при этом мы ограничиваем контекст, что хорошо для понимания отдельной области, но при этом же, многие уровни вложенности так хорошо скрывают возможности приложения, что ими редко, кто пользуется, а иногда и с трудом находит. Наконец, еще одна проблема заключается в том, что элементы графического интерфейса и данные связаны неявно (для пользователя), что не позволяет переиспользовать подобный интерфейс (т.е. ссылаться на элементы GUI). При всех преимуществах, графический интерфейс всегда поддерживается натуральным языком: в корне проблемы лежит тот факт, что визуальные элементы программы не всегда интуитивно понятны, в то время как естественному языку люди обучаются в течении десятилетий. Собственно говоря, иконки ничем не отличаются от букв (которые тоже являются иконками), но при необходимости компоновки сложных действий - это проще будет сделать при помощи естественного языка (в виде инструкции), либо при помощи абстрактного языка скриптов, а не переиспользуя графический интерфейс. В целом, хотя графический интерфейс и очень эффективен, но он не может представить любую информацию (например, звук или сложную абстракцию), поэтому универсальным может быть только символьный интерфейс.
* Интернет. Его достоинства заключаются в неразрывном сплетении двух факторов: объединение компьютеров в глобальную сеть и объединение информации внутри гипертекста (который представляет собой контейнер, объединяющий текст и другие медии). Оба эти фактора по раздельности не могли совершить революцию: представьте себе Интернет, в котором нет гипертекста, а есть один ftp протокол, или же, наоборот, существует прогрессивный формат, позволяющий переходить из текста в текст, но в рамках вашего жесткого диска. Естественно, что одно вытекало из другого и появление глобальной сети послужило спусковым крючком для появления всего набора Интернет технологий.
* Гипертекст, Веб, Веб 2.0, доменная система. В свою очередь, представляет собой симбиоз трех факторов: связывания ресурсов (различных репрезентаций информации), форматирования данных и разного рода динамика ресурсов (клиентская с ДжаваСкриптом и плагинами, серверная с формами и элементами графического интерфейса). Впоследствии, серьезное внимание было уделено форматированию и динамическим возможностя, поэтому были упущены недостатки связывания. А именно, гипертекстовое связывание позволяет реализовать ссылку только один-к-одному, и наибольший смысл имеет только тогда, когда мы ссылаемся на уникальный ресурс (или оригинал) или же ссылаемся на часть общего целого (как, например, один сайт). Если же мы ссылаемся на произвольный ресурс произвольного сайта (например, новость на определенном новостном ресурсе, хотя она продублирована на множестве других), то такая ссылка становится ограниченной и субъективной. Веб 2.0 представляет собой развитие динамической составляющей ресурсов, добавляя больше возможностей графического интерфейса со стороны клиента. Доменная система является аналогом "файловой системы" Интернета, где домен и его компоненты должны (теоретически) идентифицировать провайдера информации. Практически же, домены в виде идентификаторов часто неправильно (намеренно или нет) используются (как и имена файлов), что поощряет коррупцию вокруг доменных имен.
* Персональные страницы, электронная почта, чаты, мгновенный обмен сообщениями, блоги, микроблоги, социальные сети, комментирование, коллаборейшн сайты. Интернет стал спусковым крючком для роста накопленной информации. В пре-Интернет эпоху никому и не приходило в голову создавать документ с описанием себя любимого (кроме резюме) и распространять его каким-либо способом (здесь мы тоже видим сплетение двух неразрывных факторов: публикование персональной информации и ее распространение). Вначале, модным словом стало "персональная страница", с появлением блогов необходимость в персональных страницах постепенно отпадает, так как блоги предоставляют почти те же возможности, при меньших затратах на дизайн и поддержку, к тому же сочетая в себе возможности обмена сообщениями, но с возможностью сохранения и всемирной доступности (микроблоги являются еще более упрощенным развитием той же линии). В дополнении к этому многие сайты сейчас предоставляют системы комментирования своих ресурсов, что для некоторых постоянных посетителей является эдакой разновидностью микроблога (часто комментарии постоянных посетителей могут уклоняться от темы ресурса и становиться микроблогом). Тоже самое касается и социальных сетей. Коллаборейшн сайты, в отличие от социальных систем обмена субъективной информацией, предназначены для обмена объективной информации, в идеале, роль личности должна быть сведена к нулю. При всех недостатках, Википедия стала де-факто стандартом для справки о том или ином предмете.
* Порталы, поисковые системы. Первоначально именно порталы представлялись решением, которое позволит упорядочить информацию в Интернете. Но они обладали и определенными недостатками: (а) любая иерархия знаний частично субъективна, поэтому не всегда очевидно где внутри иерархии расположен нужный предмет, (б) любая иерархия вместе с упорядочиванием, посредством разбиения на ветви, также и скрывает информацию в этих ветвях, (в) использовалось ручное обновление каталога, хотя при этом многие порталы предоставляли эту возможность любому, что роднило их с коллаборейшн сайтами. На порталах был даже поиск по содержимому портала, но появление поисковых систем нанесло серьезный удар по их позициям, так как их поисковая строка была точкой входа (кстати, подобно консоли операционной системы) для любой информации в Интернете, причем постоянно обновляемой. Разумеется, как и любое творение человека, поисковые системы имеют и свои недостатки. Главный из которых, является, одновременно их достоинством: это представление всего массива данных Интернета в виде большой "плоской" базы данных. Точно также можно представлять весь наш мир, все континенты, города, людей, животных в виде "плоской" базы данных атомов. Конечно же, такое представление частично абсурдно (т.к. имеет значение в какие структуры эти атомы собираются). И создатели поисковых систем прекрасно это понимают, предоставляя дополнительные средства, как то: релевантность/ранжирование слов/запросов, коллаборейшн средства для повышения релевантности поиска, и т.п. Поисковая система достигает максимума продуктивности только в случае, когда слово или словосочетание полностью соответствует смыслу, скрывающемуся за ним.
* XML, Семантический Веб. Идея связывания всего и представления в одном универсальном формате лежала еще в основе HTML, а если копнуть еще глубже, то и в SGML (если уж копать дальше и дальше - идея-то прорабатывалась еще философами за много столетий до того как). XML подошел к проблеме ближе, так как, по крайней мере, был достигнут консенсус по поводу универсального формата. Однако, не хватало смысла. Семантический Веб добавил немного смысла, и стал потенциальным кандидатом на новую революцию, но он обладает и определенными недостатками. Главное - это то, что он ориентирован на обработку "интеллектуальными агентами", а не простыми пользователями. И обработку, в основном, данных, причем, данных упорядоченных. К тому же, формат тройки "субъект-предикат-объект" заставляет сомневаться в целесообразности абстрагирования всего при его помощи. Никто не подвергает сомнению факт, что всё можно втиснуть в подобный формат, но будет ли являтся это целесообразным? Этот принцип аналогичен конструкциям естественного языка, где подобные тройки выступают как символ дуальности пространства-времени и выражение факта, что любое действие происходит между двумя предметами. Но, в естественном языке формат тройки не является обязательным, к тому же часто расширяется обстоятельствами. Разумеется, что и дополнения, и обстоятельства можно представить тройками тоже, но это может быть целесообразным только, когда субъект, предикат и объект - это роли, а не смысл. Например, в таком случае в роли предиката может выступать как глагол-действие, так и глагол-отношение, а в роли объекта как существительное (объект), так и прилагательное (которое редко бывает объектом, а обычно выступает атрибутом объекта). Любимый пример в Семантическом Вебе: "небо голубое", где субъектом выступает "небо", предикатом "иметь цвет", а объектом "голубое". Как мы видим, здесь не совершается никакого действия по смыслу, а выражается только отношение (или же атрибутивность). Данный пример показывает, что изначальный смысл дуальности пространства и времени (например, в "я иду"), представляется в абстрактной форме, где вся предикат и объект являются ролями (т.е. просто оторванными от реальностями абстракциями). И, конечно, очевидный недостаток в обязательности тернарного представления, хотя большинство данных организовано в Н-арном виде, в общем случае (особенно это очевидно в мире компьютеров, где данные могут быть связаны множеством произвольных ссылок, но это истинно и для естественного языка). Онтологии Семантического Веба вводят новый уровень сложности и являются логическим продолжением форматов данных и XML схем, предоставляя еще один способ представления метаданных. В целом, мы видим картину, что с Семантическим Вебом могут работать (по крайней мере, на данный момент), в основном, эксперты, что очень сужает возможности коллаборации на его основе. Разумеется, нет сомнений в полезности Семантического Веба, но как и любой инструмент он ограничен, что зафиксировано даже в его спецификации, которая утверждает, что он и не претендует на полный анализ смысла в широком смысле, что оставлено для будущих исследований. [RDF Semantics, Patrick Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210]

ИДЕНТИФИКАЦИЯ, АБСТРАГИРОВАНИЕ, СМЫСЛ (SINE QUA NON)

Итак, работа с компьютером представляет собой работу с абстракциями, которые выражаются в абстрактных, графических и естественных языках, форматах, протоколах, представлениях. Которые, в свою очередь, представляют собой набор идентификаторов, связанных между собой правилами и отношениями (в частности системой разделителей, которые выражаются либо в определенном символе, представляют собой пустой идентификатор, выражающие обычно отношение границы или связывания). Перед появлением Интернета все революции заключались в построении все более и более высоких уровней абстракции над аппаратным обеспечением и машинным кодом, высшей формой чего явился графический интерфейс (который, теоретически, должен быть ближе всего к пользователю). Интернет революция дала нам связность информации между компьютерами и связность информации внутри гипертекста. Все остальные нововведения являются либо следствиями этих причин (появление социальных сетей, как еще одна возможность общения в Интернете), либо недостатками изначальных стандартов (как, например, динамический аспект гипертекста), либо же средствами преодоления возникших проблем (как поисковые системы и Семантический Веб). В целом же, мы видим, что каждый шаг касался трех основных аспектов: идентификация, абстракция и смысл (связность).

* Идентификация
Проблема идентификации идеально решается в программировании. Что неудивительно - ведь там это необходимое условие самого процесса (т.к. всё должно быть идентифицировано, чтобы использовать его в дальнейшем). Для всего остального мира, проблема идентификации как стояла, так и стоит, как никогда остро (впрочем, проблема существует даже в программировании на месте его стыка с миром не-программирования, например, идентификации предметов, не включенных в программу напрямую). Текстовый интерфейс усугубил проблему идентификации тысячей аббревиатур, которые необходимо запомнить (или найти). Графический интерфейс облегчил проблему тем, что показывает идентификаторы явно, однако проблема его заключается в том, что эти идентификаторы не доступны для переиспользования (например, чтобы сослаться на какой-либо элемент и изменить его значение/состояние). Файловая система вводит еще один уровень сложности идентифицирования, т.к. необходимо запоминание имен файлов и путей. Доменная система заставляет запоминать имена доменов и URL-ы. В целом, конечно, любое запоминание полезно для тренировки памяти, но на выходе мы также видим свалку из миллионов бессмысленных идентификаторов. И ладно, когда чужие идентификаторы нам ничего не говорят о содержимом, так даже те идентификаторы, которые мы используем для собственных файлов, со временем тоже могут потерять смысл.

* Абстракция
Проблема абстракции более-менее решена в программировании. Что неудивительно - ведь там это достаточное условие самого процесса, а именно, программирование постоянно оперирует с абстракциями, которые соответствуют другим абстракциям или предметам реального мира. Существует, конечно, и небольшая проблема, а именно: пройдя через несколько этапов абстрагирования (например, в цепочке "пользователь-дизайнер-разработчик-пользователь") на выходе мы имеем абстракции, которым не всегда можно поставить в соответствие исходные абстракции. Отброшенная информация либо подразумевается (дизайнером, разработчиком, и т.п.), либо просто игнорируется. Для мира вне программирования проблема выглядит по-другому, т.к. здесь абстрагирование отсутствует вообще. Почему? Главным образом, потому что не существует формального алгоритма абстрагирования. Впрочем, абстрагирование частично доступно через идентификацию (ведь идентификатору соответствует содержимое, т.е. идентификатор, по сути, и является абстракцией информации, особенно это очевидно, если в роли идентификатора выступает текст на естественном языке). Что неудивительно, так как идентификация - это как бы "идеальное" абстрагирование, когда похожесть источника и результата абстрагирования является полной.

* Смысл
Проблема смысла лучше всего решается в программировании. Что такое смысл? Простейшее определение может звучать так: комплекс идентификаторов сходны по смыслу, если стоящие за ними объекты, действия, отношения тоже сходны. Например, комплекс идентификаторов может включать: (1) фотографию части реальности, где травка зеленеет и солнышко блестит, (2) сочинение, описывающее эту часть реальности, (3) предложение "травка зеленеет, солнышко блестит", (4) предложение "весна пришла, ожили растения, стало тепло и сухо". Разумеется, что полной эквивалентности между этими комплексами достичь практически невозможно, так (1) абстрагирована при помощи фотоаппарата (а если это картинка в памяти, то абстрагирована человеческим глазом), (2), (3) и (4) являются результатом абстрагирования человеческого ума, причем (3) и (4) также могут выступать в качестве абстракции по отношению к (2). Полностью идентичное абстрагирование разных инструментов абстракции (человеческий ум, глаз, фотоаппарат, и т.п.) достижимо только в идеальных условиях. Поэтому нам приходится устанавливать допустимые границы, в пределах которого мы считаем комплексы сходными. Так, в нашем случае, смысл абстрагируется в объекты травы и солнца, которые соответственно зеленеют и блестят (действия, отношения). Абстрагируясь, мы можем отбросить факты, что трава не полностью зеленеет, и не всегда солнышко блестит. Обозначив допущения, мы можем прийти к ситуации, в которой все комплексы могут считаться сходными. В программировании каждому объекту реального мира соответствуют либо переменная, либо объект, либо комплекс объектов и т.д. Чего нет или частично нет в программировании: (а) категоризации элементов смысла (объекты, действия, отношения, временные отношения, и т.п.), (б) связи с объектами реального мира. Тоже самое касается и Семантического Веба, который пытается упорядочить информацию при помощи новых стандартов, но не решает полностью ни проблему категоризации (хотя пытается при помощи онтологий), ни проблему связи с реальным миром (хотя пытается при помощи URI/URN).

Необходимо еще раз подчеркнуть, что проблемы идентификации, абстрагирования и смысла решаются и в естественном языке. Естественный язык ссылается на предметы, действия и понятия при помощи простых (слов) и сложных идентификаторов (предложение, текст). Ссылка может быть как конкретной (в простейшем случае уникальный идентификатор соответствует одному предмету, т.е 1:1, например, "Эверест") так и абстрактной (когда комплексу идентификаторов может соответствовать разные вещи, т.е. N:M, например, "любимое занятие"). Однако все идентификаторы балансируют (при помощи абстрагирования) между конкретным и абстрактным, например, тот же "Эверест" может ссылаться на организацию или метафору большого достижения, а "любимое занятие", уже произнесенное человеком и связанное с его любимым занятием, становится более конкретным. То, на что ссылаются идентификаторы и есть смысл.

ВЫЗОВЫ НАСТОЯЩЕГО

Эти три аспекта являются необходимыми условиями решения проблемы больших объемов информации. Идентификация позволила бы ускорить сортировку, абстрагирование позволило бы уменьшить объемы необходимой сортировки, а смысл позволил бы улучшить ее точность. Но наряду с этим, перед нами стоят еще множество вызовов, которые желательно решить тоже (некоторые уже были перечислены выше):

* Большие объемы компьютерных идентификаторов (имена файлов, каталогов, сайтов, последовательность открытия графических элементов) невозможно запомнить.
* Компьютерные идентификаторы неестественны (слова естественного языка часто представляются в виде не всегда понятных аббревиатур, разделители либо пропускаются, либо заменяются другими разделителями) и сложны для запоминания (URL). Например, equalsIgnoreCase - идентификатор используемый для сравнения игнорируя регистр букв, он эквивалентен идентификатору естественного языка "equals ignoring case" или же другому компьютерному идентификатору equals(boolean ignoreCase). Как мы видим компьютерные идентификаторы приводятся к неестественному виду главным образом, т.к. игнорируются разделители естественного языка (которые используются для других целей) и т.к. часть смысла становится статической, а не динамической (параметром).
* Обычные идентификаторы (например, естественного языка) используются для графических элементов, но неотделимы от самих элементов (т.е. недоступны для переиспользования).
* Элементы интерфейса, файла, документа, приложения и сайтов монолитны и неотделимы друг от друга, что затрудняет переиспользование.
* Содержимое, а также содержание архива или файла скрыто обслуживающим приложением (например, невозможно понять, что скрывается в файле, не открыв его при помощи соответствующего приложения).
* Гипертекст жестко интегрирует информацию, что приводит в результате к "контентовому кошмару" (а. невозможно понять, где граница между контентом и не-контентом; б. сам контент представляет собой лишь последовательность символов/слов; в. субъективное и объективное смешаны)
* Гипертекстовая ссылка ссылает слово (абстрактное) на ресурс (конкретное).
* Невозможно создавать и классифицировать информацию без посредника между информацией и пользователем (например, чтобы создать заметку, относящуюся к одному из аспектов проекта, вы должны оформлять это только как документ или же использовать специальную программу для создания заметок)
* Невозможно маркировать информацию при помощи идентификаторов или смысла, не вмешиваясь в содержимое файла или в работу приложения
* Невозможно пользоваться совместно классификацией файлов (например, автор классифицирует файл как "документ проекта А" и вы автоматически видите ту же классификацию), совместно пользоваться информацией без посредника (например, чтобы передать файл другу вы должны пользоваться программой электронной почты, браузером, и т.п.), запросить информацию без посредника (например, попросить у друга документ по проекту, минуя обмен сообщениями и собственно сам поиск и передачу документа)
* Практически отсутствует возможность сохранять "снимки" информации, с которой вы работали (например, последний запрос к базе данных или сайту), с возможностью обновить позднее
* Невозможно при поиске получить точный ответ (вместо этого вы получаете миллионы ссылок)
* Практически невозможно руководствоваться целями при работе с приложениями (хотя мы их представляем, когда работаем), а только инструкциями (например, вместо того, чтобы поставить цель "послать документы господину Х" мы должны разбивать нашу цель на команды, которые включают в себя выделение документов, нахождение господина Х в адресной книге, и отсылку при помощи какого-то приложения)
* Некоторые действия приходится делать вручную (например, править файлы после инсталляции, либо изменять опции), только потому, что нет метода идентификации информации внутри контейнера и графических элементов, а методы идентификации при помощи программного интерфейса усложнен (поэтому и не реализован)
* Практически отсутствует понятие временных отношений (возможность, необходимость, и т.п.), хотя они часто подразумеваются
* Существуют принципиальные ограничения любого графического интерфейса. Лучше всего он подходит в условиях, когда человек может запомнить набор необходимых действий, чтобы автоматически их воспроизводить впоследствии. К сожалению, он плохо представляет сложные действия, т.к. человек "оптимизирован" под графическую систему естественного языка и ему сложно запоминать все тонкости новых графических систем, предоставляемых приложением или операционной системой. Построить простой графический интерфейс возможно только для простых задач (хороший пример, что всё должно быть просто, но не проще, чем необходимо), многие интерфейсы намеренно упрощают, достигая эстетического эффекта, но и снижая их возможности.
* Проблемы неупорядоченного интерфейса или контента перекладываются на пользователя ("посмотри в руководство" или "поищи в интернете"), что частично связано с проблемой любой иерархии (ограничивая область поиска она одновременно и скрывает часть информации), например, искать необходимую для вас информацию в нескольких уровнях вложенности меню или в нескольких уровнях вложенности сайта, представляет собой задачу, требующую не столько умения, сколько времени, а порой и просто удачи.
* Ассоциации (ключевые слова, теги и т.п.) часто заменяют абстракции (редуцированную или обобщенную информацию). Хотя, в общем случае, информация имеет множество ассоциаций, но одну абстракцию.
* Приложения детерминированы и не могут работать с непредусмотренными ситуациями
* Пока не существует способов фильтрации, способных значительно сужать область поиска
* Процесс абстрагирования при разработке программы и контента часто опускает часть смысла (который подразумевается или игнорируется), что приводит к несоответствию желаемого и действительного
* Семантический Веб предлагает использовать URI для идентификации любых объектов, но не предлагается способа разделять идентификаторы обычных объектов от идентификаторов http объектов
* Семантический Веб предлагает определять семантику в виде онтологий, не связывая разные онтологии между собой
* Уже созданные таксономии и онтологии используют множество отношений для определения своих элементов, что затрудняет их использование (а часто понятно только экспертам в семантике). В то время как, определение должно являться лишь одним из возможных ответов на вопрос "что такое х?", более важным является идентификация объекта (которую может сделать человек, разбирающийся в предметной области, но не являющийся экспертом в семантике).
* Парадокс, но, по сути, компьютерный мир не готов к распознаванию естественного языка: то есть, если даже завтра распознавание заработает, то распознавание отдельных слов только ускорит ввод информации, но не революционизирует работу с компьютером (т.к. программы на данный момент не готовы работать даже с простейшими фразами естественного языка, т.к. не существует общей схемы для привязывания фраз к графическому интерфейса). Распознавание же смысла пока невозможно, т.к. нет общего понимания, что же такое смысл.

РЕШЕНИЕ

Какой же подход способен разобраться с этими вызовами? Сейчас существует довольно много частных решений для каждого из них, но возможно ли более общее решение? В идеале такой подход должен решать проблемы распознавания образов, языка, абстрагирования, хранения, обработки и извлечения информации, недетерминированного поведения (подобно интеллекту). К сожалению, идеал пока недостижим технически (по тем или иным причинам). Но можно ли хотя бы подготовиться к тому моменту, когда подобный идеальный подход заработает? Ведь, пока у нас нет возможности даже примерно обозначить смысл предложений или приблизительно дать абстракцию для некой информации. А, рассуждая в более широком аспекте, у нас нет уровня абстракции, на котором мы будем оперировать исключительно терминами, которыми мы оперируем в обычной жизни, а не файлами, меню, диалогами, браузерами, адресами и т.п. Конечно, то, что мы используем компьютерные термины вполне объяснимо, так как любая область жизнедеятельности оперирует собственным словарем (т.к. любой новый термин экономит время на объяснение некоего дополнительного смысла по сравнению с объяснением, включающим полное описание, например, "браузер" вместо "приложение, позволяющее работать в Вебе" и т.п.). Но являются ли компьютерные термины необходимым условием, чтобы оперировать информацией? Не возможно ли организовать работу так, чтобы пользователь вообще не подозревал о низкоуровневых компьютерных способностях (как, мы сейчас не задумываемся в каком секторе жесткого диска хранится наш файл)? Нужно ли нам знать, что функция запускается при помощи кнопки или меню?

Обобщая, схема работы с компьютером может быть представлена так:
1. У нас имеется какое-то представление о некоем предмете или понятии.
2. Переводя в компьютерную форму, мы превращаем это представление в идентификаторы естественного языка (слова) или в данные, используя систему идентификаторов приложения. То есть, по сути, мы кодируем информацию.
3. При необходимости, вы превращаете идентификаторы естественного языка или данные обратно в представление. То есть, мы декодируем информацию.
4. При поиске, вам необходимо угадать, какие идентификаторы были использованы для кодирования.

Проблемы:
* При каждом кодировании и декодировании информации, в общем случае, информация искажается.
* Приходится гадать о том, какие идентификаторы были использованы.

Возможным решением видится новый уровень абстракции, который скроет от нас детали компьютерной реализации обработки и представления информации. Соответственно это должно уменьшить побочные эффекты кодирования-декодирования, так как целостность информации будет поддерживаться на этом новом уровнея, а нарушения целостности можно будет легче отслеживать и устранять, как можно раньше. Этот новый уровень должен стать связующим звеном между использованием компьютерных идентификаторов и терминов и идентификаторами естественного языка. К сожалению, естественный язык не может быть использован полностью в настоящее время. Но мы можем использовать естественный язык в упрощенном варианте, в виде только лишь идентификаторов. Эта тенденция очевидна и в графическом интерфейсе, но она не получила логического продолжения. Что же представляет из себя предлагаемое решение?

* Общий подход: мягкая интеграция
- Минимум вмешательства в уже существующее положение вещей. То есть, предоставить форму, которая будет подчиняться данным (а не наоборот). Дополнительную информацию о файле предоставлять в виде "оболочки", которая включает внутри себя файл(ы) и другие элементы (наподобие гипертекста, но без возможностей форматирования, которое должно быть представлено внутри самих файлов). Подобные "оболочки" могут также использоваться для маркировки уже существующих файлов, видимого для всех приложений (например, информация, помеченная как "документ проекта" попадет в контекст того же проекта и на другой машине).
- Определить новый семантический протокол (возможно использовать URN) вдобавок к уже существующему http, который нецелесообразно использовать для этих целей (он ставит ресурс/информацию в соответствие с URL, т.е. компьютерный идентификатор, в большинстве случаев, представляющий просто набор символов), вместо этого семантический протокол должен ставить информацию в соответствие идентификатору, который может представлять из себя слово(сочетание) естественного языка, идентификатор таблицы базы данных, так и URL (например, любое слово на гипертекстовой странице может выступать в качестве семантической ссылки, причем результатом будет являться множество соответствующих этому слову ресурсов). На самом деле, уже сейчас подобный протокол уже негласно используется людьми: наверное, вы часто слышали фразу "Введи в поисковике ..."?
- Информационное пространство должно быть "прозрачно" для пользователя, т.е. информация может запрашиваться из разных источников (как глобальных, так и локальных, см. ниже делегирование).
- Мягкая конкретизация, т.е. возможность устанавливать не полностью детализированные отношения, т.к. пользователь не обладает экспертными знаниями и т.к. не всегда полная конкретизация нужна (например, двигатель машины - это атрибут машины и структурно должен быть представлен отдельным объектом внутри ее? взамен мы можем просто определить, что двигатель находится внутри, без детализации), а также не концентрируясь на проблеме базовых отношений (т.к. пока нет консенсуса возможно ли их определить в принципе).
- Возможность работать с идентификаторами, соединенные в произвольные графы (как альтернатива тройкам, онтологиям и типизации, необходимой в Семантическом Вебе), что сделает семантику доступной для не-экспертов, а в целом будет ближе к ситуации, свойственной естественному языку.

* Идентификация
- Идентификация всех элементов смысла и трансляция идентификаторов между собой (например, слово "корабль" и слово "ship" должны иметь одинаковый языконезависимый идентификатор, в общем случае; в частностях же, слово "корабль" может транслироваться и на конкретный корабль, и на корабль как понятие), этот же идентификатор может транслироваться в локальный идентификатор базы данных для указания типа транспортного средства, а также в элемент графического интерфейса, который используется для редакции этого типа (что позволит, например, произвольную совместимость приложений, т.е. пользователь может сам определить совместимость идентификаторов разных приложений).
- Идентификация предпочтительно должна происходить при создании информации (предполагается, что создатель информации лучше разбирается в области, к которой принадлежит эта информация, к тому же он пользуется контекстами, о которых см. ниже). Таким образом, становятся не нужными сложные вычисления для распознавания (которые сейчас вынуждены делать приложения), которые к тому же дают неоднозначные результаты в сложных случаях.
- Идентификация элементов приложения должны включать не все объекты приложения, а только семантически значимые для пользователя (т.к. иначе пользователь потеряется в большом количестве идентификаторов).
- Трансляция идентификаторов и абстракций между собой, с указанием критериев схожести (например, модель машины может выйти в другой стране с определенными изменениями, в этом случае трансляция двух идентификаторов моделей невозможна, поэтому идентификатор может только "примерно" транслирован в другой идентификатор). В отличие от ключевых слов, тегов, ассоциаций, "похожих тем" и тому подобному, подобная трансляция подразумевает явное определение критериев схожести (абстрагирования), т.е. по сути их типизированию.
- Трансляция идентификаторов в ресурсы (гипертекстовые ссылки, файлы, и т.п.), данная трансляция должна заменить гипертекстовые ссылки, например, вместо связывания определенного слова в гипертексте с URL, мы должны будем связать слово с соответствующим идентификатором, который, в свою очередь, укажет на соответствующую ссылку или ссылки, которые относятся к нему.
- Трансляция идентификаторов может производиться и в вызовы действий/сервисов/методов (с параметрами), что аналогично предложениям естественного языка (например, "я написал письмо другу ручкой" подразумевает либо вызов "написал" с параметрами "письмо", "друг", "ручка", либо "написатьПисьмо" с двумя параметрами, либо "написатьРучкой"). Данный тип трансляции позволит: (1) ссылаться на разные идентификаторы, ресурсы, в зависимости от параметров, (2) более гибко связывать действия (например, страница может иметь идентификатор "написать письмо" без привязки к сервису или приложению), (3) использовать идентификаторы для помощи пользователю (например, инструкция вида "зайти в меню, выбрать в диалоге чекбокс, нажать ОК" может быть представлена в виде исполняемых идентификаторов) и т.п.
- Трансляция идентификаторов должна явно или неявно делегироваться (например, сначала к компьютеру пользователя, затем к более высоким уровням сетевой принадлежности: например, проект, отдел, компания, город, страна, глобальная сеть; как вариант делегация может идти по цепочке пакет приложений, приложение, библиотеки; или же используя контексты; т.е. от низкого к высшим уровням абстрагирования). Таким образом, (1) трансляция будет произведена на уровне, который способен обработать запрос, (2) трансляция может предоставлять разное понимание идентификатора из разных уровней, (3) возможно создание сетей серверов, которые будут отвечать за определенный набор идентификаторов (например, идентификаторы, относящиеся только к биологии и т.д.), (4) упростить обмен информацией (например, вы посылаете идентификатор "документ проекта" коллеге, он пытается его открыть, но операционная система сообщает, что данный документ доступен только на другой машине и предоставляет возможность сохранить его локально).

* Абстрагирование
- Явное представление результатов абстрагирования (например, статья о выпуске модели А машины марки Б должна абстрагироваться в условную фразу "выпуск модели А марки Б", которая состоит из идентификаторов "выпуск", "модель А", "марка Б", связанных между собой, где "модель А" включается в "марку Б", т.к. не может существовать независимо от нее, а "выпуск модели А марки Б" включает в себя все идентификаторы, т.к. является результатом их связывания). Типичным примером представления "идентификатор + абстрагирование" в современном мире является связка "ID + Имя", которая часто используется в приложениях, где первый элемент является компьютерным идентификатором, и второй - обычным.
- Абстрагирование форм языка, многие из которых являются историческими или же предназначены для стыковки разных форм в предложения определенного типа (например, "солнце встает" и "встающее солнце" должно быть представлено двумя одинаковыми идентификаторами, т.к. мы употребляем "встающее" обычно в ситуациях, когда необходимо употребить еще один глагол как в "встающее солнце светило ярко"; или же "плавание корабля" и "корабль плавал": "плавание" употребляется, когда нужно либо представить объединенное множество действий за определенный период времени, либо когда дальше в предложении будет употреблен глагол "плавание корабля привело к...").
- Поиск должен сначала использовать результаты абстрагирования (например, если слово "модель А" встречается в фразе "выпуск модели А марки Б", то это является более важным, чем, если это слово встречается в статье о всей продукции компании, что, в свою очередь, является более важным, чем, если это слово встречается в книге о машинах, но, если книга не о самой "модели А").
- Поиск должен абстрагировать результаты, группируя их на основе абстрактного сравнения (например, поиск по "модели А" должен давать такие группы как "проблемы с моделью А", "магазины, продающие модель А"), что уже делается современными поисковыми системами, но не всегда на регулярной основе. Данная группировка похожа на иерархии, широко применяемые ныне, но группировка является более произвольной, что более точно отражает реальное положение дел (т.к. практически любая иерархия, за малым исключением, является произвольной и зависит от того, как абстрагируется информация). Подобная группировка применяется практически в любом тексте, при разбиении на главы, абзацы, списки и т.п., тем самым, мы подчеркиваем, что смысл разных групп отличается друг от друга, а также это помогает сконцетрировать однородный смысл в одном месте.
- Поиск должен использовать критерии важности, которые основаны на способе абстрагирования и фильтрации информации (что в современном интерфейсе выражается сортировкой и фильтрацией). Другой пример применения критериев важности - выделения в тексте для визуального фильтрации текста.

* Смысл
- Семантика должна быть явной и совместимой в приложениях (для чего и нужны идентификаторы). Информация должна быть упорядочена в виде структур, таких как списки, таблицы, графы, иерархии, использование отношений 1:1, 1:N, M:1, N:M (которые соответствуют разным структурам) и использовать объекты, действия, и отношения различного рода (пространственных, временных, возможность, планирование, цель, и т.п.), которые используются в естественном языке, но не всегда явно в мире компьютеров.
- Ассоциация информации с аттрибутами, категориями и т.п. (например, как это сейчас делается при помощи тегов и ключевых слов) заменяется на связность с идентификаторами, которые, за кулисами, могут быть связаны с другими идентификаторами (т.е. если вы связываете фотографию с идентификатором "отпуск", то не нужно ее связывать с идентификатором "отдых", т.к. эта трансляция уже будет сделана неявно). Причем, эта связь должна подразумевать только саму себя (т.е. "фотографии из отпуска" означает, что фотографии относятся только к отпуску, а не документы, которые упоминают фотографии и/или отпуск).
- Любой идентификатор является результатом абстрагирования, абстрактный идентификатор использует схожесть и обычно соответствует типу (например, "машина" может быть применен к очень большому количеству предметов), конкретный - идентичность и обычно соответствует переменной (например, "моя машина" уникально идентифицирует предмет). Т.е. в общем случае, в отличие от программирования, грань между типом и переменной размыта, можно говорить только о балансе между абстрактностью и конкретностью (обычно, чем больше используется идентификаторов, тем более конкретным становится содержание).
- Любое исключение должно использовать либо дополнительные конкретизирующие идентификаторы ("машина, но на двух колесах"), либо более абстрактный идентификатор ("это уже не машина, а транспортное средство"). Подобное до- и переопределение является выражением баланса между детерминированным и возможным, которое всегда присутствует в любой информации.
- Любой предмет является статическим и динамическим одновременно и только абстракция может склонить чашу весов в ту или иную сторону. Этот аспект может быть явно обозначен для любого идентификатора (например, "цены на модель А" - это может быть запросом к сайту дилера, возвращающий текущие цены, но также и зафиксированными данными, полученными в определенный момент времени, который тоже должен быть зафиксирован; при этом обе формы могут быть связаны между собой, чтобы было возможно их обновить, а также при желании получать нотификации об обновлении; для документа подобный дуализм может быть выражен в его композитной форме, которая развивается во времени, и версиях, которые фиксируют определенную конфигурацию документа; сама версионность должна быть одним из базовых свойств информационной "оболочки", описанной выше, т.к. версии предоставляют срезы информации во времени).
- Любая информация является субъективной и объективной одновременно, объективность является критерием большей абстрагированности (т.е. чем больше субъективного консенсуса, тем больше "объективность"; еще более точным критерием является проверяемость, но он не всегда применим, особенно к информации, относящейся к неточным областям или чистым абстракциям). Для субъекта (человека или сайта) "объективным" является собственная точка зрения, поэтому важно не только отделять объективное и субъективное (т.е. статью от комментариев), но и указывать, кто является автором точки зрения (чтобы превратить объективность информации в субъективность при выходе за пределы субъекта).
- Любая информация может являться как атомарной (например, разбиение на файлы) или замкнутой (например, все необходимые значения доступны в пределах приложения или сайта), так и связанной с другой информацией (когда имеются связи внешние, по отношению к приложению или сайту). Более важно, что информация должна быть готова оборвать связи, при выходе за пределы замкнутой системы, а также быть готовой стать частью целого и приобрести связи при входе в другую замкнутую систему.

* Интерфейс
- Любой интерфейс тоже является абстракцией, скрывая за собой реализацию (действия, данные, и т.п.), поэтому к нему применимо всё то, что говорилось об абстракции. Необходим смешанный подход, который объединил бы преимущества текстового и графического интерфейсов, и добавил бы что-то новое, а также, который объединил бы преимущества иерархий (как в графическом интерфейсе и порталах) и одной точки входа (как в консоли или строке ввода поисковой системы).
- Важнейшим элементом интерфейса должна являться идентификация, которая должна предоставлять идентификаторы не глобально (как это сделано в современных поисковых системах, при помощи Веб 2.0), а ограниченные при помощи контекста. Контекст для фильтрации информации, задаваемый сочетанием идентификаторов, будет создавать область видимости информации (например, в контексте графики будут видны только графические приложения и графические файлы). Подобное ограничение сейчас делают неявно типы файлов, приложения и сайты, которые внутри себя как бы создают область видимости. Контексты также должны заменить десктоп, в качестве множественных точек входа в систему. Контекст должен предоставлять возможности по расширению и сужению области видимости, пересечению разных областей и т.п. Сама идентификация должна быть доступна опционально, по требованию, например, видя, что используемая информация противоречива, вы можете уточнить ее при помощи идентификаторов.
- Информация должна быть доступна при помощи смысловых идентификаторов (например, вместо файла 1234.sub, информация будет видна как "субтитры фильма А"; причем, "субтитры" и "фильм А" - это два связанных идентификатора, которые возможно будет переиспользовать для дальнейшего поиска/фильтрации).
- Приложения могут быть связаны в единую сущность (файлы, настройки, и т.п.), что в целом облегчит распознавание принадлежности файлов и оперирование частями приложений (например, сохранить настройки для переноса на другой компьютер).
- Доступ к элементам интерфейса при помощи идентификаторов, отражающих их смысл (т.е., доступ к полю, которое редактирует модель машины будет осуществлен при помощи идентификатора "модель машины", который можно будет переиспользовать в дальнейшем; например, вы можете сохранить статическую форму из всех полей машины, заполнить ее извне приложения, а потом сохранить уже когда приложение будет запущено; или часто встречаются ситуации, когда определенные диалоги используются много раз с одними и теми же значениями, что может дать возможность создавать "шоткаты" для подобных ситуациях, наподобие "макросов", но доступными в любом приложении, а не только тех, которые их предусматривают; также это может помочь в работе с виртуальными или удаленными машинами, когда работа с графическим интерфейсом может представлять собой работу с идентификаторами, что быстрее, а не элементами графического интерфейса).
- Опции/параметры должны быть связаны с функциональностью (например, если опции оказывают влияние на поведение функции, то при запуске этой функции мы должны видеть какие именно опции оказывают влияние).
- Любой элемент интерфейса должен быть представлен в следующих аспектах: (1) декларативном (объявление и/или идентификатор), (2) императивном (связанный с действием или же с изменениями, например, для текстового поля), (3) ссылочном, (4) вопросительном. Данные аспекты помогают понять, как данный элемент можно (1) использовать и переиспользовать, (2) менять и изменять при его помощи другие элементы, (3) связан с другими элементами, (4) может быть связан с другими элементами, вследствие недостаточных сведениях о связях или необходимости уточнения.
- Подобие командной строки (не только для операционной системы, но и для приложений и сайтов) со смысловыми ограничениями, подсказками, связностью и т.п. (например, если список товаров может быть определен только после того, как создан заказ, то при вводе "товар добавить", строка должна показать, что это действие возможно только, если заказ определен, поэтому она должна предложить либо "добавить в заказ", либо "создать заказ"). Возможность оперирования с интерфейсом при помощи и фиксированной формы (как это сделано в нынешнем GUI), и динамической формы для действий, для которых не предусмотрена фиксированная форма (действие представляется в виде идентификатора, с которым связаны параметры, для которых существуют места/placeholders, помеченные как обязательные/необязательные, ограниченные областью видимости, доступные/недоступные и т.п.).
- Безопасность, может быть дополнена (не считая уже существующих средств) контекстовой фильтрацией: т.е. приложение должно декларировать в каком контексте оно собирается работать.
- Возможность работать с нелинейным текстом (т.е. который в дополнение к линейному тексту, представляющему из себя последовательность символов, имеет еще ссылки на другую информацию). Нелинейный текст является продолжением идеи гипертекста, для которого не созданы простые средства, позволяющие создать текст, дополнить его ссылками, или же комментариями, не усложняя все форматированием и прочим (подобная задача проще решается при помощи офисных пакетов, но без использования доступных глобально идентификаторов и отношений). Данная задача очень актуальна в случаях, когда необходимы несколько фрагментов текста, связанных между собой (например, описание и субъективный комментарий, который не должен быть частью описания).

ПРИМЕРЫ

Итак, как это будет работать всё вместе? Разумеется, что важен не только сам подход, использующий идентификацию, абстрагирование и смысл, но также и интерфейс, который позволит облегчить решение этих проблем.

Пример 1. Фотографии
В отпуске вы сняли фотографии и привезли их домой.

1. Открываете контекст фотографий (в котором доступны только графические приложения и/или только файлы с фотографиями).
2. Загружаете фотографии из фотоаппарата, при этом вам сразу предлагают классифицировать их внутри данного контекста. Вы набираете "отпуск", но у вас уже есть идентификатор "отпуск 2009 дача", поэтому вам предлагают добавить новый идентификатор (т.к. атрибуты файлов фотографий 2010 года и геотаг не находится близко от дачи), например "отпуск 2010 Париж" (т.к. для обозначения времени вы используете только год, а геотаги, абстрагируются в самую крупную географическую структуру, в районе Парижа, если же например, геотаги захватывают и Версаль, то они могут быть абстрагированы как Иль-де-Франс). При дальнейшей классификации, вы можете отобрать наиболее используемые идентификаторы: "я" и "жена" (которые имеют особые значения в пределах данного компьютера), "Лувр", "лучший", выделять фотографии, и перетаскивать идентификаторы на них, таким образом связывая их с фотографиями.
3. Ваша классификация готова к использованию. "лучшие фотографии из Парижа" теперь вернет только лучшие фотографии, а не все документы, в которых встречается эти слова. "я на фотографиях" вернет в том числе и мои фотографии из Парижа.
4. Если, вам нужно отправить лучшие фотографии из Парижа другу, то для этого достаточно только применить действие "отправить" к выделенным лучшим фотографиям, при этом вы можете выбрать (а можете и нет) способ передачи. Дальше возможны варианты: (а) друг доступен за компьютером, тогда он подтверждает передачу (если она не разрешена всегда), ваши компьютеры устанавливают доступное соединение (имейл, http, ftp, IM, p2p, и т.п.) и копируют фотографии, (б) друг не доступен, ему отправляется только сообщение о намерении передать файлы, он подтверждает, когда он включает компьютер, вы получаете подтверждение и ваш компьютер начинает передачу (без вашего вмешательства) на один из промежуточных серверов, далее, когда ваш друг включит компьютер - он получит ваши фотографии с промежуточного сервера. Причем, фотографии попадают в тот же контекст, что и у вас (хотя он, при желании, может быть изменен).

В чем отличие от современного положения вещей? (1) Идентификаторы значат ровно то, что они должны значить, т.е. дача - не просто слово, а может включать географические координаты, "Париж" - город во Франции, 2009 - это не число, а год, и т.п. (2) Идентификаторы доступны не только для приложения, в котором они могут быть созданы, но для всей системы и глобально (например, для той же передачи файлов) (3) Вам не нужно помнить месторасположение фотографий на диске, использование контекста, классификация и абстракция гарантируют, что вы сможете их найти (даже использование "библиотек" файлов весьма ограничено, т.к. они представляют из себя всего лишь список файлов, тогда как данная коллекция представляет собой идентифицированную информацию, а это значит два файла могут входить в данную коллекцию, но быть частями других коллекций, которые не нужно собирать вручную). (4) Вы работаете с компьютером при помощи целей (отправить), а не инструкций (открыть приложение, найти фотографии, приаттачить, отправить) (5) Идентификаторы транслируются друг в друга, поэтому "я" будет означать себя самого для вас, а для вашего друга "я" будет означать "мой друг", т.е. оба сможете пользоваться разными идентификаторами для обозначения одного и того же человека (6) Идентификаторы абстрагируются, поэтому то, что "Лувр" находится в "Париже" должно быть вычисляемо (необязательно на вашей машине, которая может просто не вместить всех фактов)

В современной же ситуации, хотя есть и теги в приложениях, хотя есть и форматы, поддерживающие теги, но они не транслируемы друг в друга и не могут быть использованы вне определенного приложения или группы приложений, и т.п.

Пример 2. Блокирование экрана
Вы хотите запретить блокирование экрана. В настоящий момент, вы должны найти ответ на этот вопрос при помощи поиска и исправить реестр Windows. Но можно ли упростить решение? В целом же, интересно, каков процент пользователей Windows знают, что экран можно блокировать вручную? Сколько знают, что это можно делать при помощи клавиатурного быстрого доступа? Сколько знают, что блокировку вообще можно запретить? Почему эти знания не являются общедоступными?

Использование блокирования может быть описано следующими пунктами: (1) необходимо, чтобы предотвратить доступ к компьютеру, когда пользователь отсутствует, (2) включается после периода неактивности, (3) может быть включен вручную, (4) может также использоваться, чтобы установить статус отсутствия в приложении обмена сообщениями. Для описания данных фактов с точки зрения смысла, нам необходимы следующие отношения: (1) цель (чтобы предотвратить доступ..., чтобы установить статус...), (2) возможности (может быть включен после периода неактивности, либо вручную; может быть запрещена вообще), (3) причина-следствие (включается после периода неактивности), (4) после (в данном случае "после" совпадает с "причиной-следствие", но в общем случае, "после" не означает "вследствие").

Почему пользователь не знает, что экран может блокироваться вручную? Об этой возможности, должен информировать сам диалог блокировки экрана. Тоже самое касается и клавиатурного доступа. Отношение цели может быть использовано в информации о безопасности, чтобы проинформировать о такой возможности, а также в приложениях обмена сообщениями. Отношение возможности может быть использовано, когда блокировка была включена автоматически и проинформировать о возможности сделать это вручную, и наоборот, а также и сообщить о возможности запрета. Отношение причины-следствия может быть использовано после периода неактивности, которая не привела к блокировке, чтобы проинформировать, что можно использовать и блокировку. Естественно, что вся эта информация должна быть связана, так чтобы, все упомянутые возможности не подразумевали дополнительное кодирование в каждом конкретном случае, а вызывались по мере активации связей.

Что касается запрета, то здесь ситуация немного сложнее: ручная корректировка реестра не предупреждает о том, что с точки зрения безопасности запрет блокировки экрана нецелесообразен (т.е. представляет своего рода брешь, о которой нужно проинформировать пользователя). Но как пользователю все-таки использовать данную возможность, если уж он хочет игнорировать все предупреждения? Сейчас он должен либо проследовать инструкции и отредактировать реестр вручную, либо же запустить .reg файл (что без понимания его внутренностей является небезопасной операцией), либо же использовать какую-то утилиту (но которую еще надо установить, и найти интересующий пункт в дебрях опций), коими полон Интернет. Но есть и другая альтернатива: например, операционная система должна предоставлять сервис с идентификаторами "добавить ключ реестра", "изменить значение" и т.п. "Оболочка", связывающая запрет и разрешение блокировки с данными идентификаторами, и которая будет привязана напрямую к интерфейсу ОС, должна быть загружена на сайт, который сертифицирован для подобных действий, откуда пользователь его может загрузить (возможно даже из самой ОС).

По сравнению с текущим положением вещей, мы значительно сокращаем время, которое разработчики всего мира тратят на кодирование неких "фич", которые по какому-то недоразумению не охвачены стандартными средствами и которые не требуют очень сложного дизайна и разработки. Заметьте также, что при поиске вы уже не должны будете полагаться на сопоставление слов "запретить блокировку экрана", что дает неоднозначные результаты. Во-первых, вы можете начинать поиск с диалога блокировки экрана (который уже соответствует контексту "блокировка экрана в ОС такой-то". Во-вторых, вы должны указать, что "запретить" относится именно к блокировке экрана, чтобы не получить ссылку на страницу, где есть слова "блокировка экрана", а "запретить" относится к панели управления, и т.д.

Пример 3. Заказы
Вы работаете с заказами (которые имеют свои идентификаторы внутри регистрирующего приложения, которое к сожалению не имеет веб-выхода). В процессе работы вам приходится обсуждать заказы с коллегами, а иногда и с заказчиками. При этом в корреспонденции вы либо ссылаетесь на идентификаторы, либо копируете содержимое заказа в письма, и т.п.

Подобную рутину можно и нужно улучшить при помощи более гибких операций с идентификаторами и формами заказа. То, что идентификатор заказа доступен для ссылки, подразумевает: (1) вы можете получить прямой доступ к данным заказа, используя этот идентификатор (т.е. если приложение позволяет, то ссылка на идентификатор заказа должно открыть приложение и сразу проследовать к информации, соответствующей этому идентификатору), (2) вы можете получить "снимок" данных для определенного заказа и хранить их локально (пусть даже и с устарелой информацией, но с указанием даты "снимка" или версии), с возможностью прямого обновления, (3) составные заказа также доступны для ссылки, т.е. вы можете добавлять к заказу обратные ссылки, т.е. помечать, что какая то сущность ссылается на заказ (например, на обсуждение доступности заказываемых единиц), (4) если оказывается, что некоторого поля/атрибута нет в системе (например, вам нужна классификация заказов по критерию, отсутствующему в системе), то вы можете создать свой собственный, ссылаясь на заказы по идентификатору (что будет гарантией целостности данных).

Заметьте, что подобные задачи вполне решаемы при помощи программирования и сейчас, но требуют дополнительных затрат, во времени и ресурсах. Возможность же идентификации, поддержка статических и динамических форм информации, может сделать их рутинными без дополнительных затрат.

Пример 4. Приложение
Разрабатывается приложение, которое должно суммировать числа.

1. Пользователь формулирует задачу в простой фразе "суммировать числа". Он связывает это с идентификаторами "суммировать" и "числа".
2. Когда задачу принимает архитектор, он определяет это точнее в своей модели: числа он ограничивает двумя целыми 2-байтовым числом, числа подаются на вход, далее следует операция суммы, на выходе результат. Пользователь проверяет, что модель соответствует его ожиданиям (а именно, что его понятие "числа" совпадает с ограничением, которое явно обозначено в связи между формулировкой задачи и моделью).
3. Разработчик в соответствии с моделью строит графический интерфейс, связывая идентификаторы "чисел" с двумя полями ввода и "суммировать" с кнопкой "+", а "результат" с третьим полем ввода (а также с кодом). Архитектор может проверить соответствие со своей моделью, пользователь со своим пониманием.

Конечно, это простейший пример, но даже на нем видно, что, по сравнению с текущим положением вещей, не обрываются семантические связи, смысл не пропадает при передаче информации (а если и пропадает, то всегда можно проверить соответствие; также пользователь может дать комментарии, которые будут автоматически доступны для разработчика в нужном месте кода и интерфейса).

Пример 5. Обсуждение
Всем знакома ситуация, когда вы обсуждаете что-то с другом или коллегой, дискуссия постепенно обрастает деталями, цитатами, под-темами, а иногда и плодит параллельные темы, что делает управление обсуждением очень трудным. Как же предлагаемое решение должно справиться с этим?

Возьмем пример с заказами, вы обсуждаете почему заказ не был доставлен клиенту:
- Что с заказом №12345? (вопрос ссылается на указанный заказ, а возможно и заказ связывается с данной дискуссией; как только дискуссия начинается мы переходим в контекст данного заказа)
- Я обсуждал это с господином N и не вижу никаких проблем. (ответ ссылается на дискуссию с господином N)
- Хорошо, а с №12346? (вопрос ссылается на указанный заказ)
- Я сделаю запрос в компанию C. (у ответа сразу же появляется связанный элемент в виде либо TODO заметки, либо нового незаполненного запроса, который запустит нужное приложение и сделает необходимую обработку)
- Я посмотрел твою дискуссию с господином N и вижу, что проблема таки есть. (утверждение ссылается на часть дискуссии с господином N)
- Ты же его знаешь, он требует часто невозможного, а потом идет на попятную, когда объяснишь. Ссылку на его "перлы" в прошлом давать?
- Нет, не надо, это же к заказу не "пришьешь". Значит, обсуждай с ним, доказывай.
- Хорошо. А смотрел фотографии с корпоратива?
- Нет, пока.
...

Итак, сначала кажется, что сейчас при обсуждении мы делаем тоже самое. Но есть нюансы. Главный из которых возможность ссылаться на всё: (1) вопросы-ответы внутри данной дискуссии (это самое очевидное, что сделано и сейчас во всех приложениях для сообщений), (2) на другие дискуссии (это сделано в почте, но часто отсутствует в других приложениях или доступно только при помощи гиперссылки), (3) на данные внутри приложений (доступно сейчас только при помощи веб-приложений, которые еще надо создать), (4) из данных внутри приложений на дискуссии, (5) на интерфейс приложения. Само обсуждение быстро перетекает от одной подтемы к другой, но части обсуждения остаются связанными с конкретным контекстом, поэтому даже хотя заказ №12345 обсуждается в начале и середине дискуссии, контекст данного заказа включает обе части обсуждения и скрывает части, не относящиеся к нему. Также заметьте, что субъективная информация о господине N не вносится в контекст заказа (хотя, по большому счету, даже субъективное мнение о заказчике часто следует принимать во внимание), но, теоретически, компания может создать и контекст заказчиков, чтобы людям (вновь пришедшим или работающими с другими заказчиками) было понятно, с кем они имеют дело. Также стоит заметить, что сейчас мы тоже ссылаемся на всё в разговоре, но эти ссылки доступны только в виде идентификаторов естественного языка (например, "открой то, сделай то") и не могут переиспользоваться.

Пример 6. Поиск
Есть такой любимый пример у противников Семантического Веба (которые приводят его, чтобы показать, что Семантический Веб не может справиться с подобным запросом): "Is the Pope Catholic?" (сам вопрос является риторическим и звучит так: "Является ли Папа католиком?" или сокращенно "Папа католик?")

Предлагаемое решение позволяет при вводе фразы "Папа католик?" определить:
а. "Папа" может идентифицировать либо биологического/названного отца, либо Римского Папу.
б. Добавление слова "католик" уже должно разрешить противоречие в пользу первого варианта. Хотя это может произойти и автоматически, если мы находимся в контексте, относящемся к церкви, католичеству, теология и т.п.
в. Далее необходимо найти связь "является" между "Папа" и "католик", что может быть сделано при помощи делегирования, которое должно возвратить результат "да".

Современные поисковики при вводе запроса "папа католик" выдают ответы такие как "А почему католики носят обручальное кольцо на левой руке...". При уточнении запроса: "папа католик Рим", мы получаем "Британские католики записали к визиту Папы Римского компакт-диск ...". А вот, если мы вводим "Римский Папа" - тогда мы получаем и то, что ожидали. Что лишний раз доказывает, что современные поисковики дают правильный ответ только когда идентификаторы языка совпадают со смыслом. Шаг в сторону - и результаты уже далеки от искомого, даже с уточнениями, что показывает необходимость идентификации слов, входящих в запрос, а также определения отношений между ними.

Пример 7. Использование семантики
Теперь мы уже используем пример сторонников Семантического Веба (а вернее, пример, который используется в спецификации OWL): винный агент. Смысл примера показать, как красиво работает Семантический Веб, когда нам нужно выбирать вина (включая сопутствующие блюда).

Что нам необходимо при предлагаемом решении? Мы уже можем использовать имеющуюся информацию и разметить ее с идентификаторами, распознавая соответствующее вино или блюдо. Далее, если вы хотите узнать что представляет из себя вино, или сочетается ли оно с блюдами, или сразу же подобрать сочетающиеся блюда к вину, вы должны направить соответствующий запрос (который, наверняка, будет делегирован на другие машины, которые возможно решат поставленные проблемы).

Семантический Веб делает задачу более сложной (что неудивительно, т.к. предполагается, что ее будут решать эксперты, которые могут позволить сложность решения). Необходимо определить онтологию, которой будет пользоваться решатель (reasoner). При этом:
- онтология использует компьютерные идентификаторы типа "паста-с-острым-соусом", такие идентификаторы затрудняют переиспользование их составных;
- онтология использует фиксированную иерархию, которая предполагает, что "вино", например, является "бутиллированной жидкостью", хотя, в общем случае, "вино" может входить еще в сотни классификаций;
- онтология расписывает, какие поля и ограничения должны быть у вина (что в целом хорошо, т.к. служит тем же целям, благодаря которым графический интерфейс не позволяет вводить бессмысленные значения); однако, это делает набор полей детерминирован и конкретен, хотя в частностях поля могут становиться недетерминированными и абстрактными;
- запросы к решателю не выглядят легко распознаваемыми человеком;
- и т.п.

То есть, мы видим, что Семантический Веб весьма похож на ситуацию с обычными приложениями, так что он обладает всеми теми же недостатками.

ЗАКЛЮЧЕНИЕ

Что же мы получаем в итоге? Своего рода компромисс между областями, так сказать, работы "обычного пользователя" и областями, которые традиционно считались вотчиной только лишь экспертов (для пользователей они были просто недоступны, а для многих же технических профессионалов они казались слишком уж отвлеченными от реальности). Но главный вопрос все же, может ли данный компромисс справиться с информационным мусором? По крайней мере, при помощи идентификации, абстрагирования и семантики процесс сортировки должен значительно упроститься. Разумеется, что возникнет уже проблема множества ссылок. Но это уже проблема не столь сортировки (т.к. сортировка ссылок решаема при помощи предложенного подхода), а производительности, что уже требует возможно и других подходов к компьютерной архитектуре, своего рода cloud-компьютеры (не путать с cloud-вычислениями). Интересен и другой вопрос: а можно ли это всё реализовать? В целом, можно ответить, что в некоторых частных случаях, похожие подходы уже давно реализованы. В частностях же, необходим всеобщий консенсус по поводу семантического протокола и идентификаторов, доступных глобально. Достижим ли он? Надеемся, что да, так как данный подход позволяет сэкономить время и ресурсы как глобально, так и локально.

(первый вариант опубликован в CompuTerra, данный текст исправлен и дополнен)