concept-language
senso-concept-Mcs (lagCnpt)

McsHitp-creation:: {2021-01-01}

overview of lagCnpt

description::
· concept-language is a-constructed-human-language that maps structure and doing of mind-concepts.
· it is similar with a-human-language on the-input, but it has a-different output which is-understood by humans and computers today.

name::
* McsEngl.McsTchInf000007.last.html//dirTchInf/dirMcs!⇒lagCnpt,
* McsEngl.dirMcs/dirTchInf/McsTchInf000007.last.html!⇒lagCnpt,
* McsEngl.Lcnpt!⇒lagCnpt, {2021-01-12},
* McsEngl.concept-computer-language!⇒lagCnpt, {2021-03-05},
* McsEngl.concept-language!⇒lagCnpt, {2021-01-04},
* McsEngl.lagCmpr.012-concept!⇒lagCnpt,
* McsEngl.lagCmpr.concept!⇒lagCnpt,
* McsEngl.lagCnpt, {2021-01-04},
* McsEngl.lagCnpt'(McsTchInf000007)!⇒lagCnpt,
* McsEngl.lagCnpt'(concept-language)!⇒lagCnpt,
* McsEngl.lagConcept!⇒lagCnpt, {2021-01-24},
* McsEngl.lagCpt!⇒lagCnpt,
* McsEngl.lagKnlg!⇒lagCnpt,
* McsEngl.lagKnowledge!⇒lagCnpt,
* McsEngl.knowledge-language!⇒lagCnpt,
====== langoGreek:
* McsElln.γλώσσα-εννοιών!=lagCnpt,
* McsElln.γλώσσα-γνώσης!=lagCnpt,
* McsElln.εννοιακή-γλώσσα-υπολογιστών!=lagCnpt, {2021-03-05},
* McsElln.εννοιών-γλώσσα!=lagCnpt, {2021-01-04},

01_user of lagCnpt

description::
· a-human or technology that uses the-language.

name::
* McsEngl.lagCnpt'user,

human of lagCnpt

description::
· the-human that uses the-language to map his mind-view.

name::
* McsEngl.lagCnpt'human,

human.author of lagCnpt

description::
· one or more humans that create one worldview.

name::
* McsEngl.lagCnpt'author,

human.reader of lagCnpt

description::
· a-human that reads the-base.

name::
* McsEngl.lagCnpt'reader,

manager (link) of lagCnpt

02_input of lagCnpt

description::
· the-input conceptual-view-(system of concepts) we want to map for a-machine.

name::
* McsEngl.Cnptlinput,
* McsEngl.lagCnpt'02_input!⇒Cnptlinput,
* McsEngl.lagCnpt'domain!⇒Cnptlinput,
* McsEngl.lagCnpt'input!⇒Cnptlinput,
* McsEngl.lagCnpt'input-view!⇒Cnptlinput,
* problem-domain,

domain of Cnptlinput

description::
· the-set of input-views we want to map.

name::
* McsEngl.Cnptlinput'domain,
* McsEngl.lagCnpt'domain,

schema of Cnptlinput

description::
· input-schema is the-structure of the-input-view expressed in a-lagCnpt.

name::
* McsEngl.Cnptlinput'schema,
* McsEngl.lagCnpt'input-schema,
* McsEngl.input-schema-of-lagCnpt,

mind-concept of Cnptlinput

description::
· a-mind-concept that is-mapped.

name::
* McsEngl.Cnptlicpt,
* McsEngl.Cnptlinput'mind-concept!⇒Cnptlicpt,
* McsEngl.lagCnpt'input-concept!⇒Cnptlicpt,

mind-view of Cnptlinput

description::
· a-system of mind-concepts that is-mapped.

name::
* McsEngl.Cnptlinput'view!⇒Cnptliview,
* McsEngl.Cnptliview,
* McsEngl.lagCnpt'input-view!⇒Cnptliview,

mind-worldview of Cnptlinput

description::
· all the-mind-views of one author that is-mapped.

name::
* McsEngl.Cnptlinput'worldview!⇒Cnptliworld,
* McsEngl.Cnptliworld,
* McsEngl.lagCnpt'input-worldview!⇒Cnptliworld,

mind-base of Cnptlinput

description::
· the-set of input-worldviews that is-mapped.

name::
* McsEngl.Cnptlibase,
* McsEngl.Cnptlinput'base!⇒Cnptlibase,
* McsEngl.lagCnpt'input-base!⇒Cnptlibase,

03_output of lagCnpt

description::
· the-output document a-machine understands.

name::
* McsEngl.Cnptloutput,
* McsEngl.digital-mind-view!⇒Cnptloutput,
* McsEngl.knowledge-base!⇒Cnptloutput,
* McsEngl.lagCnpt'03_output!⇒Cnptloutput,
* McsEngl.lagCnpt'coodomain!⇒Cnptloutput,
* McsEngl.lagCnpt'output!⇒Cnptloutput,
* McsEngl.output-view-of-lagCnpt!⇒Cnptloutput,

output-schema of lagCnpt

description::
· output-schema is the-structure of the-output-view written in a-lagCnpt.

name::
* McsEngl.Cnptloutput'schema,
* McsEngl.lagCnpt'schema,
* McsEngl.output-schema-of-lagCnpt,

output-concept of lagCnpt

description::
· a-model of an-input-concept using the-lagCnpt.

name::
* McsEngl.Cnptlcpt,
* McsEngl.lagCnpt'output-concept!⇒Cnptlcpt,

output-view of lagCnpt

description::
· a-system of output-concepts.

name::
* McsEngl.Cnptlview,
* McsEngl.lagCnpt'output-view!⇒Cnptlview,

output-worldview of lagCnpt

description::
· all the-output-views of one author.

name::
* McsEngl.Cnptlworld,
* McsEngl.lagCnpt'output-worldview!⇒Cnptlworld,

output-base of lagCnpt

description::
· the-set of output-worldviews.

name::
* McsEngl.Cnptlbase,
* McsEngl.knowledge-base-of-Cnptlmgr!⇒Cnptlbase,
* McsEngl.lagCnpt'output-base!⇒Cnptlbase,

04_manager of lagCnpt

description::
· Cnptlmgr is techInfo that USES infoDataNo.
· in literature we see it as 'knowledge-tech'.
· any computer-system, with the-programs used and the-knowledge-base created.
· the-machine we want to understand the-input conceptual-system.

name::
* McsEngl.Cnptlmgr,
* McsEngl.Cnptlmgr'(lagCnpt'manager)!⇒Cnptlmgr,
* McsEngl.Cnptlmanager!⇒Cnptlmgr,
* McsEngl.KRS'(knowledge-representation-system)!⇒Cnptlmgr,
* McsEngl.KnowledgeBased-system!⇒Cnptlmgr,
* McsEngl.concept-language-manager!⇒Cnptlmgr,
* McsEngl.concept-tech!⇒Cnptlmgr,
* McsEngl.lagCnpt'04_manager!⇒Cnptlmgr,
* McsEngl.lagCnpt'manager!⇒Cnptlmgr,
* McsEngl.lagCnpt'technology!⇒Cnptlmgr,
* McsEngl.knowledge-based-system!⇒Cnptlmgr,
* McsEngl.knowledge-representation-system!⇒Cnptlmgr,
* McsEngl.knowledge-representaion-and-reasoning-system!⇒Cnptlmgr,
* McsEngl.knowledge-management-system!⇒Cnptlmgr,
* McsEngl.knowledge-manipulation-system!⇒Cnptlmgr,
* McsEngl.knowledge-system!⇒Cnptlmgr,
* McsEngl.knowledge-technology!⇒Cnptlmgr,
* McsEngl.manager.lagCnpt!⇒Cnptlmgr,
* McsEngl.tchCpt!⇒Cnptlmgr,
* McsEngl.techCnpt!⇒Cnptlmgr,
* McsEngl.techCnpt!⇒Cnptlmgr,
* McsEngl.tech.knowledge!⇒Cnptlmgr,
* McsEngl.tech.lagCnpt!⇒Cnptlmgr,
* McsEngl.techConcept!⇒Cnptlmgr,
* McsEngl.techInfo.001-dataNo!⇒Cnptlmgr,
* McsEngl.techInfo.dataNo!⇒Cnptlmgr,

descriptionLong::
"Knowledge-Representation-System is an ENTITY (computer or not) that manages knowledge using knowledge-representation-methods, other than simple TEXT or HYPERTEXT. In other words, represents analogically brainual--sub-worldviews and semasial--sub-worldviews."
[https://synagonism.net/HSBC.2010-08-23/hSbc/krs.html#h0.1]

tech-sys of Cnptlmgr

description::
· computer, network used.

name::
* McsEngl.Cnptlmgr'tech-sys,

app of Cnptlmgr

description::
· the-application that stores and reasons the-mind-views.

name::
* McsEngl.Cnptlapp,
* McsEngl.lagCnpt'01_02_app!⇒Cnptlapp,
* McsEngl.Cnptlmgr.app!⇒Cnptlapp,

tool of Cnptlmgr

description::
· any program used, part of Cnptlapp.

name::
* McsEngl.Cnptltool,
* McsEngl.lagCnpt'01_03_tool!⇒Cnptltool,
* McsEngl.lagCnpt'tool!⇒Cnptltool,
* McsEngl.Cnptlmgr.tool,

specific-tree-of-::
* machine-learning-system,
* machine-reasoning-system,
* machine-translating-system,
* natural-language-processing-system,
* speech-recognition-system,
* speech-to-text-system,
* text-to-speech-system,

info-resource of Cnptlmgr

description::
* https://synagonism.net/HSBC.2010-08-23/hSbc/krs.html,

name::
* McsEngl.Cnptlmgr'Infrsc,

structure of Cnptlmgr

description::
* tech-system,
* application,
* base,

name::
* McsEngl.Cnptlmgr'structure,

DOING of Cnptlmgr

description::
* building-base,
* retrieving-base,
===
* development,
* encoding,
* decoding,
* quering,
* reasoning,
** integrating,

name::
* McsEngl.Cnptlmgr'doing,

doing.building-base of Cnptlmgr

description::
· info is subjective, then the-manager must-support the-construction of many worldviews.
· info must-be monosemantic and consistent; the-manager must-integrate additions to base and find inconsistencies.

name::
* McsEngl.Cnptlmgr'building-base,
* McsEngl.Cnptlmgr'doing.building-base,
* McsEngl.Cnptlmgr'storing-base,

specific-tree-of-Cnptlmgr'building::
* acquiring-base,
* validating-base,
* name-managing,
* evoluting-storage,

building.acquiring-info of Cnptlmgr

description::
· the-methods used to acquire info.
* directly by the-authors.
* collaboratively.
* automated-acquisition.
* machine-learning: reading|understanding natural-language-texts (law, science) is the-most needed function because to the-unmanaged quantity of texts today.
* sensory mechanisms.

name::
* McsEngl.Cnptlmgr'acquiring-base,
* McsEngl.Cnptlmgr'doing.acquiring-info,

acquiring.automated of Cnptlmgr

description::
"despite the-power of author-collaboration, the-amount of information will-force us to automate the-procedures.
for example, in a-future networked-economy the-computers of the-companies and households will automatically feed the-servers with new-data.
* mechanical learning.
* sensor-support: brain-organisms have sensory-systems to acquire information in order to create|update|improve their brain-worldviews. Today computers have-not sensors. In the-future they will-have." [hmnSgm AAj around {2000}]

name::
* McsEngl.Cnptlmgr'acquiring.automated,
* McsEngl.Cnptlmgr'automated-acquiring,
* McsEngl.Cnptlmgr'doing.acquiring.automated,

building.adding-info of Cnptlmgr

description::
· the-author must add info in a-natural-language and the-manager to store it in lagCnpt.
· adding concepts the-manager must-check their validity.

name::
* McsEngl.Cnptlmgr'adding-info,
* McsEngl.Cnptlmgr'doing.adding-info,

building.changing-info of Cnptlmgr

description::
· changing concepts the-manager must-check their validity.

name::
* McsEngl.Cnptlmgr'changing-info,
* McsEngl.Cnptlmgr'doing.changing-info,

building.validating-base of Cnptlmgr

description::
· of the-most important function.
· the-manager must-check the-validity of the-base.
* for Consistency on every addition, change.
* for Completeness (no holes).
* for Classification (no undefined names).
* for Clearness (no vague boundaries).

name::
* McsEngl.Cnptlmgr'validating-base,

building.name-managing of Cnptlmgr

description::
· any new name is validating by the-name-mechanism of its language.

name::
* McsEngl.Cnptlmgr'name-managing,

building.evoluting-storage of Cnptlmgr

description::
· the-universe and our knowledge about it both are constantly EVOLVING. Then the-system must-have the-ability to store and present its information evolutionarily. It must-be able to present its state of knowledge at every previous time-point.
[AAj development]

name::
* McsEngl.Cnptlmgr'evoluting-storage,

doing.retreiving-base of Cnptlmgr

description::
· info retreival must-be easy and intuitive.

name::
* McsEngl.Cnptlmgr'doing.retreiving-base,
* McsEngl.Cnptlmgr'retreiving-base,

retreiving.accessing of Cnptlmgr

description::
· the-manager must-be an-online|internet-system that anyone can-access.

name::
* McsEngl.Cnptlmgr'accessing,
* McsEngl.Cnptlmgr'doing.accessing,

retreiving.presenting of Cnptlmgr

description::
· the-manager must-present the-base in any-natural-language.
· also written and spoken languages must-supported.
· evolution of the-base and its referent must-supported.
· levels of abstraction also.

name::
* McsEngl.Cnptlmgr'doing.presenting,
* McsEngl.Cnptlmgr'presenting,

presenting.natural-language of Cnptlmgr

description::
· the-system must-can-present the-base in any natural-language.

name::
* McsEngl.Cnptlmgr'doing.presenting.natural-language,
* McsEngl.Cnptlmgr'presenting.natural-language,

presenting.worldview of Cnptlmgr

description::
· the-system must-present the-different VIEWS that exist about an-entity.
· the-system must-have the-ability to COMPARE|analyze any other text/speech against its stored-base.

name::
* McsEngl.Cnptlmgr'doing.presenting-worldviews,
* McsEngl.Cnptlmgr'presenting-worldviews,
* McsEngl.Cnptlmgr'worldviews-presenting,

presenting.evoluting of Cnptlmgr

description::
· the-system must-have the-ability to present the-evolution of an-entity AND the-evolution of our-knowledge about this entity.

name::
* McsEngl.Cnptlmgr'doing.evoluting-presenting,
* McsEngl.Cnptlmgr'evoluting-presenting,
* McsEngl.Cnptlmgr'presenting.evoluting,

presenting.levels-of-abstraction of Cnptlmgr

description::
· the-system must-have the-ability to present its knowledge in different LEVELS-OF-ABSTRACTION.
· like the-zoom-in, zoom-out functions in the-map-software, it should-present the-same entity with more or less details.

name::
* McsEngl.Cnptlmgr'doing.presenting.levels-of-abstraction,
* McsEngl.Cnptlmgr'levels-of-abstraction-presenting,
* McsEngl.Cnptlmgr'presenting.levels-of-abstraction,

retreiving.navigating of Cnptlmgr

description::
· intuitive, graphical, textual and spoken user-interface.
· quering the-system.
· question answering.
· table of contents.

name::
* McsEngl.Cnptlmgr'doing.navigating,
* McsEngl.Cnptlmgr'navigating,

navigating.natural-language of Cnptlmgr

description::
· the-user could-choose any natural-language (written|spoken).

name::
* McsEngl.Cnptlmgr'doing.navigating.natural-language,
* McsEngl.Cnptlmgr'natural-language-navigating,
* McsEngl.Cnptlmgr'navigating.natural-language,
* McsEngl.Cnptlmgr'user-interface-for-navigation,

navigating.quering of Cnptlmgr

description::
· quering in any language written or spoken.
· the-manager must-can-search RELATED concepts and not only the-entire base; for example AAj's-smart-search.

name::
* McsEngl.Cnptlmgr'doing.quering,
* McsEngl.Cnptlmgr'finding,
* McsEngl.Cnptlmgr'navigating.searching,
* McsEngl.Cnptlmgr'quering,
* McsEngl.Cnptlmgr'searching,

navigating.table-of-contents of Cnptlmgr

description::
· table-of-contents for easy navigation on any attribute of a-concept.

name::
* McsEngl.Cnptlmgr'navigating.table-of-contents,
* McsEngl.Cnptlmgr'table-of-contents-for-navigation,

retreiving.translating of Cnptlmgr

description::
· the-manager must-can-COMPUTE the-translation of the-base in any natural-language and not just store the-translation.
· any natural-language in navigation and presentation.

name::
* McsEngl.Cnptlmgr'doing.translating,
* McsEngl.Cnptlmgr'translating,

doing.thinking of Cnptlmgr

description::
· any human-thinking done by Cnptlmgr.

name::
* McsEngl.Cnptlmgr'computing!⇒Cnptlmgr'thinking,
* McsEngl.Cnptlmgr'doing.thinking!⇒Cnptlmgr'thinking,
* McsEngl.Cnptlmgr'inferencing!⇒Cnptlmgr'thinking,
* McsEngl.Cnptlmgr'reasoning!⇒Cnptlmgr'thinking,
* McsEngl.Cnptlmgr'thinking!⇒Cnptlmgr'thinking,

thinking.SPECIFIC

description::
* generalizing,
* instantiating,
* integrating,
* specializing,
* translating,

name::
* McsEngl.Cnptlmgr'thinking.specific,

thinking.modus-ponens

description::
"A rule of inference under which, given a knowledge base which contains the formulas "A" and "A implies B", one may conclude "B"."
[{2021-02-13} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#modus-ponens]

name::
* McsEngl.Cnptlmgr'thinking.modus-ponens,
* McsEngl.modus-ponens-of-Cnptlmgr,

thinking.modus-tollens

description::
"A rule of inference which can be derived from modus ponens under which, given a knowledge base which contains the formulas "Not B" and "A implies B", one may conclude "Not A"."
[{2021-02-13} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#modus-tollens]

name::
* McsEngl.Cnptlmgr'thinking.modus-tollens,
* McsEngl.modus-tollens-of-Cnptlmgr,

thinking.integrating

description::
· making it a-consistent whole.

name::
* McsEngl.knowledge-integrating,
* McsEngl.Cnptlmgr'doing.integrating,

addressWpg::
* https://en.wikipedia.org/wiki/Ontology-based_data_integration,
* https://en.wikipedia.org/wiki/Semantic_integration,
* https://en.wikipedia.org/wiki/Data_integration,

Cnptlmgr.SPECIFIC

description::
* Mcsmgr,
** Hmcsmgr,
=== generic:
* artificial-intelligence-system,
* collaborative-system,
* conceptual-graphs-system,
* decision-support-system,
* Description-logic-system,
* Design-system,
* Diagnosis-system,
* Expert-system,
* Frame-based-system,
* Java-system,
* Lisp-system,
* logic-system,
* Mcsmgr,
* ontology-system,
* planning/scheduling-system,
* process-control-system,
* rule-based-system,
* Smalltalk-system,
* web-system,
=== individual:
* CODE4,
* ConceptBase,
* Cyc,
* McsmgrAAj,
* McsmgrHitp,
* McsmgrFv,
* Protege,
* WolframAlpha,
* WordNet,

name::
* McsEngl.Cnptlmgr.specific,

Cnptlmgr.specs-division.on-lagConcept

description::
· controlled-natural-language,
· frame-based,
· logic-based,
· rule-based,
· semantic-network,

name::
* McsEngl.Cnptlmgr.specs-division.on-lagConcept,

Cnptlmgr.specs-division.on-lagPrograming

description::
* C++-system,
* Java-system,
* Lisp-system,
* Prolog-system,
* Smalltalk-system,

name::
* McsEngl.Cnptlmgr.specs-division.on-lagPrograming,

Cnptlmgr.specs-division.on-input-info

description::
* geography-system,
* history-system,
* infotech-system,
* med-system,
* physics-system,
* worldview-system,

name::
* McsEngl.Cnptlmgr.specs-division.on-input-info,

Cnptlmgr.specs-division.on-country

description::
* Canada-system,
* Eu-system,
* Usa-system,

name::
* McsEngl.Cnptlmgr.specs-division.on-country,

05_evaluation of lagCnpt

description::
· the-cons and pros of the-lagCnpt.

name::
* McsEngl.lagCnpt'05_evaluation,
* McsEngl.lagCnpt'evaluation,

expressiveness-vs-efficiency of lagCnpt

description::
"Expressiveness in a representation language is the ability to express facts, rules, and relationships quickly, easily, and in a principled and factored way.
Efficiency in a representation language is the ability to conclude new facts from existing facts as quickly and easily as possible, with as much coverage as possible...
Most natural languages, for example English, would have a high expressiveness but a low efficiency if used as a knowledge representation language".
[http://www.cyc.com/doc/handbook/oe/06-el-hl-and-the-canonicalizer.html]

name::
* McsEngl.lagCnpt'expressiveness-vs-efficiency,

info-resource of lagCnpt

name::
* McsEngl.Cnptlrsc,
* McsEngl.lagCnpt'Infrsc!⇒Cnptlrsc,

addressWpg::
*

specification of Cnptlrsc

description::
· official formal documentation of the-language.

name::
* McsEngl.Cnptlrsc'specification,
* McsEngl.lagCnpt'specification,

data-exchange-language of Cnptlrsc

description::
"A data interchange (or exchange) language/format is a language that is domain-independent and can be used for data from any kind of discipline.[9] They have "evolved from being markup and display-oriented to further support the encoding of metadata that describes the structural attributes of the information."[10]
Practice has shown that certain types of formal languages are better suited for this task than others, since their specification is driven by a formal process instead of particular software implementation needs. For example, XML is a markup language that was designed to enable the creation of dialects (the definition of domain-specific sublanguages).[11] However, it does not contain domain-specific dictionaries or fact types. Beneficial to a reliable data exchange is the availability of standard dictionaries-taxonomies and tools libraries such as parsers, schema validators, and transformation tools.[citation needed]
Popular languages used for data exchange
* RDF,
* XML,
* Atom,
* JSON,
* YAML,
* REBOL,
* Gellish"
[{2021-01-11} https://en.wikipedia.org/wiki/Data_exchange]

name::
* McsEngl.Cnptlrsc'data-exchange-language,
* McsEngl.data-exchange-language,
* McsEngl.lagCnpt'data-exchange-language,

modeling-language of Cnptlrsc

description::
"A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure."
[{2021-01-11} https://en.wikipedia.org/wiki/Modeling_language]

name::
* McsEngl.Cnptlrsc'modeling-language,
* McsEngl.lagCnpt'modeling-language,
* McsEngl.modeling-language,

formal-concept-analysis of Cnptlrsc

description::
"Formal Concept Analysis (FCA) is a method for data analysis, knowledge representation and information management that is widely unknown among information scientists in the USA even though this technology has a significant potential for applications. FCA was invented by Rudolf Wille in the early 80s (Wille, 1982). For the first 10 years, FCA was developed mainly by a small group of researchers and Wille’s students in Germany. Because of the mathematical nature of most of the publications of that time, knowledge of FCA remained restricted to a group of “insiders”. Through funded research projects, FCA was implemented in several larger-scale applications, most notably an implementation of a knowledge exploration system for civil engineering in cooperation with the Ministry for Civil Engineering of North-Rhine Westfalia (cf. Eschenfelder et al. (2000)). But these applications were not publicized widely beyond Germany."
[{2021-02-06} https://www.upriss.org.uk/papers/arist.pdf]

name::
* McsEngl.Cnptlrsc'formal-concept-analysis,
* McsEngl.FCA'(formal-concept-analysis),
* McsEngl.formal-concept-analysis,

addressWpg::
* https://upriss.github.io/fca/fcaintro.html,
* https://upriss.github.io/fca/fca.html,
* https://en.wikipedia.org/wiki/Formal_concept_analysis,

DOING of lagCnpt

name::
* McsEngl.lagCnpt'doing,

description::
* creating,
* learning,
* using,
* translating,
* support automated-reasoning,

evoluting of lagCnpt

{2021-01-01}::
=== McsHitp-creation:
· creation of current concept.

{2020-05}-lagCnpt'Google-knowledge-graph::
"The information covered by Google's Knowledge Graph grew quickly after launch, tripling its size within seven months (covering 570 million entities and 18 billion facts[3]).
By mid-2016, Google reported that it held 70 billion facts[4] and answered "roughly one-third" of the 100 billion monthly searches they handled.
By May 2020, this had grown to 500 billion facts on 5 billion entities.[5]"
[{2021-01-31} https://en.wikipedia.org/wiki/Google_Knowledge_Graph]
* McsEngl.{lagCnpt'2020-05}-Google-knowledge-graph,

{2014-11-06}-lagCnpt'Microsoft-Cortana::
· initial release.
"Cortana is a virtual assistant developed by Microsoft, which uses the Bing search engine to perform tasks such as setting reminders and answering questions for the user."
[{2021-01-26} https://en.wikipedia.org/wiki/Cortana]
* McsEngl.{lagCnpt'2014-11-06}-Microsoft-Cortana,

{2014-04-02}-lagCnpt'Amazon-Alexa::
· initial release.
· Alexa-voice-service-(AVS) provides cloud-based automatic-speech-recognition-(ASR) and natural-language-understanding-(NLU).
[{2021-01-26} https://en.wikipedia.org/wiki/Amazon_Alexa#Alexa_Voice_Service]
* McsEngl.{lagCnpt'2014-04-02}-Amazon-Alexa,

{2009-05-18}-lagCnpt'WolframAlpha::
· WolframAlpha was-released.
· it is a-computational-knowledge-engine or answer-engine developed by WolframAlpha-LLC, a-subsidiary of Wolfram-Research.
· it is an-online-service that answers factual-queries directly by computing the-answer from externally sourced "curated-data", rather than providing a-list of documents or webpages that might contain the-answer, as a-search-engine might.
[{2021-01-26} https://en.wikipedia.org/wiki/WolframAlpha]
* McsEngl.{lagCnpt'2009-05-18}-WolframAlpha,

{2004-02-10}-lagCnpt'OWL::
"The World Wide Web Consortium created the "Web Ontology Working Group" which began work on 2001-11-01 chaired by James Hendler and Guus Schreiber. The first working drafts of the abstract syntax, reference and synopsis were published in July 2002. The OWL documents became a formal W3C recommendation on 2004-02-10 and the working group was disbanded on 2004-05-31.[4]"
[http://en.wikipedia.org/wiki/Web_Ontology_Language]
* McsEngl.{lagCnpt'2004-02-10}-OWL,

{i10-2000}-lagCnpt'www::
"A number of research efforts during the mid to late 1990s explored how the idea of knowledge representation (KR) from AI could be made useful on the World Wide Web. These included languages based on HTML (called SHOE), XML (called XOL, later OIL), and various frame-based KR languages and knowledge acquisition approaches."
[http://en.wikipedia.org/wiki/Web_Ontology_Language]
* McsEngl.{lagCnpt'i10-2000}-www,

{i10-1990}-lagCnpt'expert-system::
"Rule systems have been implemented and studied since the mid-1970s and saw significant uptake in the 1980s during the height of so-called Expert Systems."
[{2007-12-02} https://en.wikipedia.org/wiki/Rule_Interchange_Format]
"An expert system, also known as a knowledge based system, is a computer program that contains the knowledge and analytical skills of one or more human experts, related to a specific subject. This class of program was first developed by researchers in artificial intelligence during the 1960s and 1970s and applied commercially throughout the 1980s."
[http://en.wikipedia.org/wiki/Expert_systems]
* McsEngl.{lagCnpt'i10-1990}-expert-system,

{1984}-lagCnpt'Cyc-project::
"In 1984, Doug Lenat started the Cyc Project with the objective of codify, in machine-usable form, millions of pieces of knowledge that comprise human common sense.
CycL presented a proprietary knowledge representation schema that utilized first-order relationships."
[{2007-12-02} http://en.wikipedia.org/wiki/Knowledge_Science]
* McsEngl.{lagCnpt'1984}-Cyc-project,

{i10-1980}-lagCnpt'frame-based-representation::
"In the field of Artificial Intelligence, a frame is a data structure introduced by Marvin Minsky in the 1970s that can be used for knowledge representation.
Roughly similar to the object-oriented paradigm, they represent classes (called frames) with certain properties called attributes or slots.
Slots may contain values, refer to other frames (relations) or contain methods.
Frames are thus a machine-usable formalization of concepts or schemata."
[http://en.wikipedia.org/wiki/Frame_language]
* McsEngl.{lagCnpt'i10-1980}-frame-based-representation,

{1972}-lagCnpt'Prolog::
"[Prolog] was developed and implemented in Marseille, France, in 1972 by Alain Colmerauer with Philippe Roussel, based on Robert Kowalski's procedural interpretation of Horn clauses.[5][6]"
[{2021-01-30} https://en.wikipedia.org/wiki/Prolog]
* McsEngl.{lagCnpt'1972}-Prolog,

{1969}-lagCnpt'logic-programing::
"However, the first proposal to use the clausal form of logic for representing computer programs was made by Cordell Green (1969). This used an axiomatization of a subset of LISP, together with a representation of an input-output relation, to compute the relation by simulating the execution of the program in LISP."
[http://en.wikipedia.org/wiki/Logic_programming]
* McsEngl.{lagCnpt'1969}-logic-programing,

{i10-1970}-lagCnpt'frames::
"From the 1960s, the knowledge frame or just frame has been used. Each frame has its own name and a set of attributes, or slots which contain values; for instance, the frame for house might contain a color slot, number of floors slot, etc."
[http://en.wikipedia.org/wiki/Knowledge_representation]
* McsEngl.{lagCnpt'i10-1970}-frames,

name::
* McsEngl.lagCnpt'evoluting,

WHOLE-PART-TREE of lagCnpt

name::
* McsEngl.lagCnpt'whole-part-tree,

whole-tree-of-lagCnpt::
*
* ... Sympan.

part-tree-of-lagCnpt::
*

GENERIC-SPECIFIC-TREE of lagCnpt

name::
* McsEngl.lagCnpt'generic-specific-tree,

generic-tree-of-lagCnpt::
* naturalNo-human-mind--language,
* ... entity.

specific-tree-of-lagCnpt::
* processing-lagCnpt,
* representation-lagCnpt,
* processing-and-representation-lagCnpt,
===
* general-purpose,
* generalNo-purpose,
===
* explicit-krl,
* explicitNo,
===
* uniform,
* uniformNo,
===
* common-logic,
* concept-mapping,
* conceptual-graph,
* controlled-natural-language,
* description-logics,
* entity-attribute-value,
* first-order-logic,
* formal-concept-analysis,
* frame-based,
* knowledge-graph,
* logic-krl,
* ontology-krl,
* propositional-lagCnpt,
* semantic-network,
* topic-maps,
* visual,
===
* Cycl,
* KIF,
* KL_ONE,
* loom,
* OWL,
* RDF,
* RIF,
* SHOE,

lagCnpt.structure-001

description::
· it models the-structure of mind-concepts.

name::
* McsEngl.KRL'(knowledge-representation-language)!⇒lagCtsr,
* McsEngl.descriptive-concept-language!⇒lagCtsr,
* McsEngl.knowledge-representation-language!⇒lagCtsr,
* McsEngl.lagCnpt.001-representation!⇒lagCtsr,
* McsEngl.lagCnpt.representation!⇒lagCtsr,
* McsEngl.lagCtsr,
* McsEngl.lagCtst'(structure-lagCnpt)!⇒lagCtsr,
* McsEngl.representation-lagCnpt!⇒lagCtsr,
* McsEngl.structure-lagCnpt!⇒lagCtsr,

lagCnpt.doing-002

description::
· it models the-doings-(inferencing, quering, computing) of mind-concepts.

name::
* McsEngl.doing-lagCnpt!⇒lagCtdg,
* McsEngl.lagCnpt.002-processing!⇒lagCtdg,
* McsEngl.lagCnpt.processing!⇒lagCtdg,
* McsEngl.lagCtdg,
* McsEngl.lagCtdg'(doing-concept-language)!⇒lagCtdg,
* McsEngl.procedural-concept-language!⇒lagCtdg,
* McsEngl.processing-knowledge-language!⇒lagCtdg,

lagCnpt.structure-and-doing-003

description::
· it model the-structure and doings of mind-concepts.

name::
* McsEngl.doing-and-structure--lagCnpt!⇒lagCsad,
* McsEngl.lagCnpt.003-representation-and-processing!⇒lagCsad,
* McsEngl.lagCnpt.representation-and-processing!⇒lagCsad,
* McsEngl.lagCsad,
* McsEngl.lagCsad'(structure-and-doing-lagCnpt!⇒lagCsad,
* McsEngl.processing-and-structure--lagCnpt!⇒lagCsad,
* McsEngl.reasoning-and-representation--lagCnpt!⇒lagCsad,
* McsEngl.representation-and-reasoning--lagCnpt!⇒lagCsad,
* McsEngl.structure-and-doing--lagCnpt!⇒lagCsad,

lagCnpt.textual-033

description::
· the-output comprised of text.

name::
* McsEngl.lagCnpt.033-textual!⇒lagCtxt,
* McsEngl.lagCnpt.textual!⇒lagCtxt,
* McsEngl.lagCtxt,
* McsEngl.lagCtxt'(textual-lagCnpt)!⇒lagCtxt,

lagCnpt.visual-034

description::
· the-output comprised of images.

name::
* McsEngl.lagCnpt.034-visual!⇒lagCvsl,
* McsEngl.lagCnpt.visual!⇒lagCvsl,
* McsEngl.lagCvsl,
* McsEngl.lagCvsl'(visual-lagCnpt)!⇒lagCvsl,

lagCvsl.UML

description::
"The Unified Modeling Language™ (UML®) is a standard visual modeling language intended to be used for
* modeling business and similar processes,
* analysis, design, and implementation of software-based systems
UML is a common language for business analysts, software architects and developers used to describe, specify, design, and document existing or new business processes, structure and behavior of artifacts of software systems.
UML can be applied to diverse application domains (e.g., banking, finance, internet, aerospace, healthcare, etc.) It can be used with all major object and component software development methods and for various implementation platforms (e.g., J2EE, .NET)."
[{2021-02-07} https://www.uml-diagrams.org/]

name::
* McsEngl.UML'(unified-modeling-language)!⇒lagUmlg,
* McsEngl.lagCnpt.035-UML!⇒lagUmlg,
* McsEngl.lagCnpt.UML!⇒lagUmlg,
* McsEngl.lagCvsl.UML!⇒lagUmlg,

lagCvsl.concept-mapping

description::
"A concept map or conceptual diagram is a diagram that depicts suggested relationships between concepts.[1] Concept maps may be used by instructional designers, engineers, technical writers, and others to organize and structure knowledge.
A concept map typically represents ideas and information as boxes or circles, which it connects with labeled arrows, often in a downward-branching hierarchical structure. The relationship between concepts can be articulated in linking phrases such as "causes", "requires", "such as" or "contributes to".[2]
The technique for visualizing these relationships among different concepts is called concept mapping. Concept maps have been used to define the ontology of computer systems, for example with the object-role modeling or Unified Modeling Language formalism."
[{2021-03-19} https://en.wikipedia.org/wiki/Concept_map]

name::
* McsEngl.concept-mapping,
* McsEngl.lagCnpt.038-concept-mapping,
* McsEngl.lagCnpt.concept-mapping,

lagCnpt.McsHitp-007 (link)

lagCnpt.frame-037

description::
·

name::
* McsEngl.frame-and-slot-language!⇒lagFram,
* McsEngl.frame-language!⇒lagFram,
* McsEngl.lagCnpt.037-frame!⇒lagFram,
* McsEngl.lagFram,
* McsEngl.lagFram'(frame-language)!⇒lagFram,

tech of lagFram

description::
·

name::
* McsEngl.lagFram'tech,

input of lagFram

description::
·

name::
* McsEngl.lagFram'input,

output of lagFram

description::
·

name::
* McsEngl.lagFram'output,

frame of lagFram

description::
·

name::
* McsEngl.Framframe,
* McsEngl.frame-of-lagFram!⇒Framframe,
* McsEngl.lagFram'frame!⇒Framframe,
* McsEngl.lagFram'script!⇒Framframe,

evaluation of lagFram

description::
·

name::
* McsEngl.lagFram'evaluation,

info-resource of lagFram

description::
·

name::
* McsEngl.lagFram'Infrsc,

evoluting of lagFram

description::
·

name::
* McsEngl.lagFram'evoluting,

lagFram.SPECIFIC

description::
* CycL,
* KEE,
* KL-ONE,
* KRL,
* Loom,

name::
* McsEngl.lagFram.specific,

lagCnpt.propositional-011

description::
· propositional-language is a-lagConcept that uses simple propositions-(subject-relation|doing-object) as output to map mind-concepts.

name::
* McsEngl.lagCnpt.011-propositional!⇒lagPpsl,
* McsEngl.lagCnpt.propositional!⇒lagPpsl,
* McsEngl.lagPpsl,
* McsEngl.lagPpsl'(propositional-lagCnpt)!⇒lagPpsl,
* McsEngl.propositional-lagCnpt!⇒lagPpsl,
* McsEngl.propositional-language!⇒lagPpsl,

input of lagPpsl

description::
· a-mind-view we want to map with the-propositional-language.

name::
* McsEngl.Ppslinput,
* McsEngl.lagPpsl'input!⇒Ppslinput,

concept of lagPpsl

description::
· any mind-concept of lagPpsl'input.

name::
* McsEngl.Ppslconcept,
* McsEngl.lagPpsl'concept!⇒Ppslconcept,
* item@lagWkdt,

concept.generic of lagPpsl

description::
· a-generic-concept.

name::
* McsEngl.Ppslgeneric,
* McsEngl.lagPpsl'concept.generic!⇒Ppslgeneric,
* McsEngl.lagPpsl'generic-concept!⇒Ppslgeneric,
* class@lagRdfw@lagOwlg,
* concept@lagDlgc,
* unary-predicate@lagFolc,

concept.instance of lagPpsl

description::
· an-instance-concept.

name::
* McsEngl.Ppslinstance,
* McsEngl.lagPpsl'concept.instance!⇒Ppslinstance,
* McsEngl.lagPpsl'instance-concept!⇒Ppslinstance,
* constant@lagFolc,
* individual@lagOwlg@lagDlgc,

concept.relation-or-doing of lagPpsl

description::
· a-relation or a-doing.

name::
* McsEngl.lagPpsl'concept.relation-or-doing!⇒Ppslrord,
* McsEngl.lagPpsl'doing-or-relation,
* McsEngl.lagPpsl'relation-or-doing,
* binary-predicate@lagFolc,
* property@lagOwlg,

proposition of lagPpsl

description::
· proposition is a-directed-relation of concept->relation-or-doing->concept.

name::
* McsEngl.Ppslsentence,
* McsEngl.lagPpsl'proposition!⇒Ppslsentence,
* McsEngl.lagPpsl'statement!⇒Ppslsentence,
* McsEngl.proposition!lagPpsl!⇒Ppslsentence,

proposition-sys of lagPpsl

description::
· a-system of propositions.

name::
* McsEngl.Ppslsys,
* McsEngl.lagPpsl'proposition-sys!⇒Ppslsys,

output of lagPpsl

description::
· the-model that maps the-lagPpsl'input.

name::
* McsEngl.Ppsloutput,
* McsEngl.lagPpsl'output!⇒Ppsloutput,

output-concept of lagPpsl

description::
· the-model that maps an-input-concept.

name::
* McsEngl.Ppsloconcept,
* McsEngl.lagPpsl'output-concept!⇒Ppsloconcept,

output-proposition of lagPpsl

description::
· the-model that maps the-Ppslsentence.

name::
* McsEngl.Ppslosentence,
* McsEngl.lagPpsl'output-proposition!⇒Ppslosentence,
* McsEngl.output-proposition-of-lagPpsl!⇒Ppslosentence,

output-proposition-sys of lagPpsl

description::
· the-model that maps a-Ppslsys.

name::
* McsEngl.Ppslosys,
* McsEngl.lagPpsl'output-set!⇒Ppslosys,
* dataset,
* knowledge-base@lagWkdt,
* ontology@lagOntg,
* vocabulary,

evaluation of lagPpsl

description::
· the-inventors of propositional-languages do-not-understand that the-input is mind-concepts.
· that is why we see expressions like that they represent "entities, concepts, objects, attributes, properties" of the-real-world (domain of discourse).
===
· "the-first" airplanes had movable wings.
· the-same, propositional-languages model the-sentences of human-languages which in-turn are models of conceptual-views.
· we need to model directly the-conceptual-views. [hmnSgm.{2021-02-13}]

name::
* McsEngl.lagPpsl'evaluation,

lagPpsl.SPECIFIC

description::
* first-order-logic-language,
* ontology-language,

name::
* McsEngl.lagPpsl.specific,

lagPpsl.wikidata

description::
· wikidata-language is a-propositional-language that manages the-data collaborativelly.

name::
* McsEngl.lagCnpt.017-wikidata!⇒lagWkdt,
* McsEngl.lagCnpt.wikidata!⇒lagWkdt,
* McsEngl.lagPpsl.wikidata!⇒lagWkdt,
* McsEngl.lagWkdt,
* McsEngl.lagWkdt'(wikidata-lagPpsl)!⇒lagWkdt,
* McsEngl.wikidata-lagPpsl!⇒lagWkdt,

descriptionLong::
"Wikidata is the free knowledge base that anyone can edit. Just like Wikipedia, Wikidata is built on the MediaWiki wiki package which means that content on pages (just like this one!) can be added, modified, or deleted in collaboration with others. Unlike Wikipedia, Wikidata also uses Wikibase software which allows for collaborative editing of structured data."
[{2021-01-25} https://www.wikidata.org/wiki/Help:Items]
===
"Wikidata is a free, collaborative, multilingual, secondary database, collecting structured data to provide support for Wikipedia, Wikimedia Commons, the other wikis of the Wikimedia movement, and to anyone in the world."
[{2021-01-25} https://www.wikidata.org/wiki/Wikidata:Introduction]

input of lagWkdt

description::
·

name::
* McsEngl.lagWkdt'input,

output of lagWkdt

description::
·

name::
* McsEngl.lagWkdt'output,

output-concept-(item) of lagWkdt

description::
"In Wikidata, items are used to represent all the things in human knowledge, including topics, concepts, and objects. For example, the "1988 Summer Olympics", "love", "Elvis Presley", and "gorilla" are all items in Wikidata."
[{2021-01-25} https://www.wikidata.org/wiki/Help:Items]

name::
* McsEngl.Wkdtitem,
* McsEngl.item@lagWkdt!⇒Wkdtitem,
* McsEngl.lagWkdt'output-concept!⇒Wkdtitem,

output-concept.relation-or-doing-(property) of lagWkdt

description::
"A property describes the data value of a statement and can be thought of as a category of data, for example "color" for the data value "blue". Properties, when paired with values, form a statement in Wikidata. Properties are also used in qualifiers.
Properties have their own pages on Wikidata and are connected to items, resulting in a linked data structure."
[{2021-01-25} https://www.wikidata.org/wiki/Help:Properties]
"As opposed to Items, Properties do not refer to Wikipedia pages, but they do specify a Datatype for the data that they (usually) store."
[{2021-01-25} https://www.mediawiki.org/wiki/Wikibase/DataModel]

name::
* McsEngl.Wkdtproperty,
* McsEngl.lagWkdt'relation-or-doing!⇒Wkdtproperty,
* McsEngl.property@lagWkdt!⇒Wkdtproperty,

label of Wkdtproperty

description::
· the-main-name of a-Wkdtproperty.

name::
* McsEngl.Wkdtproperty'label,

ID of Wkdtproperty

description::
"Like items, properties also have a unique identifier. While items begin with a Q prefix and are found in the main namespace of Wikidata, properties have a P prefix and are stored in the property namespace."
[{2021-01-25} https://www.wikidata.org/wiki/Help:Properties]

name::
* McsEngl.Wkdtproperty'Id,

alias of Wkdtproperty

description::
· synonyms.

name::
* McsEngl.Wkdtproperty'alias,

description of Wkdtproperty

description::
· text that explains the-meaning of the-Wkdtproperty.

name::
* McsEngl.Wkdtproperty'description,

datatype of Wkdtproperty

description::
"Each property does have what is known as a data type which defines the kind of values allowed in statements with that property."
[{2021-01-25} https://www.wikidata.org/wiki/Help:Properties]

name::
* McsEngl.Wkdtproperty'datatype,

info-resource of Wkdtproperty

description::
* https://www.wikidata.org/wiki/Wikidata:Property_creators,
* https://www.wikidata.org/wiki/Wikidata:Property_proposal,

name::
* McsEngl.Wkdtproperty'Infrsc,

Wkdtproperty.SPECIFIC

description::
"On this page, you will find several lists of the currently 8,364 properties in Wikidata."
[{2021-01-25} https://www.wikidata.org/wiki/Wikidata:List_of_properties]
===
* art, art collection,
* asymmetric relation,
* author's rights,
* award,
* causality,
* e-commerce,
* graph,
* human,
* identity, equality,
* judiciary,
* link rot,
* MediaWiki page,
* number of entities,
* obsolete Wikidata property,
* occurrence,
* orderable Wikidata property,
* ownership,
* perception,
* personal life,
* politics,
* pornography, erotica,
* position,
* reflexive property,
* research,
* science,
* slavery,
* spacecraft,
* streaming media,
* symmetric relation,
* time, duration,
* transitive relation,
* transport,
* unique identifier,
* Wikidata property associated with websites,
* Wikidata property encoding a vCard value,
* Wikidata property for an identifier that generally has just one value, but rarely can have two or more values for the same entity,
* Wikidata property for an identifier value that can replaced,
* Wikidata property for properties,
* Wikidata property for the relationship between classes,
* Wikidata property for Wikivoyage,
* Wikidata property in special need of sourcing,
* Wikidata property linking to a representative image,
* Wikidata property using many other properties as qualifiers,
* Wikidata property with a single value that generally evolves over time,
* Wikidata property with a single value, but different precisions and references can lead to multiple values,
* Wikidata property with datatype string that is not an external identifier,
* Wikidata qualifier,
* Wikidata sandbox property,
* Wikipedia:Citing sources,
* woman, feminism,
* work,

name::
* McsEngl.Wkdtproperty.specific,

output-proposition of lagWkdt

description::
·

name::
* McsEngl.Wkdtstatement,
* McsEngl.lagWkdt'output-proposition!⇒Wkdtstatement,
* McsEngl.statement@lagWkdt!⇒Wkdtstatement,

claim of Wkdtstatement

description::
"The core part of a statement without references and ranks is also called claim. A claim without qualifiers is also referred to as snak."
[{2021-01-25} https://www.wikidata.org/wiki/Help:Statements]
"Statements are the main approach of representing factual data, such as the population number in the above example. A Statement consists of two parts: a claim that something is the case (e.g., the claim "Berlin has a population of 3,499,879") and a list of references for that claim (e.g., a publication by the statistical office for Berlin-Brandenburg)."
[{2021-01-25} https://www.mediawiki.org/wiki/Wikibase/DataModel]

name::
* McsEngl.Wkdtstatement'claim,
* McsEngl.claim@lagWkdt,

snak of Wkdtstatement

description::
"The core part of a statement without references and ranks is also called claim.
A claim without qualifiers is also referred to as snak."
[{2021-01-25} https://www.wikidata.org/wiki/Help:Statements]

name::
* McsEngl.Wkdtstatement'snak,
* McsEngl.snak@lagWkdt,

qualifier of Wkdtstatement

description::
· the-other verb-arguments of a-sentence except subject-target.

name::
* McsEngl.Wkdtstatement'qualifier,
* McsEngl.qualifier@lagWkdt,

descriptionLong::
"Along with sources and ranks, qualifiers allow statements to be expanded on, annotated, or contextualized beyond what can be expressed in just a simple property-value pair.
Qualifiers are used in order to further describe or refine the value of a property given in a statement. Note that a statement should still provide useful data even without a qualifier; the qualifier is just there to provide additional information.
Like statements and references, qualifiers also consist of a property and a value."
[{2021-01-25} https://www.wikidata.org/wiki/Help:Qualifiers]

references-list of Wkdtstatement

description::
"Statements are the main approach of representing factual data, such as the population number in the above example. A Statement consists of two parts: a claim that something is the case (e.g., the claim "Berlin has a population of 3,499,879") and a list of references for that claim (e.g., a publication by the statistical office for Berlin-Brandenburg).
The reference is given by a ReferenceRecord, and the list of references is allowed to be empty (like in Wikipedia, editors can add Statements without a reference, which might later be improved by others who know about a suitable reference)."
[{2021-01-25} https://www.mediawiki.org/wiki/Wikibase/DataModel]

name::
* McsEngl.Wkdtstatement'references-list,
* McsEngl.Wkdtstatement'source,
* McsEngl.reference@lagWkdt,

descriptionLong::
"The majority of statements on Wikidata should be verifiable, they should be supported by a source of information such as a book, scientific publication, or newspaper article. In Wikidata, references are used to point to specific sources that back up the data provided in a statement.
References, like statements, also consist of at least one property-value pair (for a reference, the value is the source). Typically the property used for sources is one of two options: stated in (P248) (referring to publications and media) and reference URL (P854) (used for websites and online databases)."
[{2021-01-25} https://www.wikidata.org/wiki/Help:Sources]

rank of Wkdtstatement

description::
"References merely state where a data value comes from; ranks indicate what data value is considered the most correct and, by extension, what values should be included in queries.
Ranks are not a way of asserting your view for a disputed value, but instead are used for communicating the consensus opinion for a statement. All disputes should be discussed on the item's discussion page. Edit warring over values is not acceptable.
There is however another way to state that a statement is disputed and by whom: the qualifier statement disputed by (P1310)."
[{2021-01-25} https://www.wikidata.org/wiki/Help:Ranking]

name::
* McsEngl.Wkdtstatement'rank,

output-proposition-sys of lagWkdt

description::
· the-system of Wkdtstatements.

name::
* McsEngl.Wkdtkb,
* McsEngl.knowledge-base@lagWkdt!⇒Wkdtkb,
* McsEngl.lagWkdt'output-proposition-sys!⇒Wkdtkb,

tool of lagWkdt

description::
· There are a number of ways to access Wikidata using built-in tools, external tools, or programming interfaces.

name::
* McsEngl.lagWkdt'tool,

specific-tree-of-lagWkdt'tool::
* https://www.wikidata.org/wiki/Wikidata:Tools,
* https://query.wikidata.org/,
* https://reasonator.toolforge.org/,
* https://www.wikidata.org/wiki/Wikidata:Tools/Edit_items,

info-resource of lagWkdt

description::
* https://www.wikidata.org/wiki/Wikidata:Main_Page,
* https://www.wikidata.org/wiki/Wikidata:Introduction,
* https://www.wikidata.org/wiki/Help:Items,
* https://www.wikidata.org/wiki/Help:Properties,
* https://www.wikidata.org/wiki/Help:Statements,
* https://www.mediawiki.org/wiki/Wikibase/DataModel/Primer,
* https://www.mediawiki.org/wiki/Wikibase/API,

name::
* McsEngl.lagWkdt'Infrsc,

lagPpsl.entity-attribute-value-model

description::
"Entity–attribute–value model (EAV) is a data model to encode, in a space-efficient manner, entities where the number of attributes (properties, parameters) that can be used to describe them is potentially vast, but the number that will actually apply to a given entity is relatively modest. Such entities correspond to the mathematical notion of a sparse matrix.
EAV is also known as object–attribute–value model, vertical database model, and open schema."
[{2021-01-24} https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model]

name::
* McsEngl.lagCnpt.012-entity-attribute-value-model,
* McsEngl.lagCnpt.entity-attribute-value-model,
* McsEngl.lagPpsl.entity-attribute-value-model,

lagPpsl.attribute-value-system

description::
"An attribute-value system is a basic knowledge representation framework comprising a table with columns designating "attributes" (also known as "properties", "predicates", "features", "dimensions", "characteristics", "fields", "headers" or "independent variables" depending on the context) and "rows" designating "objects" (also known as "entities", "instances", "exemplars", "elements", "records" or "dependent variables").
Each table cell therefore designates the value (also known as "state") of a particular attribute of a particular object."
[{2021-01-24} https://en.wikipedia.org/wiki/Attribute-value_system]

name::
* McsEngl.lagCnpt.013-attribute-value-system,
* McsEngl.lagCnpt.attribute-value-system,
* McsEngl.lagPpsl.attribute-value-system,

lagPpsl.Gellish

description::
"Information that is expressed in a Gellish formal language is computer interpretable and application system independent. It enables data exchange, data storage, data integration and systems interoperability without the need for data model harmonization or data conversion."
[{2021-01-29} http://wiki.gellish.net/start]

name::
* McsEngl.Gellish-language!⇒lagGlsh,
* McsEngl.lagCnpt.019-Gellish!⇒lagGlsh,
* McsEngl.lagCnpt.Gellish!⇒lagGlsh,
* McsEngl.lagGlsh,
* McsEngl.lagPpsl.Gellish!⇒lagGlsh,

descriptionLong::
"Gellish is an ontology language for data storage and communication, designed and developed by Andries van Renssen since mid-1990s.[1] It started out as an engineering modeling language ("Generic Engineering Language", giving it the name, "Gellish") but evolved into a universal and extendable conceptual data modeling language with general applications. Because it includes domain-specific terminology and definitions, it is also a semantic data modelling language and the Gellish modeling methodology is a member of the family of semantic modeling methodologies.
Although its concepts have 'names' and definitions in various natural languages, Gellish is a natural-language-independent formal language. Any natural language variant, such as Gellish Formal English is a controlled natural language. Information and knowledge can be expressed in such a way that it is computer-interpretable, as well as system-independent and natural language independent. Each natural language variant is a structured subset of that natural language and is suitable for information modeling and knowledge representation in that particular language. All expressions, concepts and individual things are represented in Gellish by (numeric) unique identifiers (Gellish UID's). This enables software to translate expressions from one formal natural language to any other formal natural languages."
[{2021-01-29} https://en.wikipedia.org/wiki/Gellish]

output of lagGlsh

description::
"The structure of expressions in the Gellish language (its syntax) is defined in the tabular standard Gellish Expression Format, which can be stored in formats such as CSV or JSON. Other formats are also possible."
[{2021-01-29} http://wiki.gellish.net/start]

name::
* McsEngl.lagGlsh'output,

dictionary of lagGlsh

description::
"Another advantage of Gellish is that its definition includes an electronic Taxonomic Dictionary that provides the concepts and terminology of the language, whereas the dictionary is extensible by any user. The power of a taxonomic dictionary is that all defined concepts inherit the knowledge about all their supertype concepts. This greatly simplifies searching and retrieval of information and it eliminates the need for re-specifying knowledge for subtypes of defined concepts. Each concept in the dictionary is identified by a natural language independent unique identifier (UID) whereas they are denoted by various terms in the formalized natural languages. The use of UIDs for representing the concepts independent of language causes that models and data structures become language independent. This enables that information that is expressed in one of the formal languages can be automatically translated by Gellish enabled software from that one formalized language to any other language. For example, queries in Formal Dutch, can be executed on databases that are in English, and the queries as well as the results can be presented to users in Dutch or any other language and vice versa. This is possible between any languages for which formal dictionaries are available."
[{2021-01-29} http://wiki.gellish.net/start]
===
"the Gellish Dictionary-Taxonomy contains more than 40,000 concepts."
[{2021-01-29} https://en.wikipedia.org/wiki/Gellish]

name::
* McsEngl.lagGlsh'dictionary,

lagCnpt.ontology-language-016

description::
"In computer science and artificial intelligence, ontology languages are formal languages used to construct ontologies. They allow the encoding of knowledge about specific domains and often include reasoning rules that support the processing of that knowledge. Ontology languages are usually declarative languages, are almost always generalizations of frame languages, and are commonly based on either first-order logic or on description logic."
[{2021-01-26} https://en.wikipedia.org/wiki/Ontology_language]

name::
* McsEngl.lagCnpt.016-ontology-language!⇒lagOntg,
* McsEngl.lagCnpt.ontology-language!⇒lagOntg,
* McsEngl.lagOntg,
* McsEngl.lagOntg'(ontology-language)!⇒lagOntg,
* McsEngl.lagPpsl.ontology-language!⇒lagOntg,

input of lagOntg

description::
· the-info we want to map with lagOntg.

name::
* McsEngl.lagOntg'input,

output of lagOntg

description::
· a-model that maps the-input.
· ontology I call the-outermost system that models an-input.

name::
* McsEngl.lagOntg'output!⇒ontology,
* McsEngl.lagOntg'ontology!⇒ontology,
* McsEngl.ontology,

descriptionLong::
"In information science a conceptualization is an abstract simplified view of some selected part of the world, containing the objects, concepts, and other entities that are presumed of interest for some particular purpose and the relationships between them.[2][3] An explicit specification of a conceptualization is an ontology, and it may occur that a conceptualization can be realized by several distinct ontologies.[2]"
[{2021-01-27} https://en.wikipedia.org/wiki/Conceptualization_(information_science)]
· the-above text shows the-confusion on what a-concept is and consequently an-ontology.
===

vocabulary of ontology

description::
· vocabulary-of-ontology I call the-set of the-names of the-concepts of the-ontology.
· the-ontology contains and the-relations and doings of the-concepts of the-ontology.

name::
* McsEngl.ontology'vocabulary,
* McsEngl.vocabulary-of-ontology,

doing of ontology

description::
* creation-of-ontology,
* alignment-of-ontology,

name::
* McsEngl.ontology'doing,

creation of ontology

description::
"Ontology learning (ontology extraction, ontology generation, or ontology acquisition) is the automatic or semi-automatic creation of ontologies, including extracting the corresponding domain's terms and the relationships between the concepts that these terms represent from a corpus of natural language text, and encoding them with an ontology language for easy retrieval. As building ontologies manually is extremely labor-intensive and time-consuming, there is great motivation to automate the process.
Typically, the process starts by extracting terms and concepts or noun phrases from plain text using linguistic processors such as part-of-speech tagging and phrase chunking. Then statistical[1] or symbolic[2][3] techniques are used to extract relation signatures, often based on pattern-based[4] or definition-based[5] hypernym extraction techniques."
[{2021-01-27} https://en.wikipedia.org/wiki/Ontology_learning]

name::
* McsEngl.ontology'building,
* McsEngl.ontology'creation,
* McsEngl.ontology'generation,

alignment of ontology

description::
"Ontology alignment, or ontology matching, is the process of determining correspondences between concepts in ontologies. A set of correspondences is also called an alignment. The phrase takes on a slightly different meaning, in computer science, cognitive science or philosophy."
[{2021-01-27} https://en.wikipedia.org/wiki/Ontology_alignment]

name::
* McsEngl.ontology'alignment,
* McsEngl.ontology'matching,

ontology.SPECIFIC

description::
* generic-ontology,
* specific-ontology,
===
* bibliographic-ontology,
* biomedical-ontology,
===
* dc="http://purl.org/dc/elements/1.1/",
* foaf="http://xmlns.com/foaf/0.1/",
* ontology="http://data.europa.eu/eli/ontology#",
* owl="http://www.w3.org/2002/07/owl#",
* rdakit="http://metadataregistry.org/uri/profile/rdakit/",
* rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#",
* rdfs="http://www.w3.org/2000/01/rdf-schema#",
* regap="http://metadataregistry.org/uri/profile/regap/",
* skos="http://www.w3.org/2004/02/skos/core#",
* terms="http://purl.org/dc/terms/",
* vann="http://purl.org/vocab/vann/",
* xml="http://www.w3.org/XML/1998/namespace",
* xsd="http://www.w3.org/2001/XMLSchema#",

name::
* McsEngl.ontology.specific,

ontology.upper

description::
"Upper ontologies (top-level or foundational ontologies) represent universal concepts and properties, independent from single scientific fields, such as event, space, time, dimension, substance, phenomenon, identity, process, quantity, etc., on which a general consensus of large user communities should be achieved. The main aim of foundational ontologies is to allow multiple artificial agents to cooperate with each other and with humans. To achieve this, foundational ontologies “negotiate meaning” and help for “establishing consensus in a mixed society” (Gangemi et al. 2002)."
[{2021-01-26} https://www.isko.org/cyclo/ontologies#5]

name::
* McsEngl.foundational-ontology,
* McsEngl.general-ontology,
* McsEngl.ontology.upper,
* McsEngl.top-level-ontology,
* McsEngl.upper-ontology,

ontology.domain

description::
"Domain ontologies conceptualize the specific realm of a field of knowledge or a particular task specifying the contents of the general categories provided by a top-level ontology. Domain ontologies offer a model of detailed knowledge, on which there may be substantial sharing of meanings already."
[{2021-01-26} https://www.isko.org/cyclo/ontologies#5]

name::
* McsEngl.domain-ontology,
* McsEngl.ontology.domain,

ontology.bibliographic

description::
"A particular attention must be paid to bibliographic ontologies, which enable the description of entities that belong to the bibliographic set, such as textual publications (e.g., articles, monographs, and series) and web pages, datasets, films etc., and define the relationships among these bibliographic entities (Nurmikko-Fuller et al. 2015; 2016). Besides, bibliographic ontologies have been built to define specific relationships, such as authorship, editorship, and aboutness among entities, as well as the relationships that connect → works (Smiraglia 2019) and their abridgments, adaptations, and translations. They can underline the relationships between a serial and the transformations it may have had over time, such as supplements or successors."
[{2021-01-26} https://www.isko.org/cyclo/ontologies#6.1]

name::
* McsEngl.bibliographic-ontology,
* McsEngl.ontology.bibliographic,

ontology.biomedical

description::
"In biological and medical domain, controlled vocabularies of terms and relations are used to share information and several domain ontologies have been developed. A consortium of ontology developers — The Open Biological and Biomedical Ontology (OBO) Foundry — was founded in 2001 to define shared principles for developing interoperable ontologies in biomedicine. The principles include the collaborative development of ontologies and the use of a common syntax (RDF/XML); use based on most prominent models such as the Gene Ontology; and the provision of open access. The library of ontologies encompasses the BFO upper ontology and domain ontologies such as the Gene Ontology, the Disease Ontology, the Plant Ontology, the Protein Ontology, the Cell Ontology, the Coronavirus Ontology and so on. The Gene Ontology (GO), developed in 1998, describes the biological domain considering three aspects: cellular components, that is, the parts of the cell; biological processes, such as chemical reactions or metabolism; and molecular functions. Thus, the GO consists of three ontologies, each one devoted to one aspect. The GO is a dynamic vocabulary that allows description of the functions and activities performed by the gene products, that is, the macromolecules, across different organisms, enabling the analysis of genomic data. The three ontologies may be used to query a database of gene product functions."
[{2021-01-26} https://www.isko.org/cyclo/ontologies#6.3]

name::
* McsEngl.biomedical-ontology,
* McsEngl.ontology.biomedical,

BioPortal of ontology.biomedical

description::
* https://bioportal.bioontology.org/,
* http://data.bioontology.org/property_search?q=has%20dimension,
===
"BioPortal provides access to commonly used biomedical ontologies and to tools for working with them. BioPortal allows you to
* browse the library of ontologies
* search for a term across multiple ontologies
* browse mappings between terms in different ontologies
* receive recommendations on which ontologies are most relevant for a corpus
* annotate text with terms from ontologies
* search biomedical resources for a term
* browse a selection of projects that use BioPortal resources
All information available through the BioPortal Web site is also available through the NCBO Web service REST API."
[{2021-02-01} https://www.bioontology.org/wiki/BioPortal_Help]

name::
* McsEngl.BioPortal,

statistics of BioPortal

description::
× Ontologies, 838
× Classes, 9,708,407
× Properties, 36,286
× Mappings, 78,104,619
[{2021-02-01} https://bioportal.bioontology.org/]

name::
* McsEngl.BioPortal'statistics,

ontology.Dublic-Core

description::
"The Dublin Core Metadata Initiative maintains a metadata element set for describing a wide range of resources. The vocabulary provides properties such as "creator", "publisher" and "title"."
[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/#section-vocabulary]

name::
* McsEngl.Dublin-core-Rdfvoc,
* McsEngl.Rdfvoc.Dublin-core,
* McsEngl.dc-ontology,
* McsEngl.ontology.Dublic-Core,
* McsEngl.ontology.dc,

ontology.foaf

description::
"One of the first RDF vocabularies used worldwide was the "Friend of a Friend" (FOAF) vocabulary for describing social networks."
[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/#section-vocabulary]

name::
* McsEngl.FOAF-Rdfvoc!⇒foaf,
* McsEngl.Rdfvoc.FOAF!⇒foaf,
* McsEngl.foaf,
* McsEngl.foaf'(friend-of-a-friend-vocabulary)!⇒foaf,
* McsEngl.foaf-ontology,
* McsEngl.ontology.foaf,

class of foaf

description::
· RDF-classes.

name::
* McsEngl.foaf'class,

foaf:Agent-class::
× sDescription: Agent - An agent (eg. person, group, software or physical artifact).
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_Agent
× sStatus: stable
× aProperties-include: [gender, yahooChatID, account, birthday, icqChatID, aimChatID, jabberID, made, mbox, interest, tipjar, skypeID, topic_interest, age, mbox_sha1sum, status, msnChatID, openid, holdsAccount, weblog]
× aUsed-with: [maker, member]
× aHas-subclass: [Group, Person, Organization]

× sDescriptionLong: The Agent class is the class of agents; things that do stuff. A well known sub-class is Person, representing people. Other kinds of agents include Organization and Group.
The Agent class is useful in a few places in FOAF where Person would have been overly specific. For example, the IM chat ID properties such as jabberID are typically associated with people, but sometimes belong to software bots.
* McsEngl.foaf/Agent,
* McsEngl.Agent@foaf,

foaf:Document-class::
× sDescription: Document - A document.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_Document
× sStatus: stable
× aProperties-include: [topic, primaryTopic, sha1]
× aUsed-with: [workInfoHomepage, workplaceHomepage, page, accountServiceHomepage, openid, tipjar, schoolHomepage, publications, isPrimaryTopicOf, interest, homepage, weblog]
× aHas-subclass: [Image, PersonalProfileDocument]
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× aDisjoint-with: [Project, Organization]

× sDescriptionLong: The Document class represents those things which are, broadly conceived, 'documents'.
The Image class is a sub-class of Document, since all images are documents.
× editorial: We do not (currently) distinguish precisely between physical and electronic documents, or between copies of a work and the abstraction those copies embody. The relationship between documents and their byte-stream representation needs clarification (see sha1 for related issues).
* McsEngl.foaf/Document,
* McsEngl.Document@foaf,

foaf:Group-class::
× sDescription: Group - A class of Agents.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_Group
× sStatus: stable
× aProperties-include: [member]
× aSubclass-of: [Agent]
* McsEngl.foaf/Group,
* McsEngl.Group@foaf,

× sDescriptionLong: The Group class represents a collection of individual agents (and may itself play the role of a Agent, ie. something that can perform actions).
This concept is intentionally quite broad, covering informal and ad-hoc groups, long-lived communities, organizational groups within a workplace, etc. Some such groups may have associated characteristics which could be captured in RDF (perhaps a homepage, name, mailing list etc.).
While a Group has the characteristics of a Agent, it is also associated with a number of other Agents (typically people) who constitute the Group. FOAF provides a mechanism, the membershipClass property, which relates a Group to a sub-class of the class Agent who are members of the group. This is a little complicated, but allows us to make group membership rules explicit.
The markup (shown below) for defining a group is both complex and powerful. It allows group membership rules to match against any RDF-describable characteristics of the potential group members. As FOAF and similar vocabularies become more expressive in their ability to describe individuals, the Group mechanism for categorising them into groups also becomes more powerful.
While the formal description of membership criteria for a Group may be complex, the basic mechanism for saying that someone is in a Group is very simple. We simply use a member property of the Group to indicate the agents that are members of the group. For example:

    <foaf:Group>
     <foaf:name>ILRT staff</foaf:name>
     <foaf:member>
      <foaf:Person>
       <foaf:name>Martin Poulter</foaf:name>
       <foaf:homepage rdf:resource="http://www.ilrt.bris.ac.uk/aboutus/staff/staffprofile/?search=plmlp"/>
       <foaf:workplaceHomepage rdf:resource="http://www.ilrt.bris.ac.uk/"/>
      </foaf:Person>
     </foaf:member>
    </foaf:Group>
    

Behind the scenes, further RDF statements can be used to express the rules for being a member of this group. End-users of FOAF need not pay attention to these details.
Here is an example. We define a Group representing those people who are ILRT staff members (ILRT is a department at the University of Bristol). The membershipClass property connects the group (conceived of as a social entity and agent in its own right) with the class definition for those people who constitute it. In this case, the rule is that all group members are in the ILRTStaffPerson class, which is in turn populated by all those things that are a Person and which have a workplaceHomepage of http://www.ilrt.bris.ac.uk/. This is typical: FOAF groups are created by specifying a sub-class of Agent (in fact usually this will be a sub-class of Person), and giving criteria for which things fall in or out of the sub-class. For this, we use the owl:onProperty and owl:hasValue properties, indicating the property/value pairs which must be true of matching agents.

    <!-- here we see a FOAF group described.
         each foaf group may be associated with an OWL definition
         specifying the class of agents that constitute the group's membership -->
    <foaf:Group>
     <foaf:name>ILRT staff</foaf:name>
     <foaf:membershipClass>
        <owl:Class rdf:about="http://ilrt.example.com/groups#ILRTStaffPerson">
         <rdfs:subClassOf rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
         <rdfs:subClassOf>
           <owl:Restriction>
             <owl:onProperty rdf:resource="http://xmlns.com/foaf/0.1/workplaceHomepage"/>
             <owl:hasValue rdf:resource="http://www.ilrt.bris.ac.uk/"/>
           </owl:Restriction>
         </rdfs:subClassOf>
       </owl:Class>
     </foaf:membershipClass>
    </foaf:Group>
    

Note that while these example OWL rules for being in the eg:ILRTStaffPerson class are based on a Person having a particular workplaceHomepage, this places no obligations on the authors of actual FOAF documents to include this information. If the information is included, then generic OWL tools may infer that some person is an eg:ILRTStaffPerson. To go the extra step and infer that some eg:ILRTStaffPerson is a member of the group whose name is "ILRT staff", tools will need some knowledge of the way FOAF deals with groups. In other words, generic OWL technology gets us most of the way, but the full Group machinery requires extra work for implimentors.
The current design names the relationship as pointing from the group, to the member. This is convenient when writing XML/RDF that encloses the members within markup that describes the group. Alternate representations of the same content are allowed in RDF, so you can write claims about the Person and the Group without having to nest either description inside the other. For (brief) example:

    <foaf:Group>
     <foaf:member rdf:nodeID="martin"/>
     <!-- more about the group here -->
    </foaf:Group>
    <foaf:Person rdf:nodeID="martin">
      <!-- more about martin here -->
    </foaf:Person>
    

There is a FOAF issue tracker associated with this FOAF term. A design goal is to make the most of W3C's OWL language for representing group-membership criteria, while also making it easy to leverage existing groups and datasets available online (eg. buddylists, mailing list membership lists etc). Feedback on the current design is solicited! Should we consider using SPARQL queries instead, for example?

foaf:Image-class::
× sDescription: Image - An image.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_Image
× sStatus: stable
× aProperties-include: [depicts, thumbnail]
× aUsed-with: [img, thumbnail, depiction]
× aSubclass-of: [Document]
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The class Image is a sub-class of Document corresponding to those documents which are images.
Digital images (such as JPEG, PNG, GIF bitmaps, SVG diagrams etc.) are examples of Image.
* McsEngl.foaf/Image,
* McsEngl.Image@foaf,

foaf:Organization-class::
× sDescription: Organization - An organization.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_Organization
× sStatus: stable
× aSubclass-of: [Agent]
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× aDisjoint-with: [Document, Person]

× sDescriptionLong: The Organization class represents a kind of Agent corresponding to social instititutions such as companies, societies etc.
× editorial: This is a more 'solid' class than Group, which allows for more ad-hoc collections of individuals. These terms, like the corresponding natural language concepts, have some overlap, but different emphasis.
* McsEngl.foaf/Organization,
* McsEngl.Organization@foaf,

foaf:Person-class::
× sDescription: Person - A person.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_Person
× sStatus: stable
× aProperties-include: [plan, surname, geekcode, pastProject, lastName, family_name, publications, currentProject, familyName, firstName, workInfoHomepage, myersBriggs, schoolHomepage, img, workplaceHomepage, knows]
× aUsed-with: [knows]
× aSubclass-of: [Agent, Spatial Thing]
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× aDisjoint-with: [Project, Organization]

× sDescriptionLong: The Person class represents people. Something is a Person if it is a person. We don't nitpic about whether they're alive, dead, real, or imaginary. The Person class is a sub-class of the Agent class, since all people are considered 'agents' in FOAF.
* McsEngl.foaf/Person,
* McsEngl.Person@foaf,

foaf:OnlineAccount-class::
× sDescription: Online Account - An online account.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_OnlineAccount
× sStatus: testing
× aProperties-include: [accountName, accountServiceHomepage]
× aUsed-with: [account, holdsAccount]
× aSubclass-of: [Thing]
× aHas-subclass: [Online E-commerce Account, Online Gaming Account, Online Chat Account]
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The OnlineAccount class represents the provision of some form of online service, by some party (indicated indirectly via a accountServiceHomepage) to some Agent. The account property of the agent is used to indicate accounts that are associated with the agent.
See OnlineChatAccount for an example. Other sub-classes include OnlineEcommerceAccount and OnlineGamingAccount.
One deployment style for this construct is to use URIs for well-known documents (or other entities) that strongly embody the account-holding relationship; for example, user profile pages on social network sites. This has the advantage of providing URIs that are likely to be easy to link with other information, but means that the instances of this class should not be considered 'accounts' in the abstract or business sense of a 'contract'.
* McsEngl.foaf/OnlineAccount,
* McsEngl.OnlineAccount@foaf,

foaf:PersonalProfileDocument-class::
× sDescription: PersonalProfileDocument - A personal profile RDF document.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_PersonalProfileDocument
× sStatus: testing
× aSubclass-of: [Document]
* McsEngl.foaf/PersonalProfileDocument,
* McsEngl.PersonalProfileDocument@foaf,

× sDescriptionLong: The PersonalProfileDocument class represents those things that are a Document, and that use RDF to describe properties of the person who is the maker of the document. There is just one Person described in the document, ie. the person who made it and who will be its primaryTopic.
The PersonalProfileDocument class, and FOAF's associated conventions for describing it, captures an important deployment pattern for the FOAF vocabulary. FOAF is very often used in public RDF documents made available through the Web. There is a colloquial notion that these "FOAF files" are often somebody's FOAF file. Through PersonalProfileDocument we provide a machine-readable expression of this concept, providing a basis for FOAF documents to make claims about their maker and topic.
When describing a PersonalProfileDocument it is typical (and useful) to describe its associated Person using the maker property. Anything that is a Person and that is the maker of some PersonalProfileDocument will be the primaryTopic of that Document. Although this can be inferred, it is often helpful to include this information explicitly within the PersonalProfileDocument.
For example, here is a fragment of a personal profile document which describes its author explicitly:

    <foaf:Person rdf:nodeID="p1">
     <foaf:name>Dan Brickley</foaf:name>
     <foaf:homepage rdf:resource="http://danbri.org/"/>
     <!-- etc... -->
    </foaf:Person>

    <foaf:PersonalProfileDocument rdf:about="">
       <foaf:maker rdf:nodeID="p1"/>
       <foaf:primaryTopic rdf:nodeID="p1"/>
    </foaf:PersonalProfileDocument>
    

Note that a PersonalProfileDocument will have some representation as RDF. Typically this will be in W3C's RDF/XML syntax, however we leave open the possibility for the use of other notations, or representational conventions including automated transformations from HTML (GRDDL spec for one such technique).

foaf:Project-class::
× sDescription: Project - A project (a collective endeavour of some kind).
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_Project
× sStatus: testing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× aDisjoint-with: [Document, Person]

× sDescriptionLong: The Project class represents the class of things that are 'projects'. These may be formal or informal, collective or individual. It is often useful to indicate the homepage of a Project.
× editorial: Further work is needed to specify the connections between this class and the FOAF properties currentProject and pastProject.
* McsEngl.foaf/Project,
* McsEngl.Project@foaf,

property of foaf

description::
· RDF-properties.

name::
* McsEngl.foaf'property,

foaf:LabelProperty-class::
× sDescription: Label Property - A foaf:LabelProperty is any RDF property with texual values that serve as labels.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_LabelProperty
× sStatus: unstable
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: A LabelProperty is any RDF property with texual values that serve as labels.
Any property that is a LabelProperty is effectively a sub-property of rdfs:label. This utility class provides an alternate means of expressing this idea, in a way that may help with OWL 2.0 DL compatibility.
* McsEngl.foaf/LabelProperty,
* McsEngl.LabelProperty@foaf,

foaf:OnlineChatAccount-class::
× sDescription: Online Chat Account - An online chat account.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_OnlineChatAccount
× sStatus: unstable
× aSubclass-of: [OnlineAccount]
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
* McsEngl.foaf/OnlineChatAccount,
* McsEngl.OnlineChatAccount@foaf,

× sDescriptionLong: A OnlineChatAccount is a OnlineAccount devoted to chat / instant messaging. The account may offer other services too; FOAF's sub-classes of OnlineAccount are not mutually disjoint.
This is a generalization of the FOAF Chat ID properties, jabberID, aimChatID, skypeID, msnChatID, icqChatID and yahooChatID.
Unlike those simple properties, OnlineAccount and associated FOAF terms allows us to describe a great variety of online accounts, without having to anticipate them in the FOAF vocabulary.
For example, here is a description of an IRC chat account, specific to the Freenode IRC network:

    <foaf:Person>
      <foaf:name>Dan Brickley</foaf:name>
      <foaf:account>
        <foaf:OnlineAccount>
          <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/OnlineChatAccount"/>
          <foaf:accountServiceHomepage
                   rdf:resource="http://www.freenode.net/"/>
          <foaf:accountName>danbri</foaf:accountName>
        </foaf:OnlineAccount>
      </foaf:account>
    </foaf:Person>
    

Note that it may be impolite to carelessly reveal someone else's chat identifier (which might also serve as an indicate of email address) As with email, there are privacy and anti-SPAM considerations. FOAF does not currently provide a way to represent an obfuscated chat ID (ie. there is no parallel to the mbox / mbox_sha1sum mapping).
In addition to the generic OnlineAccount and OnlineChatAccount mechanisms, FOAF also provides several convenience chat ID properties (jabberID, aimChatID, icqChatID, msnChatID,yahooChatID, skypeID). These serve as as a shorthand for some common cases; their use may not always be appropriate.
× editorial: We should specify some mappings between the abbreviated and full representations of Jabber, AIM, MSN, ICQ, Yahoo! and MSN chat accounts. This has been done for skypeID. This requires us to identify an appropriate accountServiceHomepage for each. If we wanted to make the OnlineAccount mechanism even more generic, we could invent a relationship that holds between a OnlineAccount instance and a convenience property. To continue the example above, we could describe how Freenode could define a property 'fn:freenodeChatID' corresponding to Freenode online accounts.

foaf:OnlineEcommerceAccount-class::
× sDescription: Online E-commerce Account - An online e-commerce account.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_OnlineEcommerceAccount
× sStatus: unstable
× aSubclass-of: [OnlineAccount]
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: A OnlineEcommerceAccount is a OnlineAccount devoted to buying and/or selling of goods, services etc. Examples include Amazon, eBay, PayPal, thinkgeek, etc.
* McsEngl.foaf/OnlineEcommerceAccount,
* McsEngl.OnlineEcommerceAccount@foaf,

foaf:OnlineGamingAccount-class::
× sDescription: Online Gaming Account - An online gaming account.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_OnlineGamingAccount
× sStatus: unstable
× aSubclass-of: [OnlineAccount]
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: A OnlineGamingAccount is a OnlineAccount devoted to online gaming.
Examples might include EverQuest, Xbox live, Neverwinter Nights, etc., as well as older text-based systems (MOOs, MUDs and suchlike).
* McsEngl.foaf/OnlineGamingAccount,
* McsEngl.OnlineGamingAccount@foaf,

foaf:homepage-property::
× sDescription: homepage - A homepage for some thing.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_homepage
× sStatus: stable
× sDomain: having this property implies being a Thing
× sRange: every value of this property is a Document
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: http://www.w3.org/2002/07/owl#InverseFunctionalProperty

× sDescriptionLong: The homepage property relates something to a homepage about it.
Many kinds of things have homepages. FOAF allows a thing to have multiple homepages, but constrains homepage so that there can be only one thing that has any particular homepage.
A 'homepage' in this sense is a public Web document, typically but not necessarily available in HTML format. The page has as a topic the thing whose homepage it is. The homepage is usually controlled, edited or published by the thing whose homepage it is; as such one might look to a homepage for information on its owner from its owner. This works for people, companies, organisations etc.
The homepage property is a sub-property of the more general page property for relating a thing to a page about that thing. See also topic, the inverse of the page property.
* McsEngl.foaf/homepage,
* McsEngl.homepage@foaf,

foaf:isPrimaryTopicOf-property::
× sDescription: is primary topic of - A document that this thing is the primary topic of.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_isPrimaryTopicOf
× sStatus: stable
× sDomain: having this property implies being a Thing
× sRange: every value of this property is a Document
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: http://www.w3.org/2002/07/owl#InverseFunctionalProperty

× sDescriptionLong: The isPrimaryTopicOf property relates something to a document that is mainly about it.
The isPrimaryTopicOf property is inverse functional: for any document that is the value of this property, there is at most one thing in the world that is the primary topic of that document. This is useful, as it allows for data merging, as described in the documentation for its inverse, primaryTopic.
page is a super-property of isPrimaryTopicOf. The change of terminology between the two property names reflects the utility of 'primaryTopic' and its inverse when identifying things. Anything that has an isPrimaryTopicOf relation to some document X, also has a page relationship to it.
Note that homepage, is a sub-property of both page and isPrimaryTopicOf. The awkwardly named isPrimaryTopicOf is less specific, and can be used with any document that is primarily about the thing of interest (ie. not just on homepages).
* McsEngl.foaf/isPrimaryTopicOf,
* McsEngl.isPrimaryTopicOf@foaf,

foaf:knows-property::
× sDescription: knows - A person known by this person (indicating some level of reciprocated interaction between the parties).
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_knows
× sStatus: stable
× sDomain: having this property implies being a Person
× sRange: every value of this property is a Person
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The knows property relates a Person to another Person that he or she knows.
We take a broad view of 'knows', but do require some form of reciprocated interaction (ie. stalkers need not apply). Since social attitudes and conventions on this topic vary greatly between communities, counties and cultures, it is not appropriate for FOAF to be overly-specific here.
If someone knows a person, it would be usual for the relation to be reciprocated. However this doesn't mean that there is any obligation for either party to publish FOAF describing this relationship. A knows relationship does not imply friendship, endorsement, or that a face-to-face meeting has taken place: phone, fax, email, and smoke signals are all perfectly acceptable ways of communicating with people you know.
You probably know hundreds of people, yet might only list a few in your public FOAF file. That's OK. Or you might list them all. It is perfectly fine to have a FOAF file and not list anyone else in it at all. This illustrates the Semantic Web principle of partial description: RDF documents rarely describe the entire picture. There is always more to be said, more information living elsewhere in the Web (or in our heads...).
Since knows is vague by design, it may be suprising that it has uses. Typically these involve combining other RDF properties. For example, an application might look at properties of each weblog that was made by someone you "knows". Or check the newsfeed of the online photo archive for each of these people, to show you recent photos taken by people you know.
To provide additional levels of representation beyond mere 'knows', FOAF applications can do several things.
They can use more precise relationships than knows to relate people to people. The original FOAF design included two of these ('knowsWell','friend') which we removed because they were somewhat awkward to actually use, bringing an inappopriate air of precision to an intrinsically vague concept. Other extensions have been proposed, including Eric Vitiello's Relationship module for FOAF.
In addition to using more specialised inter-personal relationship types (eg rel:acquaintanceOf etc) it is often just as good to use RDF descriptions of the states of affairs which imply particular kinds of relationship. So for example, two people who have the same value for their workplaceHomepage property are typically colleagues. We don't (currently) clutter FOAF up with these extra relationships, but the facts can be written in FOAF nevertheless. Similarly, if there exists a Document that has two people listed as its makers, then they are probably collaborators of some kind. Or if two people appear in 100s of digital photos together, there's a good chance they're friends and/or colleagues.
So FOAF is quite pluralistic in its approach to representing relationships between people. FOAF is built on top of a general purpose machine language for representing relationships (ie. RDF), so is quite capable of representing any kinds of relationship we care to add. The problems are generally social rather than technical; deciding on appropriate ways of describing these interconnections is a subtle art.
Perhaps the most important use of knows is, alongside the rdfs:seeAlso property, to connect FOAF files together. Taken alone, a FOAF file is somewhat dull. But linked in with 1000s of other FOAF files it becomes more interesting, with each FOAF file saying a little more about people, places, documents, things... By mentioning other people (via knows or other relationships), and by providing an rdfs:seeAlso link to their FOAF file, you can make it easy for FOAF indexing tools ('scutters') to find your FOAF and the FOAF of the people you've mentioned. And the FOAF of the people they mention, and so on. This makes it possible to build FOAF aggregators without the need for a centrally managed directory of FOAF files...
* McsEngl.foaf/knows,
* McsEngl.knows@foaf,

foaf:made-property::
× sDescription: made - Something that was made by this agent.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_made
× sStatus: stable
× sDomain: having this property implies being a Agent
× sRange: every value of this property is a Thing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The made property relates a Agent to something made by it. As such it is an inverse of the maker property, which relates a thing to something that made it. See made for more details on the relationship between these FOAF terms and related Dublin Core vocabulary.
* McsEngl.foaf/made,
* McsEngl.made@foaf,

foaf:maker-property::
× sDescription: maker - An agent that made this thing.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_maker
× sStatus: stable
× sDomain: having this property implies being a Thing
× sRange: every value of this property is a Agent
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The maker property relates something to a Agent that made it. As such it is an inverse of the made property.
The name (or other rdfs:label) of the maker of something can be described as the dc:creator of that thing.
For example, if the thing named by the URI http://danbri.org/ has a maker that is a Person whose name is 'Dan Brickley', we can conclude that http://danbri.org/ has a dc:creator of 'Dan Brickley'.
FOAF descriptions are encouraged to use dc:creator only for simple textual names, and to use maker to indicate creators, rather than risk confusing creators with their names. This follows most Dublin Core usage. See UsingDublinCoreCreator for details.
* McsEngl.foaf/maker,
* McsEngl.maker@foaf,

foaf:mbox-property::
× sDescription: personal mailbox - A personal mailbox, ie. an Internet mailbox associated with exactly one owner, the first owner of this mailbox. This is a 'static inverse functional property', in that there is (across time and change) at most one individual that ever has any particular value for foaf:mbox.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_mbox
× sStatus: stable
× sDomain: having this property implies being a Agent
× sRange: every value of this property is a Thing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: http://www.w3.org/2002/07/owl#InverseFunctionalProperty

× sDescriptionLong: The mbox property is a relationship between the owner of a mailbox and a mailbox. These are typically identified using the mailto: URI scheme (see RFC 2368).
Note that there are many mailboxes (eg. shared ones) which are not the mbox of anyone. Furthermore, a person can have multiple mbox properties.
In FOAF, we often see mbox used as an indirect way of identifying its owner. This works even if the mailbox is itself out of service (eg. 10 years old), since the property is defined in terms of its primary owner, and doesn't require the mailbox to actually be being used for anything.
Many people are wary of sharing information about their mailbox addresses in public. To address such concerns whilst continuing the FOAF convention of indirectly identifying people by referring to widely known properties, FOAF also provides the mbox_sha1sum mechanism, which is a relationship between a person and the value you get from passing a mailbox URI to the SHA1 mathematical function.
* McsEngl.foaf/mbox,
* McsEngl.mbox@foaf,

foaf:member-property::
× sDescription: member - Indicates a member of a Group
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_member
× sStatus: stable
× sDomain: having this property implies being a Group
× sRange: every value of this property is a Agent
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The member property relates a Group to a Agent that is a member of that group.
See Group for details and examples.
* McsEngl.foaf/member,
* McsEngl.member@foaf,

foaf:page-property::
× sDescription: page - A page or document about this thing.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_page
× sStatus: stable
× sDomain: having this property implies being a Thing
× sRange: every value of this property is a Document
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The page property relates a thing to a document about that thing.
As such it is an inverse of the topic property, which relates a document to a thing that the document is about.
* McsEngl.foaf/page,
* McsEngl.page@foaf,

foaf:primaryTopic-property::
× sDescription: primary topic - The primary topic of some page or document.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_primaryTopic
× sStatus: stable
× sDomain: having this property implies being a Document
× sRange: every value of this property is a Thing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: http://www.w3.org/2002/07/owl#FunctionalProperty

× sDescriptionLong: The primaryTopic property relates a document to the main thing that the document is about.
The primaryTopic property is functional: for any document it applies to, it can have at most one value. This is useful, as it allows for data merging. In many cases it may be difficult for third parties to determine the primary topic of a document, but in a useful number of cases (eg. descriptions of movies, restaurants, politicians, ...) it should be reasonably obvious. Documents are very often the most authoritative source of information about their own primary topics, although this cannot be guaranteed since documents cannot be assumed to be accurate, honest etc.
It is an inverse of the isPrimaryTopicOf property, which relates a thing to a document primarily about that thing. The choice between these two properties is purely pragmatic. When describing documents, we use primaryTopic former to point to the things they're about. When describing things (people etc.), it is useful to be able to directly cite documents which have those things as their main topic - so we use isPrimaryTopicOf. In this way, Web sites such as Wikipedia or NNDB can provide indirect identification for the things they have descriptions of.
* McsEngl.foaf/primaryTopic,
* McsEngl.primaryTopic@foaf,

foaf:weblog-property::
× sDescription: weblog - A weblog of some thing (whether person, group, company etc.).
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_weblog
× sStatus: stable
× sDomain: having this property implies being a Agent
× sRange: every value of this property is a Document
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: http://www.w3.org/2002/07/owl#InverseFunctionalProperty

× sDescriptionLong: The weblog property relates a Agent to a weblog of that agent.
* McsEngl.foaf/weblog,
* McsEngl.weblog@foaf,

foaf:account-property::
× sDescription: account - Indicates an account held by this agent.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_account
× sStatus: testing
× sDomain: having this property implies being a Agent
× sRange: every value of this property is a OnlineAccount
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The account property relates a Agent to an OnlineAccount for which they are the sole account holder. See OnlineAccount for usage details.
* McsEngl.foaf/account,
* McsEngl.account@foaf,

foaf:accountName-property::
× sDescription: account name - Indicates the name (identifier) associated with this online account.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_accountName
× sStatus: testing
× sDomain: having this property implies being a OnlineAccount
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The accountName property of a OnlineAccount is a textual representation of the account name (unique ID) associated with that account.
* McsEngl.foaf/accountName,
* McsEngl.accountName@foaf,

foaf:accountServiceHomepage-property::
× sDescription: account service homepage - Indicates a homepage of the service provide for this online account.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_accountServiceHomepage
× sStatus: testing
× sDomain: having this property implies being a OnlineAccount
× sRange: every value of this property is a Document
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The accountServiceHomepage property indicates a relationship between a OnlineAccount and the homepage of the supporting service provider.
* McsEngl.foaf/accountServiceHomepage,
* McsEngl.accountServiceHomepage@foaf,

foaf:aimChatID-property::
× sDescription: AIM chat ID - An AIM chat ID
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_aimChatID
× sStatus: testing
× sDomain: having this property implies being a Agent
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: http://www.w3.org/2002/07/owl#InverseFunctionalProperty

× sDescriptionLong: The aimChatID property relates a Agent to a textual identifier ('screenname') assigned to them in the AOL Instant Messanger (AIM) system. See AOL's AIM site for more details of AIM and AIM screennames. The iChat tools from Apple also make use of AIM identifiers.
See OnlineChatAccount (and OnlineAccount) for a more general (and verbose) mechanism for describing IM and chat accounts.
* McsEngl.foaf/aimChatID,
* McsEngl.aimChatID@foaf,

foaf:based_near-property::
× sDescription: based near - A location that something is based near, for some broadly human notion of near.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_based_near
× sStatus: testing
× sDomain: having this property implies being a Spatial Thing
× sRange: every value of this property is a Spatial Thing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The based_near relationship relates two "spatial things" (anything that can be somewhere), the latter typically described using the geo:lat / geo:long geo-positioning vocabulary (See GeoInfo in the W3C semweb wiki for details). This allows us to say describe the typical latitute and longitude of, say, a Person (people are spatial things - they can be places) without implying that a precise location has been given.
We do not say much about what 'near' means in this context; it is a 'rough and ready' concept. For a more precise treatment, see GeoOnion vocab design discussions, which are aiming to produce a more sophisticated vocabulary for such purposes.
FOAF files often make use of the contact:nearestAirport property. This illustrates the distinction between FOAF documents (which may make claims using any RDF vocabulary) and the core FOAF vocabulary defined by this specification. For further reading on the use of nearestAirport see UsingContactNearestAirport in the FOAF wiki.
* McsEngl.foaf/based_near,
* McsEngl.based_near@foaf,

foaf:currentProject-property::
× sDescription: current project - A current project this person works on.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_currentProject
× sStatus: testing
× sDomain: having this property implies being a Person
× sRange: every value of this property is a Thing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: A currentProject relates a Person to a Document indicating some collaborative or individual undertaking. This relationship indicates that the Person has some active role in the project, such as development, coordination, or support.
When a Person is no longer involved with a project, or perhaps is inactive for some time, the relationship becomes a pastProject.
If the Person has stopped working on a project because it has been completed (successfully or otherwise), pastProject is applicable. In general, currentProject is used to indicate someone's current efforts (and implied interests, concerns etc.), while pastProject describes what they've previously been doing.
× editorial: Note that this property requires further work. There has been confusion about whether it points to a thing (eg. something you've made; a homepage for a project, ie. a Document or to instances of the class Project, which might themselves have a homepage. In practice, it seems to have been used in a similar way to interest, referencing homepages of ongoing projects.
* McsEngl.foaf/currentProject,
* McsEngl.currentProject@foaf,

foaf:depiction-property::
× sDescription: depiction - A depiction of some thing.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_depiction
× sStatus: testing
× sDomain: having this property implies being a Thing
× sRange: every value of this property is a Image
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The depiction property is a relationship between a thing and an Image that depicts it. As such it is an inverse of the depicts relationship.
A common use of depiction (and depicts) is to indicate the contents of a digital image, for example the people or objects represented in an online photo gallery.
Extensions to this basic idea include 'Co-Depiction' (social networks as evidenced in photos), as well as richer photo metadata through the mechanism of using SVG paths to indicate the regions of an image which depict some particular thing. See 'Annotating Images With SVG' for tools and details.
The basic notion of 'depiction' could also be extended to deal with multimedia content (video clips, audio), or refined to deal with corner cases, such as pictures of pictures etc.
The depiction property is a super-property of the more specific property img, which is used more sparingly. You stand in a depiction relation to any Image that depicts you, whereas img is typically used to indicate a few images that are particularly representative.
* McsEngl.foaf/depiction,
* McsEngl.depiction@foaf,

foaf:depicts-property::
× sDescription: depicts - A thing depicted in this representation.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_depicts
× sStatus: testing
× sDomain: having this property implies being a Image
× sRange: every value of this property is a Thing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The depicts property is a relationship between a Image and something that the image depicts. As such it is an inverse of the depiction relationship. See depiction for further notes.
* McsEngl.foaf/depicts,
* McsEngl.depicts@foaf,

foaf:familyName-property::
× sDescription: familyName - The family name of some person.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_familyName
× sStatus: testing
× sDomain: having this property implies being a Person
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The familyName property is provided (alongside givenName) for use when describing parts of people's names. Although these concepts do not capture the full range of personal naming styles found world-wide, they are commonly used and have some value.
There is also a simple name property.
Support is also provided for the more archaic and culturally varying terminology of firstName and lastName.
See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.
* McsEngl.foaf/familyName,
* McsEngl.familyName@foaf,

foaf:firstName-property::
× sDescription: firstName - The first name of a person.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_firstName
× sStatus: testing
× sDomain: having this property implies being a Person
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The firstName property is provided (alongside lastName) as a mechanism to support legacy data that cannot be easily interpreted in terms of the (otherwise preferred) familyName and givenName properties. The concepts of 'first' and 'last' names do not work well across cultural and linguistic boundaries; however they are widely used in addressbooks and databases.
See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.
There is also a simple name property.
* McsEngl.foaf/firstName,
* McsEngl.firstName@foaf,

foaf:focus-property::
× sDescription: focus - The underlying or 'focal' entity associated with some SKOS-described concept.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_focus
× sStatus: testing
× sDomain: having this property implies being a Concept
× sRange: every value of this property is a Thing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The focus property relates a conceptualisation of something to the thing itself. Specifically, it is designed for use with W3C's SKOS vocabulary, to help indicate specific individual things (typically people, places, artifacts) that are mentioned in different SKOS schemes (eg. thesauri).
W3C SKOS is based around collections of linked 'concepts', which indicate topics, subject areas and categories. In SKOS, properties of a skos:Concept are properties of the conceptualization (see 2005 discussion for details); for example administrative and record-keeping metadata. Two schemes might have an entry for the same individual; the foaf:focus property can be used to indicate the thing in they world that they both focus on. Many SKOS concepts don't work this way; broad topical areas and subject categories don't typically correspond to some particular entity. However, in cases when they do, it is useful to link both subject-oriented and thing-oriented information via foaf:focus.
FOAF's focus property works alongside its other topic-oriented constructs: topic, primaryTopic are used when talking about the topical emphasis of a document. The notion of primaryTopic is particularly important in FOAF as it provides an indirect mechanism for identifying things indirectly. A similar approach is explored by the TDB URI scheme. FOAF includes topic-oriented functionality to address its original goals of linking people to information, as well as to other people, through the use of linked information.
* McsEngl.foaf/focus,
* McsEngl.focus@foaf,

foaf:gender-property::
× sDescription: gender - The gender of this Agent (typically but not necessarily 'male' or 'female').
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_gender
× sStatus: testing
× sDomain: having this property implies being a Agent
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: href="http://www.w3.org/2002/07/owl#FunctionalProperty

× sDescriptionLong: The gender property relates a Agent (typically a Person) to a string representing its gender. In most cases the value will be the string 'female' or 'male' (in lowercase without surrounding quotes or spaces). Like all FOAF properties, there is in general no requirement to use gender in any particular document or description. Values other than 'male' and 'female' may be used, but are not enumerated here. The gender mechanism is not intended to capture the full variety of biological, social and sexual concepts associated with the word 'gender'.
Anything that has a gender property will be some kind of Agent. However there are kinds of Agent to which the concept of gender isn't applicable (eg. a Group). FOAF does not currently include a class corresponding directly to "the type of thing that has a gender". At any point in time, a Agent has at most one value for gender. FOAF does not treat gender as a static property; the same individual may have different values for this property at different times.
Note that FOAF's notion of gender isn't defined biologically or anatomically - this would be tricky since we have a broad notion that applies to all Agents (including robots - eg. Bender from Futurama is 'male'). As stressed above, FOAF's notion of gender doesn't attempt to encompass the full range of concepts associated with human gender, biology and sexuality. As such it is a (perhaps awkward) compromise between the clinical and the social/psychological. In general, a person will be the best authority on their gender. Feedback on this design is particularly welcome (via the FOAF mailing list, foaf-dev). We have tried to be respectful of diversity without attempting to catalogue or enumerate that diversity.
This may also be a good point for a periodic reminder: as with all FOAF properties, documents that use 'gender' will on occassion be innacurate, misleading or outright false. FOAF, like all open means of communication, supports lying. Application authors using FOAF data should always be cautious in their presentation of unverified information, but be particularly sensitive to issues and risks surrounding sex and gender (including privacy and personal safety concerns). Designers of FOAF-based user interfaces should be careful to allow users to omit gender when describing themselves and others, and to allow at least for values other than 'male' and 'female' as options. Users of information conveyed via FOAF (as via information conveyed through mobile phone text messages, email, Internet chat, HTML pages etc.) should be skeptical of unverified information.
* McsEngl.foaf/gender,
* McsEngl.gender@foaf,

foaf:givenName-property::
× sDescription: Given name - The given name of some person.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_givenName
× sStatus: testing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The givenName property is provided (alongside familyName) for use when describing parts of people's names. Although these concepts do not capture the full range of personal naming styles found world-wide, they are commonly used and have some value.
There is also a simple name property.
Support is also provided for the more archaic and culturally varying terminology of firstName and lastName.
See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.
* McsEngl.foaf/givenName,
* McsEngl.givenName@foaf,

foaf:icqChatID-property::
× sDescription: ICQ chat ID - An ICQ chat ID
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_icqChatID
× sStatus: testing
× sDomain: having this property implies being a Agent
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: http://www.w3.org/2002/07/owl#InverseFunctionalProperty

× sDescriptionLong: The icqChatID property relates a Agent to a textual identifier assigned to them in the ICQ Chat system. See the icq chat site for more details of the 'icq' service. Their "What is ICQ?" document provides a basic overview, while their "About Us page notes that ICQ has been acquired by AOL. Despite the relationship with AOL, ICQ is at the time of writing maintained as a separate identity from the AIM brand (see aimChatID).
See OnlineChatAccount (and OnlineAccount) for a more general (and verbose) mechanism for describing IM and chat accounts.
* McsEngl.foaf/icqChatID,
* McsEngl.icqChatID@foaf,

foaf:img-property::
× sDescription: image - An image that can be used to represent some thing (ie. those depictions which are particularly representative of something, eg. one's photo on a homepage).
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_img
× sStatus: testing
× sDomain: having this property implies being a Person
× sRange: every value of this property is a Image
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The img property relates a Person to a Image that represents them. Unlike its super-property depiction, we only use img when an image is particularly representative of some person. The analogy is with the image(s) that might appear on someone's homepage, rather than happen to appear somewhere in their photo album.
Unlike the more general depiction property (and its inverse, depicts), the img property is only used with representations of people (ie. instances of Person). So you can't use it to find pictures of cats, dogs etc. The basic idea is to have a term whose use is more restricted than depiction so we can have a useful way of picking out a reasonable image to represent someone. FOAF defines img as a sub-property of depiction, which means that the latter relationship is implied whenever two things are related by the former.
Note that img does not have any restrictions on the dimensions, colour depth, format etc of the Image it references.
Terminology: note that img is a property (ie. relationship), and that code:Image is a similarly named class (ie. category, a type of thing). It might have been more helpful to call img 'mugshot' or similar; instead it is named by analogy to the HTML IMG element.
* McsEngl.foaf/img,
* McsEngl.img@foaf,

foaf:interest-property::
× sDescription: interest - A page about a topic of interest to this person.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_interest
× sStatus: testing
× sDomain: having this property implies being a Agent
× sRange: every value of this property is a Document
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The interest property represents an interest of a Agent, through indicating a Document whose topic(s) broadly characterises that interest.
example: For example, we might claim that a person or group has an interest in RDF by saying they stand in a interest relationship to the RDF home page. Loosly, such RDF would be saying "this agent is interested in the topic of this page".
example: Uses of interest include a variety of filtering and resource discovery applications. It could be used, for example, to help find answers to questions such as "Find me members of this organisation with an interest in XML who have also contributed to CPAN)".
This approach to characterising interests is intended to compliment other mechanisms (such as the use of controlled vocabulary). It allows us to use a widely known set of unique identifiers (Web page URIs) with minimal pre-coordination. Since URIs have a controlled syntax, this makes data merging much easier than the use of free-text characterisations of interest.
Note that interest does not imply expertise, and that this FOAF term provides no support for characterising levels of interest: passing fads and lifelong quests are both examples of someone's interest. Describing interests in full is a complex undertaking; interest provides one basic component of FOAF's approach to these problems.
* McsEngl.foaf/interest,
* McsEngl.interest@foaf,

foaf:jabberID-property::
× sDescription: jabber ID - A jabber ID for something.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_jabberID
× sStatus: testing
× sDomain: having this property implies being a Agent
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: http://www.w3.org/2002/07/owl#InverseFunctionalProperty

× sDescriptionLong: The jabberID property relates a Agent to a textual identifier assigned to them in the Jabber messaging system. See the Jabber site for more information about the Jabber protocols and tools.
Jabber, unlike several other online messaging systems, is based on an open, publically documented protocol specification, and has a variety of open source implementations. Jabber IDs can be assigned to a variety of kinds of thing, including software 'bots', chat rooms etc. For the purposes of FOAF, these are all considered to be kinds of Agent (ie. things that do stuff). The uses of Jabber go beyond simple IM chat applications. The jabberID property is provided as a basic hook to help support RDF description of Jabber users and services.
See OnlineChatAccount (and OnlineAccount) for a more general (and verbose) mechanism for describing IM and chat accounts.
* McsEngl.foaf/jabberID,
* McsEngl.jabberID@foaf,

foaf:lastName-property::
× sDescription: lastName - The last name of a person.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_lastName
× sStatus: testing
× sDomain: having this property implies being a Person
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The lastName property is provided (alongside firstName) as a mechanism to support legacy data that cannot be easily interpreted in terms of the (otherwise preferred) familyName and givenName properties. The concepts of 'first' and 'last' names do not work well across cultural and linguistic boundaries; however they are widely used in addressbooks and databases.
See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.
There is also a simple name property.
* McsEngl.foaf/lastName,
* McsEngl.lastName@foaf,

foaf:mbox_sha1sum-property::
× sDescription: sha1sum of a personal mailbox URI name - The sha1sum of the URI of an Internet mailbox associated with exactly one owner, the first owner of the mailbox.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_mbox_sha1sum
× sStatus: testing
× sDomain: having this property implies being a Agent
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: http://www.w3.org/2002/07/owl#InverseFunctionalProperty

× sDescriptionLong: A mbox_sha1sum of a Person is a textual representation of the result of applying the SHA1 mathematical functional to a 'mailto:' identifier (URI) for an Internet mailbox that they stand in a mbox relationship to.
In other words, if you have a mailbox (mbox) but don't want to reveal its address, you can take that address and generate a mbox_sha1sum representation of it. Just as a mbox can be used as an indirect identifier for its owner, we can do the same with mbox_sha1sum since there is only one Person with any particular value for that property.
Many FOAF tools use mbox_sha1sum in preference to exposing mailbox information. This is usually for privacy and SPAM-avoidance reasons. Other relevant techniques include the use of PGP encryption (see Edd Dumbill's documentation) and the use of FOAF-based whitelists for mail filtering.
Code examples for SHA1 in C#, Java, PHP, Perl and Python can be found in Sam Ruby's weblog entry. Remember to include the 'mailto:' prefix, but no trailing whitespace, when computing a mbox_sha1sum property.
* McsEngl.foaf/mbox_sha1sum,
* McsEngl.mbox_sha1sum@foaf,

foaf:msnChatID-property::
× sDescription: MSN chat ID - An MSN chat ID
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_msnChatID
× sStatus: testing
× sDomain: having this property implies being a Agent
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: http://www.w3.org/2002/07/owl#InverseFunctionalProperty

× sDescriptionLong: The msnChatID property relates a Agent to a textual identifier assigned to them in the Microsoft online chat system originally known as 'MSN', and now Windows Live Messenger. See the Microsoft mesenger and Windows Live ID sites for more details.
See OnlineChatAccount (and OnlineAccount) for a more general (and verbose) mechanism for describing IM and chat accounts.
* McsEngl.foaf/msnChatID,
* McsEngl.msnChatID@foaf,

foaf:myersBriggs-property::
× sDescription: myersBriggs - A Myers Briggs (MBTI) personality classification.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_myersBriggs
× sStatus: testing
× sDomain: having this property implies being a Person
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The myersBriggs property represents the Myers Briggs (MBTI) approach to personality taxonomy. It is included in FOAF as an example of a property that takes certain constrained values, and to give some additional detail to the FOAF files of those who choose to include it. The myersBriggs property applies only to the Person class; wherever you see it, you can infer it is being applied to a person.
The myersBriggs property is interesting in that it illustrates how FOAF can serve as a carrier for various kinds of information, without necessarily being commited to any associated worldview. Not everyone will find myersBriggs (or star signs, or blood types, or the four humours) a useful perspective on human behaviour and personality. The inclusion of a Myers Briggs property doesn't indicate that FOAF endorses the underlying theory, any more than the existence of weblog is an endorsement of soapboxes.
The values for myersBriggs are the following 16 4-letter textual codes: ESTJ, INFP, ESFP, INTJ, ESFJ, INTP, ENFP, ISTJ, ESTP, INFJ, ENFJ, ISTP, ENTJ, ISFP, ENTP, ISFJ. If multiple of these properties are applicable, they are represented by applying multiple properties to a person.
For further reading on MBTI, see various online sources (eg. this article). There are various online sites which offer quiz-based tools for determining a person's MBTI classification. The owners of the MBTI trademark have probably not approved of these.
This FOAF property suggests some interesting uses, some of which could perhaps be used to test the claims made by proponents of the MBTI (eg. an analysis of weblog postings filtered by MBTI type). However it should be noted that MBTI FOAF descriptions are self-selecting; MBTI categories may not be uniformly appealing to the people they describe. Further, there is probably a degree of cultural specificity implicit in the assumptions made by many questionaire-based MBTI tools; the MBTI system may not make sense in cultural settings beyond those it was created for.
See also Cory Caplinger's summary table or the RDFWeb article, FOAF Myers Briggs addition for further background and examples.
Note: Myers Briggs Type Indicator and MBTI are registered trademarks of Consulting Psychologists Press Inc. Oxford Psycholgists Press Ltd has exclusive rights to the trademark in the UK.
* McsEngl.foaf/myersBriggs,
* McsEngl.myersBriggs@foaf,

foaf:name-property::
× sDescription: name - A name for some thing.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_name
× sStatus: testing
× sDomain: having this property implies being a Thing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The name of something is a simple textual string.
XML language tagging may be used to indicate the language of the name. For example:
<foaf:name xml:lang="en">Dan Brickley</foaf:name>
FOAF provides some other naming constructs. While foaf:name does not explicitly represent name substructure (family vs given etc.) it does provide a basic level of interoperability. See the issue tracker for status of work on this issue.
The name property, like all RDF properties with a range of rdfs:Literal, may be used with XMLLiteral datatyped values (multiple names are acceptable whether they are in the same langauge or not). XMLLiteral usage is not yet widely adopted. Feedback on this aspect of the FOAF design is particularly welcomed.
* McsEngl.foaf/name,
* McsEngl.name@foaf,

foaf:nick-property::
× sDescription: nickname - A short informal nickname characterising an agent (includes login identifiers, IRC and other chat nicknames).
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_nick
× sStatus: testing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The nick property relates a Person to a short (often abbreviated) nickname, such as those use in IRC chat, online accounts, and computer logins.
This property is necessarily vague, because it does not indicate any particular naming control authority, and so cannot distinguish a person's login from their (possibly various) IRC nicknames or other similar identifiers. However it has some utility, since many people use the same string (or slight variants) across a variety of such environments.
For specific controlled sets of names (relating primarily to Instant Messanger accounts), FOAF provides some convenience properties: jabberID, aimChatID, msnChatID and icqChatID. Beyond this, the problem of representing such accounts is not peculiar to Instant Messanging, and it is not scaleable to attempt to enumerate each naming database as a distinct FOAF property. The OnlineAccount term (and supporting vocabulary) are provided as a more verbose and more expressive generalisation of these properties.
* McsEngl.foaf/nick,
* McsEngl.nick@foaf,

foaf:openid-property::
× sDescription: openid - An OpenID for an Agent.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_openid
× sStatus: testing
× sDomain: having this property implies being a Agent
× sRange: every value of this property is a Document
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: http://www.w3.org/2002/07/owl#InverseFunctionalProperty

× sDescriptionLong: A openid is a property of a Agent that associates it with a document that can be used as an indirect identifier in the manner of the OpenID "Identity URL". As the OpenID 1.1 specification notes, OpenID itself"does not provide any mechanism to exchange profile information, though Consumers of an Identity can learn more about an End User from any public, semantically interesting documents linked thereunder (FOAF, RSS, Atom, vCARD, etc.)". In this way, FOAF and OpenID complement each other; neither provides a stand-alone approach to online "trust", but combined they can address interesting parts of this larger problem space.
The openid property is "inverse functional", meaning that anything that is the foaf:openid of something, is the openid of no more than one thing. FOAF is agnostic as to whether there are (according to the relevant OpenID specifications) OpenID URIs that are equally associated with multiple Agents. FOAF offers sub-classes of Agent, ie. Organization and Group, that allow for such scenarios to be consistent with the notion that any foaf:openid is the foaf:openid of just one Agent.
FOAF does not mandate any particular URI scheme for use as openid values. The OpenID 1.1 specification includes a delegation model that is often used to allow a weblog or homepage document to also serve in OpenID authentication via "link rel" HTML markup. This deployment model provides a convenient connection to FOAF, since a similar technique is used for FOAF autodiscovery in HTML. A single document can, for example, serve both as a homepage and an OpenID identity URL.
* McsEngl.foaf/openid,
* McsEngl.openid@foaf,

foaf:pastProject-property::
× sDescription: past project - A project this person has previously worked on.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_pastProject
× sStatus: testing
× sDomain: having this property implies being a Person
× sRange: every value of this property is a Thing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: After a Person is no longer involved with a currentProject, or has been inactive for some time, a pastProject relationship can be used. This indicates that the Person was involved with the described project at one point.
If the Person has stopped working on a project because it has been completed (successfully or otherwise), pastProject is applicable. In general, currentProject is used to indicate someone's current efforts (and implied interests, concerns etc.), while pastProject describes what they've previously been doing.
* McsEngl.foaf/pastProject,
* McsEngl.pastProject@foaf,

foaf:phone-property::
× sDescription: phone - A phone, specified using fully qualified tel: URI scheme (refs: http://www.w3.org/Addressing/schemes.html#tel).
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_phone
× sStatus: testing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The phone of something is a phone, typically identified using the tel: URI scheme.
* McsEngl.foaf/phone,
* McsEngl.phone@foaf,

foaf:plan-property::
× sDescription: plan - A .plan comment, in the tradition of finger and '.plan' files.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_plan
× sStatus: testing
× sDomain: having this property implies being a Person
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The plan property provides a space for a Person to hold some arbitrary content that would appear in a traditional '.plan' file. The plan file was stored in a user's home directory on a UNIX machine, and displayed to people when the user was queried with the finger utility.
A plan file could contain anything. Typical uses included brief comments, thoughts, or remarks on what a person had been doing lately. Plan files were also prone to being witty or simply osbscure. Others may be more creative, writing any number of seemingly random compositions in their plan file for people to stumble upon.
See History of the Finger Protocol by Rajiv Shah for more on this piece of Internet history. The geekcode property may also be of interest.
* McsEngl.foaf/plan,
* McsEngl.plan@foaf,

foaf:publications-property::
× sDescription: publications - A link to the publications of this person.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_publications
× sStatus: testing
× sDomain: having this property implies being a Person
× sRange: every value of this property is a Document
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The publications property indicates a Document listing (primarily in human-readable form) some publications associated with the Person. Such documents are typically published alongside one's homepage.
* McsEngl.foaf/publications,
* McsEngl.publications@foaf,

foaf:schoolHomepage-property::
× sDescription: schoolHomepage - A homepage of a school attended by the person.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_schoolHomepage
× sStatus: testing
× sDomain: having this property implies being a Person
× sRange: every value of this property is a Document
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The schoolHomepage property relates a Person to a Document that is the homepage of a School that the person attended.
FOAF does not (currently) define a class for 'School' (if it did, it would probably be as a sub-class of Organization). The original application area for schoolHomepage was for 'schools' in the British-English sense; however American-English usage has dominated, and it is now perfectly reasonable to describe Universities, Colleges and post-graduate study using schoolHomepage.
This very basic facility provides a basis for a low-cost, decentralised approach to classmate-reunion and suchlike. Instead of requiring a central database, we can use FOAF to express claims such as 'I studied here' simply by mentioning a school's homepage within FOAF files. Given the homepage of a school, it is easy for FOAF aggregators to lookup this property in search of people who attended that school.
* McsEngl.foaf/schoolHomepage,
* McsEngl.schoolHomepage@foaf,

foaf:skypeID-property::
× sDescription: Skype ID - A Skype ID
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_skypeID
× sStatus: testing
× sDomain: having this property implies being a Agent
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The skype property relates a Agent to an account name of a Skype account of theirs.
See OnlineChatAccount (and OnlineAccount) for a more general (and verbose) mechanism for describing IM and chat accounts.
* McsEngl.foaf/skypeID,
* McsEngl.skypeID@foaf,

foaf:thumbnail-property::
× sDescription: thumbnail - A derived thumbnail image.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_thumbnail
× sStatus: testing
× sDomain: having this property implies being a Image
× sRange: every value of this property is a Image
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The thumbnail property is a relationship between a full-size Image and a smaller, representative Image that has been derrived from it.
It is typical in FOAF to express img and depiction relationships in terms of the larger, 'main' (in some sense) image, rather than its thumbnail(s). A thumbnail might be clipped or otherwise reduced such that it does not depict everything that the full image depicts. Therefore FOAF does not specify that a thumbnail depicts everything that the image it is derrived from depicts. However, FOAF does expect that anything depicted in the thumbnail will also be depicted in the source image.
A thumbnail is typically small enough that it can be loaded and viewed quickly before a viewer decides to download the larger version. They are often used in online photo gallery applications.
* McsEngl.foaf/thumbnail,
* McsEngl.thumbnail@foaf,

foaf:tipjar-property::
× sDescription: tipjar - A tipjar document for this agent, describing means for payment and reward.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_tipjar
× sStatus: testing
× sDomain: having this property implies being a Agent
× sRange: every value of this property is a Document
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The tipjar property relates an Agent to a Document that describes some mechanisms for paying or otherwise rewarding that agent.
The tipjar property was created following discussions about simple, lightweight mechanisms that could be used to encourage rewards and payment for content exchanged online. An agent's tipjar page(s) could describe informal ("Send me a postcard!", "here's my book, music and movie wishlist") or formal (machine-readable micropayment information) information about how that agent can be paid or rewarded. The reward is not associated with any particular action or content from the agent concerned. A link to a service such as PayPal is the sort of thing we might expect to find in a tipjar document.
Note that the value of a tipjar property is just a document (which can include anchors into HTML pages). We expect, but do not currently specify, that this will evolve into a hook for finding more machine-readable information to support payments, rewards. The OnlineAccount machinery is also relevant, although the information requirements for automating payments are not currently clear.
* McsEngl.foaf/tipjar,
* McsEngl.tipjar@foaf,

foaf:title-property::
× sDescription: title - Title (Mr, Mrs, Ms, Dr. etc)
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_title
× sStatus: testing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong:
× editorial: This property is a candidate for deprecation in favour of 'honorificPrefix' following Portable Contacts usage. See the FOAF Issue Tracker.
The approriate values for title are not formally constrained, and will vary across community and context. Values such as 'Mr', 'Mrs', 'Ms', 'Dr' etc. are expected.
* McsEngl.foaf/title,
* McsEngl.title@foaf,

foaf:topic-property::
× sDescription: topic - A topic of some page or document.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_topic
× sStatus: testing
× sDomain: having this property implies being a Document
× sRange: every value of this property is a Thing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The topic property relates a document to a thing that the document is about.
As such it is an inverse of the page property, which relates a thing to a document about that thing.
* McsEngl.foaf/topic,
* McsEngl.topic@foaf,

foaf:topic_interest-property::
× sDescription: topic_interest - A thing of interest to this person.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_topic_interest
× sStatus: testing
× sDomain: having this property implies being a Agent
× sRange: every value of this property is a Thing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The topic_interest property links a Agent to a thing that they're interested in. Unlike topic it is not indirected through a document, but links the thing directly.
* McsEngl.foaf/topic_interest,
* McsEngl.topic_interest@foaf,

foaf:workInfoHomepage-property::
× sDescription: work info homepage - A work info homepage of some person; a page about their work for some organization.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_workInfoHomepage
× sStatus: testing
× sDomain: having this property implies being a Person
× sRange: every value of this property is a Document
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The workInfoHomepage of a Person is a Document that describes their work. It is generally (but not necessarily) a different document from their homepage, and from any workplaceHomepage(s) they may have.
The purpose of this property is to distinguish those pages you often see, which describe someone's professional role within an organisation or project. These aren't really homepages, although they share some characterstics.
* McsEngl.foaf/workInfoHomepage,
* McsEngl.workInfoHomepage@foaf,

foaf:workplaceHomepage-property::
× sDescription: workplace homepage - A workplace homepage of some person; the homepage of an organization they work for.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_workplaceHomepage
× sStatus: testing
× sDomain: having this property implies being a Person
× sRange: every value of this property is a Document
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
* McsEngl.foaf/workplaceHomepage,
* McsEngl.workplaceHomepage@foaf,

× sDescriptionLong: The workplaceHomepage of a Person is a Document that is the homepage of a Organization that they work for.
By directly relating people to the homepages of their workplace, we have a simple convention that takes advantage of a set of widely known identifiers, while taking care not to confuse the things those identifiers identify (ie. organizational homepages) with the actual organizations those homepages describe.

For example, Dan Brickley works at W3C. Dan is a Person with a homepage of http://danbri.org/; W3C is a Organization with a homepage of http://www.w3.org/. This allows us to say that Dan has a workplaceHomepage of http://www.w3.org/.

    <foaf:Person>
     <foaf:name>Dan Brickley</foaf:name>
     <foaf:workplaceHomepage rdf:resource="http://www.w3.org/"/>
    </foaf:Person>
    

Note that several other FOAF properties work this way; schoolHomepage is the most similar. In general, FOAF often indirectly identifies things via Web page identifiers where possible, since these identifiers are widely used and known. FOAF does not currently have a term for the name of the relation (eg. "workplace") that holds between a Person and an Organization that they work for.

foaf:yahooChatID-property::
× sDescription: Yahoo chat ID - A Yahoo chat ID
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_yahooChatID
× sStatus: testing
× sDomain: having this property implies being a Agent
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: http://www.w3.org/2002/07/owl#InverseFunctionalProperty

× sDescriptionLong: The yahooChatID property relates a Agent to a textual identifier assigned to them in the Yahoo online Chat system. See Yahoo's the Yahoo! Chat site for more details of their service. Yahoo chat IDs are also used across several other Yahoo services, including email and Yahoo! Groups.
See OnlineChatAccount (and OnlineAccount) for a more general (and verbose) mechanism for describing IM and chat accounts.
* McsEngl.foaf/yahooChatID,
* McsEngl.yahooChatID@foaf,

foaf:age-property::
× sDescription: age - The age in years of some agent.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_age
× sStatus: unstable
× sDomain: having this property implies being a Agent
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: href="http://www.w3.org/2002/07/owl#FunctionalProperty

× sDescriptionLong: The age property is a relationship between a Agent and an integer string representing their age in years. See also birthday.
* McsEngl.foaf/age,
* McsEngl.age@foaf,

foaf:birthday-property::
× sDescription: birthday - The birthday of this Agent, represented in mm-dd string form, eg. '12-31'.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_birthday
× sStatus: unstable
× sDomain: having this property implies being a Agent
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/
× rdf:type: href="http://www.w3.org/2002/07/owl#FunctionalProperty

× sDescriptionLong: The birthday property is a relationship between a Agent and a string representing the month and day in which they were born (Gregorian calendar). See BirthdayIssue for details of related properties that can be used to describe such things in more flexible ways.
See also age.
* McsEngl.foaf/birthday,
* McsEngl.birthday@foaf,

foaf:membershipClass-property::
× sDescription: membershipClass - Indicates the class of individuals that are a member of a Group
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_membershipClass
× sStatus: unstable
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The membershipClass property relates a Group to an RDF class representing a sub-class of Agent whose instances are all the agents that are a member of the Group.
See Group for details and examples.
* McsEngl.foaf/membershipClass,
* McsEngl.membershipClass@foaf,

foaf:sha1-property::
× sDescription: sha1sum (hex) - A sha1sum hash, in hex.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_sha1
× sStatus: unstable
× sDomain: having this property implies being a Document
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The sha1 property relates a Document to the textual form of a SHA1 hash of (some representation of) its contents.
× editorial: The design for this property is neither complete nor coherent. The Document class is currently used in a way that allows multiple instances at different URIs to have the 'same' contents (and hence hash). If sha1 is an owl:InverseFunctionalProperty, we could deduce that several such documents were the self-same thing. A more careful design is needed, which distinguishes documents in a broad sense from byte sequences.
* McsEngl.foaf/sha1,
* McsEngl.sha1@foaf,

foaf:status-property::
× sDescription: status - A string expressing what the user is happy for the general public (normally) to know about their current activity.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_status
× sStatus: unstable
× sDomain: having this property implies being a Agent
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: status is a short textual string expressing what the user is happy for the general public (normally) to know about their current activity. mood, location, etc.
* McsEngl.foaf/status,
* McsEngl.status@foaf,

foaf:dnaChecksum-property::
× sDescription: DNA checksum - A checksum for the DNA of some thing. Joke.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_dnaChecksum
× sStatus: archaic
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The dnaChecksum property is mostly a joke, but also a reminder that there will be lots of different identifying properties for people, some of which we might find disturbing.
* McsEngl.foaf/dnaChecksum,
* McsEngl.dnaChecksum@foaf,

foaf:family_name-property::
× sDescription: family_name - The family name of some person.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_family_name
× sStatus: archaic
× sDomain: having this property implies being a Person
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: This property is considered an archaic spelling of familyName.
* McsEngl.foaf/family_name,
* McsEngl.family_name@foaf,

foaf:fundedBy-property::
× sDescription: funded by - An organization funding a project or person.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_fundedBy
× sStatus: archaic
× sDomain: having this property implies being a Thing
× sRange: every value of this property is a Thing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The fundedBy property relates something to something else that has provided funding for it.
× editorial: This property is tentatively considered archaic usage, unless we hear about positive implementation experience.
* McsEngl.foaf/fundedBy,
* McsEngl.fundedBy@foaf,

foaf:geekcode-property::
× sDescription: geekcode - A textual geekcode for this person, see http://www.geekcode.com/geek.html
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_geekcode
× sStatus: archaic
× sDomain: having this property implies being a Person
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The geekcode property is used to represent a 'Geek Code' for some Person.
See the Wikipedia entry for details of the code, which provides a somewhat frivolous and willfully obscure mechanism for characterising technical expertise, interests and habits. The geekcode property is not bound to any particular version of the code.
* McsEngl.foaf/geekcode,
* McsEngl.geekcode@foaf,

foaf:givenname-property::
× sDescription: Given name - The given name of some person.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_givenname
× sStatus: archaic
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: The givenName property is provided (alongside familyName) for use when describing parts of people's names. Although these concepts do not capture the full range of personal naming styles found world-wide, they are commonly used and have some value.
There is also a simple name property.
Support is also provided for the more archaic and culturally varying terminology of firstName and lastName.
See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.
* McsEngl.foaf/givenname,
* McsEngl.givenname@foaf,

foaf:holdsAccount-property::
× sDescription: account - Indicates an account held by this agent.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_holdsAccount
× sStatus: archaic
× sDomain: having this property implies being a Agent
× sRange: every value of this property is a OnlineAccount
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong:
× editorial: This property is considered archaic usage. It is generally better to use account instead.
The holdsAccount property relates a Agent to an OnlineAccount for which they are the sole account holder. See OnlineAccount for usage details.
This property is equivalent to the account property, which was introduced primarily to provide simpler naming for the same idea.
* McsEngl.foaf/holdsAccount,
* McsEngl.holdsAccount@foaf,

foaf:surname-property::
× sDescription: Surname - The surname of some person.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_surname
× sStatus: archaic
× sDomain: having this property implies being a Person
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong: A number of naming constructs are under development to provide naming substructure; draft properties include firstName, givenName, and surname. These are not currently stable or consistent; see the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.
There is also a simple name property.
* McsEngl.foaf/surname,
* McsEngl.surname@foaf,

foaf:theme-property::
× sDescription: theme - A theme.
× sSource-url: http://xmlns.com/foaf/spec/20140114.html#term_theme
× sStatus: archaic
× sDomain: having this property implies being a Thing
× sRange: every value of this property is a Thing
× rdfs:isDefinedBy: http://xmlns.com/foaf/0.1/

× sDescriptionLong:
× editorial: This property is considered archaic usage, and is not currently recommended for usage.
The theme property is rarely used and under-specified. The intention was to use it to characterise interest / themes associated with projects and groups. Further work is needed to meet these goals.
* McsEngl.foaf/theme,
* McsEngl.theme@foaf,

info-resource of foaf

description::
* http://xmlns.com/foaf/spec/, FOAF Vocabulary Specification 0.99, Namespace Document 14 January 2014 - Paddington Edition,

name::
* McsEngl.foaf'Infrsc,

ontology.eli

description::
"The European Legislation Identifier (ELI) is a framework to make legislation metadata available online in a standardised format, so that it can be accessed, exchanged and reused across borders. For general information about ELI (governance, tools and news), and the implementation status of ELI by various stakeholders (in particular, the way ELI is implemented by the Office of Publications on Eur- Lex), please consult the ELI Register on Eur-Lex."
[{2021-01-29} https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/solution/eif-toolbox/solution-eli-ontology]

name::
* McsEngl.eliontology,
* McsEngl.ontology.eli,

ontology.owl

description::
· owl="http://www.w3.org/2002/07/owl#"

name::
* McsEngl.owl-ontology,
* McsEngl.ontology.owl,

ontology.rdf

description::
· rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

name::
* McsEngl.rdf-ontology,
* McsEngl.ontology.rdf,

ontology.rdfs

description::
· rdfs="http://www.w3.org/2000/01/rdf-schema#"

name::
* McsEngl.rdfs-ontology,
* McsEngl.ontology.rdfs,

ontology.skos

description::
· skos="http://www.w3.org/2004/02/skos/core#"
"SKOS is a vocabulary for publishing classification schemes such as terminologies and thesauri on the Web. SKOS is since 2009 a W3C recommendation and is widely used in the library world. The Library of Congress published its Subject Headings as a SKOS vocabulary."
[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/#section-vocabulary]
===
"Simple Knowledge Organization System (SKOS) is a W3C recommendation designed for representation of thesauri, classification schemes, taxonomies, subject-heading systems, or any other type of structured controlled vocabulary. SKOS is part of the Semantic Web family of standards built upon RDF and RDFS, and its main objective is to enable easy publication and use of such vocabularies as linked data."
[{2021-01-24} https://en.wikipedia.org/wiki/Simple_Knowledge_Organization_System]

name::
* McsEngl.Rdfvoc.SKOS,
* McsEngl.SKOS-Rdfvoc,
* McsEngl.SKOS'(simple-knowledge-organization-system),
* McsEngl.simple-knowledge-organization-system,
* McsEngl.skos-ontology,
* McsEngl.ontology.skos,

ontology.terms

description::
· terms="http://purl.org/dc/terms/"

name::
* McsEngl.terms-ontology,
* McsEngl.ontology.terms,

ontology.xml

description::
· xml="http://www.w3.org/XML/1998/namespace"

name::
* McsEngl.xml-ontology,
* McsEngl.ontology.xml,

ontology.xsd

description::
· xsd="http://www.w3.org/2001/XMLSchema#"

name::
* McsEngl.xsd-ontology,
* McsEngl.ontology.xsd,

ontology.CIDOC-CRM

description::
"The CIDOC CRM represents an 'ontology' for cultural heritage information i.e. it describes in a formal language the explicit and implicit concepts and relations relevant to the documentation of cultural heritage. The primary role of the CIDOC CRM is to serve as a basis for mediation of cultural heritage information and thereby provide the semantic 'glue' needed to transform today's disparate, localised information sources into a coherent and valuable global resource.
The CIDOC CRM is intended to promote a shared understanding of cultural heritage information by providing a common and extensible semantic framework that any cultural heritage information can be mapped to. It is intended to be a common language for domain experts and implementers to formulate requirements for information systems and to serve as a guide for good practice of conceptual modelling. In this way, it can provide the "semantic glue" needed to mediate between different sources of cultural heritage information, such as that published by museums, libraries and archives.
The CIDOC CRM is the culmination of over 10 years work by the CIDOC Documentation Standards Working Group and CIDOC CRM SIG which are working groups of CIDOC. Since 9/12/2006 it is official standard ISO 21127:2006."
[{2021-01-26} http://www.cidoc-crm.org/node/202]

name::
* McsEngl.CIDOC-CRM-ontology,
* McsEngl.ontology.CIDOC-CRM,

ontology.DBpedia

description::
"The English version of the DBpedia knowledge base describes 4.58 million things, out of which 4.22 million are classified in a consistent ontology, including 1,445,000 persons, 735,000 places (including 478,000 populated places), 411,000 creative works (including 123,000 music albums, 87,000 films and 19,000 video games), 241,000 organizations (including 58,000 companies and 49,000 educational institutions), 251,000 species and 6,000 diseases."
[{2021-01-30} https://wiki.dbpedia.org/about]

name::
* McsEngl.ontology.DBpedia,

tool of lagOntg

description::
·

name::
* McsEngl.Ontgtool,
* McsEngl.lagOntg'tool!⇒Ontgtool,
* McsEngl.tech.lagOntg!⇒Ontgtool,

Ontgtool.WebProtégé of lagOntg

description::
"WebProtégé is an ontology development environment for the Web that makes it easy to create, upload, modify, and share ontologies for collaborative viewing and editing.
WebProtégé fully supports the latest OWL 2 Web Ontology Language. The highly configurable user interface creates the perfect environment for beginners and experts alike. Collaboration features abound, including sharing and permissions, threaded notes and discussions, watches and email notifications. RDF/XML, Turtle, OWL/XML, OBO, and other formats available for ontology upload and download.
* W3C standards compliant
* Simple, customizable user interface
* Optimized for collaboration
* Change tracking and revision history
* Web forms for domain specific editing
* Multiple upload/download formats
* Cross compatible with Protégé Desktop"
[{2021-01-28} https://protege.stanford.edu/products.php#web-protege]

name::
* McsEngl.Ontgtool.WebProtégé,
* McsEngl.WebProtégé,

info-resource of lagOntg

description::
* https://www.isko.org/cyclo/ontologies,
* https://en.wikipedia.org/wiki/Ontology_language,
* http://www.jfsowa.com/ontology/index.htm,

name::
* McsEngl.lagOntg'Infrsc,

lagOntg.SPECIFIC

description::
* markup-lagOntg,
===
* description-logic-based-lagOnt,
* first-order-logic-based-lagOnt,
* frame-based-lagOnt,
===
* Common Logic,
* CycL,
* DAML+OIL,
* DOGMA (Developing Ontology-Grounded Methods and Applications),
* F-Logic,
* KIF,
* KL-ONE,
* KM,
* LOOM,
* OCML (Operational Conceptual Modelling Language),
* OIL (Ontology Inference Layer),
* OKBC,
* OWL,
* PLIB (Parts LIBrary),
* RACER,
* RDF,
* SHOE,
[{2021-01-27} https://en.wikipedia.org/wiki/Ontology_language]

name::
* McsEngl.lagOntg.specific,

lagOntg.markup

description::
* DAML+OIL,
* OIL-(Ontology Inference Layer),
* OWL-(Web Ontology Language),
* RDF-(Resource Description Framework),
* SHOE,

name::
* McsEngl.lagOntg.markup,
* McsEngl.markup-lagOntg,

lagOntg.OWL

description::
"Ontologies are formalized vocabularies of terms, often covering a specific domain and shared by a community of users.
They specify the definitions of terms by describing their relationships with other terms in the ontology."
[{2021-01-03} https://www.w3.org/TR/owl2-overview/]

name::
* McsEngl.OWL'(web-ontology-language)!⇒lagOwlg,
* McsEngl.lagCnpt.006-OWL!⇒lagOwlg,
* McsEngl.lagCnpt.OWL!⇒lagOwlg,
* McsEngl.lagOwlg,
* McsEngl.lagOwlg'(web-ontology-language-OWL)!⇒lagOwlg,
* McsEngl.web-ontology-language!⇒lagOwlg,

descriptionLong::
"The Web Ontology Language (OWL) is a family of knowledge representation languages for authoring ontologies. Ontologies are a formal way to describe taxonomies and classification networks, essentially defining the structure of knowledge for various domains: the nouns representing classes of objects and the verbs representing relations between the objects.
Ontologies resemble class hierarchies in object-oriented programming but there are several critical differences. Class hierarchies are meant to represent structures used in source code that evolve fairly slowly (perhaps with monthly revisions) whereas ontologies are meant to represent information on the Internet and are expected to be evolving almost constantly. Similarly, ontologies are typically far more flexible as they are meant to represent information on the Internet coming from all sorts of heterogeneous data sources. Class hierarchies on the other hand tend to be fairly static and rely on far less diverse and more structured sources of data such as corporate databases.[1]
The OWL languages are characterized by formal semantics. They are built upon the World Wide Web Consortium's (W3C) XML standard for objects called the Resource Description Framework (RDF).[2] OWL and RDF have attracted significant academic, medical and commercial interest.
In October 2007,[3] a new W3C working group[4] was started to extend OWL with several new features as proposed in the OWL 1.1 member submission.[5] W3C announced the new version of OWL on 27 October 2009.[6] This new version, called OWL 2, soon found its way into semantic editors such as Protégé and semantic reasoners such as Pellet,[7] RacerPro,[8] FaCT++[9][10] and HermiT.[11]
The OWL family contains many species, serializations, syntaxes and specifications with similar names. OWL and OWL2 are used to refer to the 2004 and 2009 specifications, respectively. Full species names will be used, including specification version (for example, OWL2 EL). When referring more generally, OWL Family will be used.[12][13][14]"
[{2021-01-03} https://en.wikipedia.org/wiki/Web_Ontology_Language]

input of lagOwlg

description::
"The W3C OWL 2 Web Ontology Language (OWL) is a Semantic Web language designed to represent rich and complex knowledge about things, groups of things, and relations between things."
[{2021-01-08} https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Introduction]
===
"An ontology is a set of precise descriptive statements about some part of the world (usually referred to as the domain of interest or the subject matter of the ontology)."
[{2021-01-08} https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#What_is_OWL_2.3F]

name::
* McsEngl.Owlinput,
* McsEngl.domain-of-inerest@lagOwlg!⇒Owlinput,
* McsEngl.lagOwlg'input!⇒Owlinput,
* McsEngl.ontology@lagOwlg!⇒Owlinput,
* McsEngl.subject-matter@lagOwlg!⇒Owlinput,

IRI of Owlinput

description::
"Each ontology may have an ontology IRI, which is used to identify an ontology. If an ontology has an ontology IRI, the ontology may additionally have a version IRI, which is used to identify the version of the ontology. The version IRI may be, but need not be, equal to the ontology IRI. An ontology without an ontology IRI must not contain a version IRI."
[{2021-01-10} https://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Ontologies]

name::
* McsEngl.Owlinput'IRI,

version of Owlinput

description::
"Each ontology may have an ontology IRI, which is used to identify an ontology. If an ontology has an ontology IRI, the ontology may additionally have a version IRI, which is used to identify the version of the ontology. The version IRI may be, but need not be, equal to the ontology IRI. An ontology without an ontology IRI must not contain a version IRI."
[{2021-01-10} https://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Ontologies]

name::
* McsEngl.Owlinput'version,

entity of Owlinput

description::
"Entities: elements used to refer to real-world objects
... All atomic constituents of statements, be they objects (John, Mary), categories (female) or relations (married) are called entities."
[{2021-01-09} https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Modeling_Knowledge:_Basic_Notions]

name::
* McsEngl.Owlentity,
* McsEngl.Owlinput'entity!⇒Owlentity,
* McsEngl.entity@lagOwlg,

Owlentity.individual

description::
"All atomic constituents of statements, be they objects (John, Mary), categories (female) or relations (married) are called entities.
In OWL 2, we denote objects as individuals, categories as classes and relations as properties."
[{2021-01-09} https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Modeling_Knowledge:_Basic_Notions]

name::
* McsEngl.Owlentity.individual!⇒Owlindividual,
* McsEngl.Owlentity.object!⇒Owlindividual,
* McsEngl.Owlindividual,
* McsEngl.individual@lagOwlg,
* McsEngl.object@lagOwlg,

Owlentity.class

description::
"All atomic constituents of statements, be they objects (John, Mary), categories (female) or relations (married) are called entities.
In OWL 2, we denote objects as individuals, categories as classes and relations as properties."
[{2021-01-09} https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Modeling_Knowledge:_Basic_Notions]

name::
* McsEngl.Owlclass,
* McsEngl.Owlentity.category!⇒Owlclass,
* McsEngl.Owlentity.class!⇒Owlclass,
* McsEngl.class@lagOwlg,

Owlentity.property

description::
"All atomic constituents of statements, be they objects (John, Mary), categories (female) or relations (married) are called entities.
In OWL 2, we denote objects as individuals, categories as classes and relations as properties."
[{2021-01-09} https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Modeling_Knowledge:_Basic_Notions]

name::
* McsEngl.Owlentity.property!⇒Owlproperty,
* McsEngl.Owlentity.relation!⇒Owlproperty,
* McsEngl.Owlproperty,
* McsEngl.property@lagOwlg,
* McsEngl.relation@lagOwlg,

Owlproperty.object

description::
"Properties in OWL 2 are further subdivided.
Object properties relate objects to objects (like a person to their spouse), while datatype properties assign data values to objects (like an age to a person).
Annotation properties are used to encode information about (parts of) the ontology itself (like the author and creation date of an axiom) instead of the domain of interest."
[{2021-01-09} https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Modeling_Knowledge:_Basic_Notions]

name::
* McsEngl.Owlproperty.object,
* McsEngl.object-property@lagOwlg,

Owlproperty.datatype

description::
"Data properties connect individuals with literals."
[{2021-01-10} https://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Data_Properties]
===
"Properties in OWL 2 are further subdivided.
Object properties relate objects to objects (like a person to their spouse), while datatype properties assign data values to objects (like an age to a person).
Annotation properties are used to encode information about (parts of) the ontology itself (like the author and creation date of an axiom) instead of the domain of interest."
[{2021-01-09} https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Modeling_Knowledge:_Basic_Notions]

name::
* McsEngl.Owlproperty.datatype,
* McsEngl.data-property@lagOwlg,

Owlproperty.annotation

description::
"Properties in OWL 2 are further subdivided.
Object properties relate objects to objects (like a person to their spouse), while datatype properties assign data values to objects (like an age to a person).
Annotation properties are used to encode information about (parts of) the ontology itself (like the author and creation date of an axiom) instead of the domain of interest."
[{2021-01-09} https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Modeling_Knowledge:_Basic_Notions]

name::
* McsEngl.Owlproperty.annotation,

vocabulary of Owlinput

description::
"Entities are the fundamental building blocks of OWL 2 ontologies, and they define the vocabulary — the named terms — of an ontology.
In logic, the set of entities is usually said to constitute the signature of an ontology.
Apart from entities, OWL 2 ontologies typically also contain literals, such as strings or integers."
[{2021-01-10} https://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Entities.2C_Literals.2C_and_Anonymous_Individuals]

name::
* McsEngl.Owlinput'vocabulary,
* McsEngl.vocabulary@lagOwlg,

literal of Owlinput

description::
"Literals represent data values such as particular strings or integers.
They are analogous to typed RDF literals [RDF Concepts] and can also be understood as individuals denoting data values."
[{2021-01-10} https://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Literals]

name::
* McsEngl.Owlliteral,
* McsEngl.Owlinput'literal!⇒Owlliteral,

axiom of Owlinput

description::
"Now, in order to formulate knowledge explicitly, it is useful to assume that it consists of elementary pieces that are often referred to as statements or propositions. Statements like “it is raining” or “every man is mortal” are typical examples for such basic propositions. Indeed, every OWL 2 ontology is essentially just a collection of such basic “pieces of knowledge.” Statements that are made in an ontology are called axioms in OWL 2, and the ontology asserts that its axioms are true. In general, OWL statements might be either true or false given a certain state of affairs. This distinguishes them from entities and expressions as described further below."
[{2021-01-09} https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Modeling_Knowledge:_Basic_Notions]

name::
* McsEngl.Owlaxiom,
* McsEngl.Owlinput'axiom!⇒Owlaxiom,
* McsEngl.axiom@lagOwlg,

annotation of Owlinput

description::
"OWL 2 applications often need ways to associate additional information with ontologies, entities, and axioms. To this end, OWL 2 provides for annotations on ontologies, axioms, and entities.
eample: One might want to associate human-readable labels with IRIs and use them when visualizing an ontology. To this end, one might use the rdfs:label annotation property to associate such labels with ontology IRIs."
[{2021-01-10} https://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Annotations]

name::
* McsEngl.Owlannotation,
* McsEngl.Owlinput'annotation!⇒Owlannotation,

open-world-assumption of Owlinput

description::
"If some fact is not present in a database, it is usually considered false (the so-called closed-world assumption) whereas in the case of an OWL 2 document it may simply be missing (but possibly true), following the open-world assumption."
[{2021-01-08} https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#What_is_OWL_2.3F]

name::
* McsEngl.Owlinput'open-world-assumption,
* McsEngl.lagOwlg'open-world-assumption,
* McsEngl.open-world-assumption@lagOwlg,

descriptionLong::
"In addition, OWL makes an open world assumption. That is, descriptions of resources are not confined to a single file or scope. While class C1 may be defined originally in ontology O1, it can be extended in other ontologies. The consequences of these additional propositions about C1 are monotonic. New information cannot retract previous information. New information can be contradictory, but facts and entailments can only be added, never deleted.
The possibility of such contradictions is something the designer of an ontology needs to take into consideration. It is expected that tool support will help detect such cases.
[http://www.w3.org/TR/2004/REC-owl-guide-20040210/]

output of lagOwlg

description::
· the-output of the-mapping.
===
"An OWL 2 ontology is an abstract notion defined in terms of the structural specification. Each ontology is associated with an ontology document, which physically contains the ontology stored in a particular way. The name "ontology document" reflects the expectation that a large number of ontologies will be stored in physical text documents written in one of the syntaxes of OWL 2. OWL 2 tools, however, are free to devise other types of ontology documents — that is, to introduce other ways of physically storing ontologies."
[{2021-01-10} https://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Ontologies]

name::
* McsEngl.Owloutput,
* McsEngl.lagOwlg'document!⇒Owloutput,
* McsEngl.lagOwlg'output!⇒Owloutput,

ontology of lagOwlg

description::
· the-whole output system that models the-input, I call ontology.

name::
* McsEngl.Owlontology,
* McsEngl.lagOwlg'output-system!⇒Owlontology,

Owlontology.Bibo

description::
"Bibo, the Bibliographic Ontology developed by Bruce D’Arcus and Frédérick Giasson in 2009, is the first OWL ontology that provides main concepts and properties for describing bibliographic entities and citations. Bibo’s properties have been used since 2011 in the BNB Linked Data Platform, which provides access to the British National Bibliography published as linked open data. The Linked Data Service of the Deutsche Nationalbibliothek also has used Bibo since 2010. Bibo includes five principal classes and 34 subclasses, 32 object properties and 20 sub-properties, 20 datatype properties (10 of which are OWL equivalent properties) and 26 sub-properties. Bibo presents a variety of entities related to the bibliographic world, organized into five principal classes: Agent, Collection, Document, Document Status, Event, and 34 subclasses. The classes Document and Collection accommodate most of the bibliographic sub-entities. Among the subclasses of Document, there are Article, Book, Image, Legal Document, Manuscript, Report, Web page, etc. Among the subclasses of Collection, there are Periodical, Series, and Web site.
Even though the developers of Bibo curated sound definitions of the classes that belong to the bibliographic field, it is worth mentioning that this ontology is not very detailed with respect to the properties required in a bibliographic environment. Although it represents the translations of bibliographic resources, the properties that concern derivative, merging, and absorbed resources, which are provided instead by BIBFRAME, are not represented in Bibo. The aforementioned properties refer to two different categories of relationships very relevant in the bibliographic field: derivative relationships, which concern different editions of the same work and works derived from a pre-existing work, and sequential relationships that include sequels of a monograph, the logical continuation of, or the transformation of another work (Tillett 1989; Green 2001; IFLA 2017, 69-78)."
[{2021-01-26} https://www.isko.org/cyclo/ontologies#6]

name::
* McsEngl.Bibo-Owlontology,
* McsEngl.Owlontology.Bibo,

tool of lagOwlg

description::
* editor,
* reasoner,

name::
* McsEngl.lagOwlg'tool,

addressWpg::
* https://www.w3.org/2001/sw/wiki/Tools,

info-resource of lagOwlg

description::
* https://www.w3.org/TR/owl2-overview/,
* https://www.w3.org/TR/owl2-primer/,
* https://en.wikipedia.org/wiki/Web_Ontology_Language,

name::
* McsEngl.lagOwlg'Infrsc,

DOING of lagOwlg

description::
"... with the ultimate goal of making Web content more accessible to machines."
[{2021-01-08} https://www.w3.org/TR/2012/REC-owl2-overview-20121211/#Introduction]

name::
* McsEngl.lagOwlg'doing,

lagOntg.OWL2

description::
"Relationship to OWL 1
OWL 2 has a very similar overall structure to OWL 1. Looking at Figure 1, almost all the building blocks of OWL 2 were present in OWL 1, albeit possibly under different names.
The central role of RDF/XML, the role of other syntaxes, and the relationships between the Direct and RDF-Based semantics (i.e., the correspondence theorem) have not changed. More importantly, backwards compatibility with OWL 1 is, to all intents and purposes, complete: all OWL 1 Ontologies remain valid OWL 2 Ontologies, with identical inferences in all practical cases (see Section 4.2 of OWL 2 New Features and Rationale [OWL 2 New Features and Rationale]).
OWL 2 adds new functionality with respect to OWL 1. Some of the new features are syntactic sugar (e.g., disjoint union of classes) while others offer new expressivity, including:
* keys;
* property chains;
* richer datatypes, data ranges;
* qualified cardinality restrictions;
* asymmetric, reflexive, and disjoint properties; and
* enhanced annotation capabilities
OWL 2 also defines three new profiles [OWL 2 Profiles] and a new syntax [OWL 2 Manchester Syntax]. In addition, some of the restrictions applicable to OWL DL have been relaxed; as a result, the set of RDF Graphs that can be handled by Description Logics reasoners is slightly larger in OWL 2.
All of the above is documented in detail in the OWL 2 New Features and Rationale document [OWL 2 New Features and Rationale]. The OWL 2 Quick Reference Guide [OWL 2 Quick Guide] also provides an overview of the features of OWL 2, clearly indicating those that are new."
[{2021-01-30} https://www.w3.org/TR/2012/REC-owl2-overview-20121211/#Relationship_to_OWL_1]

name::
* McsEngl.OWL2!⇒lagOwl2,
* McsEngl.lagOntl.OWL2!⇒lagOwl2,
* McsEngl.lagOwl2,

lagOntg.SWRL (link)

lagCnpt.rule-020

description::
· rule-language is a-propositional-language that uses if-then-propositions.

name::
* McsEngl.lagCnpt.020-rule!⇒lagRule,
* McsEngl.lagCnpt.rule!⇒lagRule,
* McsEngl.lagPpsl.rule!⇒lagRule,
* McsEngl.lagRule,
* McsEngl.rule-language!⇒lagRule,

descriptionLong::
"Rules are a simple way of encoding knowledge, and are a drastic simplification of first order logic, for which it is relatively easy to implement inference engines that can process the conditions and draw the right conclusions. A rule system is an implementation of a particular syntax and semantics of rules, which may extend the simple notion described above to include existential quantification, disjunction, logical conjunction, negation, functions, non monotonicity, and many other features. Rule systems have been implemented and studied since the mid-1970s and saw significant uptake in the 1980s during the height of so-called Expert Systems."
[{2021-01-30} https://en.wikipedia.org/wiki/Rule_Interchange_Format]

lagRule.specific

description::
* RIF,
* RuleML,
* SWRL,
===
"Rule-based languages instantiate rules when activated by conditions in a set of data. Of all possible activations, some set is selected and the statements belonging to those rules execute. Rule-based languages include:[citation needed]
* awk,
* CLIPS,
* Constraint Handling Rules,
* Drools,
* GOAL agent programming language,
* Jess,
* OPS5,
* Prolog,
* ToonTalk – robots are rules,
* Mathematica,
* XSLT[citation needed],
* Wolfram Language",
[{2021-02-01} https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Rule-based_languages]

name::
* McsEngl.lagRule.specific,

lagRule.RuleML

description::
"Rules have many uses, coming in a multitude of forms. RuleML is a unifying system of families of languages for Web rules over Web documents and data. RuleML is specified syntactically through schema languages (normatively, in Relax NG), originally developed for XML and transferable to other formats such as JSON. Since Version 1.02, rather than assuming predefined default semantics, RuleML allows partially constrained semantic profiles and fully-specified semantics. PSOA RuleML employs model-theoretic semantics and transformational realizations, bridges between (deductive) graph and relational databases and other data paradigms, formalizes Cypher-like labeled property graphs, and is illustrated via (blockchain, ...) examples and (air traffic control, ...) use cases."
[{2021-01-30} http://wiki.ruleml.org/index.php/Introducing_RuleML]

name::
* McsEngl.RuleML!⇒lagRlml,
* McsEngl.lagRlml,
* McsEngl.lagRule.RuleML!⇒lagRlml,

descriptionLong::
"RuleML is a global initiative, led by a non-profit organization RuleML Inc., that is devoted to advancing research and industry standards design activities in the technical area of rules that are semantic and highly inter-operable. The standards design takes the form primarily of a markup language, also known as RuleML. The research activities include an annual research conference, the RuleML Symposium, also known as RuleML for short. Founded in fall 2000 by Harold Boley, Benjamin Grosof, and Said Tabet, RuleML was originally devoted purely to standards design, but then quickly branched out into the related activities of coordinating research and organizing an annual research conference starting in 2002. The M in RuleML is sometimes interpreted as standing for Markup and Modeling. The markup language was developed to express both forward (bottom-up) and backward (top-down) rules in XML for deduction, rewriting, and further inferential-transformational tasks. It is defined by the Rule Markup Initiative, an open network of individuals and groups from both industry and academia[1] that was formed to develop a canonical Web language for rules using XML markup and transformations from and to other rule standards/systems."
[{2021-01-30} https://en.wikipedia.org/wiki/RuleML]

lagRule.RIF

description::
"The Rule Interchange Format (RIF) is a W3C Recommendation. RIF is part of the infrastructure for the semantic web, along with (principally) SPARQL, RDF and OWL. Although originally envisioned by many as a "rules layer" for the semantic web, in reality the design of RIF is based on the observation that there are many "rules languages" in existence, and what is needed is to exchange rules between them.[1]
RIF includes three dialects, a Core dialect which is extended into a Basic Logic Dialect (BLD) and Production Rule Dialect (PRD).[2]"
[{2021-01-05} https://en.wikipedia.org/wiki/Rule_Interchange_Format]

name::
* McsEngl.RIF'(rule-interchange-format)!⇒lagRift,
* McsEngl.lagCnpt.008-RIF!⇒lagRift,
* McsEngl.lagCnpt.RIF!⇒lagRift,
* McsEngl.lagRift,
* McsEngl.lagRule.RIF!⇒lagRift,
* McsEngl.rule-interchange-format!⇒lagRift,

relation-to-RuleML of lagRift

description::
"3.4 What is the relationship between RuleML and RIF?
RuleML has provided input for RIF on several levels, including the use of 'striped' XML as well as the structuring of rule classes into a family of sublanguages with, e.g., Datalog RuleML partially mappable to the RIF Core Dialect, Derivation RuleML to the RIF Basic Logic Dialect, and the production-rule sublanguage of Reaction RuleML to the RIF Production Rule Dialect. Conversely, RuleML adopted some features that were developed as part of the RIF Working Group such as role tags <if> ... <then> instead of <body> ... <head>. Shared RIF RuleML implementations and use cases are projected to lead to further convergence."
[{2021-01-30} https://www.w3.org/2005/rules/wiki/RIF_FAQ]

name::
* McsEngl.lagRift'relation-to-RullML,

info-resource of lagRift

description::
* https://www.w3.org/TR/rif-overview/,

name::
* McsEngl.lagRift'Infrsc,

lagOntg.SWRL

description::
"The Semantic Web Rule Language (SWRL) is a proposed language for the Semantic Web that can be used to express rules as well as logic, combining OWL DL or OWL Lite with a subset of the Rule Markup Language (itself a subset of Datalog).[1]
The specification was submitted in May 2004 to the W3C by the National Research Council of Canada, Network Inference (since acquired by webMethods), and Stanford University in association with the Joint US/EU ad hoc Agent Markup Language Committee. The specification was based on an earlier proposal for an OWL rules language.[2][3]
SWRL has the full power of OWL DL, but at the price of decidability and practical implementations.[4] However, decidability can be regained by restricting the form of admissible rules, typically by imposing a suitable safety condition.[5]
Rules are of the form of an implication between an antecedent (body) and consequent (head). The intended meaning can be read as: whenever the conditions specified in the antecedent hold, then the conditions specified in the consequent must also hold."
[{2021-01-28} https://en.wikipedia.org/wiki/Semantic_Web_Rule_Language]

name::
* McsEngl.SWRL'(semantic-web-rule-language)!⇒lagSwrl,
* McsEngl.lagOntg.Swrl!⇒lagSwrl,
* McsEngl.lagSwrl,
* McsEngl.semantic-web-rule-language!⇒lagSwrl,

lagCnpt.semantic-network-018

description::
· semantic-network-lang is a-concept-language that models mind-concepts as a-NETWORK.

name::
* McsEngl.frame-network!⇒lagSnet,
* McsEngl.graph-lagCnpt!⇒lagSnet,
* McsEngl.lagCnpt.022-semantic-network!⇒lagSnet,
* McsEngl.lagCnpt.semantic-network!⇒lagSnet,
* McsEngl.lagNtwk!⇒lagSnet,
* McsEngl.lagSnet,
* McsEngl.lagSnet'(semantic-network)!⇒lagSnet,
* McsEngl.semantic-network!⇒lagSnet,

descriptionLong::
"A semantic network, or frame network is a knowledge base that represents semantic relations between concepts in a network. This is often used as a form of knowledge representation. It is a directed or undirected graph consisting of vertices, which represent concepts, and edges, which represent semantic relations between concepts,[1] mapping or connecting semantic fields. A semantic network may be instantiated as, for example, a graph database or a concept map.
Typical standardized semantic networks are expressed as semantic triples.
Semantic networks are used in natural language processing applications such as semantic parsing[2] and word-sense disambiguation.[3]"
[{2021-01-30} https://en.wikipedia.org/wiki/Semantic_network]

output of lagSnet

description::
"A knowledge graph is a knowledge base that uses a graph-structured data model or topology to integrate data. Knowledge graphs are often used to store interlinked descriptions of entities – objects, events, situations or abstract concepts – with free-form semantics.[1]
Since the development of the Semantic Web, knowledge graphs are often associated with linked open data projects, focusing on the connections between concepts and entities.[2][3] They are also prominently associated with and used by search engines such as Google, Bing, and Yahoo; knowledge-engines and question-answering services such as WolframAlpha, Apple's Siri, and Amazon Alexa; and social networks such as LinkedIn and Facebook."
[{2021-01-31} https://en.wikipedia.org/wiki/Knowledge_graph]

name::
* McsEngl.Snetoutput,
* McsEngl.knowledge-graph!⇒Snetoutput,
* McsEngl.lagSnet'output!⇒Snetoutput,
* knowledge-base,

addressWpg::
* https://www.stardog.com/blog/what-is-a-knowledge-graph/, and its relation with database-graph,

Snetoutput.Google-knowledge-graph

description::
"The Google Knowledge Graph is a knowledge base used by Google and its services to enhance its search engine's results with information gathered from a variety of sources. The information is presented to users in an infobox next to the search results. These infoboxes were added to Google's search engine in May 2012, starting in the United States, with international expansion by the end of the year.[1] Google has referred to these infoboxes, which appear to the right (top on mobile) of search results, as "knowledge panels".[2]
The information covered by Google's Knowledge Graph grew quickly after launch, tripling its size within seven months (covering 570 million entities and 18 billion facts[3]). By mid-2016, Google reported that it held 70 billion facts[4] and answered "roughly one-third" of the 100 billion monthly searches they handled. By May 2020, this had grown to 500 billion facts on 5 billion entities.[5]
There is no official documentation of how the Google Knowledge Graph is implemented.[6] According to Google, its information is retrieved from many sources, including the CIA World Factbook, Wikidata, and Wikipedia.[1][7] It is used to answer direct spoken questions in Google Assistant[8][9] and Google Home voice queries.[10] It has been criticized for providing answers without source attribution or citation.[11]"
[{2021-01-31} https://en.wikipedia.org/wiki/Google_Knowledge_Graph]

name::
* McsEngl.Google-knowledge-graph,
* McsEngl.Snetoutput.Google-knowledge-graph,

Snetoutput.Wordnet

description::
"WordNet® is a large lexical database of English. Nouns, verbs, adjectives and adverbs are grouped into sets of cognitive synonyms (synsets), each expressing a distinct concept. Synsets are interlinked by means of conceptual-semantic and lexical relations. The resulting network of meaningfully related words and concepts can be navigated with the browser(link is external). WordNet is also freely and publicly available for download. WordNet's structure makes it a useful tool for computational linguistics and natural language processing.
WordNet superficially resembles a thesaurus, in that it groups words together based on their meanings. However, there are some important distinctions. First, WordNet interlinks not just word forms—strings of letters—but specific senses of words. As a result, words that are found in close proximity to one another in the network are semantically disambiguated. Second, WordNet labels the semantic relations among words, whereas the groupings of words in a thesaurus does not follow any explicit pattern other than meaning similarity."
[{2021-02-02} https://wordnet.princeton.edu/]
===
"Some early knowledge graphs were topic-specific. In 1985, Wordnet was founded, capturing semantic relationships between words and meanings – an application of this idea to language itself."
[{2021-01-31} https://en.wikipedia.org/wiki/Knowledge_graph]

name::
* McsEngl.Snetoutput.Wordnet,
* McsEngl.Wordnet,

addressWpg::
* https://wordnet.princeton.edu/,
* online: http://wordnetweb.princeton.edu/perl/webwn,
* concept neighbourhoods: http://www.ketlab.org.uk/wordnet.html,

lagSnet.SPECIFIC

description::
·

name::
* McsEngl.lagSnet.specific,

lagSnet.concept-map

description::
·

name::
* McsEngl.lagCnpt.032-concept-map!⇒lagCtmp,
* McsEngl.lagCnpt.concept-map!⇒lagCtmp,
* McsEngl.lagCtmp,
* McsEngl.lagCtmp'(concept-map)!⇒lagCtmp,
* McsEngl.lagSnet.concept-map!⇒lagCtmp,
* McsEngl.concept-map!⇒lagCtmp,

descriptionLong::
"A concept map or conceptual diagram is a diagram that depicts suggested relationships between concepts.[1] Concept maps may be used by instructional designers, engineers, technical writers, and others to organize and structure knowledge.
A concept map typically represents ideas and information as boxes or circles, which it connects with labeled arrows, often in a downward-branching hierarchical structure. The relationship between concepts can be articulated in linking phrases such as "causes", "requires", "such as" or "contributes to".[2]
The technique for visualizing these relationships among different concepts is called concept mapping. Concept maps have been used to define the ontology of computer systems, for example with the object-role modeling or Unified Modeling Language formalism."
[{2021-02-07} https://en.wikipedia.org/wiki/Concept_map]

lagCnpt.controlled-natural-language-018

description::
· controlled-natural-language is a-propositional-language that uses a-subset of a-natural-language to make it unambiguous and monosemantic to be-understood by machines.

name::
* McsEngl.CNL'(controlled-natural-language)!⇒lagCdnl,
* McsEngl.controlled-natural-language!⇒lagCdnl,
* McsEngl.lagCdnl,
* McsEngl.lagCdnl'(controlled-natural-language)!⇒lagCdnl,
* McsEngl.lagCnpt.018-controlled-natural-language!⇒lagCdnl,
* McsEngl.lagCnpt.controlled-natural-language!⇒lagCdnl,
* McsEngl.lagPpsl.controlled-natural-language!⇒lagCdnl,
* McsEngl.machine-oriented-controlled-natural-language!⇒lagCdnl,

descriptionLong::
"This paper presents a survey of research in controlled natural languages that can be used as high-level knowledge representation languages.
Over the past 10 years or so, a number of machine-oriented controlled natural languages have emerged that can be used as high-level interface languages to various kinds of knowledge systems.
These languages are relevant to the area of computational linguistics since they have two very interesting properties: firstly, they look informal like natural languages and are therefore easier to write and understand by humans than formal languages; secondly, they are precisely defined subsets of natural languages and can be translated automatically (and often deterministically) into a formal target language and then be used for automated reasoning.
We present and compare the most mature of these novel languages, show how they can balance the disadvantages of natural languages and formal languages for knowledge representation, and discuss how domain specialists can be supported writing specifications in controlled natural language."
[{2021-01-28} http://web.science.mq.edu.au/~rolfs/papers/coling10-schwitter.pdf]

info-resource of lagCdnl

description::
* Controlled Natural Languages for Knowledge Representation, Rolf Schwitter, Centre for Language Technology, Macquarie University, Rolf.Schwitter@mq.edu.au, http://web.science.mq.edu.au/~rolfs/papers/coling10-schwitter.pdf,

name::
* McsEngl.lagCdnl'Infrsc,

lagCdnl.SPECIFIC

description::
* ACE'(attempto-controlled-English)-lagCdnl,
* CLCE'(common-logic-controlled-English)-lagCdnl,
* CLOnE-lagCdnl,
* CPL'(computer-processable-language)-lagCdnl,
* Formalized-English-lagCdnl,
* Lite-Natural-Language-lagCdnl,
* PENG'(processable-English)-lagCdnl,
* Rabbit-lagCdnl,
* SOS'(Sydney-OWL-Syntax)-lagCdnl,

name::
* McsEngl.lagCdnl.specific,

lagCdnl.ACE

description::
·

name::
* McsEngl.ACE'(attempto-controlled-English)!⇒lagAcen,
* McsEngl.attempto-controlled-English!⇒lagAcen,
* McsEngl.lagAcen,
* McsEngl.lagAcen'(attempto-controlled-English)!⇒lagAcen,
* McsEngl.lagCdnl.Ace!⇒lagAcen,

descriptionLong::
"ACE (Fuchs et al., 2008) is a CNL that covers a well-defined subset of English that can be translated unambiguously into first-order logic via discourse representation structures (Kamp and Reyle, 1993) and then be used for automated reasoning. ACE is defined by a small set of construction rules that describe its syntax and a small set of interpretation rules that disambiguate constructs that might appear ambiguous in full English. The vocabulary of ACE consists of predefined function words (e.g. determiners, conjunctions, and pronouns), some predefined fixed phrases (e.g. there is, it is false that), and content words (nouns, proper names, verbs, adjectives, and adverbs). ACE supports language constructs such as:
• active and passive verbs (and modal verbs);
• strong negation (e.g. no, does not) and weak negation (e.g. is is not provable that);
• subject and object relative clauses;
• declarative, interrogative, imperative and conditional sentences;
• various forms of anaphoric references to noun phrases (e.g. he, himself, the man, X).
It is important to note that the meaning of words in ACE is not predefined; the user is expected to define their meaning by ACE sentences or import these definitions from an existing formal ontology.
Here is a simple example of an ACE text together with a question:
Every company that buys at least three machines gets a discount. Six Swiss companies each buy one machine. A German company buys four machines. Who gets a discount?
Note that ACE uses disambiguation markers (e.g. each) on the surface level and mathematical background knowledge about natural numbers in order to answer the question above. This mathematical knowledge is implemented as a set of Prolog predicates which are executed during the proof (question answering process).
ACE is supported by various tools[2], among them a text editor that helps users to construct correct ACE sentences with the help of hints and error messages, a parser that translates ACE texts into discourse representation structures, a paraphraser that reflects the interpretation of the machine in CNL, and a Satchmo-style reasoning engine that can be used for consistency and redundancy checking as well as for question answering. Applications of ACE include software and hardware specifications, agent control, legal and medical regulations, and ontology construction.
[2] http://attempto.ifi.uzh.ch/site/tools/"
[{2021-01-28} http://web.science.mq.edu.au/~rolfs/papers/coling10-schwitter.pdf]

lexicon of lagAcen

description::
· it is-written in Prolog.
· there are 2: a-common-Clex and a-user-Ulex.
· contains 11 different word classes: adverbs, intransitive adjectives, transitive adjectives, countable nouns, mass nouns, measurement nouns, proper names, intransitive verbs, transitive verbs, ditransitive verbs, and prepositions.
[{2021-01-30} http://attempto.ifi.uzh.ch/site/docs/ace_lexicon.html]
· ~100,000 entries.
[{2021-01-30} https://github.com/Attempto]

name::
* McsEngl.lagAcen'lexicon,

info-resource of lagAcen

description::
* http://attempto.ifi.uzh.ch/site/,
* https://github.com/Attempto,
* http://attempto.ifi.uzh.ch/aceview/,

name::
* McsEngl.lagAcen'Infrsc,

lagCdnl.ClearTalk

description::
"ClearTalk is a controlled natural language—a kind of a formal language for expressing information that is designed to be both human-readable (being based on English) and easily processed by a computer.
Anyone who can read English can immediately read ClearTalk, and the people who write ClearTalk learn to write it while using it. The ClearTalk system itself does most of the training through use: the restrictions are shown by menus and templates and are enforced by immediate syntactic checks. By consistently using ClearTalk for its output, a system reinforces the acceptable syntactic forms.[1]
It is used by the experimental knowledge management software Ikarus and by a knowledge base management system Fact Guru.[2]"
[{2021-01-30} https://en.wikipedia.org/wiki/ClearTalk]

name::
* McsEngl.ClearTalk-lagCdnl,
* McsEngl.lagCdnl.ClearTalk,

lagCnpt.logic-programing-021

description::

name::
· logic-programing-language is a-propositional-language based on formal-logic.
* McsEngl.lagCnpt.021-logic-programing!⇒lagLogic,
* McsEngl.lagCnpt.logic-programing!⇒lagLogic,
* McsEngl.lagLgcp!⇒lagLogic,
* McsEngl.lagLogic,
* McsEngl.logic-programing-language!⇒lagLogic,

descriptionLong::
"Logic programming is a programming paradigm which is largely based on formal logic. Any program written in a logic programming language is a set of sentences in logical form, expressing facts and rules about some problem domain. Major logic programming language families include Prolog, answer set programming (ASP) and Datalog."
[{2021-01-30} https://en.wikipedia.org/wiki/Logic_programming]

relation-to-natural-language of lagLogic

description::
"Natural languages are highly expressive systems that can state anything that has ever been stated in any formal language or logic.
They can even express metalevel statements about themselves, their relationships to other languages, and the truth of any such statements.
Such enormous expressive power can easily generate contradictions and paradoxes, such as the statement This sentence is false.
Most formal languages avoid such paradoxes by imposing restrictions on the expressive power."
[{2021-02-07} http://www.jfsowa.com/cg/cg_hbook.pdf]

name::
* McsEngl.lagHmnm'relation-to-lagLogic,
* McsEngl.lagLogic'relation-to-natural-language,

lagLogic.SPECIFIC

description::
* Functional logic programming languages‎,
* Prolog programming language family‎,
* Absys,
* Algebraic Logic Functional programming language,
* Alice (programming language),
* Alma-0,
* CHIP (programming language),
* Ciao (programming language),
* CLACL,
* CycL,
* Datalog,
* Datomic,
* DLV,
* ECLiPSe,
* F-logic,
* Flix (programming language),
* Flora-2,
* Fril,
* FuzzyCLIPS,
* Game Description Language,
* Gödel (programming language),
* HiLog,
* Janus (concurrent constraint programming language),
* ΛProlog,
* Logtalk,
* Maude system,
* Mercury (programming language),
* Oracle Policy Automation,
* Oz (programming language),
* Parlog,
* Planner (programming language),
* PROGOL,
* Prolog,
* Prolog++,
* Prolog32,
* Prova,
* .QL,
* Rebeca (programming language),
* ROOP (programming language),
* SWI-Prolog,
* ToonTalk,
* Transaction logic,
* Twelf,
* Visual Prolog,
* XSB,
[{2021-02-05} https://en.wikipedia.org/wiki/Category:Logic_programming_languages]

name::
* McsEngl.lagLogic.specific,

lagLogic.first-order-logic

description::
·

name::
* McsEngl.FOL'(first-order-logic-language)!⇒lagFolc,
* McsEngl.first-order-logic-language!⇒lagFolc,
* McsEngl.first-order-predicate-calculus!⇒lagFolc,
* McsEngl.lagCnpt.014-first-order-logic!⇒lagFolc,
* McsEngl.lagCnpt.first-order-logic!⇒lagFolc,
* McsEngl.lagFolc,
* McsEngl.lagFolc'(first-order-logic-language)!⇒lagFolc,
* McsEngl.lagLogic.first-order-logic!⇒lagFolc,
* McsEngl.lagPpsl.first-order-logic!⇒lagFolc,
* McsEngl.predicate-logic!⇒lagFolc,
* McsEngl.quantificational-logic!⇒lagFolc,

descriptionLong::
"First-order logic — also known as predicate logic, quantificational logic, and first-order predicate calculus — is a collection of formal systems used in mathematics, philosophy, linguistics, and computer science. First-order logic uses quantified variables over non-logical objects, and allows the use of sentences that contain variables, so that rather than propositions such as "Socrates is a man", one can have expressions in the form "there exists x such that x is Socrates and x is a man", where "there exists" is a quantifier, while x is a variable.[1] This distinguishes it from propositional logic, which does not use quantifiers or relations;[2] in this sense, propositional logic is the foundation of first-order logic.
A theory about a topic is usually a first-order logic together with a specified domain of discourse (over which the quantified variables range), finitely many functions from that domain to itself, finitely many predicates defined on that domain, and a set of axioms believed to hold about them. Sometimes, "theory" is understood in a more formal sense, which is just a set of sentences in first-order logic.
The adjective "first-order" distinguishes first-order logic from higher-order logic, in which there are predicates having predicates or functions as arguments, or in which one or both of predicate quantifiers or function quantifiers are permitted.[3]:56 In first-order theories, predicates are often associated with sets. In interpreted higher-order theories, predicates may be interpreted as sets of sets.
There are many deductive systems for first-order logic which are both sound (i.e., all provable statements are true in all models) and complete (i.e. all statements which are true in all models are provable). Although the logical consequence relation is only semidecidable, much progress has been made in automated theorem proving in first-order logic. First-order logic also satisfies several metalogical theorems that make it amenable to analysis in proof theory, such as the Löwenheim–Skolem theorem and the compactness theorem.
First-order logic is the standard for the formalization of mathematics into axioms, and is studied in the foundations of mathematics. Peano arithmetic and Zermelo–Fraenkel set theory are axiomatizations of number theory and set theory, respectively, into first-order logic. No first-order theory, however, has the strength to uniquely describe a structure with an infinite domain, such as the natural numbers or the real line. Axiom systems that do fully describe these two structures (that is, categorical axiom systems) can be obtained in stronger logics such as second-order logic.
The foundations of first-order logic were developed independently by Gottlob Frege and Charles Sanders Peirce.[4] For a history of first-order logic and how it came to dominate formal logic, see José Ferreirós (2001)."
[{2021-01-24} https://en.wikipedia.org/wiki/First-order_logic]

lagFolc.KIF

description::
·

name::
* McsEngl.KIF'(knowledge-interchange-format)!⇒lagKift,
* McsEngl.knowledge-interchange-format!⇒lagKift,
* McsEngl.lagFolc.KIF!⇒lagKift,
* McsEngl.lagKift,

descriptionLong::
"Knowledge Interchange Format (KIF) is a computer language designed to enable systems to share and re-use information from knowledge-based systems. KIF is similar to frame languages such as KL-One and LOOM but unlike such language its primary role is not intended as a framework for the expression or use of knowledge but rather for the interchange of knowledge between systems. The designers of KIF likened it to PostScript. PostScript was not designed primarily as a language to store and manipulate documents but rather as an interchange format for systems and devices to share documents. In the same way KIF is meant to facilitate sharing of knowledge across different systems that use different languages, formalisms, platforms, etc.
KIF has a declarative semantics.[1] It is meant to describe facts about the world rather than processes or procedures. Knowledge can be described as objects, functions, relations, and rules. It is a formal language, i.e., it can express arbitrary statements in first order logic and can support reasoners that can prove the consistency of a set of KIF statements. KIF also supports non-monotonic reasoning. KIF was created by Michael Genesereth, Richard Fikes and others participating in the DARPA knowledge sharing Effort.[2]
Although the original KIF group intended to submit to a formal standards body, that did not occur. A later version called Common Logic has since been developed for submission to ISO and has been approved and published. A variant called SUO-KIF[3] is the language in which the Suggested Upper Merged Ontology[4] is written.
A practical application of the Knowledge interchange format is an agent communication language in a multi-agent system.[5]"
[{2021-01-26} https://en.wikipedia.org/wiki/Knowledge_Interchange_Format]

lagLogic.higher-order-logic

description::
"First-order logic quantifies only variables that range over individuals; second-order logic, in addition, also quantifies over sets; third-order logic also quantifies over sets of sets, and so on.
Higher-order logic is the union of first-, second-, third-, …, nth-order logic; i.e., higher-order logic admits quantification over sets that are nested arbitrarily deeply."
[{2021-02-05} https://en.wikipedia.org/wiki/Higher-order_logic]

name::
* McsEngl.HOL'(higher-order-logic)!⇒lagHolc,
* McsEngl.higher-order-logic!⇒lagHolc,
* McsEngl.lagCnpt.028-higher-order-logic!⇒lagHolc,
* McsEngl.lagCnpt.higher-order-logic!⇒lagHolc,
* McsEngl.lagHolc,
* McsEngl.lagHolc'(higher-order-logic)!⇒lagHolc,
* McsEngl.lagLogic.higher-order-logic!⇒lagHolc,

descriptionLong::
"In mathematics and logic, a higher-order logic is a form of predicate logic that is distinguished from first-order logic by additional quantifiers and, sometimes, stronger semantics. Higher-order logics with their standard semantics are more expressive, but their model-theoretic properties are less well-behaved than those of first-order logic.
The term "higher-order logic", abbreviated as HOL, is commonly used to mean higher-order simple predicate logic. Here "simple" indicates that the underlying type theory is the theory of simple types, also called the simple theory of types (see Type theory). Leon Chwistek and Frank P. Ramsey proposed this as a simplification of the complicated and clumsy ramified theory of types specified in the Principia Mathematica by Alfred North Whitehead and Bertrand Russell. Simple types is nowadays sometimes also meant to exclude polymorphic and dependent types.[1]"
[{2021-02-05} https://en.wikipedia.org/wiki/Higher-order_logic]

lagLogic.conceptual-graphs

description::
"Conceptual graphs (CGs) are a system of logic based on the existential graphs of Charles Sanders Peirce and the semantic networks of artificial intelligence.
They express meaning in a form that is logically precise, humanly readable, and computationally tractable.
With a direct mapping to language, conceptual graphs serve as an intermediate language for translating computer-oriented formalisms to and from natural languages.
With their graphic representation, they serve as a readable, but formal design and specification language.
CGs have been implemented in a variety of projects for information retrieval, database design, expert systems, and natural language processing."
[{2021-02-07} http://www.jfsowa.com/cg/-{2005-03-14}]

name::
* McsEngl.CGs'(conceptual-graphs)!⇒lagCgaf,
* McsEngl.conceptual-graphs-abstract-form!⇒lagCgaf,
* McsEngl.lagCnpt.031-conceptual-graphs!⇒lagCgaf,
* McsEngl.lagCnpt.conceptual-graphs!⇒lagCgaf,
* McsEngl.lagCgaf,
* McsEngl.lagCgaf'(conceptual-graphs)!⇒lagCgaf,
* McsEngl.lagLogic.conceptual-graphs!⇒lagCgaf,

tech of lagCgaf

description::
* https://sourceforge.net/projects/amine-platform/, Java,

name::
* McsEngl.lagCgaf'tech,

input of lagCgaf

description::
· sentences of a-natural-language.

name::
* McsEngl.Cgafinput,
* McsEngl.lagCgaf'input!⇒Cgafinput,

output of lagCgaf

description::
·

name::
* McsEngl.Cgafoutput,
* McsEngl.lagCgaf'output!⇒Cgafoutput,

concept of Cgafoutput

description::
· in a-conceptual-graph, the-boxes are-called concepts.

name::
* McsEngl.Cgafocpt,
* McsEngl.Cgafoutput'concept!⇒Cgafocpt,
* McsEngl.concept@lagCgaf!⇒Cgafocpt,

referent of Cgafocpt

description::
"Every concept has a concept type t and a referent r.
Comment.
This abstract definition does not say how the type and referent are represented. In computer storage, they may be represented by a pair of pointers, one pointing to a specification of the concept type and the other pointing to a specification of the referent. In the concrete notations, the type field is on the left, and the referent field is on the right.
In the concept [Bus], "Bus" is the type, and the referent field contains a blank, which represents an existential quantifier; the actual referent is a physical entity of type Bus that exists somewhere in the world.
In the concept [Person: John], "Person" specifies the type, and the name "John" designates some person who is the referent."
[CG Standard, http://www.bestweb.net/~sowa/cg/cgdpansw.htm, 1999aug01]

name::
* McsEngl.Cgafocpt'referent,

type of Cgafocpt

description::
"Every concept has a concept type t and a referent r.
Comment.
This abstract definition does not say how the type and referent are represented. In computer storage, they may be represented by a pair of pointers, one pointing to a specification of the concept type and the other pointing to a specification of the referent. In the concrete notations, the type field is on the left, and the referent field is on the right.
In the concept [Bus], "Bus" is the type, and the referent field contains a blank, which represents an existential quantifier; the actual referent is a physical entity of type Bus that exists somewhere in the world.
In the concept [Person: John], "Person" specifies the type, and the name "John" designates some person who is the referent."
[CG Standard, http://www.bestweb.net/~sowa/cg/cgdpansw.htm, 1999aug01]

name::
* McsEngl.Cgafocpt'type,

conceptual-relation of Cgafoutput

description::
· the-circles are-called conceptual-relations.

name::
* McsEngl.Cgaforln
* McsEngl.Cgafoutput'conceptual-relation,!⇒Cgaforln

conceptual-graph of Cgafoutput

description::
"A conceptual graph g is a bipartite graph that has two kinds of nodes called concepts and conceptual relations.
a) Every arc a of g must link a conceptual relation r in g to a concept c in g. The arc a is said to belong to the relation r; it is said to be attached to the concept c, but it does not belong to c.
b) The conceptual graph g may have concepts that are not linked to any conceptual relation; but every arc that belongs to any conceptual relation in g must be attached to exactly one concept in g.
c) Three kinds of conceptual graphs are given distinguished names:
c1) The blank is an empty conceptual graph with no concepts, conceptual relations, or arcs.
c2) A singleton is a conceptual graph that consists of a single concept, but no conceptual relations or arcs.
c3) A star is a conceptual graph that consists of a single conceptual relation r and 1 or more concepts, which are attached to the arcs of r."
[Sowa]

name::
* McsEngl.Cgafogrph,
* McsEngl.Cgafoutput'conceptual-graph!⇒Cgafogrph,

Cgafogrph.SPECIFIC

description::
* http://www.jfsowa.com/cg/cgexampw.htm,

name::
* McsEngl.Cgafograph.specific,

Cgafogrph.example

description::
"To illustrate this definition, consider the following conceptual graph, which represents the sentence John is going to Boston:
[Person: John]->(Agnt)->[Go]<-(Dest)<-[City: Boston].
This graph contains three concepts: [Person: John], [Go], and [City: Boston].
It contains two conceptual relations: (Agnt) relates [Go] to the agent John, and (Dest) relates [Go] to the destination Boston.
The term bipartite means that every arc of a conceptual graph connects one concept and one conceptual relation; there are no arcs that connect concepts to concepts or relations to relations. Two of the four arcs in the graph belong to (Agnt), and the other two belong to (Dest)."
[Sowa]

name::
* McsEngl.Cgafogrph.example,

evaluation of lagCgaf

description::
"It uses 2 building units, instead of one.
* it is language based.
* dificult terminology."
[KasNik, 2007.12.15]

name::
* McsEngl.lagCgaf'evaluation,

relation-to-existential-graphs of lagCgaf

description::
"The differences between EGs and CGs result from differences in their origin and motivation.
In formulating EGs, Peirce was trying to find the simplest possible primitives for representing logic and operating on logical statements.
In formulating CGs, Sowa was trying to find the most direct mapping from natural languages to logic.
Since ordinary language has a much richer variety of expressive forms than Peirce's primitives, the CG notation includes many notational extensions that are designed to represent the major semantic forms of natural languages. To balance expressive power with simplicity, CGs provide both a basic and an extended notation.
The basic CG notation is essentially a typed version of Peirce's EGs with the same logical primitives: negation, conjunction, and the existential quantifier.
The extended CG notation, however, provides mechanisms for defining an open-ended range of new forms of expression, each of which has a direct mapping to some natural language expression and a formally defined expansion into the basic primitives. Following are the ways in which the extended CGs differ from EGs:

In the basic CGs, Peirce's line of identity is represented by one or more concept nodes linked by dotted lines called coreference links. As an alternate notation, the dotted lines may be replaced by symbols, called coreference labels, such as *x and ?x. One label marked with * is called the defining node, and the others marked with ? are called bound nodes. The labels are sanctioned by one of Peirce's observations that any line of identity could be cut with the two ends labeled to show how they could be reconnected.

In the extended CGs, generalized quantifiers can be introduced, including the universal, plurals, and various kinds of indexicals. Each of the extended forms, however, is defined by a formal mapping to the basic notation.

Each concept includes a type label inside the concept box. That label corresponds to a monadic predicate that could be attached to an EG line of identity. In the extended notation, the type labels may be replaced by lambda expressions that define them. The term lambda expression is taken from Alonzo Church, but the idea was anticipated by Peirce, who used labeled hooks instead of the Greek letter lambda.

In CGs, Peirce's ovals for negation are represented by concept boxes with the type label Proposition and an attached negation relation Neg (or its abbreviation by a ^ symbol). Instead of Peirce's tinctures for representing modalities, other relations can be attached to the concept box, such as Psbl for possibility or Necs for necessity.

Besides a type label, a concept box includes a referent field that identifies or partially identifies the referent of the concept. Following Peirce, the three kinds of referents are icons (represented by a diagram or picture), indexes (represented by a name or other indexical), and symbols (represented by a nested conceptual graph that describes the entity).

The linguistic work on thematic roles or case relations has been adopted for the basic types of conceptual relations. New types of relations can be defined in terms of them by lambda expressions, which like the lambda expressions for concept types can be written in place of the relation labels.

Except for notation, the basic CGs are minimal variants of EGs. The extended CGs provide a richer notation that maps almost one-to-one to the semantic structures of natural languages. The formal mapping from the extended to the basic CGs helps to bridge the gap between language and logic.
[Fulfilling Peirce's Dream: Conceptual Structures and Communities of Inquiry, Leroy Searle, Mary Keeler, John Sowa, Harry Deluagch, and Dickson Lukose, ICCS'97]

name::
* McsEngl.lagCgaf'relation-to-existential-graphs,

relation-to-discourse-representation-structures of lagCgaf

description::
"When Conceptual Structures appeared at the end of 1983, it did not include recent work by Hans Kamp [8] on discourse representation theory. After spending some time translating English to logic, Kamp had realized that the mapping to predicate calculus involved convoluted distortions of the sentence structure of English and other natural languages. In order to simplify the mapping, Kamp designed his discourse representation structures (DRSs) and formulated rules for representing and resolving indexicals in the DRS notation. Although Kamp's motivation was very different from Peirce's and he had no awareness of Peirce's graphs, Kamp's DRS notation happened to be isomorphic to Peirce's EGs. Since CGs are based on EGs, they are also isomorphic to DRSs; therefore, Kamp's rules for resolving indexicals in the DRS notation can be applied directly to EGs and CGs. A century after Peirce's pioneering work on both graph logic and indexicals, the former proved to be ideally suited for representing the latter.
[8]Kamp, Hans, Events, Discourse Representations, and Temporal References, Langages, vol. 64, 1981, pp. 39-64.
[Fulfilling Peirce's Dream: Conceptual Structures and Communities of Inquiry, Leroy Searle, Mary Keeler, John Sowa, Harry Deluagch, and Dickson Lukose, ICCS'97]

name::
* McsEngl.lagCgaf'relation-to-discourse-representation-structures,

info-resource of lagCgaf

description::
* http://www.jfsowa.com/cg/cg_hbook.pdf,
* ISO-standard: http://www.jfsowa.com/cg/cgstand.htm,
* existential-graphs: http://www.jfsowa.com/peirce/ms514.htm,

name::
* McsEngl.lagCgaf'Infrsc,

bibliography of lagCgaf

1995 Ellis et al.::
Gerard Ellis and Robert A. Levinson and William Rich and John F. Sowa (Eds.) (1995) "Conceptual Graphs: Structure-based Knowledge Representation", Proceedings of the Third International Conference on Conceptual Structures ICCS'95, August 14-18, University of California, Santa Cruz, USA, Lecture Notes in Artificial Intelligence, Springer-Verlag, Number 954, Berlin.

1994 Tephenhart et al.::
William M. Tepfenhart and Judith P. Dick and John F. Sowa (Eds.) (1994) "Conceptual Structures: Current Practices", Second International Conference on Conceptual Structures, ICCS'94, College Park, Maryland, USA, August, Lecture Notes in Artifical Intelligence, Number 835, Springer-Verlag, Berlin.

1993 Mineau et al.::
Guy W. Mineau and Bernard Moulin and John F. Sowa (Eds.) (1993) "Conceptual Graphs for Knowledge Representation", Lecture Notes in Artificial Intelligence, Springer-Verlag, Berlin, Number 699, Proceedings of the 1st International Conference on Conceptual Structures, Quebec City, Canada, August 4-7.

1993 Pfeiffer et al.::
Heather D. Pfeiffer and Timothy E. Nagle (Eds.) (1993) "Conceptual Structures: Theory and Implementation", Springer-Verlag, Number 754, Lecture Notes in Artificial Intelligence, Proceedings of the Seventh Annual Workshop on Conceptual Graphs, Las Cruces, New Mexico, July 8-10, 1992.

1993 Sowa::
John F. Sowa (1993) "Relating Diagrams to Logic", Guy W. Mineau and Bernard Moulin and John F. Sowa (Eds.), Conceptual Graphs for Knowledge Representation, Lecture Notes in Artificial Intelligence, Springer-Verlag, Berlin, Number 699, Proceedings of the 1st International Conference on Conceptual Structures, Quebec City, Canada, August 4-7.

1993 Sowa::
John F. Sowa (1993) "Logical Foundations for Representing Object-Oriented Systems", Journal of Experimental & Theoretical Artificial Intelligence, volume 5.

1992 Nagle et al.::
Tim Nagle and Jan Nagle and Laurie Gerholz and Peter Eklund (Eds.) (1992) "Conceptual Structures: Current Research and Practice", Ellis Horwood.

1992 Sowa::
John F. Sowa (1992) "Conceptual Graphs Summary", T. E. Nagle and J. A. Nagle and L. L. Gerholz and P. W. Eklund (Eds.), Conceptual Structures: Current Research and Practice, Ellis Horwood, p. 3-51.

1991 Sowa::
John F. Sowa (1991) "Toward the Expressive Power of Natural Language," J.F. Sowa (Ed.), Principles of Semantic Networks: Explorations in the Representation of Knowledge, Morgan Kaufmann, San Mateo, CA, p. 157-189.

1990 Ketner::
Kenneth Laine Ketner (1990) "Elements of Logic: An Introduction to Peirce's Existential Graphs," Texas Tech University Press, Lubbock, Texas.

1984 Sowa::
John F. Sowa (1984) "Conceptual Structures: Information Processing in Mind and Machine", Addison-Wesley, Reading, MA.

1976 Sowa::
Sowa, John F., Conceptual Graphs for a Data Base Interface, IBM Journal of Research and Development, vol. 20, 1976, pp. 336-357.

1973 Roberts::
Don D. Roberts (1973) "The Existential Graphs of Charles S. Peirce", Mouton, The Hague, 1973. Collected papers of Charles Sanders Peirce Charles (1931-58) Hartshorne and Paul Weiss (Eds.) Harvard University Press, Cambridge.

1964 Zeeman::
Zeeman, Jay. "The Graphical Logic of C. S. Peirce." Ph.D. diss., University of Chicago, 1964.

name::
* McsEngl.lagCgaf'bibliography,

evoluting of lagCgaf

{1984}-Sowa-Conceptual-Structures::
John F. Sowa (1984) "Conceptual Structures: Information Processing in Mind and Machine", Addison-Wesley, Reading, MA.

{1976}-Sowa-Conceptual-Graphs::
Sowa, John F., Conceptual Graphs for a Data Base Interface, IBM Journal of Research and Development, vol. 20, 1976, pp. 336-357.
"Sowa (1976) developed a version of conceptual graphs (CGs) as an intermediate language for mapping natural language questions and assertions to a relational database."
* McsEngl.{lagCnpt'1976}-Sowa-Conceptual-graphs,
[{2021-02-07} http://www.jfsowa.com/cg/cg_hbook.pdf]

{1896}-Existential-Graphs::
Charles-Sanders-Peirce developed the logic of Existential Graphs.

name::
* McsEngl.lagCgaf'evoluting,

lagCgaf.display-form

description::
"This graphic form, which is called the display form, is highly readable for humans and it maps directly to the abstract CG form."

name::
* McsEngl.lagCgdf,
* McsEngl.lagCgaf.display-form!⇒lagCgdf,
* McsEngl.lagCgaf.graphic-form!⇒lagCgdf,

lagCgaf.linear-form

description::
The linear form for CGs is intended as a more compact notation than DF, but with good human readability. It is exactly equivalent in expressive power to the abstract syntax and the display form. Following is the LF for Figure 1 "John is going to Boston by bus.":
[Go]-
  (Agnt)?[Person: John]
  (Dest)?[City: Boston]
  (Inst)?[Bus].

name::
* McsEngl.lagCglf,
* McsEngl.lagCgaf.linear-form!⇒lagCglf,

lagCgaf.CGIF

description::
For communications between computers, another form called the conceptual graph interchange format (CGIF) has a simpler syntax and a more restricted character set. Following is the CGIF form of Figure 1:
[Cat: *x] [Mat: *y] (On ?x ?y).

name::
* McsEngl.CGIF'(conceptual-graphs-interchange-format)!⇒lagCgif,
* McsEngl.conceptual-graphs-interchange-format!⇒lagCgif,
* McsEngl.lagCgif,
* McsEngl.lagCgaf.CGIF!⇒lagCgif,

lagLogic.description-logic

description::
"Description logics (DL) are a family of formal knowledge representation languages. Many DLs are more expressive than propositional logic but less expressive than first-order logic. In contrast to the latter, the core reasoning problems for DLs are (usually) decidable, and efficient decision procedures have been designed and implemented for these problems. There are general, spatial, temporal, spatiotemporal, and fuzzy description logics, and each description logic features a different balance between expressive power and reasoning complexity by supporting different sets of mathematical constructors.[1]
DLs are used in artificial intelligence to describe and reason about the relevant concepts of an application domain (known as terminological knowledge). It is of particular importance in providing a logical formalism for ontologies and the Semantic Web: the Web Ontology Language (OWL) and its profile is based on DLs. The most notable application of DLs and OWL is in biomedical informatics where DL assists in the codification of biomedical knowledge."
[{2021-01-24} https://en.wikipedia.org/wiki/Description_logic]

name::
* McsEngl.DL'(description-logic-language)!⇒lagDlgc,
* McsEngl.description-logic-language!⇒lagDlgc,
* McsEngl.lagCnpt.015-description-logic!⇒lagDlgc,
* McsEngl.lagCnpt.description-logic!⇒lagDlgc,
* McsEngl.lagDlgc,
* McsEngl.lagLogic'(description-logic-language)!⇒lagDlgc,
* McsEngl.lagPpsl.description-logic!⇒lagDlgc,
* McsEngl.lagPpsl.description-logic!⇒lagDlgc,

descriptionLong::
"Description logic was designed as an extension to frames and semantic networks, which were not equipped with formal logic-based semantics".
[http://en.wikipedia.org/wiki/Description_logic]

lagLogic.frame-logic

description::
"The Frame Logic (or F-logic) provides a logical foundation for frame-based and object-oriented languages for data and knowledge representation."
[{2021-02-04} http://flora.sourceforge.net/aboutFlogic.html]

name::
* McsEngl.F-logic-language!⇒lagFlgc,
* McsEngl.frame-logic-language!⇒lagFlgc,
* McsEngl.lagCnpt.026-frame-logic!⇒lagFlgc,
* McsEngl.lagCnpt.frame-logic!⇒lagFlgc,
* McsEngl.lagFlgc,
* McsEngl.lagFlgc'(frame-logic-language)!⇒lagFlgc,
* McsEngl.lagLogic.F-logic!⇒lagFlgc,

descriptionLong::
"F-logic [15] extends classical predicate calculus with the concepts of objects, classes, and types, which are adapted from object-oriented programming.
In this way, F-logic integrates the paradigms of logic programming and deductive databases with the object-oriented programming paradigm.
Most of the applications of F-logic have been as a language for intelligent information systems based on the logic programming paradigm. This was the original motivation for the development of F-logic. More recently, Flogic has been used to represent ontologies and other forms of Semantic Web reasoning [9, 8, 25, 1, 23, 14]."
[{2021-02-04} https://www3.cs.stonybrook.edu/~kifer/TechReports/ontologies-rules-flogic.pdf]
===
"F-logic (frame logic) is a knowledge representation and ontology language. F-logic combines the advantages of conceptual modeling with object-oriented, frame-based languages and offers a declarative, compact and simple syntax, as well as the well-defined semantics of a logic-based language.
Features include, among others, object identity, complex objects, inheritance, polymorphism, query methods, encapsulation. F-logic stands in the same relationship to object-oriented programming as classical predicate calculus stands to relational database programming."
[{2021-02-04} https://en.wikipedia.org/wiki/F-logic]

relation-to-description-logic of lagFlgc

description::
"No discussion of F-logic is complete without a comparison with description logics (abbr. DL) [2] and, in particular, with languages such as OWL [21].
Since the first-order flavor of F-logic is an extension of classical predicate logic, it is clear that a description logic subset can be defined within Flogic and, indeed, this has been done [3].
In this sense, F-logic subsumes DLs."
[{2021-02-04} https://www3.cs.stonybrook.edu/~kifer/TechReports/ontologies-rules-flogic.pdf]

name::
* McsEngl.lagDlgc'relation-to-lagFlgc,
* McsEngl.lagFlgc'relation-to-lagDlgc,

lagLogic.transaction-logic

description::
"Transaction Logic provides logical foundations for state changes and side effects in a logic programming language. A significant portion of this theory is implemented in Flora-2. Applications of Transaction Logic include modeling and reasoning about workflows, planning, robotics, view maintenance in databases, and more."
[{2021-02-04} http://flora.sourceforge.net/aboutTR.html]

name::
* McsEngl.lagCnpt.027-transaction-logic!⇒lagTlgc,
* McsEngl.lagCnpt.transaction-logic!⇒lagTlgc,
* McsEngl.lagLogic.transaction-logic!⇒lagTlgc,
* McsEngl.lagTlgc,
* McsEngl.lagTlgc'(transaction-logic-language)!⇒lagTlgc,

lagLogic.Prolog

description::
"Prolog is a logic programming language associated with artificial intelligence and computational linguistics."
[{2021-02-04} https://en.wikipedia.org/wiki/Prolog]

name::
* McsEngl.Prolog!⇒lagPrlg,
* McsEngl.lagCnpt.023-Prolog!⇒lagPrlg,
* McsEngl.lagCnpt.Prolog!⇒lagPrlg,
* McsEngl.lagLogic.Prolog!⇒lagPrlg,
* McsEngl.lagPrlg,
* McsEngl.lagPrlg'(Prolog)!⇒lagPrlg,

descriptionLong::
"Prolog is a logic programming language associated with artificial intelligence and computational linguistics.[1][2][3]
Prolog has its roots in first-order logic, a formal logic, and unlike many other programming languages, Prolog is intended primarily as a declarative programming language: the program logic is expressed in terms of relations, represented as facts and rules. A computation is initiated by running a query over these relations.[4]
The language was developed and implemented in Marseille, France, in 1972 by Alain Colmerauer with Philippe Roussel, based on Robert Kowalski's procedural interpretation of Horn clauses.[5][6]
Prolog was one of the first logic programming languages[7] and remains the most popular such language today, with several free and commercial implementations available. The language has been used for theorem proving,[8] expert systems,[9] term rewriting,[10] type systems,[11] and automated planning,[12] as well as its original intended field of use, natural language processing.[13][14] Modern Prolog environments support the creation of graphical user interfaces, as well as administrative and networked applications.
Prolog is well-suited for specific tasks that benefit from rule-based logical queries such as searching databases, voice control systems, and filling templates."
[{2021-02-04} https://en.wikipedia.org/wiki/Prolog]

lagPrlg.SPECIFIC

description::
* Absys,
* B-Prolog,
* BNR Prolog,
* ECLiPSe,
* GNU Prolog,
* KL0,
* KL1,
* ΛProlog,
* Logtalk,
* Objlog,
* Prolog++,
* Prolog32,
* Strand (programming language),
* SWI-Prolog,
* Visual Prolog,
* YAP (Prolog),
[{2021-02-05} https://en.wikipedia.org/wiki/Category:Prolog_programming_language_family]

name::
* McsEngl.lagPrlg.specific,

lagLogic.functional-logic

description::
"Functional logic programming is the combination, in a single programming language, of the paradigms of functional programming and logic programming.[1] This style of programming is embodied by various programming languages, including Curry and Mercury.[2][1]
A journal devoted to the integration of functional and logic programming was published by MIT Press and the European Association for Programming Languages and Systems between 1995 and 2008.[3]"
[{2021-02-05} https://en.wikipedia.org/wiki/Functional_logic_programming]

name::
* McsEngl.lagCnpt.029-functional-logic!⇒lagFulo,
* McsEngl.lagCnpt.functional-logic!⇒lagFulo,
* McsEngl.lagFulo,
* McsEngl.lagFulo'(functional-logic)!⇒lagFulo,
* McsEngl.lagLogic.functional-logic!⇒lagFulo,

lagLogic.common-logic

description::
"Common Logic (CL) evolved from two projects to develop parallel ANSI standards for conceptual graphs and the Knowledge Interchange Format (Genesereth & Fikes 1992). Eventually, those projects were merged into a single ISO project to develop a common abstract syntax and model-theoretic foundation for a family of logic-based notations (ISO/IEC 24707). Hayes and Menzel (2001) defined a very general model theory for CL, which Hayes and McBride (2003) used to define the semantics for the languages RDF(S) and OWL. In addition to the abstract syntax and model theory, the CL standard specifies three concrete dialects that are capable of expressing the full CL semantics: the Common Logic Interchange Format (CLIF), the Conceptual Graph Interchange Format (CGIF), and the XML-based notation for CL (XCL). Since the semantics of RDF and OWL is based on a subset of CL semantics, those languages can also be considered dialects of CL: any statement in RDF or OWL can be translated to CLIF, CGIF, or XCL, but only a subset of CL can be translated back to RDF or OWL."
[{2021-02-05} http://www.jfsowa.com/cg/cgif.htm]

name::
* McsEngl.CL'(common-logic-language)!⇒lagCmlg,
* McsEngl.common-logic-language!⇒lagCmlg,
* McsEngl.lagCmlg,
* McsEngl.lagCmlg'(common-logic)!⇒lagCmlg,
* McsEngl.lagCnpt.030-common-logic!⇒lagCmlg,
* McsEngl.lagCnpt.common-logic!⇒lagCmlg,
* McsEngl.lagLogic.common-logic!⇒lagCmlg,

info-resource of lagCmlg

description::
* ISO/IEC 24707:2018, EN, 2nd, Information technology — Common Logic (CL) — A framework for a family of logic-based languages, ISO/IEC JTC 1/SC 32, https://standards.iso.org/ittf/PubliclyAvailableStandards/,

name::
* McsEngl.lagCmlg'Infrsc,

lagCmlg.SPECIFIC

description::
* CGIF,
* CLIF,
* XCL,
* OWL,
* RDF(S),
"Hayes and Menzel (2001) defined a very general model theory for CL, which Hayes and McBride (2003) used to define the semantics for the languages RDF(S) and OWL. In addition to the abstract syntax and model theory, the CL standard specifies three concrete dialects that are capable of expressing the full CL semantics: the Common Logic Interchange Format (CLIF), the Conceptual Graph Interchange Format (CGIF), and the XML-based notation for CL (XCL). Since the semantics of RDF and OWL is based on a subset of CL semantics, those languages can also be considered dialects of CL: any statement in RDF or OWL can be translated to CLIF, CGIF, or XCL, but only a subset of CL can be translated back to RDF or OWL."
[{2021-02-06} http://www.jfsowa.com/cg/cgif.htm]

name::
* McsEngl.lagCmlg.specific,

lagLogic.XSB

description::
"XSB is the name of a dialect of the Prolog programming language and its implementation developed at Stony Brook University in collaboration with the Katholieke Universiteit Leuven, the New University of Lisbon, Uppsala University and software vendor XSB, Inc.
XSB extends Prolog with tabled resolution and HiLog (a standard extension of Prolog permitting limited higher-order logic programming).
The open source XSB implementation includes an interface to the Java programming language."
[{2021-02-04} https://en.wikipedia.org/wiki/XSB]

name::
* McsEngl.XSB!⇒lagXsbl,
* McsEngl.lagCnpt.024-XSB!⇒lagXsbl,
* McsEngl.lagCnpt.XSB!⇒lagXsbl,
* McsEngl.lagLogic.XSB!⇒lagXsbl,
* McsEngl.lagXsbl,

descriptionLong::
"Since its inception, a primary goal of XSB has been to expand the areas in which Prolog is used, by making Prolog more powerful, more efficient, and more declarative. In 1993 when XSB was first released, it supported this goal by including both tabled resolution for definite programs, which provided it with deductive databasestyle features of such systems as Coral (Ramakrishnan et al. 1992) and LDL (Chimenti et al. 1990). At the time, while XSB was faster than those systems, it was basically suitable only for research by its developers. Since then, XSB has become a widely used multi-threaded Prolog that is compliant with most standards. During this development, XSB’s research focus has continued to be centered on tabling.
At one level, the idea behind tabling is simple; subgoals encountered in a query evaluation are maintained in a table, along with answers to these subgoals. If a subgoal is re-encountered, the evaluation reuses information from the table rather than re-performing resolution against program clauses.
[{2021-02-04} https://www3.cs.stonybrook.edu/~tswift/webpapers/tplp-10-sips.pdf]

lagLogic.Flora-2

description::
"Flora-2 (a.k.a. Ergo Lite) is an advanced object-oriented knowledge representation and reasoning system. It is a dialect of F-logic with numerous extensions, including meta-programming in the style of HiLog, logical updates in the style of Transaction Logic, and defeasible reasoning. Applications include intelligent agents, Semantic Web, knowledge-based networking, ontology management, integration of information, security policy analysis, and more."
[{2021-02-04} http://flora.sourceforge.net/]

name::
* McsEngl.lagCnpt.025-Flora-2-language!⇒lagFlr2,
* McsEngl.lagCnpt.Flora-2-language!⇒lagFlr2,
* McsEngl.lagFlr2,
* McsEngl.lagFlr2'(Flora-2-language)!⇒lagFlr2,
* McsEngl.lagLogic.Flora-2!⇒lagFlr2,

descriptionLong::
"Flora-2 is an open source semantic rule-based system for knowledge representation and reasoning. The language of the system is derived from F-logic,[1] HiLog,[2] and Transaction logic.[3] Being based on F-logic and HiLog implies that object-oriented syntax and higher-order representation are the major features of the system. Flora-2 also supports a form of defeasible reasoning called Logic Programming with Defaults and Argumentation Theories (LPDA).[4] Applications include intelligent agents, Semantic Web, knowledge-bases networking, ontology management, integration of information, security policy analysis, automated database normalization, and more.[5][6][7][8][9][10]
Flora-2 relies on the XSB system for its inference engine. The design and architecture of Flora-2 are described in a number of works.[11][12][13][14]
Details of the system and its use are described in the Flora-2 User's Manual.[15] Flora-2 is available for all major computing platforms, including Linux and other flavors of Unix, Microsoft Windows (both 32- and 64-bit), and Mac OS X."
[{2021-02-04} https://en.wikipedia.org/wiki/Flora-2]

lagFlr2'tech

description::
"FLORA-2 is build upon the OpenSource XSB Prolog engine which is developed in C and thus has a C interface"
[{2021-02-04} https://github.com/johannesloetzsch/reasonablepy]

name::
* McsEngl.lagFlr2'tech,

lagCnpt.semantic-web-004

description::
· semantic-web-language is a-language we use to make the-web readable by machines.
· from web-of-documents-(HTML) to web-of-data-(RDF) to web-of-concepts-(McsHitp).

name::
* McsEngl.lagCnpt.004-semantic-web!⇒lagSweb,
* McsEngl.lagCnpt.semantic-web!⇒lagSweb,
* McsEngl.lagSweb,
* McsEngl.semantic-web-language!⇒lagSweb,

descriptionLong::
"In addition to the classic “Web of documents” W3C is helping to build a technology stack to support a “Web of data,” the sort of data you find in databases. The ultimate goal of the Web of data is to enable computers to do more useful work and to develop systems that can support trusted interactions over the network. The term “Semantic Web” refers to W3C’s vision of the Web of linked data. Semantic Web technologies enable people to create data stores on the Web, build vocabularies, and write rules for handling data. Linked data are empowered by technologies such as RDF, SPARQL, OWL, and SKOS."
[{2021-01-03} https://www.w3.org/standards/semanticweb/]
===
"In the original concept of the Semantic Web, software agents would have processed contents, found information from different sources, reasoned about data, and produced output."
[{2021-01-26} https://www.isko.org/cyclo/ontologies]

linked-data of lagSweb

description::
"The Semantic Web is a Web of Data — of dates and titles and part numbers and chemical properties and any other data one might conceive of. The collection of Semantic Web technologies (RDF, OWL, SKOS, SPARQL, etc.) provides an environment where application can query that data, draw inferences using vocabularies, etc.
However, to make the Web of Data a reality, it is important to have the huge amount of data on the Web available in a standard format, reachable and manageable by Semantic Web tools. Furthermore, not only does the Semantic Web need access to data, but relationships among data should be made available, too, to create a Web of Data (as opposed to a sheer collection of datasets). This collection of interrelated datasets on the Web can also be referred to as Linked Data.
To achieve and create Linked Data, technologies should be available for a common format (RDF), to make either conversion or on-the-fly access to existing databases (relational, XML, HTML, etc). It is also important to be able to setup query endpoints to access that data more conveniently. W3C provides a palette of technologies (RDF, GRDDL, POWDER, RDFa, the upcoming R2RML, RIF, SPARQL) to get access to the data."
[{2021-01-03} https://www.w3.org/standards/semanticweb/data.html]

name::
* McsEngl.lagLddt,
* McsEngl.lagLddt'(linked-data-language)!⇒lagLddt,
* McsEngl.lagSweb'linked-data!⇒lagLddt,
* McsEngl.linked-data-of-lagSweb!⇒lagLddt,

descriptionLong::
"The term Linked Data refers to a set of best practices for publishing structured data on the Web. These principles have been coined by Tim Berners-Lee in the design issue note Linked Data. The principles are:
* Use URIs as names for things
* Use HTTP URIs so that people can look up those names.
* When someone looks up a URI, provide useful information.
* Include links to other URIs. so that they can discover more things.
The idea behind these principles is on the one hand side, to use standards for the representation and the access to data on the Web. On the other hand, the principles propagate to set hyperlinks between data from different sources. These hyperlinks connect all Linked Data into a single global data graph, similar as the hyperlinks on the classic Web connect all HTML documents into a single global information space. Thus, LinkedData is to spreadsheets and databases what the Web of hypertext documents is to word processor files. The Linked Open Data cloud diagramms give an overview of the linked data sets that are available on the Web."
[{2021-01-03} https://www.w3.org/wiki/LinkedData]

info-resource of lagLddt

description::
* https://json-ld.org/,
* https://github.com/digitalbazaar/jsonld.js,

name::
* McsEngl.lagLddt'Infrsc,

ontology of lagSweb

description::
"On the Semantic Web, vocabularies define the concepts and relationships (also referred to as “terms”) used to describe and represent an area of concern. Vocabularies are used to classify the terms that can be used in a particular application, characterize possible relationships, and define possible constraints on using those terms. In practice, vocabularies can be very complex (with several thousands of terms) or very simple (describing one or two concepts only).
There is no clear division between what is referred to as “vocabularies” and “ontologies”. The trend is to use the word “ontology” for more complex, and possibly quite formal collection of terms, whereas “vocabulary” is used when such strict formalism is not necessarily used or only in a very loose sense. Vocabularies are the basic building blocks for inference techniques on the Semantic Web."
[{2021-01-03} https://www.w3.org/standards/semanticweb/ontology]

name::
* McsEngl.lagSweb'ontology,
* McsEngl.lagSweb'vocabulary,
* McsEngl.ontology@lagSweb,
* McsEngl.vocabulary@lagSweb,

evaluation of lagSweb

description::
"The name of the OWL language itself provides a good example of the value of a Semantic Web. If one were to search for "OWL" using the Internet today most of the pages retrieved would be on the bird Owl rather than the standard OWL. With a Semantic Web it would be possible to specify the concept "Web Ontology Language" and the user would not need to worry about the various possible acronyms or synonyms as part of the search. Likewise, the user would not need to worry about homonyms crowding the search results with irrelevant data such as information about birds of prey as in this simple example."
[{2021-02-08} https://en.wikipedia.org/wiki/Frame_(artificial_intelligence)#Implementations]

name::
* McsEngl.lagSweb'evaluation,

query of lagSweb

description::
"“Query” in the Semantic Web context means technologies and protocols that can programmatically retrieve information from the Web of Data.
What is Query Used For?
The Semantic Web is a Web of data — of dates and titles and part numbers and chemical properties and any other data one might conceive of. RDF provides the foundation for publishing and linking your data. Various technologies allow you to embed data in documents (RDFa, GRDDL) or expose what you have in SQL databases, or make it available as RDF files.
However, just as relational databases or XML need specific query languages (SQL and XQuery, respectively), the Web of Data, typically represented using RDF as a data format, needs its own, RDF-specific query language and facilities. This is provided by the SPARQLquery language and the accompanying protocols. SPARQL makes it possible to send queries and receive results, e.g., through HTTP or SOAP.
Technically, SPARQL queries are based on (triple) patterns. RDF can be seen as a set of relationships among resources (i.e., RDF triples); SPARQL queries provide one or more patterns against such relationships. These triple patterns are similar to RDF triples, except that one or more of the constituent resource references are variables. A SPARQL engine would returns the resources for all triples that match these patterns.
Using SPARQL consumers of the Web of Data can extract possibly complex information (i.e., existing resource references and their relationships) which are returned, for example, in a table format. This table can be incorporated into another Web page; using this approach SPARQL provides a powerful tool to build, for example, complex mash-up sites or search engines that include data stemming from the Semantic Web."
[{2021-01-03} https://www.w3.org/standards/semanticweb/query]

name::
* McsEngl.lagSweb'query,

inference of lagSweb

description::
"Broadly speaking, inference on the Semantic Web can be characterized by discovering new relationships. On the Semantic Web, data is modeled as a set of (named) relationships between resources. “Inference” means that automatic procedures can generate new relationships based on the data and based on some additional information in the form of a vocabulary, e.g., a set of rules. Whether the new relationships are explicitly added to the set of data, or are returned at query time, is an implementation issue.
On the Semantic Web, the source of such extra information can be defined via vocabularies or rule sets. Both of these approaches draw upon knowledge representation techniques. In general, ontologies concentrate on classification methods, putting an emphasis on defining 'classes', 'subclasses', on how individual resources can be associated to such classes, and characterizing the relationships among classes and their instances. Rules, on the other hand, concentrate on defining a general mechanism on discovering and generating new relationships based on existing ones, much like logic programs, like Prolog, do. In the family of Semantic Web related W3C Recommendations RDFS, OWL, or SKOS are the tools of choice to define ontologies, whereas RIF has been developed to cover rule based approaches."
[{2021-01-03} https://www.w3.org/standards/semanticweb/inference.html]

name::
* McsEngl.lagSweb'inference,

lagSweb.RDF

description::
"The Resource Description Framework (RDF) is a family of World Wide Web Consortium (W3C) specifications[1] originally designed as a metadata data model. It has come to be used as a general method for conceptual description or modeling of information that is implemented in web resources, using a variety of syntax notations and data serialization formats. It is also used in knowledge management applications.
RDF was adopted as a W3C recommendation in 1999. The RDF 1.0 specification was published in 2004, the RDF 1.1 specification in 2014."
[{2021-01-03} https://en.wikipedia.org/wiki/Resource_Description_Framework]

name::
* McsEngl.RDF'(resource-description-framework)!⇒lagRdfw,
* McsEngl.lagCnpt.005-RDF!⇒lagRdfw,
* McsEngl.lagCnpt.RDF!⇒lagRdfw,
* McsEngl.lagRdf!⇒lagRdfw,
* McsEngl.lagRdfw, {2021-01-05},
* McsEngl.lagRdfw'(resource-description-framework)!⇒lagRdfw,
* McsEngl.resource-description-framework!⇒lagRdfw,

input of lagRdfw

description::
"The Resource Description Framework (RDF) is a framework for expressing information about resources. Resources can be anything, including documents, people, physical objects, and abstract concepts.
RDF is intended for situations in which information on the Web needs to be processed by applications, rather than being only displayed to people. RDF provides a common framework for expressing this information so it can be exchanged between applications without loss of meaning. Since it is a common framework, application designers can leverage the availability of common RDF parsers and processing tools. The ability to exchange information between different applications means that the information may be made available to applications other than those for which it was originally created."
[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/]

name::
* McsEngl.Rdfinput,
* McsEngl.lagRdfw'input!⇒Rdfinput,

info-resource of Rdfinput

description::
"Resources can be anything, including documents, people, physical objects, and abstract concepts."
[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/]

name::
* McsEngl.Rdfinput'resource,
* McsEngl.Rdfiresource,
* McsEngl.lagRdfw'resource!⇒Rdfiresource,
* McsEngl.resource@lagRdfw,

Rdfiresource.subject

description::
· subject is-called the-left resource of an-Rdf-property.

name::
* McsEngl.Rdfiresource.subject!⇒Rdfisubject,
* McsEngl.Rdfisubject,

Rdfiresource.object

description::
· object is-called the-right resource of an-Rdf-property.

name::
* McsEngl.Rdfiobject,
* McsEngl.Rdfiresource.object!⇒Rdfiobject,

Rdfiresource.class

description::
· a-generic Rdfiresource is-called Rdficlass.
===
"Resources may be divided into groups called classes.
The members of a class are known as instances of the class.
Classes are themselves resources.
They are often identified by IRIs and may be described using RDF properties.
The rdf:type property may be used to state that a resource is an instance of a class."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_classes]

name::
* McsEngl.Rdficlass,
* McsEngl.Rdfinput'class!⇒Rdficlass,
* McsEngl.Rdfiresource.class!⇒Rdficlass,
* McsEngl.class@lagRdfw,
* McsEngl.lagRdfw'class!⇒Rdficlass,

Rdficlass.instance

description::
· a-specific Rdficlass is-called Rdfiinstance.
===
The members of a class are known as instances of the class.
... The rdf:type property may be used to state that a resource is an instance of a class."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_classes]

name::
* McsEngl.Rdficlass.instance!⇒Rdfiinstance,
* McsEngl.Rdfiinstance,

Rdficlass.extension

description::
· the-set of all Rdfiinstances of an-Rdficlass.

name::
* McsEngl.Rdficlass.extension!⇒Rdficlass-extension,
* McsEngl.Rdficlass-extension,

descriptionLong::
"RDF distinguishes between a class and the set of its instances. Associated with each class is a set, called the class extension of the class, which is the set of the instances of the class. Two classes may have the same set of instances but be different classes. For example, the tax office may define the class of people living at the same address as the editor of this document. The Post Office may define the class of people whose address has the same zip code as the address of the author. It is possible for these classes to have exactly the same instances, yet to have different properties. Only one of the classes has the property that it was defined by the tax office, and only the other has the property that it was defined by the Post Office.
A class may be a member of its own class extension and may be an instance of itself."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_classes]

Rdficlass.subclass

description::
· a-specific but not individual of an-Rdficlass.
===
"If a class C is a subclass of a class C', then all instances of C will also be instances of C'. The rdfs:subClassOf property may be used to state that one class is a subclass of another. The term super-class is used as the inverse of subclass. If a class C' is a super-class of a class C, then all instances of C are also instances of C'."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_classes]

name::
* McsEngl.Rdficlass.sublass!⇒Rdfisubclass,
* McsEngl.Rdfisubclass,

Rdficlass.rdfs:Resource

description::
"All things described by RDF are called resources, and are instances of the class rdfs:Resource. This is the class of everything. All other classes are subclasses of this class. rdfs:Resource is an instance of rdfs:Class."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_classes]

name::
* McsEngl.Rdficlass.rdfs:Resource,
* McsEngl.rdfs:Resource,

Rdficlass.rdfs:Class

description::
"This is the class of resources that are RDF classes. rdfs:Class is an instance of rdfs:Class."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_classes]

name::
* McsEngl.Rdficlass.rdfs:Class,
* McsEngl.rdfs:Class,

Rdficlass.rdfs:Literal

description::
"The class rdfs:Literal is the class of literal values such as strings and integers. Property values such as textual strings are examples of RDF literals.
rdfs:Literal is an instance of rdfs:Class. rdfs:Literal is a subclass of rdfs:Resource."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_classes]

name::
* McsEngl.Rdficlass.rdfs:Literal,
* McsEngl.rdfs:Literal,

Rdficlass.rdfs:Datatype

description::
"rdfs:Datatype is the class of datatypes. All instances of rdfs:Datatype correspond to the RDF model of a datatype described in the RDF Concepts specification [RDF11-CONCEPTS]. rdfs:Datatype is both an instance of and a subclass of rdfs:Class. Each instance of rdfs:Datatype is a subclass of rdfs:Literal."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_classes]

name::
* McsEngl.Rdficlass.rdfs:Datatype,
* McsEngl.rdfs:Datatype,

Rdficlass.rdf:lagString

description::
"The class rdf:langString is the class of language-tagged string values. rdf:langString is an instance of rdfs:Datatype and a subclass of rdfs:Literal."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_classes]

name::
* McsEngl.Rdficlass.rdf:lagString,
* McsEngl.rdf:lagString,

Rdficlass.rdf:HTML

description::
"The class rdf:HTML is the class of HTML literal values. rdf:HTML is an instance of rdfs:Datatype and a subclass of rdfs:Literal."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_classes]

name::
* McsEngl.Rdficlass.rdf:HTML,
* McsEngl.rdf:HTML,

Rdficlass.rdf:XMLLiteral

description::
"The class rdf:XMLLiteral is the class of XML literal values. rdf:XMLLiteral is an instance of rdfs:Datatype and a subclass of rdfs:Literal."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_classes]

name::
* McsEngl.Rdficlass.rdf:XMLLiteral,
* McsEngl.rdf:XMLLiteral,

Rdficlass.rdf:Property

description::
"rdf:Property is the class of RDF properties. rdf:Property is an instance of rdfs:Class."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_classes]

name::
* McsEngl.Rdficlass.rdf:Property,
* McsEngl.rdf:Property,

Rdficlass.rdf:Statement

description::
"The class of RDF statements."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/]

name::
* McsEngl.Rdficlass.rdf:Statement,
* McsEngl.rdf:Statement,

Rdficlass.rdf:Bag

description::
"The class of unordered containers."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/]

name::
* McsEngl.Rdficlass.rdf:Bag,
* McsEngl.rdf:Bag,

Rdficlass.rdf:Seq

description::
"The class of ordered containers."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/]

name::
* McsEngl.Rdficlass.rdf:Seq,
* McsEngl.rdf:Seq,

Rdficlass.rdf:Alt

description::
"The rdf:Alt class is the class of RDF 'Alternative' containers. It is a subclass of rdfs:Container. Whilst formally it is no different from an rdf:Seq or an rdf:Bag, the rdf:Alt class is used conventionally to indicate to a human reader that typical processing will be to select one of the members of the container. The first member of the container, i.e. the value of the rdf:_1 property, is the default choice.
...The class of containers of alternatives."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/]

name::
* McsEngl.Rdficlass.rdf:Alt,
* McsEngl.rdf:Alt,

Rdficlass.rdfs:Container

description::
"The rdfs:Container class is a super-class of the RDF Container classes, i.e. rdf:Bag, rdf:Seq, rdf:Alt.
...The class of RDF containers."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/]

name::
* McsEngl.Rdficlass.rdfs:Container,
* McsEngl.rdfs:Container,

Rdficlass.rdfs:ContainerMembershipProperty

description::
"The rdfs:ContainerMembershipProperty class has as instances the properties rdf:_1, rdf:_2, rdf:_3 ... that are used to state that a resource is a member of a container. rdfs:ContainerMembershipProperty is a subclass of rdf:Property. Each instance of rdfs:ContainerMembershipProperty is an rdfs:subPropertyOf the rdfs:member property.
Given a container C, a triple of the form:
C rdf:_nnn O
where nnn is the decimal representation of an integer greater than 0 with no leading zeros, states that O is a member of the container C.
Container membership properties may be applied to resources other than containers.
The class of container membership properties, rdf:_1, rdf:_2, ..., all of which are sub-properties of 'member'."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/]

name::
* McsEngl.Rdficlass.rdfs:ContainerMembershipProperty,
* McsEngl.rdfs:ContainerMembershipProperty,

Rdficlass.rdf:List

description::
"The class of RDF Lists."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/]

name::
* McsEngl.Rdficlass.rdf:List,
* McsEngl.Rdfilist,
* McsEngl.rdf:List,

Rdfilist.rdf:nil

description::
"The resource rdf:nil is an instance of rdf:List that can be used to represent an empty list or other list-like structure.
A triple of the form:
L rdf:rest rdf:nil
states that L is an instance of rdf:List that has one item; that item can be indicated using the rdf:first property."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_nil]

name::
* McsEngl.Rdfilist.rdf:nil,
* McsEngl.rdf:nil,

Rdfiresource.node

description::
"The set of nodes of an RDF graph is the set of subjects and objects of triples in the graph.
It is possible for a predicate IRI to also occur as a node in the same graph."
[{2021-01-06} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-rdf-triple]
===
"In Semantic Web languages, such as RDF and OWL, a property is a binary relation: instances of properties link two individuals. Often we refer to the second individual as the "value" or to both both individuals as "arguments" [See note on vocabulary]."
[{2021-01-06} https://www.w3.org/TR/2006/NOTE-swbp-n-aryRelations-20060412/#general]

name::
* McsEngl.Rdfinode,
* McsEngl.Rdfiresource.node!⇒Rdfinode,
* McsEngl.argument@lagRdfw,

Rdfiresource.blank-node

description::
· blank-node is an-Rdfiresource known but NOT identifiable.
"Blank nodes are treated as simply indicating the existence of a thing, without using an IRI to identify any particular thing. This is not the same as assuming that the blank node indicates an 'unknown' IRI."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf11-mt-20140225/#blank-nodes]

name::
* McsEngl.blank-node-Rdfiresource,
* McsEngl.Rdfiresource.blank-node,

Rdfiresource.property

description::
"The predicate itself is an IRI and denotes a property, that is, a resource that can be thought of as a binary relation."
[{2021-01-06} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-property]
"The RDF Concepts and Abstract Syntax specification [RDF11-CONCEPTS] describes the concept of an RDF property as a relation between subject resources and object resources."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_properties]

name::
* McsEngl.Rdfinput'property,
* McsEngl.Rdfiproperty,
* McsEngl.Rdfiresource.property!⇒Rdfiproperty,
* McsEngl.lagRdfw'property!⇒Rdfiproperty,
* McsEngl.property@lagRdfw,

subject of Rdfiproperty

description::
· subject-of-Rdfiproperty is the-Rdfiresource on its left.

name::
* McsEngl.Rdfiproperty'subject,
* McsEngl.subject@lagRdfw,

object of Rdfiproperty

description::
· object-of-Rdfiproperty is the-Rdfiresource on its right.
===
"In Semantic Web languages, such as RDF and OWL, a property is a binary relation: instances of properties link two individuals. Often we refer to the second individual as the "value" or to both both individuals as "arguments" [See note on vocabulary]."
[{2021-01-06} https://www.w3.org/TR/2006/NOTE-swbp-n-aryRelations-20060412/#general]

name::
* McsEngl.Rdfiproperty'object,
* McsEngl.object@lagRdfw,
* McsEngl.value@lagRdfw,

domain of Rdfiproperty

description::
· domain-of-Rdfiproperty is its generic subject.

name::
* McsEngl.Rdfiproperty'domain,

range of Rdfiproperty

description::
· range-of-Rdfiproperty it its generic object.

name::
* McsEngl.Rdfiproperty'range,

Rdfiproperty.rdfs:range

description::
"rdfs:range is an instance of rdf:Property that is used to state that the values of a property are instances of one or more classes.
The triple
P rdfs:range C
states that P is an instance of the class rdf:Property, that C is an instance of the class rdfs:Class and that the resources denoted by the objects of triples whose predicate is P are instances of the class C.
Where P has more than one rdfs:range property, then the resources denoted by the objects of triples with predicate P are instances of all the classes stated by the rdfs:range properties.
The rdfs:range property can be applied to itself. The rdfs:range of rdfs:range is the class rdfs:Class. This states that any resource that is the value of an rdfs:range property is an instance of rdfs:Class.
The rdfs:range property is applied to properties. This can be represented in RDF using the rdfs:domain property. The rdfs:domain of rdfs:range is the class rdf:Property. This states that any resource with an rdfs:range property is an instance of rdf:Property."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_properties]

name::
* McsEngl.Rdfiproperty.rdfs:range,
* McsEngl.rdfs:range,

Rdfiproperty.rdfs:domain

description::
"rdfs:domain is an instance of rdf:Property that is used to state that any resource that has a given property is an instance of one or more classes.
A triple of the form:
P rdfs:domain C
states that P is an instance of the class rdf:Property, that C is a instance of the class rdfs:Class and that the resources denoted by the subjects of triples whose predicate is P are instances of the class C.
Where a property P has more than one rdfs:domain property, then the resources denoted by subjects of triples with predicate P are instances of all the classes stated by the rdfs:domain properties.
The rdfs:domain property may be applied to itself. The rdfs:domain of rdfs:domain is the class rdf:Property. This states that any resource with an rdfs:domain property is an instance of rdf:Property.
The rdfs:range of rdfs:domain is the class rdfs:Class. This states that any resource that is the value of an rdfs:domain property is an instance of rdfs:Class."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_properties]

name::
* McsEngl.Rdfiproperty.rdfs:domain,
* McsEngl.rdfs:domain,

Rdfiproperty.rdf:type

description::
"rdf:type is an instance of rdf:Property that is used to state that a resource is an instance of a class.
A triple of the form:
R rdf:type C
states that C is an instance of rdfs:Class and R is an instance of C.
The rdfs:domain of rdf:type is rdfs:Resource. The rdfs:range of rdf:type is rdfs:Class."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_properties]

name::
* McsEngl.Rdfiproperty.rdf:type,
* McsEngl.rdf:type,

Rdfiproperty.rdfs:subClassOf

description::
"The property rdfs:subClassOf is an instance of rdf:Property that is used to state that all the instances of one class are instances of another.
A triple of the form:
C1 rdfs:subClassOf C2
states that C1 is an instance of rdfs:Class, C2 is an instance of rdfs:Class and C1 is a subclass of C2. The rdfs:subClassOf property is transitive.
The rdfs:domain of rdfs:subClassOf is rdfs:Class. The rdfs:range of rdfs:subClassOf is rdfs:Class."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_properties]

name::
* McsEngl.Rdfiproperty.rdfs:subClassOf,
* McsEngl.rdfs:subClassOf,

Rdfiproperty.rdfs:subPropertyOf

description::
"The property rdfs:subPropertyOf is an instance of rdf:Property that is used to state that all resources related by one property are also related by another.
A triple of the form:
P1 rdfs:subPropertyOf P2
states that P1 is an instance of rdf:Property, P2 is an instance of rdf:Property and P1 is a subproperty of P2. The rdfs:subPropertyOf property is transitive.
The rdfs:domain of rdfs:subPropertyOf is rdf:Property. The rdfs:range of rdfs:subPropertyOf is rdf:Property."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_properties]

name::
* McsEngl.Rdfiproperty.rdfs:subPropertyOf,
* McsEngl.rdfs:subPropertyOf,

Rdfiproperty.rdfs:label

description::
"rdfs:label is an instance of rdf:Property that may be used to provide a human-readable version of a resource's name.
A triple of the form:
R rdfs:label L
states that L is a human readable label for R.
The rdfs:domain of rdfs:label is rdfs:Resource. The rdfs:range of rdfs:label is rdfs:Literal.
Multilingual labels are supported using the language tagging facility of RDF literals."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_properties]

name::
* McsEngl.Rdfiproperty.rdfs:label,
* McsEngl.rdfs:label,

Rdfiproperty.rdfs:comment

description::
"rdfs:comment is an instance of rdf:Property that may be used to provide a human-readable description of a resource.
A triple of the form:
R rdfs:comment L
states that L is a human readable description of R.
The rdfs:domain of rdfs:comment is rdfs:Resource. The rdfs:range of rdfs:comment is rdfs:Literal.
A textual comment helps clarify the meaning of RDF classes and properties. Such in-line documentation complements the use of both formal techniques (Ontology and rule languages) and informal (prose documentation, examples, test cases). A variety of documentation forms can be combined to indicate the intended meaning of the classes and properties described in an RDF vocabulary. Since RDF vocabularies are expressed as RDF graphs, vocabularies defined in other namespaces may be used to provide richer documentation.
Multilingual documentation is supported through use of the language tagging facility of RDF literals."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_properties]

name::
* McsEngl.Rdfiproperty.rdfs:comment,
* McsEngl.rdfs:comment,

Rdfiproperty.rdfs:member

description::
"rdfs:member is an instance of rdf:Property that is a super-property of all the container membership properties i.e. each container membership property has an rdfs:subPropertyOf relationship to the property rdfs:member.
The rdfs:domain of rdfs:member is rdfs:Resource. The rdfs:range of rdfs:member is rdfs:Resource.
...A member of the subject resource. rdfs:Resource rdfs:Resource"
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/]

name::
* McsEngl.Rdfiproperty.rdfs:member,
* McsEngl.rdfs:member,

Rdfiproperty.rdf:first

description::
"The first item in the subject RDF list. rdf:List rdfs:Resource"
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_sumproperties]

name::
* McsEngl.Rdfiproperty.rdf:first,
* McsEngl.rdf:first,

Rdfiproperty.rdf:rest

description::
"The rest of the subject RDF list after the first item. rdf:List rdf:List"
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_sumproperties]

name::
* McsEngl.Rdfiproperty.rdf:rest,
* McsEngl.rdf:rest,

Rdfiproperty.rdfs:seeAlso

description::
"Further information about the subject resource. rdfs:Resource rdfs:Resource"
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_sumproperties]

name::
* McsEngl.Rdfiproperty.rdfs:seeAlso,
* McsEngl.rdfs:seeAlso,

Rdfiproperty.rdfs:isDefinedBy

description::
"The definition of the subject resource. rdfs:Resource rdfs:Resource"
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_sumproperties]

name::
* McsEngl.Rdfiproperty.rdfs:isDefinedBy,
* McsEngl.rdfs:isDefinedBy,

Rdfiproperty.rdf:value

description::
"Idiomatic property used for structured values. rdfs:Resource rdfs:Resource"
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_sumproperties]

name::
* McsEngl.Rdfiproperty.rdf:value,
* McsEngl.rdf:value,

Rdfiproperty.rdf:subject

description::
"The subject of the subject RDF statement. rdf:Statement rdfs:Resource"
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_sumproperties]

name::
* McsEngl.Rdfiproperty.rdf:subject,
* McsEngl.rdf:subject,

Rdfiproperty.rdf:predicate

description::
"The predicate of the subject RDF statement. rdf:Statement rdfs:Resource"
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_sumproperties]

name::
* McsEngl.Rdfiproperty.rdf:predicate,
* McsEngl.rdf:predicate,

Rdfiproperty.rdf:object

description::
"The object of the subject RDF statement. rdf:Statement rdfs:Resource"
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_sumproperties]

name::
* McsEngl.Rdfiproperty.rdf:object,
* McsEngl.rdf:object,

Rdfiproperty.rdf:_1

description::
"RDF also uses properties called rdf:_1, rdf:_2, rdf:_3... etc., each of which is both a sub-property of rdfs:member and an instance of the class rdfs:ContainerMembershipProperty. "
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_sumproperties]

name::
* McsEngl.Rdfiproperty.rdf:_1,
* McsEngl.rdf:_1,

Rdfiproperty.rdf:_2

description::
"RDF also uses properties called rdf:_1, rdf:_2, rdf:_3... etc., each of which is both a sub-property of rdfs:member and an instance of the class rdfs:ContainerMembershipProperty. "
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_sumproperties]

name::
* McsEngl.Rdfiproperty.rdf:_2,
* McsEngl.rdf:_2,

Rdfiresource.referent

description::
"The resource denoted by an IRI is also called its referent."
[{2021-01-06} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-referent]

name::
* McsEngl.Rdfireferent,
* McsEngl.Rdfiresource.referent!⇒Rdfireferent,
* McsEngl.referent@lagRdfw,

Rdfiresource.RDF-source

description::
"We informally use the term RDF source to refer to a persistent yet mutable source or container of RDF graphs.
An RDF source is a resource that may be said to have a state that can change over time.
A snapshot of the state can be expressed as an RDF graph.
For example, any web document that has an RDF-bearing representation may be considered an RDF source.
Like all resources, RDF sources may be named with IRIs and therefore described in other RDF graphs."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-rdf-source]

name::
* McsEngl.Rdfiresource.RDF-source,
* McsEngl.RDF-source@lagRdfw,

term of Rdfinput

description::
"IRIs, literals and blank nodes are collectively known as RDF terms.
IRIs, literals and blank nodes are distinct and distinguishable.
For example, http://example.org/ as a string literal is neither equal to http://example.org/ as an IRI, nor to a blank node with the blank node identifier http://example.org/."
[{2021-01-06} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-rdf-triple]

name::
* McsEngl.Rdfinput'term!⇒Rdfiterm,
* McsEngl.Rdfiterm,
* McsEngl.term@lagRdfw,

Rdfiterm.IRI

description::
"An IRI (Internationalized Resource Identifier) within an RDF graph is a Unicode string [UNICODE] that conforms to the syntax defined in RFC 3987 [RFC3987].
IRIs in the RDF abstract syntax must be absolute, and may contain a fragment identifier.
IRI equality: Two IRIs are equal if and only if they are equivalent under Simple String Comparison according to section 5.1 of [RFC3987]. Further normalization must not be performed when comparing IRIs for equality."
===
"The abbreviation IRI is short for "International Resource Identifier". An IRI identifies a resource. The URLs (Uniform Resource Locators) that people use as Web addresses are one form of IRI. Other forms of IRI provide an identifier for a resource without implying its location or how to access it. The notion of IRI is a generalization of URI (Uniform Resource Identifier), allowing non-ASCII characters to be used in the IRI character string. IRIs are specified in RFC 3987 [RFC3987].
IRIs can appear in all three positions of a triple.
As mentioned, IRIs are used to identify resources such as documents, people, physical objects, and abstract concepts. For example, the IRI for Leonardo da Vinci in DBpedia is:
http://dbpedia.org/resource/Leonardo_da_Vinci
The IRI for an INA video about the Mona Lisa entitled 'La Joconde à Washington' in Europeana is:
http://data.europeana.eu/item/04802/243FA8618938F4117025F17A8B813C5F9AA4D619
IRIs are global identifiers, so other people can re-use this IRI to identify the same thing. For example, the following IRI is used by many people as an RDF property to state an acquaintance relationship between people:
http://xmlns.com/foaf/0.1/knows
RDF is agnostic about what the IRI represents. However, IRIs may be given meaning by particular vocabularies or conventions. For example, DBpedia uses IRIs of the form http://dbpedia.org/resource/Name to denote the thing described by the corresponding Wikipedia article."
[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/#section-IRI]

name::
* McsEngl.IRI'(internationalized-resource-identifier)!⇒Rdfiiri,
* McsEngl.IRI@lagRdfw,
* McsEngl.Rdfiiri,
* McsEngl.Rdfiterm.IRI!⇒Rdfiiri,
* McsEngl.internationalized-resource-identifier!⇒Rdfiiri,

relation-to-URL of Rdfiiri

description::
"URIs and IRIs: IRIs are a generalization of URIs [RFC3986] that permits a wider range of Unicode characters.
Every absolute URI and URL is an IRI, but not every IRI is an URI.
When IRIs are used in operations that are only defined for URIs, they must first be converted according to the mapping defined in section 3.1 of [RFC3987].
A notable example is retrieval over the HTTP protocol.
The mapping involves UTF-8 encoding of non-ASCII characters, %-encoding of octets not allowed in URIs, and Punycode-encoding of domain names."
[{2021-01-06} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#section-IRIs]

name::
* McsEngl.IRI-relation-to-URL,
* McsEngl.Rdfiiri'relation-to-URL,
* McsEngl.URL-relation-to-IRI,

Rdfiiri.datatype (link)
Rdfiiri.namespace (link)
Rdfiterm.literal

description::
"Literals are used for values such as strings, numbers, and dates.
A literal in an RDF graph consists of two or three elements:
× a lexical form, being a Unicode [UNICODE] string, which should be in Normal Form C [NFC],
* a datatype IRI, being an IRI identifying a datatype that determines how the lexical form maps to a literal value, and
if and only if the datatype IRI is http://www.w3.org/1999/02/22-rdf-syntax-ns#langString, a non-empty language tag as defined by [BCP47]. The language tag must be well-formed according to section 2.2.9 of [BCP47].
A literal is a language-tagged string if the third element is present. Lexical representations of language tags may be converted to lower case. The value space of language tags is always in lower case.
Please note that concrete syntaxes may support simple literals consisting of only a lexical form without any datatype IRI or language tag. Simple literals are syntactic sugar for abstract syntax literals with the datatype IRI http://www.w3.org/2001/XMLSchema#string. Similarly, most concrete syntaxes represent language-tagged strings without the datatype IRI because it always equals http://www.w3.org/1999/02/22-rdf-syntax-ns#langString."
[{2021-01-06} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#section-Graph-Literal]

name::
* McsEngl.Rdfiliteral,
* McsEngl.Rdfiterm.literal!⇒Rdfiliteral,
* McsEngl.literal@lagRdfw,

lexical-form of Rdfiliteral

description::
"A literal in an RDF graph consists of two or three elements:
× a lexical form, being a Unicode [UNICODE] string, which should be in Normal Form C [NFC],
* a datatype IRI, being an IRI identifying a datatype that determines how the lexical form maps to a literal value, and
* if and only if the datatype IRI is http://www.w3.org/1999/02/22-rdf-syntax-ns#langString, a non-empty language tag as defined by [BCP47]. The language tag must be well-formed according to section 2.2.9 of [BCP47]."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-literal]

name::
* McsEngl.Rdfiliteral'lexical-form,
* McsEngl.lexical-form@lagRdfw,

datatype-IRI of Rdfiliteral

description::
"A literal in an RDF graph consists of two or three elements:
× a lexical form, being a Unicode [UNICODE] string, which should be in Normal Form C [NFC],
* a datatype IRI, being an IRI identifying a datatype that determines how the lexical form maps to a literal value, and
* if and only if the datatype IRI is http://www.w3.org/1999/02/22-rdf-syntax-ns#langString, a non-empty language tag as defined by [BCP47]. The language tag must be well-formed according to section 2.2.9 of [BCP47]."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-literal]

name::
* McsEngl.Rdfiliteral'datatype-IRI,
* McsEngl.datatype-IRI@lagRdfw,

datatype of datatype-IRI

description::
"Datatypes are used with RDF literals to represent values such as strings, numbers and dates.
The datatype abstraction used in RDF is compatible with XML Schema [XMLSCHEMA11-2].
Any datatype definition that conforms to this abstraction may be used in RDF, even if not defined in terms of XML Schema.
RDF re-uses many of the XML Schema built-in datatypes, and defines two additional non-normative datatypes, rdf:HTML and rdf:XMLLiteral.
The list of datatypes supported by an implementation is determined by its recognized datatype IRIs."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#section-Datatypes]

name::
* McsEngl.Rdfiliteral'datatype-IRI'datatype,
* McsEngl.datatype@lagRdfw,

lexical-space of datatype of datatype-IRI

description::
"The lexical space of a datatype is a set of Unicode [UNICODE] strings."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-lexical-space]

name::
* McsEngl.datatype@lagRdfw'lexical-space,
* McsEngl.lexical-space@lagRdfw,

value-space of datatype of datatype-IRI

description::
"The lexical-to-value mapping of a datatype is a set of pairs whose first element belongs to the lexical space, and the second element belongs to the value space of the datatype.
Each member of the lexical space is paired with exactly one value, and is a lexical representation of that value.
The mapping can be seen as a function from the lexical space to the value space."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-lexical-to-value-mapping]

name::
* McsEngl.datatype@lagRdfw'value-space,
* McsEngl.value-space@lagRdfw,

lexical-to-value-mapping of datatype of datatype-IRI

description::
"The lexical-to-value mapping of a datatype is a set of pairs whose first element belongs to the lexical space, and the second element belongs to the value space of the datatype.
Each member of the lexical space is paired with exactly one value, and is a lexical representation of that value.
The mapping can be seen as a function from the lexical space to the value space."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-lexical-to-value-mapping]

name::
* McsEngl.datatype@lagRdfw'lexical-to-value-mapping,
* McsEngl.lexical-to-value-mapping@lagRdfw,

datatype-IRI.recognized

description::
"Datatypes are identified by IRIs.
If D is a set of IRIs which are used to refer to datatypes, then the elements of D are called recognized datatype IRIs.
Recognized IRIs have fixed referents.
If any IRI of the form http://www.w3.org/2001/XMLSchema#xxx is recognized, it must refer to the RDF-compatible XSD type named xsd:xxx for every XSD type listed in section 5.1.
Furthermore, the following IRIs are allocated for non-normative datatypes:
- The IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral refers to the datatype rdf:XMLLiteral
- The IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML refers to the datatype rdf:HTML"
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-recognized-datatype-iris]

name::
* McsEngl.Rdfiliteral'datatype-IRI.recognized,
* McsEngl.recognized-datatype-IRI@lagRdfw,

datatype-IRI.XML-Schema

description::
"IRIs of the form http://www.w3.org/2001/XMLSchema#xxx, where xxx is the name of a datatype, denote the built-in datatypes defined in XML Schema 1.1 Part 2: Datatypes [XMLSCHEMA11-2].
The XML Schema built-in types listed in the following table are the RDF-compatible XSD types.
Their use is recommended."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#xsd-datatypes]

name::
* McsEngl.datatype-IRI.XML-Schema,
* McsEngl.datatype-IRI.xsd,

xsd:string::
× sDescription: Character strings (but not all Unicode character strings)
× sType: Core type
* McsEngl.xsd:string@lagRdfw,
* McsEngl.string//xsd,

xsd:boolean::
× sValue: true, false
× sType: Core type
* McsEngl.xsd:boolean@lagRdfw,
* McsEngl.boolean//xsd,

xsd:decimal::
× sValue: Arbitrary-precision decimal numbers
× sType: Core type
* McsEngl.xsd:decimal@lagRdfw,
* McsEngl.decimal//xsd,

xsd:integer::
× sValue: Arbitrary-size integer numbers
× sType: Core type
* McsEngl.xsd:integer@lagRdfw,
* McsEngl.integer//xsd,

xsd:double::
× sValue: 64-bit floating point numbers incl. ±Inf, ±0, NaN
× sType: IEEE floating-point number
* McsEngl.xsd:double@lagRdfw,
* McsEngl.double//xsd,

xsd:float::
× sValue: 32-bit floating point numbers incl. ±Inf, ±0, NaN
× sType: IEEE floating-point number
* McsEngl.xsd:float@lagRdfw,
* McsEngl.float//xsd,

xsd:date::
× sValue: Dates (yyyy-mm-dd) with or without timezone
× sType: Time and date
* McsEngl.xsd:date@lagRdfw,
* McsEngl.date//xsd,

xsd:time::
× sValue: Times (hh:mm:ss.sss…) with or without timezone
× sType: Time and date
* McsEngl.xsd:time@lagRdfw,
* McsEngl.time//xsd,

xsd:dateTime::
× sValue: Date and time with or without timezone
× sType: Time and date
* McsEngl.xsd:dateTime@lagRdfw,
* McsEngl.dateTime//xsd,

xsd:dateTimeStamp::
× sValue: Date and time with required timezone
× sType: Time and date
* McsEngl.xsd:dateTimeStamp@lagRdfw,
* McsEngl.dateTimeStamp//xsd,

xsd:gYear::
× sValue: Gregorian calendar year
× sType: Recurring and partial date
* McsEngl.xsd:gYear@lagRdfw,
* McsEngl.gYear//xsd,

xsd:gMonth::
× sValue: Gregorian calendar month
× sType: Recurring and partial date
* McsEngl.xsd:gMonth@lagRdfw,
* McsEngl.gMonth//xsd,

xsd:gDay::
× sValue: Gregorian calendar day of the month
× sType: Recurring and partial date
* McsEngl.xsd:gDay@lagRdfw,
* McsEngl.gDay//xsd,

xsd:gYearMonth::
× sValue: Gregorian calendar year and month
× sType: Recurring and partial date
* McsEngl.xsd:gYearMonth@lagRdfw,
* McsEngl.gYearMonth//xsd,

xsd:gMonthDay::
× sValue: Gregorian calendar month and day
× sType: Recurring and partial date
* McsEngl.xsd:gMonthDay@lagRdfw,
* McsEngl.gMonthDay//xsd,

xsd:duration::
× sValue: Duration of time
× sType: Recurring and partial date
* McsEngl.xsd:duration@lagRdfw,
* McsEngl.duration//xsd,

xsd:yearMonthDuration::
× sValue: Duration of time (months and years only)
× sType: Recurring and partial date
* McsEngl.xsd:yearMonthDuration@lagRdfw,
* McsEngl.yearMonthDuration//xsd,

xsd:dayTimeDuration::
× sValue: Duration of time (days, hours, minutes, seconds only)
× sType: Recurring and partial date
* McsEngl.xsd:dayTimeDuration@lagRdfw,
* McsEngl.dayTimeDuration//xsd,

xsd:byte::
× sValue: -128…+127 (8 bit)
× sType: Limited-range integer number
* McsEngl.xsd:byte@lagRdfw,
* McsEngl.byte//xsd,

xsd:short::
× sValue: -32768…+32767 (16 bit)
× sType: Limited-range integer number
* McsEngl.xsd:short@lagRdfw,
* McsEngl.short//xsd,

xsd:int::
× sValue: -2147483648…+2147483647 (32 bit)
× sType: Limited-range integer number
* McsEngl.xsd:int@lagRdfw,
* McsEngl.int//xsd,

xsd:long::
× sValue: -9223372036854775808…+9223372036854775807 (64 bit)
× sType: Limited-range integer number
* McsEngl.xsd:long@lagRdfw,
* McsEngl.long//xsd,

xsd:unsignedByte::
× sValue: 0…255 (8 bit)
× sType: Limited-range integer number
* McsEngl.xsd:unsignedByte@lagRdfw,
* McsEngl.unsignedByte//xsd,

xsd:unsignedShort::
× sValue: 0…65535 (16 bit)
× sType: Limited-range integer number
* McsEngl.xsd:unsignedShort@lagRdfw,
* McsEngl.unsignedShort//xsd,

xsd:unsignedInt::
× sValue: 0…4294967295 (32 bit)
× sType: Limited-range integer number
* McsEngl.xsd:unsignedInt@lagRdfw,
* McsEngl.unsignedInt//xsd,

xsd:unsignedLong::
× sValue: 0…18446744073709551615 (64 bit)
× sType: Limited-range integer number
* McsEngl.xsd:unsignedLong@lagRdfw,
* McsEngl.unsignedLong//xsd,

xsd:positiveInteger::
× sValue: Integer numbers >0
× sType: Limited-range integer number
* McsEngl.xsd:positiveInteger@lagRdfw,
* McsEngl.positiveInteger//xsd,

xsd:nonNegativeInteger::
× sValue: Integer numbers ≥0
× sType: Limited-range integer number
* McsEngl.xsd:nonNegativeInteger@lagRdfw,
* McsEngl.nonNegativeInteger//xsd,

xsd:negativeInteger::
× sValue: Integer numbers <0
× sType: Limited-range integer number
* McsEngl.xsd:negativeInteger@lagRdfw,
* McsEngl.negativeInteger//xsd,

xsd:nonPositiveInteger::
× sValue: Integer numbers ≤0
× sType: Limited-range integer number
* McsEngl.xsd:nonPositiveInteger@lagRdfw,
* McsEngl.nonPositiveInteger//xsd,

xsd:hexBinary::
× sValue: Hex-encoded binary data
× sType: Encoded binary data
* McsEngl.xsd:hexBinary@lagRdfw,
* McsEngl.hexBinary//xsd,

xsd:base64Binary::
× sValue: Base64-encoded binary data
× sType: Encoded binary data
* McsEngl.xsd:base64Binary@lagRdfw,
* McsEngl.base64Binary//xsd,

xsd:anyURI::
× sValue: Absolute or relative URIs and IRIs
× sType: Miscellaneous XSD type
* McsEngl.xsd:anyURI@lagRdfw,
* McsEngl.anyURI//xsd,

xsd:language::
× sValue: Language tags per [BCP47]
× sType: Miscellaneous XSD type
* McsEngl.xsd:language@lagRdfw,
* McsEngl.language//xsd,

xsd:normalizedString::
× sValue: Whitespace-normalized strings
× sType: Miscellaneous XSD type
* McsEngl.xsd:normalizedString@lagRdfw,
* McsEngl.normalizedString//xsd,

xsd:token::
× sValue: Tokenized strings
× sType: Miscellaneous XSD type
* McsEngl.xsd:token@lagRdfw,
* McsEngl.token//xsd,

xsd:NMTOKEN::
× sValue: XML NMTOKENs
× sType: Miscellaneous XSD type
* McsEngl.xsd:NMTOKEN@lagRdfw,
* McsEngl.NMTOKEN//xsd,

xsd:Name::
× sValue: XML Names
× sType: Miscellaneous XSD type
* McsEngl.xsd:Name@lagRdfw,
* McsEngl.Name//xsd,

xsd:NCName::
× sValue: XML NCNames
× sType: Miscellaneous XSD type
* McsEngl.xsd:NCName@lagRdfw,
* McsEngl.NCName//xsd,

datatype-IRI.rdf:HTML

description::
"RDF provides for HTML content as a possible literal value. This allows markup in literal values. Such content is indicated in an RDF graph using a literal whose datatype is set to rdf:HTML. This datatype is defined as non-normative because it depends on [DOM4], a specification that has not yet reached W3C Recommendation status."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#section-html]

name::
* McsEngl.datatype-IRI.rdf:HTML,
* McsEngl.rdf:HTML@lagRdfw,

datatype-IRI.rdf:XMLLiteral

description::
"RDF provides for XML content as a possible literal value. Such content is indicated in an RDF graph using a literal whose datatype is set to rdf:XMLLiteral. This datatype is defined as non-normative because it depends on [DOM4], a specification that has not yet reached W3C Recommendation status."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#section-XMLLiteral]

name::
* McsEngl.datatype-IRI.rdf:XMLLiteral,
* McsEngl.rdf:XMLLiteral@lagRdfw,

language-tag of Rdfiliteral

description::
"A literal in an RDF graph consists of two or three elements:
× a lexical form, being a Unicode [UNICODE] string, which should be in Normal Form C [NFC],
* a datatype IRI, being an IRI identifying a datatype that determines how the lexical form maps to a literal value, and
* if and only if the datatype IRI is http://www.w3.org/1999/02/22-rdf-syntax-ns#langString, a non-empty language tag as defined by [BCP47]. The language tag must be well-formed according to section 2.2.9 of [BCP47]."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-literal]

name::
* McsEngl.Rdfiliteral'language-tag,
* McsEngl.language-tag@lagRdfw,

value of Rdfiliteral

description::
"The literal value associated with a literal is:
* If the literal is a language-tagged string, then the literal value is a pair consisting of its lexical form and its language tag, in that order.
* If the literal's datatype IRI is in the set of recognized datatype IRIs, let d be the referent of the datatype IRI.
** If the literal's lexical form is in the lexical space of d, then the literal value is the result of applying the lexical-to-value mapping of d to the lexical form.
** Otherwise, the literal is ill-typed and no literal value can be associated with the literal. Such a case produces a semantic inconsistency but is not syntactically ill-formed. Implementations must accept ill-typed literals and produce RDF graphs from them. Implementations may produce warnings when encountering ill-typed literals.
* If the literal's datatype IRI is not in the set of recognized datatype IRIs, then the literal value is not defined by this specification."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-literal-value]

name::
* McsEngl.Rdfiliteral'value,
* McsEngl.literal-value@lagRdfw,
* McsEngl.value-of-literal@lagRdfw,

Rdfiliteral.language-tagged-string

description::
"A literal is a language-tagged string if the third element is present.
Lexical representations of language tags may be converted to lower case.
The value space of language tags is always in lower case."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-language-tagged-string]

name::
* McsEngl.Rdfiliteral.language-tagged-string,
* McsEngl.language-tagged-string@lagRdfw,

Rdfiliteral.simple

description::
"Please note that concrete syntaxes may support simple literals consisting of only a lexical form without any datatype IRI or language tag.
Simple literals are syntactic sugar for abstract syntax literals with the datatype IRI http://www.w3.org/2001/XMLSchema#string.
Similarly, most concrete syntaxes represent language-tagged strings without the datatype IRI because it always equals http://www.w3.org/1999/02/22-rdf-syntax-ns#langString."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-simple-literal]

name::
* McsEngl.Rdfiliteral.simple,
* McsEngl.simple-literal@lagRdfw,

triple of Rdfinput

description::
"An RDF triple consists of three components:
* the subject, which is an IRI or a blank node
* the predicate, which is an IRI
* the object, which is an IRI, a literal or a blank node
An RDF triple is conventionally written in the order subject, predicate, object."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-rdf-triple]

name::
* McsEngl.Rdfinput'triple!⇒Rdfitriple,
* McsEngl.Rdfinput'statement!⇒Rdfitriple,
* McsEngl.statement@lagRdfw,

graph of Rdfinput

description::
"An RDF graph is a set of RDF triples."
[{2021-01-06} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-rdf-graph]

name::
* McsEngl.Rdfigraph,
* McsEngl.Rdfinput'graph!⇒Rdfigraph,
* McsEngl.graph@lagRdfw,

dataset of Rdfinput

description::
"RDF datasets, defined in RDF Concepts [RDF11-CONCEPTS], package up zero or more named RDF graphs along with a single unnamed, default RDF graph."
[{2021-01-05} https://www.w3.org/TR/2014/REC-rdf11-mt-20140225/#blank-nodes]

name::
* McsEngl.Rdfidataset,
* McsEngl.Rdfinput'dataset!⇒Rdfidataset,
* McsEngl.dataset@lagRdfw,

output of lagRdfw

description::
"An RDF document is a document that encodes an RDF graph or RDF dataset in a concrete RDF syntax, such as Turtle [TURTLE], RDFa [RDFA-PRIMER], JSON-LD [JSON-LD], or TriG [TRIG]. RDF documents enable the exchange of RDF graphs and RDF datasets between systems."
[{2021-01-06} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-rdf-document]

name::
* McsEngl.Rdfdoc,
* McsEngl.lagRdfw'document!⇒Rdfdoc,
* McsEngl.lagRdfw'output!⇒Rdfdoc,

output-dataset of lagRdfw

description::
· RDF-datasets are collections of RDF-graphs, comprised of a-default-graph and zero or more named-graphs.
[{2021-01-03} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/]

name::
* McsEngl.lagRdfw'output-dataset,

output-graph of lagRdfw

description::
· RDF-graphs are SETS of subject-predicate-object triples.
[{2021-01-03} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/]

name::
* McsEngl.Rdfograph,
* McsEngl.lagRdfw'graph!⇒Rdfograph,

name of Rdfograph

description::
"The IRI associated with the graph is called the graph name."
[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/#section-multiple-graphs]

name::
* McsEngl.Rdfograph'name,

output-triple of lagRdfw

description::
"RDF allows us to make statements about resources. The format of these statements is simple. A statement always has the following structure:
<subject> <predicate> <object>
An RDF statement expresses a relationship between two resources. The subject and the object represent the two resources being related; the predicate represents the nature of their relationship. The relationship is phrased in a directional way (from subject to object) and is called in RDF a property. Because RDF statements consist of three elements they are called triples."
[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/]

name::
* McsEngl.Rdfotriple,
* McsEngl.lagRdfw'output-statement!⇒Rdfotriple,
* McsEngl.lagRdfw'output-triple!⇒Rdfotriple,

output-subject of lagRdfw

description::
·

name::
* McsEngl.lagRdfw'output-subject,

predicate of lagRdfw

description::
·

name::
* McsEngl.lagRdfw'output-predicate,
* McsEngl.lagRdfw'output-property,

object of lagRdfw

description::
·

name::
* McsEngl.lagRdfw'output-object,

output-IRI of lagRdfw

description::

name::
* McsEngl.Rdfoiri,
* McsEngl.lagRdfw'output-IRI!⇒Rdfoiri,

output-literal of lagRdfw

description::
"Literals are basic values that are not IRIs. Examples of literals include strings such as "La Joconde", dates such as "the 4th of July, 1990" and numbers such as "3.14159". Literals are associated with a datatype enabling such values to be parsed and interpreted correctly. String literals can optionally be associated with a language tag. For example, "Léonard de Vinci" could be associated with the "fr" language tag and "李奥纳多·达·文西" with the "zh" language tag.
Literals may only appear in the object position of a triple.
The RDF Concepts document provides a (non-exhaustive) list of datatypes. This includes many datatypes defined by XML Schema, such as string, boolean, integer, decimal and date."
[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/#section-literal]

name::
* McsEngl.lagRdfw'output-literal,

output-blank-node of lagRdfw

description::
"IRIs and literals together provide the basic material for writing down RDF statements. In addition, it is sometimes handy to be able to talk about resources without bothering to use a global identifier. For example, we might want to state that the Mona Lisa painting has in its background an unidentified tree which we know to be a cypress tree. A resource without a global identifier, such as the painting's cypress tree, can be represented in RDF by a blank node. Blank nodes are like simple variables in algebra; they represent some thing without saying what their value is.
Blank nodes can appear in the subject and object position of a triple. They can be used to denote resources without explicitly naming them with an IRI."
[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/#section-blank-node]

name::
* McsEngl.lagRdfw'output-blank-node,

vocabulary of lagRdfw

description::
"An RDF vocabulary is a collection of IRIs intended for use in RDF graphs.
For example, the IRIs documented in [RDF11-SCHEMA] are the RDF Schema vocabulary.
RDF Schema can itself be used to define and document additional RDF vocabularies."
[{2021-01-06} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-rdf-vocabulary]
===
"The term “namespace” on its own does not have a well-defined meaning in the context of RDF, but is sometimes informally used to mean “namespace IRI” or “RDF vocabulary”."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-namespace]

name::
* McsEngl.RDF-vocabulary!⇒Rdfvoc,
* McsEngl.Rdfvoc,
* McsEngl.lagRdfw'vocabulary!⇒Rdfvoc,
* McsEngl.namespace@lagRdfw,
* McsEngl.vocabulary@lagRdfw,

namespace-IRI of Rdfvoc

description::
"The IRIs in an RDF vocabulary often begin with a common substring known as a namespace IRI.
Some namespace IRIs are associated by convention with a short name known as a namespace prefix.
Some examples:"

Namespace prefix Namespace IRI RDF vocabulary
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# The RDF built-in vocabulary [RDF11-SCHEMA]
rdfs http://www.w3.org/2000/01/rdf-schema# The RDF Schema vocabulary [RDF11-SCHEMA]
xsd http://www.w3.org/2001/XMLSchema# The RDF-compatible XSD types

[{2021-01-06} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-rdf-vocabulary]

name::
* McsEngl.Rdfvoc'namespace-IRI,
* McsEngl.namespace-IRI@lagRdfw,

abbreviation of namespace-IRI

description::
"In some serialization formats it is common to abbreviate IRIs that start with namespace IRIs by using a namespace prefix in order to assist readability.
For example, the IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral would be abbreviated as rdf:XMLLiteral.
Note however that these abbreviations are not valid IRIs, and must not be used in contexts where IRIs are expected.
Namespace IRIs and namespace prefixes are not a formal part of the RDF data model.
They are merely a syntactic convenience for abbreviating IRIs."
[{2021-01-07} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-rdf-vocabulary]

name::
* McsEngl.Rdfvoc'namespace-IRI'abbreviation,

namespace-prefix of Rdfvoc

description::
"Some namespace IRIs are associated by convention with a short name known as a namespace prefix.
Some examples:"

Namespace prefix Namespace IRI RDF vocabulary
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# The RDF built-in vocabulary [RDF11-SCHEMA]
rdfs http://www.w3.org/2000/01/rdf-schema# The RDF Schema vocabulary [RDF11-SCHEMA]
xsd http://www.w3.org/2001/XMLSchema# The RDF-compatible XSD types

[{2021-01-06} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-rdf-vocabulary]

name::
* McsEngl.Rdfvoc'namespace-prefix,
* McsEngl.namespace-prefix@lagRdfw,

Rdfvoc.SPECIFIC

description::
* Dublin-core,
* FOAF,
* SCOS,
* schema.org,

name::
* McsEngl.Rdfvoc.specific,

Rdfvoc.Dublin-core (link)
Rdfvoc.FOAF (link)
Rdfvoc.schema.org (link)
Rdfvoc.SKOS (link)

output.YAGO of lagRdfw

description::
· YAGO is-stored in RDF.
· combines wikidata and schema.org
"YAGO is a knowledge base, i.e., a database with knowledge about the real world. YAGO contains both entities (such as movies, people, cities, countries, etc.) and relations between these entities (who played in which movie, which city is located in which country, etc.). All in all, YAGO contains more than 50 million entities and 2 billion facts."
[{2021-01-30} https://yago-knowledge.org/getting-started]

name::
* McsEngl.YAGO,

info-resource of lagRdfw

description::
* RDF 1.1 Primer, W3C Working Group Note 24 June 2014, https://www.w3.org/TR/rdf11-primer/,
* RDF 1.1 Concepts and Abstract Syntax, W3C Recommendation 25 February 2014, https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/,
* RDF 1.1 Semantics, W3C Recommendation 25 February 2014, https://www.w3.org/TR/rdf11-mt/,
* RDF Schema 1.1, W3C Recommendation 25 February 2014, https://www.w3.org/TR/rdf-schema/,

name::
* McsEngl.lagRdfw'Infrsc,

evoluting of lagRdfw

lagRdfw.SPECIFIC

description::
* Turtle family of RDF languages (N-Triples, Turtle, TriG and N-Quads),
* JSON-LD (JSON-based RDF syntax),
* RDFa (for HTML and XML embedding),
* RDF/XML (XML syntax for RDF),

name::
* McsEngl.lagRdfw.specific,

lagRdfw.concrete-RDF-syntax

description::
"An RDF document is a document that encodes an RDF graph or RDF dataset in a concrete RDF syntax, such as Turtle [TURTLE], RDFa [RDFA-PRIMER], JSON-LD [JSON-LD], or TriG [TRIG]. RDF documents enable the exchange of RDF graphs and RDF datasets between systems.
A concrete RDF syntax may offer many different ways to encode the same RDF graph or RDF dataset, for example through the use of namespace prefixes, relative IRIs, blank node identifiers, and different ordering of statements. While these aspects can have great effect on the convenience of working with the RDF document, they are not significant for its meaning."
[{2021-01-06} https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-concrete-rdf-syntax]

name::
* McsEngl.lagRdfw.concrete-RDF-syntax,
* McsEngl.lagRdfw.instance,
* McsEngl.concrete-RDF-syntax@lagRdfw,

lagRdfw.JSON-LD (link)

lagRdfw.N-Triples

description::
· example:
01 <http://example.org/bob#me> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://xmlns.com/foaf/0.1/Person> .
02 <http://example.org/bob#me> <http://xmlns.com/foaf/0.1/knows> <http://example.org/alice#me> .
03 <http://example.org/bob#me> <http://schema.org/birthDate> "1990-07-04"^^<http://www.w3.org/2001/XMLSchema#date> .
04 <http://example.org/bob#me> <http://xmlns.com/foaf/0.1/topic_interest> <http://www.wikidata.org/entity/Q12418> .
05 <http://www.wikidata.org/entity/Q12418> <http://purl.org/dc/terms/title> "Mona Lisa" .
06 <http://www.wikidata.org/entity/Q12418> <http://purl.org/dc/terms/creator> <http://dbpedia.org/resource/Leonardo_da_Vinci> .
07 <http://data.europeana.eu/item/04802/243FA8618938F4117025F17A8B813C5F9AA4D619> <http://purl.org/dc/terms/subject> <http://www.wikidata.org/entity/Q12418> .

[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/#section-n-triples]

name::
* McsEngl.N-Triple-lagRdfw,
* McsEngl.lagRdfw.N-Triple,

lagRdfw.Turtle

description::
· example:
01 BASE <http://example.org/>
02 PREFIX foaf: <http://xmlns.com/foaf/0.1/>
03 PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
04 PREFIX schema: <http://schema.org/>
05 PREFIX dcterms: <http://purl.org/dc/terms/>
06 PREFIX wd: <http://www.wikidata.org/entity/>
07
08 <bob#me>
09 a foaf:Person ;
10 foaf:knows <alice#me> ;
11 schema:birthDate "1990-07-04"^^xsd:date ;
12 foaf:topic_interest wd:Q12418 .
13
14 wd:Q12418
15 dcterms:title "Mona Lisa" ;
16 dcterms:creator <http://dbpedia.org/resource/Leonardo_da_Vinci> .
17
18 <http://data.europeana.eu/item/04802/243FA8618938F4117025F17A8B813C5F9AA4D619>
19 dcterms:subject wd:Q12418 .
[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/#section-turtle]

name::
* McsEngl.Turtle-lagRdfw,
* McsEngl.lagRdfw.Turtle,

lagRdfw.TriG

description::
· The syntax of Turtle supports only the specification of single graphs without a means for "naming" them. TriG [TRIG] is an extension of Turtle enabling the specification of multiple graphs in the form of an RDF dataset.
· example:
01 BASE <http://example.org/>
02 PREFIX foaf: <http://xmlns.com/foaf/0.1/>
03 PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
04 PREFIX schema: <http://schema.org/>
05 PREFIX dcterms: <http://purl.org/dc/terms/>
06 PREFIX wd: <http://www.wikidata.org/entity/>
07
08 GRAPH <http://example.org/bob>
09 {
10 <bob#me>
11 a foaf:Person ;
12 foaf:knows <alice#me> ;
13 schema:birthDate "1990-07-04"^^xsd:date ;
14 foaf:topic_interest wd:Q12418 .
15 }
16
17 GRAPH <https://www.wikidata.org/wiki/Special:EntityData/Q12418>
18 {
19 wd:Q12418
20 dcterms:title "Mona Lisa" ;
21 dcterms:creator <http://dbpedia.org/resource/Leonardo_da_Vinci> .
22
23 <http://data.europeana.eu/item/04802/243FA8618938F4117025F17A8B813C5F9AA4D619>
24 dcterms:subject wd:Q12418 .
25 }
26
27 <http://example.org/bob>
28 dcterms:publisher <http://example.org> ;
29 dcterms:rights <http://creativecommons.org/licenses/by/3.0/> .

[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/#section-trig]

name::
* McsEngl.TriG-lagRdfw,
* McsEngl.lagRdfw.TriG,

lagRdfw.N-Quads

description::
"N-Quads [N-QUADS] is a simple extension to N-Triples to enable the exchange of RDF datasets. N-Quads allows one to add a fourth element to a line, capturing the graph IRI of the triple described on that line."
[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/#section-n-quads]

name::
* McsEngl.N-Quads-lagRdfw,
* McsEngl.lagRdfw.N-Quads,

lagRdfw.RDFa

description::
""RDFa [RDFA-PRIMER] is an RDF syntax that can be used to embed RDF data within HTML and XML documents. This enables, for example, search engines to aggregate this data when crawling the Web and use it to enrich search results (see, e.g., schema.org and Rich Snippets).
EXAMPLE 14: RDFa


    
01 <body prefix="foaf: http://xmlns.com/foaf/0.1/
02 schema: http://schema.org/
03 dcterms: http://purl.org/dc/terms/">
04 <div resource="http://example.org/bob#me" typeof="foaf:Person">
05 <p>
06 Bob knows <a property="foaf:knows" href="http://example.org/alice#me">Alice</a>
07 and was born on the <time property="schema:birthDate" datatype="xsd:date">1990-07-04</time>.
08 </p>
09 <p>
10 Bob is interested in <span property="foaf:topic_interest"
11 resource="http://www.wikidata.org/entity/Q12418">the Mona Lisa</span>.
12 </p>
13 </div>
14 <div resource="http://www.wikidata.org/entity/Q12418">
15 <p>
16 The <span property="dcterms:title">Mona Lisa</span> was painted by
17 <a property="dcterms:creator" href="http://dbpedia.org/resource/Leonardo_da_Vinci">Leonardo da Vinci</a>
18 and is the subject of the video
19 <a href="http://data.europeana.eu/item/04802/243FA8618938F4117025F17A8B813C5F9AA4D619">'La Joconde à Washington'</a>.
20 </p>
21 </div>
22 <div resource="http://data.europeana.eu/item/04802/243FA8618938F4117025F17A8B813C5F9AA4D619">
23 <link property="dcterms:subject" href="http://www.wikidata.org/entity/Q12418"/>
24 </div>
25 </body>

The example above contains four special RDFa attributes to enable specification of RDF triples within HTML: resource, property, typeof and prefix."
[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/#section-rdfa]

name::
* McsEngl.RDFa-lagRdfw,
* McsEngl.lagRdfw.RDFa,

lagRdfw.RDF/XML

description::
"RDF/XML [RDF-SYNTAX-GRAMMAR] provides an XML syntax for RDF graphs. When RDF was originally developed in the late 1990s, this was its only syntax, and some people still call this syntax "RDF". In 2001, a precursor to Turtle called "N3" was proposed, and gradually the other languages listed here have been adopted and standardized."
example:


    
01 <?xml version="1.0" encoding="utf-8"?>
02 <rdf:RDF
03 xmlns:dcterms="http://purl.org/dc/terms/"
04 xmlns:foaf="http://xmlns.com/foaf/0.1/"
05 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
06 xmlns:schema="http://schema.org/">
07 <rdf:Description rdf:about="http://example.org/bob#me">
08 <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
09 <schema:birthDate rdf:datatype="http://www.w3.org/2001/XMLSchema#date">1990-07-04</schema:birthDate>
10 <foaf:knows rdf:resource="http://example.org/alice#me"/>
11 <foaf:topic_interest rdf:resource="http://www.wikidata.org/entity/Q12418"/>
12 </rdf:Description>
13 <rdf:Description rdf:about="http://www.wikidata.org/entity/Q12418">
14 <dcterms:title>Mona Lisa</dcterms:title>
15 <dcterms:creator rdf:resource="http://dbpedia.org/resource/Leonardo_da_Vinci"/>
16 </rdf:Description>
17 <rdf:Description rdf:about="http://data.europeana.eu/item/04802/243FA8618938F4117025F17A8B813C5F9AA4D619">
18 <dcterms:subject rdf:resource="http://www.wikidata.org/entity/Q12418"/>
19 </rdf:Description>
20 </rdf:RDF>

[{2021-01-03} https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/#section-rdfxml]

name::
* McsEngl.RDF/XML-lagRdfw,
* McsEngl.lagRdfw.RDF/XML,

lagCnpt.SPARQL-009

description::
"SPARQL (pronounced "sparkle" /ˈspɑːkəl/, a recursive acronym[2] for SPARQL Protocol and RDF Query Language) is an RDF query language—that is, a semantic query language for databases—able to retrieve and manipulate data stored in Resource Description Framework (RDF) format.[3][4] It was made a standard by the RDF Data Access Working Group (DAWG) of the World Wide Web Consortium, and is recognized as one of the key technologies of the semantic web.[citation needed] On 15 January 2008, SPARQL 1.0 was acknowledged by W3C as an official recommendation,[5][6] and SPARQL 1.1 in March, 2013.[7]
SPARQL allows for a query to consist of triple patterns, conjunctions, disjunctions, and optional patterns.[8]
Implementations for multiple programming languages exist.[9] There exist tools that allow one to connect and semi-automatically construct a SPARQL query for a SPARQL endpoint, for example ViziQuer.[10] In addition, tools exist to translate SPARQL queries to other query languages, for example to SQL[11] and to XQuery.[12]"
[{2021-01-05} https://en.wikipedia.org/wiki/SPARQL]

name::
* McsEngl.SPARQL!⇒lagSprq,
* McsEngl.lagCnpt.009-SPARQL!⇒lagSprq,
* McsEngl.lagCnpt.SPARQL!⇒lagSprq,
* McsEngl.lagSprq,
* McsEngl.lagSprg'(SPARQL)!⇒lagSprq,

lagCnpt.XML-010

description::
· XML is a-markup-language that can-model conceptual-views human and machine-readable.

name::
* McsEngl.XML'(extensible-markup-language)!⇒lagXmlg,
* McsEngl.lagCnpt.010-XML!⇒lagXmlg,
* McsEngl.lagCnpt.XML!⇒lagXmlg,
* McsEngl.lagXmlg,
* McsEngl.lagXmlg'(extensible-markup-language)!⇒lagXmlg,

descriptionLong::
"The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document.
Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML.
XML has been designed for ease of implementation and for interoperability with both SGML and HTML."
[{2021-01-11} https://www.w3.org/TR/2006/REC-xml11-20060816/]
===
"Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. The World Wide Web Consortium's XML 1.0 Specification[2] of 1998[3] and several other related specifications[4]—all of them free open standards—define XML.[5]
The design goals of XML emphasize simplicity, generality, and usability across the Internet.[6] It is a textual data format with strong support via Unicode for different human languages. Although the design of XML focuses on documents, the language is widely used for the representation of arbitrary data structures[7] such as those used in web services.
Several schema systems exist to aid in the definition of XML-based languages, while programmers have developed many application programming interfaces (APIs) to aid the processing of XML data."

machine of lagXmlg

description::
· any computer.

name::
* McsEngl.lagXmlg'machine,

input of lagXmlg

description::
· lagXmlg maps simple conceptual-views eg a-person[a] with some attributes of it[a].

name::
* McsEngl.lagXmlg'input,

output of lagXmlg

description::
· the-output is a-markup-document with Xmlelements denoting concepts or attributes of concepts.

name::
* McsEngl.Xmldoc,
* McsEngl.lagXmlg'instance-document!⇒Xmldoc,
* McsEngl.lagXmlg'output!⇒Xmldoc,

entity of Xmldoc

description::
"Physically, the document is composed of units called entities. An entity may refer to other entities to cause their inclusion in the document. A document begins in a "root" or document entity."
[{2021-01-11} https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-documents]

name::
* McsEngl.Xmldoc'entity!⇒Xmlentity,

Xmlentity.root of Xmldoc

description::
"[Definition: The document entity serves as the root of the entity tree and a starting-point for an XML processor.] This specification does not specify how the document entity is to be located by an XML processor; unlike other entities, the document entity has no name and might well appear on a processor input stream without any identification at all."
[{2021-01-11} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-docent]

name::
* McsEngl.Xmldoc'document-entity,
* McsEngl.Xmldocument-entity,
* McsEngl.Xmlentity.document,
* McsEngl.Xmlentity.root,

Xmlentity.parsed of Xmldoc

description::
"Entities may be either parsed or unparsed.
[Definition: The contents of a parsed entity are referred to as its replacement text; this text is considered an integral part of the document.]"
[{2021-01-13} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-parsedent]

name::
* McsEngl.Xmlentity.parsed,

Xmlentity.unparsed of Xmldoc

description::
"[Definition: An unparsed entity is a resource whose contents may or may not be text, and if text, may be other than XML. Each unparsed entity has an associated notation, identified by name. Beyond a requirement that an XML processor make the identifiers for the entity and notation available to the application, XML places no constraints on the contents of unparsed entities.]"
[{2021-01-13} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-unparsed]

name::
* McsEngl.Xmlentity.unparsed,

text of Xmldoc

description::
"Definition: A parsed entity contains text, a sequence of characters, which may represent markup or character data."
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-text]

name::
* McsEngl.Xmldoc'text!⇒Xmltext,
* McsEngl.Xmltext,

character of Xmldoc

description::
"Definition: A character is an atomic unit of text as specified by ISO/IEC 10646 [ISO/IEC 10646].
Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646. ..Character Range
[2] Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */
[2a] RestrictedChar ::= [#x1-#x8] | [#xB-#xC] | [#xE-#x1F] | [#x7F-#x84] | [#x86-#x9F]
The mechanism for encoding character code points into bit patterns may vary from entity to entity. "
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-character]

name::
* McsEngl.Xmlchar,
* McsEngl.Xmldoc'character!⇒Xmlchar,
* McsEngl.Xmltext'character!⇒Xmlchar,
* McsEngl.character//XML!⇒Xmlchar,

Xmlchar.whitespace

description::
"S (white space) consists of one or more space (#x20) characters, carriage returns, line feeds, or tabs.
White Space
[3] S ::= (#x20 | #x9 | #xD | #xA)+
Note:
The presence of #xD in the above production is maintained purely for backward compatibility with the First Edition. As explained in 2.11 End-of-Line Handling, all #xD characters literally present in an XML document are either removed or replaced by #xA characters before any other processing is done. The only way to get a #xD character to match this production is to use a character reference in an entity value literal."
[{2021-01-13} https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-common-syn]

name::
* McsEngl.Xmlchar.whitespace,

Xmlchar.name

description::
"[Definition: A Name is a token beginning with a letter or one of a few punctuation characters, and continuing with letters, digits, hyphens, underscores, colons, or full stops, together known as name characters.] Names beginning with the string "xml", or with any string which would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in this or future versions of this specification.
Note:
The Namespaces in XML Recommendation [XML Names] assigns a meaning to names containing colon characters. Therefore, authors should not use the colon in XML names except for namespace purposes, but XML processors must accept the colon as a name character.
... Names and Tokens
[4] NameStartChar ::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
[4a] NameChar ::= NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
[5] Name ::= NameStartChar (NameChar)*
[6] Names ::= Name (#x20 Name)*
[7] Nmtoken ::= (NameChar)+
[8] Nmtokens ::= Nmtoken (#x20 Nmtoken)*"
[{2021-01-13} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-name]

name::
* McsEngl.Xmlchar.name!⇒Xmlname,
* McsEngl.Xmlname,

Xmlchar.namespace

description::
"Definition: An XML namespace is identified by a URI reference [RFC3986]; element and attribute names may be placed in an XML namespace using the mechanisms described in this specification."
[{2021-01-13} https://www.w3.org/TR/2009/REC-xml-names-20091208/#dt-namespace]

name::
* McsEngl.Xmlchar.namespace!⇒Xmlnamespace,
* McsEngl.Xmlnamespace,
* McsEngl.namespace//XML,

Xmlnamespace'name

description::
"[Definition: An expanded name is a pair consisting of a namespace name and a local name. ]
[Definition: For a name N in a namespace identified by a URI I, the namespace name is I. For a name N that is not in a namespace, the namespace name has no value. ]
[Definition: In either case the local name is N. ]
It is this combination of the universally managed URI namespace with the vocabulary's local names that is effective in avoiding name clashes."
[{2021-01-13} https://www.w3.org/TR/2009/REC-xml-names-20091208/#dt-namespace]

name::
* McsEngl.Xmlnamespace'name,
* McsEngl.namespace-name//XML,

Xmlchar.expanded-name

description::
"[Definition: An expanded name is a pair consisting of a namespace name and a local name. ]
[Definition: For a name N in a namespace identified by a URI I, the namespace name is I. For a name N that is not in a namespace, the namespace name has no value. ]
[Definition: In either case the local name is N. ]
It is this combination of the universally managed URI namespace with the vocabulary's local names that is effective in avoiding name clashes."
[{2021-01-13} https://www.w3.org/TR/2009/REC-xml-names-20091208/#dt-namespace]

name::
* McsEngl.Xmlchar.expanded-name,
* McsEngl.expanded-name//XML,

Xmlchar.local-name

description::
"[Definition: An expanded name is a pair consisting of a namespace name and a local name. ]
[Definition: For a name N in a namespace identified by a URI I, the namespace name is I. For a name N that is not in a namespace, the namespace name has no value. ]
[Definition: In either case the local name is N. ]
It is this combination of the universally managed URI namespace with the vocabulary's local names that is effective in avoiding name clashes."
[{2021-01-13} https://www.w3.org/TR/2009/REC-xml-names-20091208/#dt-namespace]

name::
* McsEngl.Xmlchar.local-name,
* McsEngl.local-name//XML,

Xmlchar.qualified-name

description::
"URI references can contain characters not allowed in names, and are often inconveniently long, so expanded names are not used directly to name elements and attributes in XML documents. Instead qualified names are used.
[Definition: A qualified name is a name subject to namespace interpretation. ]
In documents conforming to this specification, element and attribute names appear as qualified names. Syntactically, they are either prefixed names or unprefixed names. An attribute-based declaration syntax is provided to bind prefixes to namespace names and to bind a default namespace that applies to unprefixed element names; these declarations are scoped by the elements on which they appear so that different bindings may apply in different parts of a document. Processors conforming to this specification MUST recognize and act on these declarations and prefixes.
... In XML documents conforming to this specification, some names (constructs corresponding to the nonterminal Name) MUST be given as qualified names, defined as follows:

Qualified Name
[7] QName ::= PrefixedName | UnprefixedName
[8] PrefixedName ::= Prefix ':' LocalPart
[9] UnprefixedName ::= LocalPart
[10] Prefix ::= NCName
[11] LocalPart ::= NCName
The Prefix provides the namespace prefix part of the qualified name, and MUST be associated with a namespace URI reference in a namespace declaration. [Definition: The LocalPart provides the local part of the qualified name.]
Note that the prefix functions only as a placeholder for a namespace name. Applications SHOULD use the namespace name, not the prefix, in constructing names whose scope extends beyond the containing document.
[{2021-01-13} https://www.w3.org/TR/2009/REC-xml-names-20091208/#dt-qualname]

name::
* McsEngl.Xmlcha.qualified-name,
* McsEngl.qualified-name//XML,

markup of Xmldoc

description::
"Definition: Markup takes the form of start-tags, end-tags, empty-element tags, entity references, character references, comments, CDATA section delimiters, document type declarations, processing instructions, XML declarations, text declarations, and any white space that is at the top level of the document entity (that is, outside the document element and not inside any other markup)."
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-markup]

name::
* McsEngl.Xmldoc'markup!⇒Xmlmarkup,
* McsEngl.Xmlmarkup,

Xmlmarkup.tagStart

description::
"Definition: The beginning of every non-empty XML element is marked by a start-tag."
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-stag]

name::
* McsEngl.Xmldoc'start-tag,
* McsEngl.Xmldoc'tagStart,
* McsEngl.Xmlmarkup.tagStart,

Xmlmarkup.tagEnd

description::
"[Definition: The end of every element that begins with a start-tag must be marked by an end-tag containing a name that echoes the element's type as given in the start-tag:]
End-tag
[42] ETag ::= '</' Name S? '>'
An example of an end-tag:
</termdef>"
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-etag]

name::
* McsEngl.Xmldoc'end-tag,
* McsEngl.Xmldoc'tagEnd,
* McsEngl.Xmlmarkup.tagEnd,

Xmlmarkup.tagEmpty

description::
"[Definition: An element with no content is said to be empty.] The representation of an empty element is either a start-tag immediately followed by an end-tag, or an empty-element tag. [Definition: An empty-element tag takes a special form:]
Tags for Empty Elements
[44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>' [WFC: Unique Att Spec]
Empty-element tags may be used for any element which has no content, whether or not it is declared using the keyword EMPTY. For interoperability, the empty-element tag should be used, and should only be used, for elements which are declared EMPTY.
Examples of empty elements:
<IMG align="left" src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/>"
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-empty]

name::
* McsEngl.Xmldoc'empty-tag,
* McsEngl.Xmldoc'tagEmpty,
* McsEngl.Xmlmarkup.tagEmpty,

Xmlmarkup.referenceEntity

description::
"[Definition: An entity reference refers to the content of a named entity.]
[Definition: References to parsed general entities use ampersand (&) and semicolon (;) as delimiters.]
[Definition: Parameter-entity references use percent-sign (%) and semicolon (;) as delimiters.]"
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-entref]

name::
* McsEngl.Xmldoc'entity-reference,
* McsEngl.Xmldoc'referenceEntity,
* McsEngl.Xmlmarkup.referenceEntity,

Xmlmarkup.referenceCharacter

description::
"[Definition: A character reference refers to a specific character in the ISO/IEC 10646 character set, for example one not directly accessible from available input devices.]"
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-charref]

name::
* McsEngl.Xmldoc'character-reference,
* McsEngl.Xmldoc'referenceCharacter,
* McsEngl.Xmlmarkup.referenceCharacter,

Xmlmarkup.comment

description::
"[Definition: Comments may appear anywhere in a document outside other markup; in addition, they may appear within the document type declaration at places allowed by the grammar. They are not part of the document's character data; an XML processor may, but need not, make it possible for an application to retrieve the text of comments. For compatibility, the string "--" (double-hyphen) must not occur within comments.] Parameter entity references must not be recognized within comments.
Comments
[15] Comment ::= '<!--' ((Char - '-') | ('-' (Char - '-')))* '-->'
An example of a comment:
<!-- declarations for <head> & <body> -->
Note that the grammar does not allow a comment ending in --->. The following example is not well-formed.
<!-- B+, B, or B--->"
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-comment]

name::
* McsEngl.Xmlmarkup.comment,

Xmlmarkup.CDATA-section-delimiter

description::
"Definition: CDATA sections may occur anywhere character data may occur; they are used to escape blocks of text containing characters which would otherwise be recognized as markup. CDATA sections begin with the string "<![CDATA[" and end with the string "]]>":]
CDATA Sections
[18] CDSect ::= CDStart CData CDEnd
[19] CDStart ::= '<![CDATA['
[20] CData ::= (Char* - (Char* ']]>' Char*))
[21] CDEnd ::= ']]>'
Within a CDATA section, only the CDEnd string is recognized as markup, so that left angle brackets and ampersands may occur in their literal form; they need not (and cannot) be escaped using "<" and "&". CDATA sections cannot nest.
An example of a CDATA section, in which "<greeting>" and "</greeting>" are recognized as character data, not markup:
<![CDATA[<greeting>Hello, world!</greeting>]]>"
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-cdsection]

name::
* McsEngl.Xmldoc'CDATA-section-delimiter,
* McsEngl.Xmlmarkup.CDATA-section-delimiter,

Xmlmarkup.declarationDocument-type

description::
"Definition: The XML document type declaration contains or points to markup declarations that provide a grammar for a class of documents. This grammar is known as a document type definition, or DTD. The document type declaration can point to an external subset (a special kind of external entity) containing markup declarations, or can contain the markup declarations directly in an internal subset, or can do both. The DTD for a document consists of both subsets taken together."
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-doctype]

name::
* McsEngl.Xmldoc'declarationDocument-type,
* McsEngl.Xmldoc'document-type-declaration,
* McsEngl.Xmlmarkup.declarationDocument-type,

Xmlmarkup.declarationXml

description::
· example: <?xml version="1.1"?>

name::
* McsEngl.Xmldoc'declarationXml,
* McsEngl.Xmldoc'Xml-declaration,
* McsEngl.Xmlmarkup.declarationXml,

Xmlmarkup.declarationText

description::
"External parsed entities should each begin with a text declaration.
Text Declaration
[77] TextDecl ::= '<?xml' VersionInfo? EncodingDecl S? '?>'
The text declaration must be provided literally, not by reference to a parsed entity. The text declaration must not appear at any position other than the beginning of an external parsed entity. The text declaration in an external parsed entity is not considered part of its replacement text."
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#NT-TextDecl]

name::
* McsEngl.Xmldoc'declarationText,
* McsEngl.Xmldoc'text-declaration,
* McsEngl.Xmlmarkup.declarationText,

Xmlmarkup.processing-instruction

description::
"[Definition: Processing instructions (PIs) allow documents to contain instructions for applications.]
Processing Instructions
[16] PI ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
[17] PITarget ::= Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))
PIs are not part of the document's character data, but must be passed through to the application. The PI begins with a target (PITarget) used to identify the application to which the instruction is directed. The target names "XML", "xml", and so on are reserved for standardization in this or future versions of this specification. The XML Notation mechanism may be used for formal declaration of PI targets. Parameter entity references must not be recognized within processing instructions."
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-pi]

name::
* McsEngl.Xmldoc'processing-instruction!⇒Xmlpi,
* McsEngl.Xmlmarkup.processing-instruction!⇒Xmlpi,
* McsEngl.Xmlpi,

character-data of Xmldoc

description::
"Definition: All text that is not markup constitutes the character data of the document."
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-chardata]

name::
* McsEngl.Xmldoc'character-data,

element of Xmldoc

description::
"Definition: Each XML document contains one or more elements, the boundaries of which are either delimited by start-tags and end-tags, or, for empty elements, by an empty-element tag. Each element has a type, identified by name, sometimes called its "generic identifier" (GI), and may have a set of attribute specifications."
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-element]

name::
* McsEngl.Xmldoc'element!⇒Xmlelement,
* McsEngl.Xmlelement,
* McsEngl.element//XML,

name of Xmlelement

description::
·

name::
* McsEngl.Xmlelement'name,

attribute of Xmlelement

description::
"Definition: The Name-AttValue pairs are referred to as the attribute specifications of the element"
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-attr]

name::
* McsEngl.Xmlelement'attribute,

content of Xmlelement

description::
"[Definition: The text between the start-tag and end-tag is called the element's content:]
Content of Elements
[43] content ::= CharData? ((element | Reference | CDSect | PI | Comment) CharData?)*"
[{2021-01-13} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-content]

name::
* McsEngl.Xmlelement'content,

Xmlelement.root

description::
"[Definition: There is exactly one element, called the root, or document element, no part of which appears in the content of any other element.] For all other elements, if the start-tag is in the content of another element, the end-tag is in the content of the same element. More simply stated, the elements, delimited by start- and end-tags, nest properly within each other."
[{2021-01-13} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-root]

name::
* McsEngl.Xmlelement.document,
* McsEngl.Xmlelement.root,

Xmlelement.parent-of-e

description::
"[Definition: As a consequence of this, for each non-root element C in the document, there is one other element P in the document such that C is in the content of P, but is not in the content of any other element that is in the content of P. P is referred to as the parent of C, and C as a child of P.]"
[{2021-01-13} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-parentchild]

name::
* McsEngl.Xmlelement.parent-of-e,

Xmlelement.child-of-e

description::
"[Definition: As a consequence of this, for each non-root element C in the document, there is one other element P in the document such that C is in the content of P, but is not in the content of any other element that is in the content of P. P is referred to as the parent of C, and C as a child of P.]"
[{2021-01-13} https://www.w3.org/TR/2006/REC-xml11-20060816/#dt-parentchild]

name::
* McsEngl.Xmlelement.child-of-e,

schema of Xmldoc

description::
· Xmlschema is a-document that describes the-structure of an-Xmldoc expressed in a-lagCnpt.

name::
* McsEngl.Xmldoc'schema!⇒Xmlschema,
* McsEngl.Xmlschema,

descriptionLong::
"The purpose of a schema is to define a class of XML documents, and so the term "instance document" is often used to describe an XML document that conforms to a particular schema."
[{2021-01-13} https://www.w3.org/TR/xmlschema-0/#PO]

Xmlschema.SPECIFIC

description::
"There are languages developed specifically to express XML schemas. The document type definition (DTD) language, which is native to the XML specification, is a schema language that is of relatively limited capability, but that also has other uses in XML aside from the expression of schemas. Two more expressive XML schema languages in widespread use are XML Schema (with a capital S) and RELAX NG."
[{2021-01-14} https://en.wikipedia.org/wiki/XML_schema]

name::
* McsEngl.Xmlschema.specific,

Xmlschema.XML-Schema

description::
· XML-Schema is an-Xmlschema created by W3C after DTD.

name::
* McsEngl.XML-Schema!⇒xsd,
* McsEngl.xsd,
* McsEngl.xsd'(XML-Schema)!⇒xsd,
* McsEngl.Xmlschema.XML-Schema!⇒xsd,

XML-Schema-language of xsd

description::
· the-language in which an-xsd is-written.
· it is an-XML-language.
===
"There are several different languages available for specifying an XML schema. Each language has its strengths and weaknesses.
The primary purpose of a schema language is to specify what the structure of an XML document can be. This means which elements can reside in which other elements, which attributes are and are not legal to have on a particular element, and so forth. A schema is analogous to a grammar for a language; a schema defines what the vocabulary for the language may be and what a valid "sentence" is."
[{2021-01-14} https://en.wikipedia.org/wiki/XML_schema]

name::
* McsEngl.XML-Schema-language!⇒lagXsdl,
* McsEngl.lagXsdl,
* McsEngl.lagXsdl'(XML-Schema-language)!⇒lagXsdl,
* McsEngl.xsd'language!⇒lagXsdl,

addressWpg::
* https://www.w3.org/TR/xmlschema11-1/,
* https://www.w3.org/TR/xmlschema11-2/,

schema-element of xsd

description::
· example:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
...
</xsd:schema>

name::
* McsEngl.xsd'schema-element!⇒xsd:schema,
* McsEngl.xsd:schema,

element-element of xsd

description::
· example:
<xsd:element name="street" type="xsd:string"/>

name::
* McsEngl.xsd:element-element,

attribute-element of xsd

description::
· example:
<xsd:attribute name="country" type="xsd:NMTOKEN" fixed="US"/>

name::
* McsEngl.xsd:attribute-element,

complexType-element of xsd

description::
· example:
"<xsd:complexType name="USAddress" >
 <xsd:sequence>
   <xsd:element name="name" type="xsd:string"/>
   <xsd:element name="street" type="xsd:string"/>
   <xsd:element name="city" type="xsd:string"/>
   <xsd:element name="state" type="xsd:string"/>
   <xsd:element name="zip" type="xsd:decimal"/>
 </xsd:sequence>
 <xsd:attribute name="country" type="xsd:NMTOKEN" fixed="US"/>
</xsd:complexType>

The consequence of this definition is that any element appearing in an instance whose type is declared to be USAddress (e.g. shipTo in po.xml) must consist of five elements and one attribute. These elements must be called name, street, city, state and zip as specified by the values of the declarations' name attributes, and the elements must appear in the same sequence (order) in which they are declared. The first four of these elements will each contain a string, and the fifth will contain a number. The element whose type is declared to be USAddress may appear with an attribute called country which must contain the string US.
... In XML Schema, there is a basic difference between complex types which allow elements in their content and may carry attributes, and simple types which cannot have element content and cannot carry attributes."
[{2021-01-14} https://www.w3.org/TR/xmlschema-0/#DefnDeclars]

name::
* McsEngl.xsd-compleType-element,

simpleType-element of xsd

description::
· example:
<xsd:simpleType name="SKU">
 <xsd:restriction base="xsd:string">
   <xsd:pattern value="\d{3}-[A-Z]{2}"/>
 </xsd:restriction>
</xsd:simpleType>

"simple types which cannot have element content and cannot carry attributes."
[{2021-01-14} https://www.w3.org/TR/xmlschema-0/#DefnDeclars]

name::
* McsEngl.xsd:simpleType-element,

xsd.example

description::

"Example
    The Purchase Order Schema, po.xsd
    <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

      <xsd:annotation>
        <xsd:documentation xml:lang="en">
         Purchase order schema for Example.com.
         Copyright 2000 Example.com. All rights reserved.
        </xsd:documentation>
      </xsd:annotation>

      <xsd:element name="purchaseOrder" type="PurchaseOrderType"/>

      <xsd:element name="comment" type="xsd:string"/>

      <xsd:complexType name="PurchaseOrderType">
        <xsd:sequence>
          <xsd:element name="shipTo" type="USAddress"/>
          <xsd:element name="billTo" type="USAddress"/>
          <xsd:element ref="comment" minOccurs="0"/>
          <xsd:element name="items"  type="Items"/>
        </xsd:sequence>
        <xsd:attribute name="orderDate" type="xsd:date"/>
      </xsd:complexType>

      <xsd:complexType name="USAddress">
        <xsd:sequence>
          <xsd:element name="name"   type="xsd:string"/>
          <xsd:element name="street" type="xsd:string"/>
          <xsd:element name="city"   type="xsd:string"/>
          <xsd:element name="state"  type="xsd:string"/>
          <xsd:element name="zip"    type="xsd:decimal"/>
        </xsd:sequence>
        <xsd:attribute name="country" type="xsd:NMTOKEN"
                       fixed="US"/>
      </xsd:complexType>

      <xsd:complexType name="Items">
        <xsd:sequence>
          <xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="productName" type="xsd:string"/>
                <xsd:element name="quantity">
                  <xsd:simpleType>
                    <xsd:restriction base="xsd:positiveInteger">
                      <xsd:maxExclusive value="100"/>
                    </xsd:restriction>
                  </xsd:simpleType>
                </xsd:element>
                <xsd:element name="USPrice"  type="xsd:decimal"/>
                <xsd:element ref="comment"   minOccurs="0"/>
                <xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
              </xsd:sequence>
              <xsd:attribute name="partNum" type="SKU" use="required"/>
            </xsd:complexType>
          </xsd:element>
        </xsd:sequence>
      </xsd:complexType>

      <!-- Stock Keeping Unit, a code for identifying products -->
      <xsd:simpleType name="SKU">
        <xsd:restriction base="xsd:string">
          <xsd:pattern value="\d{3}-[A-Z]{2}"/>
        </xsd:restriction>
      </xsd:simpleType>

    </xsd:schema>

    of
    The Purchase Order, po.xml
    <?xml version="1.0"?>
    <purchaseOrder orderDate="1999-10-20">
       <shipTo country="US">
          <name>Alice Smith</name>
          <street>123 Maple Street</street>
          <city>Mill Valley</city>
          <state>CA</state>
          <zip>90952</zip>
       </shipTo>
       <billTo country="US">
          <name>Robert Smith</name>
          <street>8 Oak Avenue</street>
          <city>Old Town</city>
          <state>PA</state>
          <zip>95819</zip>
       </billTo>
       <comment>Hurry, my lawn is going wild</comment>
       <items>
          <item partNum="872-AA">
             <productName>Lawnmower</productName>
             <quantity>1</quantity>
             <USPrice>148.95</USPrice>
             <comment>Confirm this is electric</comment>
          </item>
          <item partNum="926-AA">
             <productName>Baby Monitor</productName>
             <quantity>1</quantity>
             <USPrice>39.98</USPrice>
             <shipDate>1999-05-21</shipDate>
          </item>
       </items>
    </purchaseOrder>"

[{2021-01-14} https://www.w3.org/TR/xmlschema-0/#POSchema]

name::
* McsEngl.xsd.example,

Xmlschema.DTD

description::
· an-XmlDtd is an-Xmlschema, the-first created by W3C.
===
"A DTD defines the valid building blocks of an XML document.
It defines the document structure with a list of validated elements and attributes.
A DTD can be declared inline inside an XML document, or as an external reference.[1]
XML uses a subset of SGML DTD.
As of 2009, newer XML namespace-aware schema languages (such as W3C XML Schema and ISO RELAX NG) have largely superseded DTDs. A namespace-aware version of DTDs is being developed as Part 9 of ISO DSDL. DTDs persist in applications that need special publishing characters, such as the XML and HTML Character Entity References, which derive from larger sets defined as part of the ISO SGML standard effort."
[{2021-01-12} https://en.wikipedia.org/wiki/Document_type_definition]

name::
* McsEngl.DTD-of-lagXmlg!⇒XmlDtd,
* McsEngl.Xmldoc'DTD!⇒XmlDtd,
* McsEngl.XmlDtd,
* McsEngl.XmlDtd'(DTD-for-XML)!⇒XmlDtd,
* McsEngl.lagXmlg'DTD!⇒XmlDtd,

addressWpg::
* https://en.wikipedia.org/wiki/Document_type_definition,

security of XmlDtd

description::
"An XML DTD can be used to create a denial of service (DoS) attack by defining nested entities that expand exponentially, or by sending the XML parser to an external resource that never returns.[10]
For this reason, .NET Framework provides a property that allows prohibiting or skipping DTD parsing,[10] and recent versions of Microsoft Office applications (Microsoft Office 2010 and higher) refuse to open XML files that contain DTD declarations."
[{2021-01-12} https://en.wikipedia.org/wiki/Document_type_definition#Security]

name::
* McsEngl.XmlDtd'security,

evaluation of lagXmlg

description::
·

name::
* McsEngl.lagXmlg'evaluation,

relation-to-lagJson (link) of lagXmlg

relation-to-lagHtml of lagXmlg

description::
"XML differs from HTML in three major respects:
1. Information providers can define new tag and attribute names at will.
2. Document structures can be nested to any level of complexity.
3. Any XML document can contain an optional description of its grammar for use by applications that need to perform structural validation.
[Bosak-{1997-03-10}]

name::
* McsEngl.lagXmlg'relation-to-HTML,
* McsEngl.lagHtml'relation-to-XML,

tool of lagXmlg

description::
·

name::
* McsEngl.lagXmlg'tool,

info-resource of lagXmlg

description::
* https://relaxng.org/, a-schema-language for Xmlg,

name::
* McsEngl.lagXmlg'Infrsc,

specification of lagXmlg

description::
* Extensible Markup Language (XML) 1.1 (Second Edition), W3C Recommendation 16 August 2006, edited in place 29 September 2006, https://www.w3.org/TR/xml11/,
* Namespaces in XML 1.0 (Third Edition), W3C Recommendation 8 December 2009, https://www.w3.org/TR/REC-xml-names/,
* XML Schema Part 0: Primer Second Edition, W3C Recommendation 28 October 2004, https://www.w3.org/TR/xmlschema-0/,
* W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures, W3C Recommendation 5 April 2012, https://www.w3.org/TR/xmlschema11-1/,
* W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes, W3C Recommendation 5 April 2012, https://www.w3.org/TR/xmlschema11-2/,

name::
* McsEngl.Xmlspec,
* McsEngl.lagXmlg'specification!⇒Xmlspec,

DOING of lagXmlg

description::
* parsing,
* validating,

name::
* McsEngl.lagXmlg'doing,

validating of lagXmlg

description::
"The process of checking to see if a XML document conforms to a schema is called validation, which is separate from XML's core concept of syntactic well-formedness. All XML documents must be well-formed, but it is not required that a document be valid unless the XML parser is "validating", in which case the document is also checked for conformance with its associated schema. DTD-validating parsers are most common, but some support XML Schema or RELAX NG as well.
Validation of an instance document against a schema can be regarded as a conceptually separate operation from XML parsing. In practice, however, many schema validators are integrated with an XML parser."
[{2021-01-14} https://en.wikipedia.org/wiki/XML_schema#Validation]

name::
* McsEngl.lagXmlg'validating,

evoluting of lagXmlg

{2012-04}-XML-Schema-1.1::
"XSD 1.1 became a W3C Recommendation in April 2012, which means it is an approved W3C specification."
[{2021-01-14} https://en.wikipedia.org/wiki/XML_Schema_(W3C)]

{2001-05}-XML-Schema::
"XML Schema, published as a W3C recommendation in May 2001,[2] is one of several XML schema languages. It was the first separate schema language for XML to achieve Recommendation status by the W3C. Because of confusion between XML Schema as a specific W3C specification, and the use of the same term to describe schema languages in general, some parts of the user community referred to this language as WXS, an initialism for W3C XML Schema, while others referred to it as XSD, an initialism for XML Schema Definition.[3][4] In Version 1.1 the W3C has chosen to adopt XSD as the preferred name, and that is the name used in this article."
* McsEngl.{lagCnpt'2001-05}-XML-Schema,
[{2021-01-14} https://en.wikipedia.org/wiki/XML_Schema_(W3C)]

{1996}-XML-creation::
"XML was developed by an XML Working Group (originally known as the SGML Editorial Review Board) formed under the auspices of the World Wide Web Consortium (W3C) in 1996. It was chaired by Jon Bosak of Sun Microsystems with the active participation of an XML Special Interest Group (previously known as the SGML Working Group) also organized by the W3C. The membership of the XML Working Group is given in an appendix. Dan Connolly served as the Working Group's contact with the W3C."
* McsEngl.{lagCnpt'1996}-XML-creation,
[{2021-01-12} https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-origin-goals]

name::
* McsEngl.lagXmlg'evoluting,

lagXmlg.SPECIFIC

description::
·

name::
* McsEngl.lagXmlg.specific,

addressWpg::
* https://en.wikipedia.org/wiki/List_of_XML_markup_languages,
* https://en.wikipedia.org/wiki/List_of_types_of_XML_schemas,

lagCnpt.CycL-036

description::
"CycL is Cyc's large and extraordinarily flexible knowledge representation language.
It is essentially an augmentation of first-order predicate calculus (FOPC), with extensions to handle equality, default reasoning, skolemization, and some second-order features.
(For example, quantification over predicates is allowed in some circumstances, and complete assertions can appear as intensional components of other assertions.)
CycL uses a form of circumscription, includes the unique names assumption, and can make use of the closed world assumption where appropriate."
[{2014-02-05} http://www.cyc.com/cyc/cycl]

name::
* McsEngl.CycL!⇒lagCycl,
* McsEngl.lagCnpt.036-CycL!⇒lagCycl,
* McsEngl.lagCnpt.CycL!⇒lagCycl,
* McsEngl.lagCycl,
* McsEngl.lagLogic.CycL!⇒lagCycl,

descriptionLong::
"CycL in computer science and artificial intelligence is an ontology language used by Doug Lenat's Cyc artificial intelligence project. Ramanathan V. Guha was instrumental in the design of early versions of the language. There is a close variant of CycL known as MELD.
The original version of CycL was a frame language, but the modern version is not. Rather, it is a declarative language based on classical first-order logic, with extensions for modal operators and higher order quantification.
CycL is used to represent the knowledge stored in the Cyc Knowledge Base, available from Cycorp. The source code written in CycL released with the OpenCyc system is licensed as open source, to increase its usefulness in supporting the semantic web."
[{2021-02-08} https://en.wikipedia.org/wiki/CycL]
===
"CycL is a formal language whose syntax derives from first-order predicate calculus (the language of formal logic). In order to express common sense knowledge, however, it goes far beyond first order logic."
[{1998-02-26} http://www.cyc.com/cyc-2-1/ref/cycl-syntax.html,{1997-08-08}]

tech of lagCycl

description::
· any tech used.

name::
* McsEngl.lagCycl'tech,

app of lagCycl

description::
· the-application that stores and reasons the-Cyclkb.

name::
* McsEngl.CYC!⇒Cycapp,
* McsEngl.Cyc!⇒Cycapp,
* McsEngl.Cycapp,
* McsEngl.lagCycl'app!⇒Cycapp,

descriptionLong::
"The platform consists of four foundational components that work together to enable our clients to address meaningful business challenges in ways never before possible:
* A formal knowledge representation language with the same expressive power as English. The expressiveness of Cyc’s knowledge representation is a powerful differentiator, enabling the system to fully and systematically represent the unique judgments, perspectives, and problem-solving approaches of your very best performers.
* A pre-existing knowledge base primed with tens of millions of rules-of-thumb and rules of good judgment spanning common sense, domain knowledge, and a general understanding of “how the world works.” Cyc’s ever-growing knowledge base is the broadest, deepest, and most complete AI tool ever developed, by several orders of magnitude.
* A battery of more than 1,100 stylized “inference engines” which work to intelligently and efficiently produce the same hypotheses, insights, and conclusions that a subject matter expert would, given a set of data and findings in an application area.
* Out-of-the-box mechanisms to connect Cyc’s ontology, your internal systems, and useful third-party data sources. This virtual data integration eliminates the need for brittle, expensive, and time-consuming traditional system integration."
[{2021-02-11} https://www.cyc.com/products]

user-interface of Cycapp

description::
· the-part of the-app that handles the-human–machine interaction.

name::
* McsEngl.Cycapp'user-interface!⇒Cycui,
* McsEngl.Cycui,

Cycui.frame-based

description::
"A frame-based display can present representations which are frame-based (a series of slots with values), or which are isomorphic to frames. For example, some CYC® interfaces use a frame-based display method for showing the binary predicates the displayed concept is a first argument to."
[{2021-02-13} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#frame-based]

name::
* McsEngl.Cycui.frame-based,

browser of Cycapp

server of Cycapp

DOING of Cycapp

description::
"There have been over 100 successful applications of Cyc;[17]"
[{2021-02-11} https://en.wikipedia.org/wiki/Cyc#Applications]

name::
* McsEngl.Cycapp'doing!⇒Cycdoing,
* McsEngl.Cycdoing,

Cycdoing.ASK of Cycapp

description::
"The purpose of an ASK operation is to query a CYC® Server about the truth of a formula.
The details of an ASK operation vary from interface to interface. However, in most interfaces you will be asked to supply:
* A CycL formula, which may or may not contain free variables. If the formula contains variables, then you are asking CYC® to supply bindings to those variables which make the formula true; otherwise, you are simply asking whether the formula is true.
* A microtheory within which to look. In other words, each binding returned must come from a formula which is known to be true in, or can be inferred from assertions in, the specified microtheory and its baseMts.
* Optionally, a direction (or access level). If the direction is forward, no expensive inferencing is performed, and the only bindings returned are ones which can be found through a simple KB lookup. If the direction is backward, inferencing is performed.
* Optionally, a number of bindings requested. Once this number of bindings has been found, the ASK operation will terminate, even if more bindings exist. The default value varies among interfaces; if no value is passed by the interface on to the underlying code, the operation will continue until one of the other resource limits has been reached or until the KB has been exhaustively searched, which could take a long time.
* Optionally, a time limit. No more than this many seconds will be spent on the ASK operation. Again, a particular interface may provide a default time limit, but if none is passed to the underlying code, the ASK operation will continue until one of the other resource limits has been reached or until the KB has been exhaustively searched.
* Optionally, a inference depth cutoff. The search for bindings will go no deeper than this number of levels. In the search for bindings, each time the inference engine tries to satisfy a literal, the search is extended by one depth level. Currently, this is true whether literals are satisified by firing rules or by simple KB lookup. If no inference-depth cutoff is passed by your interface on to the underlying code, the ASK operation will continue until one of the other resource limits has been reached or until the KB has been exhaustively searched.
* Optionally, an axiom depth cutoff. No more than this many rules will be used in the search for bindings. If no axiom-depth cutoff is passed by your interface on to the underlying code, the ASK operation will continue until one of the other resource limits has been reached or until the KB has been exhaustively searched.
For example, if you wanted to find some people who have served as head of state of a European country, you might execute an ASK with the following parameters:
Formula: (#$and (#$geographicalSubRegions #$ContinentOfEurope ?X) (#$headOfStateOf ?X ?Y))
Microtheory: #$BaseKB
Direction: backward
Number: 5
Time: 10
Inference Depth: 10
Axiom Depth: 3
This asks CYC® to find no more than 5 bindings for ?X and ?Y, satisfiable in the #$BaseKB, that can be found in 10 seconds of processor time or less. CYC® can use rules in the search, since the direction is backward, and can stop pursuing any search path as soon as it requires using a 4th rule or satisfying an 11th literal."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#ASK]

name::
* McsEngl.Cycdoing.ASK,

Cyc-10 of Cycapp

description::
"The current version of CYC® developed at Cycorp under the direction of Keith Goolsbey, and first deployed there in March, 1995. All current CYC® development effort is with Cyc-10."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#Cyc-10]

name::
* McsEngl.Cyc-10!⇒Cycapp10,
* McsEngl.Cycapp'Cyc-10!⇒Cycapp10,
* McsEngl.Cycapp10,

Cyc-9 of Cycapp

description::
"The last version of CYC® developed at MCC."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#Cyc-9]

name::
* McsEngl.Cyc-9!⇒Cycapp09,
* McsEngl.Cycapp'Cyc-9!⇒Cycapp09,
* McsEngl.Cycapp09,

OpenCyc of Cycapp

description::
"The first version of OpenCyc was released in spring 2002 and contained only 6,000 concepts and 60,000 facts. The knowledge base was released under the Apache License. Cycorp stated its intention to release OpenCyc under parallel, unrestricted licences to meet the needs of its users. The CycL and SubL interpreter (the program that allows users to browse and edit the database as well as to draw inferences) was released free of charge, but only as a binary, without source code. It was made available for Linux and Microsoft Windows. The open source Texai[15] project released the RDF-compatible content extracted from OpenCyc.[16] A version of OpenCyc, 4.0, was released in June 2012. OpenCyc 4.0 included much of the Cyc ontology at that time, containing hundreds of thousands of terms, along with millions of assertions relating the terms to each other; however, these are mainly taxonomic assertions, not the complex rules available in Cyc. The OpenCyc 4.0 knowledge base contained 239,000 concepts and 2,093,000 facts.
The main point of releasing OpenCyc was to help AI researchers understand what was missing from what they now call ontologies and knowledge graphs. It's useful and important to have properly taxonomized concepts like person, night, sleep, lying down, waking, happy, etc., but what's missing from the OpenCyc content about those terms, but present in the Cyc KB content, are the various rules of thumb that most of us share about those terms: that (as a default, in the ModernWesternHumanCultureMt) each person sleeps at night, sleeps lying down, can be woken up, is not happy about being woken up, and so on. That point does not require continually-updated releases of OpenCyc, so, as of 2017, OpenCyc is no longer available."
[{2021-02-11} https://en.wikipedia.org/wiki/Cyc#OpenCyc]

name::
* McsEngl.Cycapp'OpenCyc,
* McsEngl.OpenCyc,

Infrsc OpenCyc

description::
* {2017-04-04} https://www.mkbergman.com/2034/fare-thee-well-opencyc/,

name::
* McsEngl.OpenCyc'Infrsc,

ResearchCyc of Cycapp

description::
"In July 2006, Cycorp released the executable of ResearchCyc 1.0, a version of Cyc aimed at the research community, at no charge. (ResearchCyc was in beta stage of development during all of 2004; a beta version was released in February 2005.) In addition to the taxonomic information contained in OpenCyc, ResearchCyc includes significantly more semantic knowledge (i.e., additional facts and rules of thumb) involving the concepts in its knowledge base; it also includes a large lexicon, English parsing and generation tools, and Java based interfaces for knowledge editing and querying. In addition it contains a system for Ontology-based data integration. As of 2017, regular releases of ResearchCyc continued to appear, with 600 research groups utilizing licenses around the world at no cost for noncommercial research purposes. As of December 2019, ResearchCyc is no longer supported. Cycorp expects to improve and overhaul tools for external developers over the coming years."
[{2021-02-11} https://en.wikipedia.org/wiki/Cyc#ResearchCyc]

name::
* McsEngl.Cycapp'ResearchCyc,
* McsEngl.ResearchCyc,

inference-engine of lagCycl

description::
"An inference engine is a computer program that tries to derive answers from a knowledge base. The Cyc inference engine performs general logical deduction (including modus ponens, modus tollens, universal quantification and existential quantification).[14] It also performs inductive reasoning, statistical machine learning and symbolic machine learning, and abductive reasoning (but of course sparingly and using the existing knowledge base as a filter and guide)."
[{2021-02-10} https://en.wikipedia.org/wiki/Cyc]
===
"The Cyc inference engine handles modus ponens and modus tollens (contrapositive) inferencing, universal and existential quantification, and mathematical inferencing. It uses contexts called microtheories to optimize inferencing by restricting search domains.
The Cyc knowledge base contains over 1 million assertions. Many approaches commonly taken by other inference engines (such as frames, RETE match, Prolog, etc.) just don’t scale well to KBs of this size. As a result, the Cyc team has been forced to develop other techniques.
Cyc also includes several special-purpose inferencing modules for handling a few specific classes of inference. One set of modules handles reasoning concerning collection membership, subsethood, and disjointness. Another handles equality reasoning. Others implement fast reasoning with #$genlPreds and #$genlAttributes. Still others implement symmetry, transitivity and reflexivity reasoning."
[{2021-02-09} http://web.archive.org/web/20160915203525/http://www.cyc.com/documentation/overview-cyc-inferencing/]

name::
* McsEngl.Cyc-inference-engine!⇒Cycinfrc,
* McsEngl.Cycinfrc,
* McsEngl.lagCycl'inference-engine!⇒Cycinfrc,

license of Cycinfrc

description::
"CycL has a publicly released specification and dozens of HL modules were described in Lenat and Guha's textbook,[8] but the actual Cyc inference engine code, and the full list of 1000+ HL modules, is Cycorp-proprietary.[3]"
[{2021-02-10} https://en.wikipedia.org/wiki/Cyc]

name::
* McsEngl.Cycinfrc'license,

natural-language-system of lagCycl

description::
"Cyc offers sophisticated natural language understanding and generation functionality, using the power of Cyc knowledge to address semantics and pragmatics rather than just syntactic or statistical processing."
[{2021-02-09} http://web.archive.org/web/20161101092302/http://www.cyc.com/natural-language-processing-in-cyc/]

name::
* McsEngl.Cyc-NL!⇒Cycnls,
* McsEngl.Cycapp'NLS!⇒Cycnls,
* McsEngl.Cycnls,
* McsEngl.lagCycl'natural-language-system!⇒Cycnls,

truth-maintenance-system of Cycapp

description::
"A truth maintenance system is a mechanism whereby a knowledge based system can keep reasonably consistent and truthful as its knowledge changes. For example, if facts have been added to the KB through inference based on a set of premises, and one of the premises is later removed from the KB, any conclusion that depends on that premise should also be removed from the KB. The CYC® TMS relies on the fact that each assertion has all of its arguments recorded in the datastructure."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#TMS]

name::
* McsEngl.Cycapp'TMS'(truth-maintenance-system),
* McsEngl.Cycapp'truth-maintenance-system,

API of Cycapp

description::
"The CYC® API is an applications programming interface that allows programmers to build applications based on the CYC® technology."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#API]

name::
* McsEngl.Cycapi,
* McsEngl.Cycapp'API!⇒Cycapi,

input of lagCycl

description::
· common sense knowledge.

name::
* McsEngl.lagCycl'input,

output of lagCycl

description::
·

name::
* McsEngl.lagCycl'output,

term of lagCycl

description::
· Cyclterm is THE-NAME of its concepts.

name::
* McsEngl.Cyclterm,
* McsEngl.lagCycl'constant!⇒Cyclterm,
* McsEngl.lagCycl'term!⇒Cyclterm,

descriptionLong::
"A term is anything that can be an argument to a predicate or function. Variables are terms. Constants, both atomic constants and reified NATs, are terms. Non-reified NATs are terms. Numbers, strings, or even entire formulas can serve as terms."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#term]

Cyclterm.SPECIFIC

description::
* http://web.archive.org/web/20121222173652/http://www.cyc.com/cycdoc/vocab/fundamental-vocab.html,

name::
* McsEngl.Cyclterm.specific,

Cyclterm.aggregate

description::
"Cyc's ontology grew to about 100,000 terms during the first decade of the project, to 1994, and as of 2017 contained about 1,500,000 terms."
[{2021-02-10} https://en.wikipedia.org/wiki/Cyc]

name::
* McsEngl.Cyclterm.aggregate,

Cyclterm.FORT

description::
"There are two kinds of FORTs: constants and non-atomic terms (NATs)."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#FORT]

name::
* McsEngl.Cyclfort,
* McsEngl.Cyclterm.FORT'(first-order-reified-term)!⇒Cyclfort,
* McsEngl.lagCycl'FORT'(first-order-reified-term)!⇒Cyclfort,

Cyclterm.constant

description::
"Constants are terms introduced into CycL by explicit creation.
Constants such as #$BillM or #$likesAsFriend begin with "#$".
Constants are one type of FORT; the other type are non-atomic terms (NAT's)."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#constant]

name::
* McsEngl.Cyclconstant,
* McsEngl.Cyclterm.constant!⇒Cyclconstant,
* McsEngl.lagCycl'constant!⇒Cyclconstant,

Cyclterm.NAT

description::
"A term which is neither a variable nor a constant. NATs are terms formed by applying a function to its arguments. Like constants, each NAT denotes some thing in the Cyc KB. Currently, there are two kinds of NAT: Reified NATs, which are a type of FORT, and are implemented with data structures that have indexing allowing all uses of the NAT to be retrieved; and non-reified NATs, which have no such indexing and remain in the form of a "lispy" expresion in the formulas in which they occur."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#NAT]

name::
* McsEngl.Cyclnat,
* McsEngl.Cyclterm.NAT!⇒Cyclnat,
* McsEngl.lagCycl'NAT'(non-atomic-term)!⇒Cyclnat,

Cyclnat.IBQE

description::
"interval-based quantity expression (IBQE)
In Cyc-10, quantities like "5 dollars", "10 seconds", and "300 kilometers" are expressed using IBQEs.
An IBQE is a special kind of non-atomic term in which the CycL function is an instance of #$UnitOfMeasure. Units of measure are regular (but not reifiable) functions, which take two arguments: a minimum value and a maximum value. The second argument is optional, and if it is omitted, it is assumed to be equal to the first. In other words, an IBQE with just one argument is taken to denote a single value.
(#$massOfObject #$BillM (#$Pound-UnitOfMass 175 185))
(#$heightOfObject #$BillM (#$Inch 74))
The unit of measure may be a NAT, rather than a constant:
(#$massOfObject #$BillM ((#$Kilo #$Gram) 80 84))"
[{2021-02-13} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#IBQE]

name::
* McsEngl.Cyclnat.IBQE,
* McsEngl.lagCycl'IBQE'(interval-based-quantity-expression),
* McsEngl.lagCycl'interval-based-quantity-expression,

Cyclterm.variable

description::
"One type of term. Variables appear in CYC® rules to stand for not-known-in-advance constants that satisfy the formula of the rule. Variables also are used in formulas given to the ASK utility, to stand for the results the asker wishes to find."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#variable]
"Sentences can also contain variables, strings starting with "?". These sentences are called "rules""
[{2021-02-10} https://en.wikipedia.org/wiki/Cyc]

name::
* McsEngl.Cyclterm.variable!⇒Cyclvar,
* McsEngl.Cyclvar,
* McsEngl.lagCycl'variable!⇒Cyclvar,

Cyclterm.relation

description::
"In Cyc® "relation" is informally used to refer to predicates and functions. In the math or database worlds, a relation is a set of ordered n-tuples. One might talk about the relation "Father", whose elements include (Katherine, Lloyd), (Karen, Wes), (John, Bob), and so on, where the first item in each element is a person and the second is that person's biological father. CycL relations are also ordered n-tuples. The notation we use is different from that above and depends on whether the relation to be represented by a CycL function or a CycL predicate. In both cases, we reify a constant to stand for the relation. In our example, we might call the constant #$FatherFn -- an uppercase name, because the relation is a function (people have only one biological father). We'd write, for example
(#$FatherFn #$Katherine)
to refer to Lloyd, since Katherine and Lloyd are in the "Father" relation.
CycL predicates are the other main sort of relation-denoting constant in CYC®. The latter are used to represent relations which are not functions (not single-valued). The relation denoted by "parents" should be represented with a CycL predicate. For example, we'd write
(#$parents #$Katherine #$Lloyd)
(#$parents #$Katherine #$Bonnie)
to say that (Katherine, Lloyd) and (Katherine, Bonnie) are in the parents relation. The arity of CycL predicates is the same as the arity of the represented relation, and the arity of CycL functions is one less than the arity of the relations they represent."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#relation]

name::
* McsEngl.Cyclrelation,
* McsEngl.Cyclterm.relation!⇒Cyclrelation,
* McsEngl.lagCycl'relation!⇒Cyclrelation,
* McsEngl.relation-denoting-term@lagCycl!⇒Cyclrelation,

arity of Cyclrelation

description::
"The arity of a CycL predicate or function is the number of arguments it takes.
* Unary predicates and functions take just 1 argument.
* Binary predicates and functions take 2 arguments.
* Ternary predicates and functions take 3 arguments.
* Quaternary predicates and functions take 4 arguments.
* Quintary predicates and functions take 5 arguments.
No CycL predicate or function currently takes more than 5 arguments."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#arity]

name::
* McsEngl.Cyclrelation'arity,

Cyclrelation.function

description::
"A function (in the mathematical sense) is a relation such that for each thing in its domain (the universe of things it can be applied to), there is a single thing in its range (the universe of results it can have) such that the relation holds between them. In CycL, functions are denoted by certain constants. These constants are referred to as "function-denoting constants, "CycL functions," or sometimes just "functions."
CycL functions can be applied to arguments to form non-atomic terms, which can serve as arguments to a predicate just as other terms can. There are more details about CycL functions in the Functions section of "The Syntax of Cycl"."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#function]

name::
* McsEngl.Cyclfunction,
* McsEngl.Cyclrelation.function!⇒Cyclfunction,
* McsEngl.function@lagCycl!⇒Cyclfunction,
* McsEngl.lagCycl'function!⇒Cyclfunction,

Cyclrelation.truth-function

description::
"Truth functions, which can apply to one or more other concepts and return either true or false. For example, #$siblings is the sibling relationship, true if the two arguments are siblings.
By convention, truth function constants start with a lower-case letter.
Truth functions may be broken down into logical connectives (such as #$and, #$or, #$not, #$implies), quantifiers (#$forAll, #$thereExists, etc.) and predicates."
[{2021-02-10} https://en.wikipedia.org/wiki/Cyc]

name::
* McsEngl.Cyclrelation.truth-function,
* McsEngl.Cyclterm.truth-function,

Cyclrelation.predicate (link)

Cyclterm.predicate

description::
"Predicates are represented in CycL by constants that are sometimes referred to as "CycL predicates" or, more casually, as "predicates." Like CycL functions (the other kind of relation-denoting constants), CycL predicates can be used as the leading term (after the initial parenthesis) in CycL expressions. When a CycL predicate is applied to the right number and type of arguments, the expression formed is a CycL formula--a formula expressing a proposition about something. In contrast, expressions formed with functions as arg 0 (in the leading position) are terms and so do not express propositions.
By convention, constants that denote predicates begin with lowercase letters."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#predicate]

name::
* McsEngl.Cyclpredicate,
* McsEngl.Cyclrelation.predicate!⇒Cyclpredicate,
* McsEngl.lagCycl'predicate!⇒Cyclpredicate,
* McsEngl.predicate@lagCycl!⇒Cyclpredicate,

Cyclpredicate.slot

description::
"A slot is simply a CycL binary predicate such as #$startingDate.
Historically, the name derives from the days when CYC® was a frame-based system.
People will sometimes speak of a slot on a certain constant, or of a constant having slots.
One might say, for example, that the constant #$BillM has a #$likesAsFriend slot, or that #$likesAsFriend is a slot on #$BillM.
This signifies only that there is some GAF in the KB having #$likesAsFriend as its predicate and #$BillM as its first argument."
[{2021-02-13} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#slot]

name::
* McsEngl.Cyclpredicate.slot,
* McsEngl.lagCycl'slot,
* McsEngl.slot@lagCycl,

Cyclpredicate.#$isa

description::
"Two important binary predicates are #$isa and #$genls. The first one describes that one item is an instance of some collection, the second one that one collection is a subcollection of another one. Facts about concepts are asserted using certain CycL sentences. Predicates are written before their arguments, in parentheses:
(#$isa #$BillClinton #$UnitedStatesPresident)
"Bill Clinton belongs to the collection of U.S. presidents.""
[{2021-02-10} https://en.wikipedia.org/wiki/Cyc]

name::
* McsEngl.Cyclpredicate.#$isa,
* McsEngl.lagCycl'#$isa,

Cyclpredicate.#$genls

description::
· the-generals of an-entity.
"Two important binary predicates are #$isa and #$genls. The first one describes that one item is an instance of some collection, the second one that one collection is a subcollection of another one. Facts about concepts are asserted using certain CycL sentences. Predicates are written before their arguments, in parentheses:
...
(#$genls #$Tree-ThePlant #$Plant)
"All trees are plants.""
[{2021-02-10} https://en.wikipedia.org/wiki/Cyc]

name::
* McsEngl.Cyclpredicate.#$genls,
* McsEngl.lagCycl'#$genls,

Cyclpredicate.#$spec

description::
· the-specifics of an-entity.
""spec" means "subset". In Cyc-8, there was a predicate called #$spec, which was the inverse of #$genls. The predicate became obsolete in Cyc-9, but Cyclists still use it all the time when talking about the CYC® ontology. For instance, one might say, "#$Deity is a spec of #$Agent.""
[{2021-02-11} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#strength]

name::
* McsEngl.Cyclpredicate.#$spec,
* McsEngl.lagCycl'#$spec,

Cyclterm.logical-connective

description::
"Truth functions may be broken down into logical connectives (such as #$and, #$or, #$not, #$implies), quantifiers (#$forAll, #$thereExists, etc.) and predicates."
[{2021-02-10} https://en.wikipedia.org/wiki/Cyc]

name::
* McsEngl.Cycllogcon,
* McsEngl.Cyclterm.logical-connective!⇒Cycllogcon,
* McsEngl.lagCycl'logical-connective!⇒Cycllogcon,

Cycllogcon.#$and

description::
·

name::
* McsEngl.Cycllogcon.#$and,
* McsEngl.lagCycl'#$and,

Cycllogcon.#$or

description::
·

name::
* McsEngl.Cycllogcon.#$or,
* McsEngl.lagCycl'#$or,

Cycllogcon.#$not

description::
·

name::
* McsEngl.Cycllogcon.#$not,
* McsEngl.lagCycl'#$not,

Cycllogcon.#$implies

description::
"Newcomers to formal logic may misinterpret #$implies as implying a causal relationship.
But, strictly speaking, a #$implies assertion says only that either the first argument is false, or the second argument is true.
[{1998-03-01} http://www.cyc.com/cyc-2-1/ref/cycl-syntax.html,{1997-08-08}]

name::
* McsEngl.Cycllogcon.#$implies,
* McsEngl.lagCycl'#$implies,

Cyclterm.quantifier

description::
"A quantifier is a special type of CYC® constant used in quantification. CycL contains five quantifiers: #$forAll, #$thereExists, #$thereExistAtLeast, #$thereExistAtMost, and #$thereExistExactly. Each quantifier introduces a new variable."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#quantifier]

name::
* McsEngl.Cyclquantifier,
* McsEngl.Cyclterm.quantifier!⇒Cyclquantifier,
* McsEngl.lagCycl'quantifier!⇒Cyclquantifier,
* McsEngl.quantifier@lagCycl!⇒Cyclquantifier,

Cyclquantifier.#$forAll

description::
·

name::
* McsEngl.Cyclquantifier.#$forAll,
* McsEngl.lagCyclquan'#$forAll,

Cyclquantifier.#$thereExists

description::
·

name::
* McsEngl.Cyclquantifier.#$thereExists,
* McsEngl.lagCyclquan'#$thereExists,

Cyclquantifier.#$thereExistAtLeast

description::
·

name::
* McsEngl.Cyclquantifier.#$thereExistAtLeast,
* McsEngl.lagCyclquan'#$thereExistAtLeast,

Cyclquantifier.#$thereExistAtMost

description::
·

name::
* McsEngl.Cyclquantifier.#$thereExistAtMost,
* McsEngl.lagCyclquan'#$thereExistAtMost,

Cyclquantifier.#$thereExistExactly

description::
·

name::
* McsEngl.Cyclquantifier.#$thereExistExactly,
* McsEngl.lagCyclquan'#$thereExistExactly,

expression of lagCycl

description::
"In the most general sense, an expression is a sequence of symbols. The phrase CycL expression refers to expressions that follow the syntax rules of CycL.
Some CycL expressions are propositions or statements about the world; these are called CycL formulas.
Other CycL expressions form terms that stand for concepts; these are called non-atomic terms (NATs)."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#expression]

name::
* McsEngl.Cyclexpression,
* McsEngl.lagCycl'expression!⇒Cyclexpression,

argumentNo of Cyclexpression

description::
· function, predicate, logical-connective, quantifier.

name::
* McsEngl.Cyclexpression'argumentNo,

argument of Cyclexpression

description::
"The term "argument" is used in two different ways by Cyclists:
* Most commonly, the term "argument" is used to refer to any CycL term which follows a predicate, a function, a logical connective, or a quantifier in a Cycl expression. Thus, in the CycL formula (#$likesAsFriend #$BillM #$Goolsbey), #$likesAsFriend is a predicate, and #$BillM and #$Goolsbey are the first and second arguments to that predicate.
* The term "argument" is also used to refer to a reason why an assertion is present in the KB with its truth value. Arguments are of two main types: the first type of argument is essentially a statement that the formula was explicitly "asserted" (or "local"). The second type of argument is the group of assertions through which the assertion was "inferred" (in which case the assertion is called "remote"). In this case there is a chain of inference which supports the truth value of the supported assertion. Such arguments are also called deductions."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#argument]

name::
* McsEngl.Cyclexpression'argument,
* McsEngl.lagCycl'argument-of-expression,

Cyclexpression.SPECIFIC

description::
* formula,
* non-atomic-term,

name::
* McsEngl.Cyclexpression.specific,

Cyclexpression.literal

description::
"Most generally, a literal is a Cyc expression of the form (predicate arg1 [arg2 ... argn]), or its negation, where the number of arguments to the predicate can be any positive integer (but in Cyc, not more than 5), and the arguments can be any kind of term. For example,
(#$likesAsFriend #$Goolsbey #$Brandy)
(#$eatsWillingly #$BillM (#$FruitFn ?X))
(#$isa ?CAR #$Automobile)
(#$performedBy ?ACT ?ORG)
(#$not (#$performedBy ?ACT ?ORG))
Because it includes negated formulas, the class of literals is a superset of the class of atomic formulas.
Usually, "literal" is used to refer to the atomic formulas that make up the internal representation of any assertion's formula. In Cyc-10, formulas that are asserted into the KB are converted into conjunctive normal form; the formula of each single assertion is internally represented as a disjunction of literals. Those literals that would be negated in conjunctive normal form are called negative literals; the rest are called positive literals. GAFs are the subset of literals in which there are no variables. [{1998-02-27} http://www.cyc.com/cyc-2-1/ref/glossary.html,{1997-08-08}]

name::
* McsEngl.Cyclexpression.literal!⇒Cyclliteral,
* McsEngl.Cyclliteral,
* McsEngl.literal@lagCycl!⇒Cyclliteral,

assertion of lagCycl

description::
"The assertion is the fundamental unit of knowledge in the Cyc system.
Every assertion consists of:
- a CycL formula which states the content of the assertion
- a truth value
- a microtheory of which the assertion is part
- a direction
- a justification
The set of assertions includes both rules and GAFs."
[{1998-02-27} http://www.cyc.com/cyc-2-1/ref/glossary.html,{1997-08-08}]

name::
* McsEngl.Cyclassertion,
* McsEngl.lagCycl'assertion!⇒Cyclassertion,

formula of Cyclassertion

description::
"Every formula has the structure of a parenthesized list. I.e., it starts with a left parenthesis, then therer follow a series of objects which are commonly designated ARG0, ARG1, ARG2, etc., and finally there is a matching right parenthesis.
The object in the ARG0 position may be a predicate, a logical connective, or a quantifier.
The remaining arguments may be atomic constants, non-atomic terms, variables, numbers, English strings delimited by double quotes ("), or other formulas."
[{1998-03-01} http://www.cyc.com/cyc-2-1/ref/cycl-syntax.html,{1997-08-08}]

name::
* McsEngl.Cyclassertion'formula!⇒Cyclformula,
* McsEngl.Cyclformula,
* McsEngl.Cyclsentence!⇒Cyclformula,
* McsEngl.lagCycl'formula!⇒Cyclformula,
* McsEngl.lagCycl'sentence!⇒Cyclformula,
* McsEngl.proposition@lagCycl!⇒Cyclformula,
* McsEngl.statement@lagCycl!⇒Cyclformula,
===
"Some CycL expressions are propositions or statements about the world; these are called CycL formulas."
[{2021-02-13} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#expression]

conjunctive-normal-form of Cyclformula

description::
"In previous versions of Cyc, formulas are stored and reasoned with in the same form in which they appear in the KB browser, e.g.
(implies (and (isa ?afp AdultFemalePerson) (residesInRegion ?afp Guam)) (and (acquaintedWith Zippy ?afp) (likesAsFriend Zippy ?afp)))
In Cyc-10, formulas asserted to the KB are stored internally, and reasoned with, in conjunctive normal form (CNF). When converted to CNF, a formula gets rewritten as a conjunction of disjunctions of negated and non-negated literals. So, for example, the formula above would be written in CNF as:
(and (or (not (isa ?afp AdultFemalePerson)) (not (residesInRegion ?afp Guam)) (acquaintedWith Zippy ?afp)) (or (not (isa ?afp AdultFemalePerson)) (not (residesInRegion ?afp Guam)) (likesAsFriend Zippy ?afp)))
Each of the conjuncts would become a separate assertion.
Converting to CNF is part of the job of the Cyc-10 canonicalizer."
[{2021-02-09} http://web.archive.org/web/20150907111619/http://www.cyc.com/documentation/internal-representation-assertions/]

name::
* McsEngl.Cyclassertion'CNF-(conjunctive-normal-form),
* McsEngl.lagCycl'CNF-(conjunctive-normal-form),
* McsEngl.lagCycl'conjunctive-normal-form,

Cyclformula.well-formed

description::
"A formula in CycL is well-formed if it conforms to the syntax of CycL and passes all the restrictions on arity and argument types of the relations that are used in it."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#well-formed]

name::
* McsEngl.Cyclformula.well-formed,

truth-value of Cyclassertion

description::
"In the Cyc® KB, a truth value is a value attached to an assertion which indicates its degree of truth. There are five possible truth values:
* monotonically true (100): True always and under all conditions. Normally reserved for things that are true by definition.
* default true (T): Assumed true, but subject to exceptions. Most rules in the KB are default true.
* unknown (~): Not known to be true, and not known to be false.
* default false (F): Assumed false, but subject to exceptions.
* monotonically false (0): False always and under all conditions.
Of these, the most commonly used are the first two.
Each of these truth values is represented by a different colored ball in the KB Browser. For details on the icons used in the Browser, see the Key For Icons In the Browser.
"Truth value" is a heuristic level property; it is a combination of what is 2 separate properties at the epistemological level: strength (:default or :monotonic) and negation status (whether or not a formula begins with #$not).
If you are unsure whether to make an assertion monotonically true or default true, go with the latter."
[{2021-02-11} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#tv]

name::
* McsEngl.Cyclassertion'truth-value,

microtheory of Cyclassertion

description::
"a microtheory of which the assertion is part"

name::
* McsEngl.Cyclassertion'microtheory,

direction of Cyclassertion

description::
"Direction is a value attached to every assertion which determines whether inferencing involving the assertion is done at assert time or at ask time. There are three possible values for direction: :forward (inferencing done at assert time), :backward (inferencing done at ask time), and :code (HL module performs reasoning, assertion not used in regular inference). Most interfaces enforce the following default: GAFs have direction :forward and rules have direction :backward. Direction is new in Cyc-10; it replaces access level."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#direction]

name::
* McsEngl.Cyclassertion'direction,

descriptionLong::
"access level (AL)
(obs.) In Cyc-9, the access level of an assertion determines whether inferencing involving that assertion occurs at assert time or at ask time. Access level is replaced in Cyc-10 by direction.
Only two access level values were commonly used in Cyc-9: 0, which corresponds to the Cyc-10 direction forward, and 4, which corresponds to the Cyc-10 direction backward."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#access%20level]

justification of Cyclassertion

description::
·

name::
* McsEngl.Cyclassertion'justification,

argument of Cyclassertion

description::
"The term "argument" is used in two different ways by Cyclists:
* Most commonly, the term "argument" is used to refer to any CycL term which follows a predicate, a function, a logical connective, or a quantifier in a Cycl expression. Thus, in the CycL formula (#$likesAsFriend #$BillM #$Goolsbey), #$likesAsFriend is a predicate, and #$BillM and #$Goolsbey are the first and second arguments to that predicate.
* The term "argument" is also used to refer to a reason why an assertion is present in the KB with its truth value. Arguments are of two main types:
- the first type of argument is essentially a statement that the formula was explicitly "asserted" (or "local").
- The second type of argument is the group of assertions through which the assertion was "inferred" (in which case the assertion is called "remote"). In this case there is a chain of inference which supports the truth value of the supported assertion. Such arguments are also called deductions."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#argument]

name::
* McsEngl.Cyclassertion'argument,
* McsEngl.lagCycl'argument-of-assertion,

Cyclassertion.complexNo

description::
· assertion without logical-connective.

name::
* McsEngl.Cyclassertion.complexNo,

Cyclassertion.complexNo.variableNo (Gaf)

description::
· assertion without logical-connectives and variables.

name::
* McsEngl.Cyclassertion.GAF!⇒Cyclgaf,
* McsEngl.Cyclassertion.complexNo.variableNo!⇒Cyclgaf,
* McsEngl.Cyclassertion.ground-atomim-formula!⇒Cyclgaf,
* McsEngl.Cyclgaf,
* McsEngl.lagCycl'ground-atomim-formula!⇒Cyclgaf,

descriptionLong::
"gaf: An acronym for Ground Atomic Formula which is an assertion without any variables. Gafs form the great majority of KB assertions. The Arg0 term in a gaf is the predicate."
[http://www.cyc.com/cyc-api.html,v0.3-{1999-03-11}]

Cyclassertion.complexNo.variable

description::
·

name::
* McsEngl.Cyclassertion.complexNo.variable,

Cyclassertion.complex

description::
"Complex sentences can be built up out of atomic sentences or other complex sentences by using logical connectives, which are special constants analogous to the logical operators of formal logic. The most important logical connectives in CycL are #$not, #$and, #$or, and #$implies."
[{2007-09-21} http://www.cyc.com/doc/handbook/oe/02-the-syntax-of-cycl.html]

name::
* McsEngl.Cyclassertion.complex,

Cyclassertion.local

description::
"A local assertion is one which was added to the KB from an outside source (most commonly, a human KEer), rather than inferred from other assertions.
Local assertions have at least one local justification among their supports."
[{1998-02-27} http://www.cyc.com/cyc-2-1/ref/glossary.html,{1997-08-08}]

name::
* McsEngl.Cyclassertion.axiom,
* McsEngl.Cyclassertion.local,
* McsEngl.lagCycl'axiom,

descriptionLong::
"Strictly speaking, an axiom is one of a set of fundamental formulas that one starts with to prove theorems by deduction.
In CYC®, the axioms are those formulas that have been locally asserted into the CYC® KB. CYC® axioms are well-formed CYC® formulas, since the system won't let you add formulas to CYC® that are not well-formed. However, not all well-formed CYC® formulas are axioms, since not all of them are actually in the KB. And some of the formulas in the KB are not, strictly speaking, axioms, since they were added to the KB via inference, instead of being locally asserted.
In informal usage, though, Cyclists don't always adhere to the strict meaning of axiom, and may refer to a formula they are considering adding to the KB or have recently removed from the KB as an axiom.
Axiom is also the name of one of the internal KB data structure types."
[{2021-02-13} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#axiom]

Cyclassertion.localNo

description::
"A local assertion is one which was added to the KB from an outside source (most commonly, a human KEer), rather than inferred from other assertions.
Local assertions have at least one local justification among their supports."
[{1998-02-27} http://www.cyc.com/cyc-2-1/ref/glossary.html,{1997-08-08}]

name::
* McsEngl.Cyclassertion.localNo,
* McsEngl.Cyclassertion.inferred,
* McsEngl.Cyclassertion.remote,

Cyclassertion.quantification

description::
· an-assertion with quantifier.

name::
* McsEngl.Cyclassertion.quantification!⇒Cyclquantification,
* McsEngl.Cyclquantification,

Cyclquantification.existential

description::
"Quantifying with #$thereExists. For example, the following existentially quantified assertion
(#$thereExists ?SING
 (#$and
   (#$isa ?SING #$HumanAdult)
   (#$maritalStatus ?SING #$Single))),
states that there is some unmarried human adult."
[{2021-02-13} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#existential%20quantification]

name::
* McsEngl.Cyclquantification.existential,
* McsEngl.lagCycl'existential-quantification,

Cyclquantification.universal

description::
"Quantifying with #$forAll. In CycL formulas, variables which are not explicitly bound by a quantifier are assumed to be universally quantified. For example,
(#$forAll ?LEAF (#$implies
 (#$isa ?LEAF Leaf)
 (#$colorOfObject ?LEAF GreenColor)))
means that every leaf is green. But in CycL, this sentence means the same as the following sentence:
(#$implies
 (#$isa ?LEAF Leaf)
 (#$colorOfObject ?LEAF GreenColor))"
[{2021-02-13} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#universal-quantification]

name::
* McsEngl.Cyclquantification.universal,
* McsEngl.lagCycl'universal-quantification,

Cyclassertion.fact

description::
"The purpose of the ASSERT operation is to add a new assertion--a "fact" or a "rule"--to the KB."
[{2021-02-11} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#ASSERT]

name::
* McsEngl.Cyclassertion.fact!⇒Cyclfact,
* McsEngl.Cyclfact,

Cyclassertion.rule

description::
"Sentences can also contain variables, strings starting with "?". These sentences are called "rules". One important rule asserted about the #$isa predicate reads:

(#$implies
  (#$and
    (#$isa ?OBJ ?SUBSET)
    (#$genls ?SUBSET ?SUPERSET))
  (#$isa ?OBJ ?SUPERSET))
"If OBJ is an instance of the collection SUBSET and SUBSET is a subcollection of SUPERSET, then OBJ is an instance of the collection SUPERSET"."
[{2021-02-10} https://en.wikipedia.org/wiki/Cyc]

name::
* McsEngl.Cyclrule,
* McsEngl.Cyclassertion.rule!⇒Cyclrule,
* McsEngl.lagCycl'rule!⇒Cyclrule,

microtheory of lagCycl

description::
"The knowledge base is divided into microtheories (Mt), collections of concepts and facts typically pertaining to one particular realm of knowledge.
Unlike the knowledge base as a whole, each microtheory must be free from monotonic contradictions.
Each microtheory is a first-class object in the Cyc ontology; it has a name that is a regular constant; microtheory constants contain the string "Mt" by convention.
An example is #$MathMt, the microtheory containing mathematical knowledge.
The microtheories can inherit from each other and are organized in a hierarchy: one specialization of #$MathMt is #$GeometryGMt, the microtheory about geometry."
[{2021-02-10} https://en.wikipedia.org/wiki/Cyc]

name::
* McsEngl.Cyclmt,
* McsEngl.Cyclmt'(lagCycl'microtheory)!⇒Cyclmt,
* McsEngl.context@lagCycl!⇒Cyclmt,
* McsEngl.lagCycl'context!⇒Cyclmt,
* McsEngl.lagCycl'microtheory!⇒Cyclmt,
* McsEngl.microtheory@lagCycl!⇒Cyclmt,
===
"context: Often used interchangeably with microtheory."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#context]

Cyclmt.#$genlMt

description::
"One microtheory is a #$genlMt of another if all its assertions are true in the other microtheory.
#$BaseKB is a #$genlMt of all microtheories."
[{2021-02-13} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#genlMt]

name::
* McsEngl.Cyclmt.#$genlMt-of-another,
* McsEngl.lagCycl'#$genlMt,

Cyclmt.#$BaseKB

description::
"One microtheory is a #$genlMt of another if all its assertions are true in the other microtheory.
#$BaseKB is a #$genlMt of all microtheories."
[{2021-02-13} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#genlMt]

name::
* McsEngl.Cyclmt.#$BaseKB,
* McsEngl.lagCycl'#$BaseKB,

knowledge-base of lagCycl

description::
"The CYC® KB is the repository of Cyc's knowledge. It consists of a large number of FORTs and an even larger number of assertions involving those constants."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#KB]

name::
* McsEngl.Cycapp'knowledge-base!⇒Cyclkb,
* McsEngl.Cyclkb,
* McsEngl.lagCycl'knowledge-base!⇒Cyclkb,
* McsEngl.lagCycl'ontology!⇒Cyclkb,
* McsEngl.ontology@lagCycl!⇒Cyclkb,

descriptionLong::
"In philosophy, ontology is the study of being. In knowledge-based systems, an ontology is that part of the system which specifies what things exist and what is true about them. Cyc's ontology is essentially its whole knowledge base. You may hear people refer to their "ontology of devices" or their "temporal ontology". What they are talking about is those parts of their knowledge base (the constants and assertions) that concern devices or time."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#ontology]

SubL of lagCycl

description::
"SubL is a computer language built by members of Cycorp.
SubL was written to support the Cyc® application, allowing it to run both under Lisp environments and as a C application generated by a SubL-to-C translator"
[{2021-02-09} http://web.archive.org/web/20160822085707/http://www.cyc.com/documentation/subl-reference/]
===
"SubL stands for SubLanguage, and is a computer language created by the CYC® team. It is designed to be easy to translate into C. The entire CYC® application is written in SubL.
Sublisp
An archaic term for SubL."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#SubL]

name::
* McsEngl.SubL!⇒lagSubl,
* McsEngl.SubLanguage!⇒lagSubl,
* McsEngl.Sublisp!⇒lagSubl,
* McsEngl.lagCycl'SubL!⇒lagSubl,
* McsEngl.lagSubl,

human of lagCycl

description::
· any human related to Cyc-project.

name::
* McsEngl.Cychmn,
* McsEngl.lagCycl'human!⇒Cychmn,

Cychmn.Cyclist

description::
"A Cyclist is a registered modifier of the CYC® KB. Everyone who works on the CYC® project is a Cyclist, as are individuals working with CYC® at participating organizations."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#Cyclist]

name::
* McsEngl.Cychmn.Cyclist,
* McsEngl.Cyclist,

Cychmn.knowledge-enterer

description::
"Short for Knowledge Enterer. One who writes CycL assertions for inclusion in the CYC® KB."
[{2021-02-09} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#KEer]

name::
* McsEngl.Cycapp'KEer!⇒Cyckger,
* McsEngl.Cycapp'knowledge-enterer!⇒Cyckger,
* McsEngl.Cyckger,
* McsEngl.Cychmn.knowledge-enterer!⇒Cyckger,

Cychmn.Lenat.Doug

description::
"Doug Lenat (President and CEO)
Dr. Douglas B. Lenat is one of the world’s leading computer scientists, and is the founder of the Cyc project and president of Cycorp.
Dr. Lenat has been a Professor of Computer Science at Carnegie-Mellon University and Stanford University and has received numerous honors including:
* Awarded the bi-annual IJCAI Computers and Thought Award which is the highest honor in Artificial Intelligence;
* Named the first Fellow of the AAAI, the Association for the Advancement of Artificial Intelligence.
* Fellow of the American Academy for the Advancement of Science (AAAS)
He is a prolific author, whose hundreds of publications include the following books:
* Knowledge Based Systems in Artificial Intelligence (1982, McGraw-Hill)
* Building Expert Systems (1983, Addison-Wesley)
* Knowledge Representation (1988, Addison-Wesley)
* Building Large Knowledge Based Systems (1989, Addison-Wesley)
His 1976 Stanford thesis earned him the bi-annual IJCAI Computers and Thought Award in 1977.
Dr. Lenat received his Ph.D. in computer science from Stanford University and his BA and MS in Mathematics from the University of Pennsylvania."
[{2021-02-09} http://web.archive.org/web/20161013223411/http://www.cyc.com:80/about/team/]

name::
* McsEngl.Cychmn.Lenat.Doug!⇒hmnLenatDoug,
* McsEngl.Doug-Lenat!⇒hmnLenatDoug,
* McsEngl.Lenat.Doug!⇒hmnLenatDoug,
* McsEngl.hmnLenatDoug,

Cychmn.Shepherd.Mary

description::
"Senior Vice President of Operations
Ms. Mary Shepherd is the Senior VP for Operations. Mary has been with the Cyc project since its inception at MCC in 1984 and is responsible for Cycorp’s financial, personnel, facilities, and operations functions."
[{2021-02-09} http://web.archive.org/web/20161013223411/http://www.cyc.com:80/about/team/]

name::
* McsEngl.Cychmn.Shepherd.Mary!⇒hmnShepherdMary,
* McsEngl.Shepherd.Mary!⇒hmnShepherdMary,
* McsEngl.hmnShepherdMary,

organization of lagCycl

description::
·

name::
* McsEngl.lagCycl'organization,

Cyclozn.Cycorp

description::
·

name::
* McsEngl.Cyclozn.Cycorp!⇒oznCycorp,
* McsEngl.Cycorp!⇒oznCycorp,
* McsEngl.oznCycorp,

Cyclozn.MCC

description::
"Microelectronics and Computer Technology Corporation (also Microelectronics and Computer Consortium, MCC) was the first, and at one time one of the largest, computer industry research and development consortia in the United States. MCC ceased operations in 2000 and was formally dissolved in 2004."
[{2021-02-09} https://en.wikipedia.org/wiki/Microelectronics_and_Computer_Technology_Corporation]

name::
* McsEngl.MCC'(Microelectronics-and-Computer-Technology-Corporation)!⇒oznMcc,
* McsEngl.Microelectronics-and-Computer-Technology-Consortium!⇒oznMcc,
* McsEngl.Microelectronics-and-Computer-Technology-Corporation!⇒oznMcc,
* McsEngl.oznMcc,

project of lagCycl

description::
· Cycapp created as a-project at MCC.

name::
* McsEngl.Cycproject,
* McsEngl.lagCycl'project!⇒Cycproject,

evaluation of lagCycl

description::
· there is no ONE common sense knowledge.

name::
* McsEngl.lagCycl'evaluation,

info-resource of lagCycl

description::
* http://www.cyc.com/,
* http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html,

name::
* McsEngl.lagCycl'Infrsc,

evoluting of lagCycl

{2012}-OpenCyc-4.0::
"A version of OpenCyc, 4.0, was released in June 2012. OpenCyc 4.0 included much of the Cyc ontology at that time, containing hundreds of thousands of terms, along with millions of assertions relating the terms to each other; however, these are mainly taxonomic assertions, not the complex rules available in Cyc. The OpenCyc 4.0 knowledge base contained 239,000 concepts and 2,093,000 facts."
[{2021-02-08} https://en.wikipedia.org/wiki/Cyc#OpenCyc]

{2002}-OpenCyc::
"The first version of OpenCyc was released in spring 2002 and contained only 6,000 concepts and 60,000 facts. The knowledge base was released under the Apache License. Cycorp stated its intention to release OpenCyc under parallel, unrestricted licences to meet the needs of its users. The CycL and SubL interpreter (the program that allows users to browse and edit the database as well as to draw inferences) was released free of charge, but only as a binary, without source code. It was made available for Linux and Microsoft Windows. The open source Texai[15] project released the RDF-compatible content extracted from OpenCyc.[16]"
[{2021-02-08} https://en.wikipedia.org/wiki/Cyc#OpenCyc]

{1995}-CYC-project-Cycorp::
"Douglas Lenat began the project in July 1984 at MCC, where he was Principal Scientist 1984–1994, and then, since January 1995, has been under active development by the Cycorp company, where he is the CEO."
* McsEngl.{lagCnpt'1995}-Cyc-project-at-Cycorp,
[{2021-02-10} https://en.wikipedia.org/wiki/Cyc]

{1989}-lagCycl-HOL::
"By 1989,[6] CycL had expanded in expressive power to Higher Order Logic (HOL)."
[{2021-02-10} https://en.wikipedia.org/wiki/Cyc]

{1984}-CYC-project::
"Doug Lenat's CYC (from enCYClopedia) Project at MCC in Austin, a ten-year $35 million project begun in 1984, uses logic, too, but emphasizes the Aristotle-problem, employing a dozen 'ontological engineers' to enumerate tens of millions of common-sense facts that will ultimately 'add up' to logical intelligence. Lenat's goal is a system that can understand and speak ordinary language, and detect violations of common sense as readily as humans can."
[{2021-02-08} http://sandcastle.cosc.brocku.ca/~bross/3P71/misc/outsider_ai.txt-{1995-12-26}]

name::
* McsEngl.Cycapp'evoluting,
* McsEngl.Cycproject'evoluting,
* McsEngl.lagCycl'evoluting,

lagCycl.SPECIFIC

description::
"Every representation is a trade-off between expressiveness (how easily you can say complicated things) and efficiency (how easily the machine can reason with what you've told it).
English is very expressive but not very efficient.
Most computer languages, such as Basic, C, and Fortran, are efficient but not very expressive.
To get both qualities, we separated the epistemological problem (what should the system know?) from the heuristic problem (how can it effectively reason with what it knows?) and developed two separate languages, respectively EL and HL.
Our knowledge enterers talk to CYC in the clean, expressive language (EL).
Their input is then converted into the heuristic language (HL), which is efficient for dealing with many sorts of frequently recurring inference problems, such as reasoning about time, causality, containment, and so forth."
[{2021-02-12} http://web.archive.org/web/20001208155800/http://www.cyc.com/halslegacy.html]

name::
* McsEngl.lagCycl.specific,

lagCycl.expressive

description::
"Every representation is a trade-off between expressiveness (how easily you can say complicated things) and efficiency (how easily the machine can reason with what you've told it).
English is very expressive but not very efficient.
Most computer languages, such as Basic, C, and Fortran, are efficient but not very expressive.
To get both qualities, we separated the epistemological problem (what should the system know?) from the heuristic problem (how can it effectively reason with what it knows?) and developed two separate languages, respectively EL and HL.
Our knowledge enterers talk to CYC in the clean, expressive language (EL).
Their input is then converted into the heuristic language (HL), which is efficient for dealing with many sorts of frequently recurring inference problems, such as reasoning about time, causality, containment, and so forth."
[{2021-02-12} http://web.archive.org/web/20001208155800/http://www.cyc.com/halslegacy.html]

name::
* McsEngl.lagCycl.EL'(expressive-language),
* McsEngl.lagCycl.expressive,

descriptionLong::
"Epistemological level refers to the way knowledge is expressed when CYC® communicates with users or external programs. This stands in contrast with heuristic level, which refers to the way knowledge is actually stored, and inference implemented, in CYC®."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#EL]

lagCycl.heuristic

description::
"Every representation is a trade-off between expressiveness (how easily you can say complicated things) and efficiency (how easily the machine can reason with what you've told it).
English is very expressive but not very efficient.
Most computer languages, such as Basic, C, and Fortran, are efficient but not very expressive.
To get both qualities, we separated the epistemological problem (what should the system know?) from the heuristic problem (how can it effectively reason with what it knows?) and developed two separate languages, respectively EL and HL.
Our knowledge enterers talk to CYC in the clean, expressive language (EL).
Their input is then converted into the heuristic language (HL), which is efficient for dealing with many sorts of frequently recurring inference problems, such as reasoning about time, causality, containment, and so forth."
[{2021-02-12} http://web.archive.org/web/20001208155800/http://www.cyc.com/halslegacy.html]

name::
* McsEngl.lagCycl.HL'(heuristic-language),
* McsEngl.lagCycl.heuristic,

descriptionLong::
"heuristic level (HL)
Another name for this might be "implementation level". Heuristic level refers to the way knowledge is actually stored, and inference implemented, in CYC®. This stands in contrast to the Epistemological Level (EL), which refers to the way knowledge is expressed when CYC® communicates with users or external programs."
[{2021-02-12} http://web.archive.org/web/20121219042246/http://www.cyc.com:80/cycdoc/ref/glossary.html#HL]

lagCnpt.Wolfram-language-018

description::
"The Wolfram Language is a highly developed knowledge-based language that unifies a broad range of programming paradigms and uses its unique concept of symbolic programming to add a new level of flexibility to the very concept of programming."
[{2021-02-14} http://reference.wolfram.com/language/guide/LanguageOverview.html]

name::
* McsEngl.Lwlfm!⇒lagWlfm,
* McsEngl.Wlfml!⇒lagWlfm,
* McsEngl.Wolfram-language!⇒lagWlfm,
* McsEngl.lagWlfm,
* McsEngl.lagWlfm'(Wolfram-language)!⇒lagWlfm,
* McsEngl.lagWolfram!⇒lagWlfm,

descriptionLong::
"The Wolfram Language is a computer language. It gives you a way to communicate with computers, in particular so you can tell them what to do.
There are many computer languages, such as C++, Java, Python and JavaScript. The Wolfram Language is unique in that it’s knowledge based. That means that it already knows a lot—so you have to tell it much less to get it to do things you want."
[{2021-01-26} https://www.wolfram.com/language/elementary-introduction/2nd-ed/what-is-the-wolfram-language.html]

tech of lagWlfm

description::
· any techInfo that uses lagWlfm.

name::
* McsEngl.Wlfmltech,
* McsEngl.lagWlfm'tech!⇒Wlfmltech,

Wolfram-system of Wlfmltech

description::
"The Wolfram Language is fundamentally an interpreter that scans through expressions calling internal code pointed to by the symbol table entries of heads that it encounters."
[{2021-02-21} https://reference.wolfram.com/language/tutorial/SomeNotesOnInternalImplementation.html#16446]
===
"The Wolfram System is one of the more complex software systems ever constructed.
It is built from several million lines of source code, written in C/C++, Java, and the Wolfram Language."
[http://reference.wolfram.com/language/tutorial/TheSoftwareEngineeringOfTheWolframSystem.html]

name::
* McsEngl.Wlfmlapp!⇒Wlfmlsys,
* McsEngl.Wlfmlsys,
* McsEngl.Wlfmltech'Wolfram-system!⇒Wlfmlsys,
* McsEngl.Wolfram-language-application!⇒Wlfmlsys,
* McsEngl.Wolfram-system!⇒Wlfmlsys,

directory of Wlfmlsys

description::
"The main installation directory has three standard subdirectories that contain material distributed with the Wolfram System. Under normal circumstances, none of the contents of these directories should ever be modified, except, for example, if you choose to edit a shared stylesheet.
* AddOns bundled Wolfram System add-ons
* Documentation Wolfram Language documentation
* SystemFiles Wolfram System files
Top-level subdirectories of the main installation directory."
[http://reference.wolfram.com/language/tutorial/WolframSystemFileOrganization.html]"

name::
* McsEngl.Wlfmlsys'directory,

kernel of Wlfmlsys

description::
"The Wolfram Language kernel is a process that runs under the operating system on your computer. Within the Wolfram Language there are several global variables that allow you to find the characteristics of this process and its environment.
[http://reference.wolfram.com/language/tutorial/GlobalSystemInformation.html]
===
In the Wolfram Language kernel the breakdown of different parts of the code is roughly as follows: language and system: 30%; numerical computation: 20%; algebraic computation: 20%; graphics and kernel output: 30%.
... The source code for the kernel, save a fraction of a percent, is identical for all computer systems on which the Wolfram System runs.
[http://reference.wolfram.com/language/tutorial/TheSoftwareEngineeringOfTheWolframSystem.html]

name::
* McsEngl.Wlfmlsys'kernel,

user-interface of Wlfmlsys

description::
· the-part of Wlfmlsys[a] with which a-user interacts with it[a].

name::
* McsEngl.Wlfmlsys'front-end!⇒Wlfmlui,
* McsEngl.Wlfmlsys'user-interface!⇒Wlfmlui,
* McsEngl.Wlfmlui,
* McsEngl.Wlfmlui'(user-interface-of-Wlfmlsys)!⇒Wlfmlui,

code of Wlfmlui

description::
"For the front end, however, a significant amount of specialized code is needed to support each different type of user interface environment. The front end contains about 700,000 lines of system-independent C++ source code, of which roughly 200,000 lines are concerned with expression formatting. Then there are between 50,000 and 100,000 lines of specific code customized for each user interface environment."
[http://reference.wolfram.com/language/tutorial/TheSoftwareEngineeringOfTheWolframSystem.html]

name::
* McsEngl.Wlfmlui'code,

Wlfmlui.SPECIFIC

description::
* batch-interface,
* notebook-interface,
* Wolfram|Alpha,
* Wolfram-Cloud,

name::
* McsEngl.Wlfmlui.specific,

Wlfmlui.batch-mode

description::
"The Wolfram System is usually used interactively, but it can also operate in a batch mode—say taking input from a file and writing output to a file. In such a case, a program cannot for example expect to get interactive input from the user."
[http://reference.wolfram.com/language/tutorial/GlobalSystemInformation.html]

name::
* McsEngl.Wlfmlui.batch-mode,

Wlfmlui.text-based

description::
"The standard front end interface, as discussed in "Using a Notebook Interface", is appropriate for most users' purposes.
In some cases, however, you may not need to use the notebook front end, and you may want instead to interact more directly with the Wolfram Language kernel. You can do this by using a text‐based interface, in which text you type on the keyboard goes straight to the kernel.
It is important to note that while the text-based interface provides access to most of the capabilities of the Wolfram Language kernel, the graphics functionality and dynamic interactivity of the Wolfram System front end are not available.

name::
* McsEngl.Wlfmlui.text-based,

Wlfmlui.notebook

description::
"From simple calculations to full publishable documents and sophisticated dynamic interfaces, everything you can do with the Wolfram System's standard interactive interface is done in a notebook. Carefully designed to leverage familiar word-processing metaphors, Wolfram System notebooks are uniquely powerful computational documents that support live computation, arbitrary dynamic interfaces, full typeset input, image input, automatic code annotation, a complete high-level programmatic interface, and in all, thousands of carefully organized functions and options."
[{2021-02-16} https://reference.wolfram.com/language/guide/NotebookBasics.html]
===
· expession: Notebook[cells, options]

name::
* McsEngl.Wlfmlnbi,
* McsEngl.Wlfmlnbi'(notebook-interface-of-lagWlfm)!⇒Wlfmlnbi,
* McsEngl.Wlfmlui.notebook!⇒Wlfmlnbi,
* McsEngl.lagWlfm'notebook-interface!⇒Wlfmlnbi,
* McsEngl.notebook-front-end-of-lagWlfm!⇒Wlfmlnbi,

descriptionLong::
"Like everything else in the Wolfram Language, notebooks are ultimately symbolic expressions. When you edit notebooks—or apply high-level programmatic functions—the Wolfram Language automatically updates these expressions. But if you look at the lowest level—say by opening a notebook file as text—you will see the underlying expressions, in which formatting constructs are represented as a hierarchy of low-level symbolic "boxes"."
[{2021-02-18} https://reference.wolfram.com/language/guide/LowLevelNotebookStructure.html]

shortcut of Wlfmlnbi

description::
* = — at beginning of input: specify a complete computation using natural language.
* Ctrl+= — translate from natural language anywhere in Wolfram Language input.
— specify an entity using natural language.
* Ctrl+Shift+e — toggle between formatted display and underlying symbolic expression

name::
* McsEngl.Wlfmlsys'shortcut,
* McsEngl.Wlfmlnbi'shortcut,

cell of Wlfmlnbi

description::
· the-parts of a-notebook.
· expression: Cell[contents,"style",options]

name::
* McsEngl.Wlfmlnbi'cell,

CDF of lagWlfm

description::
"CDF: Computable Document Format
Make computable documents part of the language
Built into the Wolfram Language are "notebook" documents that mix executable code with text, graphics, interfaces and more.
* Make a single document with code, examples, documentation, etc.
* Programmatically create full-featured reports and documents
* Instantly create interactive elements backed by computation
* 11,000+ examples in the Wolfram Demonstrations Project
[{2021-02-17} https://www.wolfram.com/language/principles/]

name::
* McsEngl.CDF'(computable-document-format),
* McsEngl.computable-document-format-of-lagWlfm,
* McsEngl.lagWlfm'CDF'(computable-document-format),

info-resource of Wlfmlnbi

description::
* https://reference.wolfram.com/language/tutorial/UsingANotebookInterface.html,
* https://reference.wolfram.com/language/tutorial/NotebooksAsDocuments.html,
* https://reference.wolfram.com/language/tutorial/ManipulatingNotebooks.html,
* https://reference.wolfram.com/language/guide/NotebookBasics.html,
* https://reference.wolfram.com/language/guide/SpecialCharacters.html,
* https://www.wolfram.com/wolfram-u/introduction-to-notebooks/,
* https://reference.wolfram.com/language/guide/NotebookShortcuts.html,
* embed in webpages: https://reference.wolfram.com/language/WolframNotebookEmbedder/,

name::
* McsEngl.Wlfmlnbi'Infrsc,

interpreter of Wlfmlsys

description::
"The Wolfram System compiler provides an important way both to speed up and also to work with Wolfram Language computations."
[http://reference.wolfram.com/language/Compile/tutorial/Overview.html]

name::
* McsEngl.Wlfmlsys'interpreter!⇒Wlfmlitpr, /intérpiter/,
* McsEngl.Wlfmlitpr,
* McsEngl.Wlfmlitpr'(interpreter-of-lagWlfm)!⇒Wlfmlitpr,
* McsEngl.lagWlfm'compiler!⇒Wlfmlitpr,
* McsEngl.lagWlfm'interpreter!⇒Wlfmlitpr,

info-resource of Wlfmlitpr

description::
* https://reference.wolfram.com/language/Compile/tutorial/Overview.html,
* https://reference.wolfram.com/language/Compile/tutorial/Introduction.html,

name::
* McsEngl.Wlfmlitpr'Infrsc,

memory of Wlfmlsys

description::
"Particularly for symbolic computations, memory is usually the primary resource which limits the size of computations you can do. If a computation runs slowly, you can always potentially let it run longer. But if the computation generates intermediate expressions which simply cannot fit in the memory of your computer system, then you cannot proceed with the computation.
The Wolfram System is careful about the way it uses memory. Every time an intermediate expression you have generated is no longer needed, the Wolfram System immediately reclaims the memory allocated to it. This means that at any point in a session, the Wolfram System stores only those expressions that are actually needed; it does not keep unnecessary objects which have to be "garbage collected" later."
[{2021-02-16} https://reference.wolfram.com/language/tutorial/GlobalAspectsOfWolframSystemSessions.html#15717]

name::
* McsEngl.Wlfmlsys'memory,

info-resource of Wlfmlsys

description::
* https://reference.wolfram.com/language/guide/SystemInformation.html,

name::
* McsEngl.Wlfmlsys'Infrsc,

structure of Wlfmlsys

description::
"A full Wolfram System installation consists of thousands of separate files, arranged in several hundred directories under the main installation directory."
[http://reference.wolfram.com/language/tutorial/WolframSystemFileOrganization.html]

name::
* McsEngl.Wlfmlsys'structure,

Wlfmlsys.SPECIFIC

description::
* Wolfram|Alpha,
* Wolfram-Cloud,
* Wolfram-Mathematica,

name::
* McsEngl.Wlfmlsys.specific,

WloframScript of Wlfmltech

description::
"WolframScript runs Wolfram Language code, functions and deployed APIs locally, in the cloud or on WSTPServer, allowing input from standard input, command-line arguments, files, URLs, etc."
[{2021-02-20} https://reference.wolfram.com/language/ref/program/wolframscript.html]
"WolframScript enables Wolfram Language code to be run from any terminal, whether or not a Wolfram kernel is available on the system.
With WolframScript, users can decide where and how to run their Wolfram Language code. Along with configurable kernel and cloud settings, WolframScript includes a collection of convenience functions for a wide variety of tasks, including running pure functions with command-line input, calling cloud APIs and exporting data to any format supported by the Wolfram Language. Now you can run code in the Wolfram Cloud with wolframscript -cloud or with #!/usr/bin/env wolframscript -cloud in Unix shell scripts."
[{2021-02-20} https://www.wolfram.com/wolframscript/]

name::
* McsEngl.Wlfmltech.WolframScript,
* McsEngl.WolframScript,

Mathematica of Wlfmltech

description::
"WOLFRAM MATHEMATICA
The world's definitive system for modern technical computing
For three decades, Mathematica has defined the state of the art in technical computing—and provided the principal computation environment for millions of innovators, educators, students, and others around the world.
Widely admired for both its technical prowess and elegant ease of use, Mathematica provides a single integrated, continually expanding system that covers the breadth and depth of technical computing—and seamlessly available in the cloud through any web browser, as well as natively on all modern desktop systems."
[{2021-02-16} https://www.wolfram.com/mathematica/]

name::
* McsEngl.Wlfmlmath,
* McsEngl.Wlfmlmath'(Wolfram-Mathematica)!⇒Wlfmlmath,
* McsEngl.Wlfmltech.Mathematica!⇒Wlfmlmath,

Wolfram|Alpha of Wlfmltech

description::
"Wolfram|Alpha is a unique engine for computing answers and providing knowledge.
It works by using its vast store of expert-level knowledge and algorithms to automatically answer questions, do analysis and generate reports."
[{2021-02-10} https://www.wolframalpha.com/tour/]

name::
* McsEngl.Wlfmltech'Wolfram|Alpha,
* McsEngl.Wolfram|Alpha,

Wolfram-cloud of Wlfmltech

description::
"The Wolfram Cloud combines a state-of-the-art notebook interface with the world's most productive programming language—scalable for programs from tiny to huge, with immediate access to a vast depth of built-in algorithms and knowledge.
Natively running the Wolfram Language, the Wolfram Cloud in effect makes every aspect of cloud operations programmable—introducing an unprecedented level of integration, flexibility, simplicity and power into a new generation of cloud technology.
Products Powered by the Wolfram Cloud
Wolfram Cloud Basic offers free access to get started immediately. Sign up for free access
WOLFRAM|ONE »
Your entry point to the Wolfram technology stack.
MATHEMATICA ONLINE »
Bring Mathematica to life in the cloud.
WOLFRAM PROGRAMMING LAB »
Get introduced to modern computational thinking with the Wolfram Language.
WOLFRAM CLOUD APP »
Mobile-optimized interface to view and edit notebooks, and access cloud-deployed apps.
WOLFRAM DATA DROP »
Open service that makes it easy to accumulate data of any kind, from anywhere.
WOLFRAMSCRIPT »
Run Wolfram Language code from any terminal, even if a local Wolfram kernel is unavailable.
WOLFRAM ENTERPRISE PRIVATE CLOUD »
Install a complete private instance of the Wolfram Cloud inside your organization.
WOLFRAM|ALPHA APPLIANCE »
Get a custom, private Wolfram|Alpha within your organization or with your data."
[{2021-02-14} https://www.wolfram.com/cloud/]

name::
* McsEngl.Wlfmlcloud,
* McsEngl.Wlfmltech'Wolfram-cloud!⇒Wlfmlcloud,
* McsEngl.Wolfram-cloud!⇒Wlfmlcloud,

info-resource of Wlfmlcloud

description::
* https://www.wolframcloud.com/,

name::
* McsEngl.Wlfmlcloud'Infrsc,

input of lagWlfm

description::
"SOME OF WHAT'S BUILT INTO THE WOLFRAM LANGUAGE:
* 2D, 3D Visualization,
* Graph Analysis,
* Data Analytics,
* Image Processing,
* Audio Processing,
* Machine Learning,
* Equation Solving,
* Algebraic Computation,
* Arbitrary Precision,
* Calculus Computation,
* Matrix Computation,
* String Manipulation,
* Combinatorial Optimization,
* Computational Geometry,
* Database Connectivity,
* Built-In Testing,
* Device Connectivity,
* Functional Programming,
* Natural Language Understanding,
* Sequence Analysis,
* Time Series,
* Geographic Data,
* Geomapping,
* Weather Data,
* Physics & Chemistry Data,
* Genomic Data,
* Units & Measures,
* Control Theory,
* Reliability Analysis,
* Parallel Computation,
* Engineering Data,
* Financial Data,
* Financial Computation,
* Socioeconomic Data,
* Popular Culture Data,
* Boolean Computation,
* Number Theory,
* Document Generation,
* Table Formatting,
* Mathematical Typesetting,
* Interactive Controls,
* Interface Building,
* Form Construction,
* XML Templating,
* Data Import & Export,
* Semantic Interpretation,
* API Connectivity,
* Interprocess Communication,
[http://www.wolfram.com/programming-cloud/?source=footer]

name::
* McsEngl.Wlfmlinput,
* McsEngl.lagWlfm'input!⇒Wlfmlinput,

output of lagWlfm

description::
· any output model of the-input.

name::
* McsEngl.Wlfmloutput,
* McsEngl.lagWlfm'output!⇒Wlfmloutput,

expression-(en) of Wlfmloutput

description::
"Everything in the Wolfram Language is a symbolic expression.
numbers strings images arrays graphs formulas documents interfaces code ...
All symbolic expressions have the same fundamental structure: head[arguments]
[{2021-02-21} https://www.wolfram.com/language/fast-introduction-for-programmers/en/symbolic-expressions/]
===
"Everything Is an Expression
The Wolfram Language handles many different kinds of things: mathematical formulas, lists, and graphics, to name a few. Although they often look very different, the Wolfram Language represents all of these things in one uniform way. They are all expressions."
[{2021-02-15} https://reference.wolfram.com/language/tutorial/Expressions.html#4715]

name::
* McsEngl.Wlfmlen,
* McsEngl.Wlfmlen'(expression-of-lagWlfm)!⇒Wlfmlen,
* McsEngl.Wlfmloutput'expression!⇒Wlfmlen,
* McsEngl.expression@lagWlfm!⇒Wlfmlen,
* McsEngl.lagWlfm'expression!⇒Wlfmlen,
* McsEngl.lagWlfm'symbolic-expression!⇒Wlfmlen,
* McsEngl.symbolic-expression@lagWlfm!⇒Wlfmlen,

descriptionLong::
"At the core of the Wolfram Language is the foundational idea that everything—data, programs, formulas, graphics, documents—can be represented as symbolic expressions.
And it is this unifying concept that underlies the Wolfram Language's symbolic programming paradigm, and makes possible much of the unique power of the Wolfram Language and the Wolfram System."
[{2021-02-15} https://reference.wolfram.com/language/guide/Expressions.html]
"We’ve now seen all sorts of things that exist in the Wolfram Language: lists, graphics, pure functions and much more. And now we’re ready to discuss a very fundamental fact about the Wolfram Language: that each of these things—and in fact everything the language deals with—is ultimately constructed in the same basic kind of way. Everything is what’s called a symbolic expression.
Symbolic expressions are a very general way to represent structure, potentially with meaning associated with that structure. f[x,y] is a simple example of a symbolic expression."
[{2021-02-14} https://www.wolfram.com/language/elementary-introduction/2nd-ed/33-expressions-and-their-structure.html]

part of Wlfmlen

description::
* head,
* element,

name::
* McsEngl.Wlfmlen'part,

head of Wlfmlen

description::
"In f[x,y], f is called the head of the expression. x and y are called arguments. The function Head extracts the head of an expression.
... Every part of an expression has a head, even its atoms."
[{2021-02-14} https://www.wolfram.com/language/elementary-introduction/2nd-ed/33-expressions-and-their-structure.html]

name::
* McsEngl.Wlfmlen'head,

element of Wlfmlen

description::
"A Wolfram Language expression internally consists of a contiguous array of pointers, the first to the head, and the rest to its successive elements.
[http://reference.wolfram.com/language/tutorial/SomeNotesOnInternalImplementation.html]"

name::
* McsEngl.Wlfmlen'element,

level of Wlfmlen

description::
"Levels provide a general way of specifying collections of parts in Wolfram Language expressions. Many Wolfram Language functions allow you to specify the levels in an expression on which they should act.
... You can think of levels in expressions in terms of trees. The level of a particular part in an expression is simply the distance down the tree at which that part appears, with the top of the tree considered as level 0."
[http://reference.wolfram.com/language/tutorial/LevelsInExpressions.html]

name::
* McsEngl.Wlfmlen'level,

form of Wlfmlen

description::
· syntax of an-expression

name::
* McsEngl.Wlfmlen'form,
* McsEngl.lagWlfm'form-of-expression,

input-form of Wlfmlen

description::
"The Wolfram Language allows you to use special notation for many common operators. For example, although internally the Wolfram System represents a sum of two terms as Plus[x,y], you can enter this expression in the much more convenient form x+y.
... The Wolfram Language has a definite grammar that specifies how your input should be converted to internal form."
[http://reference.wolfram.com/language/tutorial/SpecialWaysToInputExpressions.html]
===
* f[x,y] standard form for f
* f@x prefix form for f[x]
* x//f postfix form for f[x]
* x~f~y infix form for f
Four ways to write expressions in the Wolfram Language.
[http://reference.wolfram.com/language/tutorial/SpecialWaysToInputExpressions.html]

name::
* McsEngl.Wlfmlsys'input-form-of-expression,
* McsEngl.Wlfmlen'input-form,

output-form of Wlfmlen

description::
"OutputForm[expr]
prints as a two-dimensional representation of expr using only keyboard characters.
OutputForm is an approximation to StandardForm which uses only ordinary keyboard characters.
* The OutputForm of many kinds of expressions is quite different from their internal representation.
* When an input evaluates to OutputForm[expr], OutputForm does not appear in the output. »
* OutputForm cannot be used directly for input to the Wolfram Language.
* When possible, OutputForm uses approximations to special characters. Thus ≥ is given as >= and é as e'. »"
[{2021-02-18} https://reference.wolfram.com/language/ref/OutputForm.html]

name::
* McsEngl.Wlfmlen'output-form,

internal-form of Wlfmlen

description::
"The Wolfram Language allows you to use special notation for many common operators. For example, although internally the Wolfram System represents a sum of two terms as Plus[x,y], you can enter this expression in the much more convenient form x+y.
... The Wolfram Language has a definite grammar that specifies how your input should be converted to internal form."
[http://reference.wolfram.com/language/tutorial/SpecialWaysToInputExpressions.html]

name::
* McsEngl.Wlfmlen'internal-form,

binary-form of Wlfmlen

description::
"A Wolfram Language expression internally consists of a contiguous array of pointers, the first to the head, and the rest to its successive elements.
Each expression contains a special form of hash code that is used both in pattern matching and evaluation."
[http://reference.wolfram.com/language/tutorial/SomeNotesOnInternalImplementation.html]
===
general expressions sequences of pointers to the head and elements
[http://reference.wolfram.com/language/tutorial/BasicInternalArchitecture.html]

name::
* McsEngl.Wlfmlen'binary-form,

TraditionalForm of Wlfmlen

description::
"TraditionalForm differs from StandardForm, the default format for input and output. It is important to understand that TraditionalForm expressions cannot always be provided as unambiguous input to the Wolfram System. Therefore, while StandardForm is an input format and an output format, TraditionalForm is primarily intended as an output format.
In general, the TraditionalForm representation of a mathematical function differs from its StandardForm representation in two ways: function arguments are enclosed in parentheses rather than square brackets, and one-character variable and function names are set in italics rather than plain text.
In addition to these general differences, TraditionalForm transforms a large group of expressions into their conventionally used mathematical notation."
[{2021-02-18} https://reference.wolfram.com/language/tutorial/TraditionalFormReferenceInformation.html]

name::
* McsEngl.Wlfmlen'TraditionalForm,
* McsEngl.lagWlfm'TraditionalForm,

full-form of Wlfmlen

description::
·

name::
* McsEngl.Wlfmlen'full-form,

tree-form of Wlfmlen

description::
"You can think of any Wolfram Language expression as a tree."
[http://reference.wolfram.com/language/tutorial/ExpressionsAsTrees.html]

name::
* McsEngl.Wlfmlen'tree-form,

TeXForm of Wlfmlen

description::
TeXForm[x^2 + Sqrt[y]] >> x^2+\sqrt{y}

name::
* McsEngl.Wlfmlen'TeXForm,
* McsEngl.lagWlfm'TeXForm,

MathMLForm of Wlfmlen

description::
·

name::
* McsEngl.Wlfmlen'MathMLForm,
* McsEngl.lagWlfm'MathMLForm,

Grid of Wlfmlen

description::
· Grid[{{1,2,3},{4,5,6}}], output like table.

name::
* McsEngl.Wlfmlen'Grid,

TableForm of Wlfmlen

description::
· TableForm[{{1,2,3},{4,5,6}}]

name::
* McsEngl.Wlfmlen'TableForm,

CForm of Wlfmlen

description::
·

name::
* McsEngl.Wlfmlen'CForm,
* McsEngl.lagWlfm'CForm,

FortranForm of Wlfmlen

description::
·

name::
* McsEngl.Wlfmlen'FortranForm,
* McsEngl.lagWlfm'FortranForm,

info-resource of Wlfmlen

description::
* https://reference.wolfram.com/language/tutorial/Expressions.html,
* https://reference.wolfram.com/language/tutorial/EvaluationOfExpressions.html,
* https://reference.wolfram.com/language/guide/Expressions.html,

name::
* McsEngl.Wlfmlen'Infrsc,

structure of Wlfmlen

description::
"You can think of any Wolfram Language expression as a tree."
[http://reference.wolfram.com/language/tutorial/ExpressionsAsTrees.html]
===
"Expression Structure
A foundational idea in the Wolfram Language is that all expressions—whatever they may represent—ultimately have a uniform tree-like structure."
[http://reference.wolfram.com/language/guide/ExpressionStructure.html]
===
"Thus, for example, the pattern (1+x_)^2 can stand for expressions like (1+a)^2 or (1+b^3)^2 that have the same structure. However, it cannot stand for the expression 1+2a+a^2. Although this expression is mathematically equal to (1+a)^2, it does not have the same structure as the pattern (1+x_)^2.
The fact that patterns in the Wolfram Language specify the structure of expressions is crucial in making it possible to set up transformation rules which change the structure of expressions, while leaving them mathematically equal.
It is worth realizing that in general it would be quite impossible for the Wolfram Language to match patterns by mathematical, rather than structural, equivalence."
[http://reference.wolfram.com/language/tutorial/Introduction-Patterns.html]

name::
* McsEngl.Wlfmlen'structure,

DOING of Wlfmlen

usage of Wlfmlen

description::
"Although all expressions have the same basic structure, there are many different ways that expressions can be used."
[http://reference.wolfram.com/language/tutorial/TheMeaningOfExpressions.html]
===
"Expressions in the Wolfram System are often used to specify operations. So, for example, typing in 2+3 causes 2 and 3 to be added together, while Factor[x^6-1] performs factorization.
Perhaps an even more important use of expressions in the Wolfram System, however, is to maintain a structure, which can then be acted on by other functions. An expression like {a,b,c} does not specify an operation. It merely maintains a list structure, which contains a collection of three elements. Other functions, such as Reverse or Dot, can act on this structure.
The full form of the expression {a,b,c} is List[a,b,c]. The head List performs no operations. Instead, its purpose is to serve as a "tag" to specify the "type" of the structure.
You can use expressions in the Wolfram System to create your own structures. For example, you might want to represent points in three‐dimensional space, specified by three coordinates. You could give each point as point[x,y,z]. The "function" point again performs no operation. It serves merely to collect the three coordinates together, and to label the resulting object as a point.
You can think of expressions like point[x,y,z] as being "packets of data", tagged with a particular head. Even though all expressions have the same basic structure, you can distinguish different "types" of expressions by giving them different heads. You can then set up transformation rules and programs which treat different types of expressions in different ways.
[{2021-02-15} https://reference.wolfram.com/language/tutorial/Expressions.html#20284]

name::
* McsEngl.Wlfmlen'usage,

testing of Wlfmlen

description::
"Wolfram Language symbolic expressions can represent an immense range of types of objects.
The Wolfram Language provides a rich collection of functions to test expressions. Functions that "ask a question" have names that end in Q. They return True for an explicit true answer, and False otherwise."
[http://reference.wolfram.com/language/guide/TestingExpressions.html]

name::
* McsEngl.Wlfmlen'testing,

Wlfmlen.SPECIFIC

description::
* assignment,
* association,
* atom,
* function,
* list,
* number,
* operation,
* operationNo,
* rule,
* string,
* symbol,
===
"Wolfram Language symbolic expressions can represent an immense range of types of objects."
[http://reference.wolfram.com/language/guide/TestingExpressions.html]
===
* x+y+z Plus[x,y,z]
* xyz Times[x,y,z]
* x^n Power[x,n]
* {a,b,c} List[a,b,c]
* a->b Rule[a,b]
* a=b Set[a,b]
Some examples of Wolfram Language expressions.
[{2021-02-15} https://reference.wolfram.com/language/tutorial/Expressions.html#4715]

name::
* McsEngl.Wlfmlen.specific,

atom-(am) of Wlfmloutput

description::
"All expressions in the Wolfram Language are ultimately made up from a small number of basic or atomic types of objects.
These objects have heads that are symbols that can be thought of as "tagging" their types. The objects contain "raw data", which can usually be accessed only by functions specific to the particular type of object. You can extract the head of the object using Head, but you cannot directly extract any of its other parts.
* Symbol symbol (extract name using SymbolName )
* String character string "cccc" (extract characters using Characters)
* Integer integer (extract digits using IntegerDigits )
* Real approximate real number (extract digits using RealDigits )
* Rational rational number (extract parts using Numerator and Denominator)
* Complex complex number (extract parts using Re and Im)
Atomic objects.
Atomic objects in the Wolfram Language are considered to have depth 0 and yield True when tested with AtomQ."
[{2021-02-14} https://reference.wolfram.com/language/tutorial/BasicObjects.html#15871]

name::
* McsEngl.Wlfmlam,
* McsEngl.Wlfmlam'(atomic-object-of-lagWlfm)!⇒Wlfmlam,
* McsEngl.Wlfmloutput'atomic-object!⇒Wlfmlam,
* McsEngl.Wlfmloutput'basic-object!⇒Wlfmlam,
* McsEngl.atomic-object@lagWlfm!⇒Wlfmlam,
* McsEngl.lagWlfm'atom!⇒Wlfmlam,
* McsEngl.lagWlfm'atomic-element!⇒Wlfmlam,

descriptionLong::
"All expressions in the Wolfram Language are ultimately built from a small number of distinct types of atomic elements."
[{2021-02-17} https://reference.wolfram.com/language/guide/AtomicElementsOfExpressions.html]

specific-tree-of-Wlfmlam::
* number,
* string,
* symbol,
"What are the ultimate building blocks of symbolic expressions? They’re called atoms (after the building blocks of physical materials). The main kinds of atoms are numbers, strings and symbols."
[{2021-02-14} https://www.wolfram.com/language/elementary-introduction/2nd-ed/33-expressions-and-their-structure.html]

Wlfmlam.number-(nr)

description::
·

name::
* McsEngl.Wlfmlnr,
* McsEngl.Wlfmlnr'(number-of-lagWlfm)!⇒Wlfmlnr,
* McsEngl.Wlfmloutput'number!⇒Wlfmlnr,
* McsEngl.lagWlfm'number!⇒Wlfmlnr,

Wlfmlam.string-(sg)

description::
· a-sequence of characters: "string"

name::
* McsEngl.Wlfmloutput'string!⇒Wlfmlsg,
* McsEngl.Wlfmlsg,
* McsEngl.Wlfmlsg'(string-of-lagWlfm)!⇒Wlfmlsg,
* McsEngl.lagWlfm'string!⇒Wlfmlsg,

functions of Wlfmlsg

description::
· functions of strings:
* StringLength["string"] length of a string
* StringReverse["string"] reverse a string
* StringTake["string",4] take characters at the beginning of a string
* StringJoin["string","string"] join strings together
* StringJoin[{"string","string"}] join a list of strings
* ToUpperCase["string"] convert characters to uppercase
* Characters["string"] convert a string to a list of characters
* TextWords["string"] list of words from a string
* TextSentences["string"] list of sentences
* WikipediaData["topic"] Wikipedia article about a topic
* WordCloud["text"] word cloud based on word frequencies
* WordList[ ] list of common words in English
* Alphabet[] list of letters of the alphabet
* LetterNumber["c"] where a letter appears in the alphabet
* FromLetterNumber[n] letter appearing at a position in the alphabet
* Transliterate["text"] transliterate text in any language into English
* Transliterate["text","alphabet"] transliterate text into other alphabets
* RomanNumeral[n] convert a number to its Roman numeral string
* IntegerName[n] convert a number to its English name string
* InputForm["string"] show a string with quotes
* Rasterize["string"] make a bitmap image
[{2021-02-14} https://www.wolfram.com/language/elementary-introduction/2nd-ed/11-strings-and-text.html]

name::
* McsEngl.Wlfmlfn.string,
* McsEngl.Wlfmlsg'function,

Wlfmlam.symbol-(sl)

description::
"Things like x, y, f, Plus, Graphics and Table are all symbols. Every symbol has a unique name. Sometimes it’ll also have a meaning attached. Sometimes it’ll be associated with evaluation. Sometimes it’ll just be part of defining a structure that other functions can use. But it doesn’t have to have any of those things; it just has to have a name.
A crucial defining feature of the Wolfram Language is that it can handle symbols purely as symbols—“symbolically”—without them having to evaluate, say to numbers."
[{2021-02-14} https://www.wolfram.com/language/elementary-introduction/2nd-ed/33-expressions-and-their-structure.html]

name::
* McsEngl.Wlfmloutput'symbol!⇒Wlfmlsl,
* McsEngl.Wlfmlsl,
* McsEngl.Wlfmlsl'(symbol-of-lagWlfm)!⇒Wlfmlsl,
* McsEngl.lagWlfm'symbol!⇒Wlfmlsl,
* McsEngl.symbol@lagWlfm!⇒Wlfmlsl,

individual-name of Wlfmlsl

description::
· name for an-individual-symbol.

name::
* McsEngl.Wlfmlsl'name.individual,
* McsEngl.Wlfmlsl'individual-name,

full-name of Wlfmlsl

description::
"The full name of any symbol in the Wolfram Language consists of two parts: a context and a short name.
The full name is written in the form context ` name."
[http://reference.wolfram.com/language/tutorial/BasicObjects.html#1832]

name::
* McsEngl.Wlfmlsl'full-name,

short-name of Wlfmlsl

description::
"In general, when you type in a short name for a symbol, the Wolfram Language assumes that you want the symbol with that name whose context appears EARLIEST in the context search path.
As a result, symbols with the same short name whose contexts appear LATER in the context search path or symbols with the same short name in the current context are effectively "shadowed". To refer to these symbols, you need to use their full names.
The Wolfram Language issues a message when you introduce new symbols that "shadow" existing symbols with your current choice for $ContextPath. In addition, in the notebook front end the Wolfram Language warns you of shadowed symbols by coloring them red."
[http://reference.wolfram.com/language/tutorial/Contexts.html]

name::
* McsEngl.Wlfmlsl'short-name,

value of Wlfmlsl

description::
"Any Wolfram Language symbol can have both a variety of types of values, and a variety of independently settable attributes that define overall aspects of its behavior."
[http://reference.wolfram.com/language/guide/Attributes.html]
"Definitions such as f[x_]=x^2 specify values for functions."
[http://reference.wolfram.com/language/tutorial/Attributes.html]

name::
* McsEngl.Wlfmlsl'value,

attribute of Wlfmlsl

description::
"Any Wolfram Language symbol can have both a variety of types of values, and a variety of independently settable attributes that define overall aspects of its behavior."
[http://reference.wolfram.com/language/guide/Attributes.html]
"Definitions such as f[x_]=x^2 specify values for functions.
Sometimes, however, you need to specify general properties of functions, without necessarily giving explicit values.
The Wolfram Language provides a selection of attributes that you can use to specify various properties of functions. For example, you can use the attribute Flat to specify that a particular function is "flat", so that nested invocations are automatically flattened, and it behaves as if it were associative."
[http://reference.wolfram.com/language/tutorial/Attributes.html]

name::
* McsEngl.Wlfmlsl'attribute,
* McsEngl.Wlfmlsl'property,

context of Wlfmlsl

description::
"Wolfram Language symbols are the ultimate atoms of symbolic data. Every symbol has a unique name, exists in a certain Wolfram Language context or namespace, and can have a variety of types of values and attributes."
[http://reference.wolfram.com/language/guide/SymbolHandling.html]

name::
* McsEngl.Wlfmlcontext,
* McsEngl.Wlfmlsl'context!⇒Wlfmlcontext,
* McsEngl.Wlfmlsl'namespace!⇒Wlfmlcontext,
* McsEngl.namespace//lagWlf!⇒Wlfmlcontext,
* McsEngl.lagWlfm'context!⇒Wlfmlcontext,
* McsEngl.lagWlfm'namespace!⇒Wlfmlcontext,

context-mark of Wlfmlcontext

description::
"The full name is written as CONTEXT ` SHORT, where the ` is the backquote or grave accent character (ASCII decimal code 96), called a "context mark" in the Wolfram Language."
[http://reference.wolfram.com/language/tutorial/Contexts.html]

name::
* McsEngl.Wlfmlcontext'mark,
* McsEngl.lagWlfm'context-mark,

context-search-path of Wlfmlcontext

description::
"In order to let you easily access not only symbols in the context Global`, but also in contexts such as System`, the Wolfram Language supports the notion of a context search path.
At any point in a Wolfram Language session, there is both a current context $Context, and also a current context search path $ContextPath.
The idea of the search path is to allow you to type in the short name of a symbol, then have the Wolfram Language search in a sequence of contexts to find a symbol with that short name."
[http://reference.wolfram.com/language/tutorial/Contexts.html]

name::
* McsEngl.Wlfmlcontext'context-search-path,
* McsEngl.Wlfmlsl'context-search-path,
* McsEngl.lagWlfm'context-search-path,

Wlfmlcontext.SPECIFIC

description::
* CUDACompileTools`Utilities`,
* CloudObject`,
* CloudSystem`,
* CloudSystem`DataSciencePlatform`,
* CloudSystem`Grammar`,
* CloudSystem`Logging`,
* CloudSystem`OutputSizeLimit`,
* Compile`Core`CodeGeneration`Backend`LLVM`,
* CompilerSandbox`,
* EntityFrameworkCommonQueriesLoader`,
* Global`,
* JLink`,
* KernelServer`,
* LLVMCompileTools`,
* LLVMTools`,
* MSP`,
* MortalityPacletDataLoader`,
* SVTools`,
* Security`,
* StreamLink`,
* System`,
* Utilities`URLTools`,
* WolframAppCatalog`,

name::
* McsEngl.Wlfmlcontext.specific,

Wlfmlcontext.Global

description::
"When you start a Wolfram Language session, the default current context is Global`. Symbols that you introduce will usually be in this context."
[http://reference.wolfram.com/language/tutorial/Contexts.html]

name::
* McsEngl.Wlfmlcontext.default,
* McsEngl.Wlfmlcontext.Global,

Wlfmlcontext.System

description::
"When you start a Wolfram Language session, the default current context is Global`. Symbols that you introduce will usually be in this context.
However, built-in symbols such as Pi are in the context System`."
[http://reference.wolfram.com/language/tutorial/Contexts.html]

name::
* McsEngl.Wlfmlcontext.System,

symbolic-table of Wlfmlsl

description::
"For every symbol there is a central symbolic table entry that stores all information about the symbol."
[{2021-02-21} https://reference.wolfram.com/language/tutorial/SomeNotesOnInternalImplementation.html#11333]
===
"Crucial to the operation of the Wolfram Language is the notion of symbols such as x. Whenever x appears in an expression, the Wolfram Language represents it by a pointer. But the pointer is always to the same place in computer memory—an entry in a central table of all symbols defined in your Wolfram Language session.
This table is a repository of all information about each symbol. It contains a pointer to a string giving the symbol's name, as well as pointers to expressions that give rules for evaluating the symbol."
[{2021-02-21} https://reference.wolfram.com/language/tutorial/TheInternalsOfTheWolframSystem.html#6608]

name::
* McsEngl.Wlfmlsl'central-table-of-all-symbols,
* McsEngl.Wlfmlsl'symbolic-table,
* McsEngl.lagWlfm'central-symbolic-table,
* McsEngl.lagWlfm'symbolic-table,

DOING of Wlfmlsl

description::
* creating,
* removing,
* clearing-values,

name::
* McsEngl.Wlfmlsl'doing,

Wlfmlsl.SPECIFIC

description::
* builtin,
* builtinNo,
===
* global,
* local,
===
* variable,
* variableNo,

name::
* McsEngl.Wlfmlsl.specific,

Wlfmlsl.builtin

description::
"System-defined symbols conventionally have names that consist of one or more complete English words.
The first letter of each word is capitalized, and the words are run together."
[http://reference.wolfram.com/language/tutorial/BasicObjects.html#11134]

name::
* McsEngl.Wlfmlsl.builtin,
* McsEngl.Wlfmlsl.system,

Wlfmlsl.builtinNo

description::
"Once created, an ordinary symbol in the Wolfram Language continues to exist unless it is explicitly removed using Remove. However, symbols created automatically in scoping constructs such as Module carry the attribute Temporary, which specifies that they should automatically be removed as soon as they no longer appear in any expression.
When a new symbol is to be created, the Wolfram Language first applies any value that has been assigned to $NewSymbol to strings giving the name of the symbol and the context in which the symbol would be created.
If the message General::newsym is switched on, then the Wolfram Language reports new symbols that are created. This message is switched off by default. Symbols created automatically in scoping constructs are not reported."
[http://reference.wolfram.com/language/tutorial/BasicObjects.html#11134]

name::
* McsEngl.Wlfmlsl.builtinNo,
* McsEngl.Wlfmlsl.ordinary,

Wlfmlsl.global

description::
·

name::
* McsEngl.Wlfmlsl.global,

Wlfmlsl.globalNo

description::
"quite different variables in two different programs. In this case, you need the x in each program to be treated as a local variable.
You can set up local variables in the Wolfram Language using modules. Within each module, you can give a list of variables which are to be treated as local to the module."
[{2021-02-21} https://reference.wolfram.com/language/tutorial/ModularityAndTheNamingOfThings.html#7693]

name::
* McsEngl.Wlfmlsl.globalNo,
* McsEngl.Wlfmlsl.local,

Wlfmlsl.variable

description::
· variable is a-symbol with different values.

name::
* McsEngl.Wlfmlsl.variable,

Wlfmlsl.variableNo

description::
· constant is a-symbol with always the-same value.
===
"Module allows you to set up local variables, to which you can assign values and then change them. Often, however, all you really need are local constants, to which you assign a value only once. The Wolfram Language With construct allows you to set up such local constants."
[{2021-02-21} https://reference.wolfram.com/language/tutorial/ModularityAndTheNamingOfThings.html#19459]

name::
* McsEngl.Wlfmlsl.constant,
* McsEngl.Wlfmlsl.variableNo,

function-(fn) of Wlfmloutput

description::
"When you type 2+2, the Wolfram Language understands it as Plus[2,2]. Plus is a function. There are more than 5000 functions built into the Wolfram Language. Arithmetic uses just a very few of these."
[{2021-02-14} https://www.wolfram.com/language/elementary-introduction/2nd-ed/02-introducing-functions.html]

name::
* McsEngl.Wlfmlfn,
* McsEngl.Wlfmlfunction!⇒Wlfmlfn,
* McsEngl.Wlfmloutput'function!⇒Wlfmlfn,
* McsEngl.lagWlfm'function!⇒Wlfmlfn,

name of Wlfmlfn

description::
"The names of built‐in functions follow some general guidelines.
* The name consists of complete English words, or standard mathematical abbreviations. American spelling is used.
* The first letter of each word is capitalized.
* Functions whose names end with Q usually "ask a question", and return either True or False.
* Mathematical functions that are named after people usually have names in the Wolfram Language of the form PersonSymbol."
[{2021-02-14} https://reference.wolfram.com/language/tutorial/SomeGeneralNotationsAndConventions.html]

name::
* McsEngl.Wlfmlfn'name,

argument of Wlfmlfn

description::
"The main expression or object on which a built‐in function acts is usually given as the first argument to the function. Subsidiary parameters appear as subsequent arguments.
The following are exceptions:
* In functions like Map and Apply, the function to apply comes before the expression it is to be applied to.
* In scoping constructs such as Module and Function, local variables and parameter names come before bodies.
* In functions like Write and Export, the name of the file is given before the objects to be written to it.
For mathematical functions, arguments that are written as subscripts in standard mathematical notation are given before those that are written as superscripts."
[{2021-02-14} https://reference.wolfram.com/language/tutorial/SomeGeneralNotationsAndConventions.html#25128]

name::
* McsEngl.Wlfmlfn'argument,
* McsEngl.Wlfmlfn'parameter,

DOING of Wlfmlfn

description::
* creating,
* calling,

name::
* McsEngl.Wlfmlfn'doing,

creating of Wlfmlfn

description::
· f[x_] := x^2

name::
* McsEngl.Wlfmlfn'creating,
* McsEngl.Wlfmlfn'defining,

calling of Wlfmlfn

description::
· apply the-function f to 4:
· f[4]
· f@4
· 4//f
· f/@{2,3} //apply f to EACH element of the-list {2,3}
[{2021-02-14} https://www.wolfram.com/language/elementary-introduction/2nd-ed/25-ways-to-apply-functions.html]

name::
* McsEngl.Wlfmlfn'applying,
* McsEngl.Wlfmlfn'calling,

Wlfmlfn.SPECIFIC

description::
* https://reference.wolfram.com/language/ref/[name].html
===
* built-in,
* built-inNo,
====
* list-function,
* mathematical-function,
* string-function,

name::
* McsEngl.Wlfmlfn.specific,

list-(lt) of Wlfmloutput

description::
"Lists are a basic way to collect things together in the Wolfram Language. {1,2,3} is a list of numbers. On their own, lists don’t do anything; they’re just a way to store things."
[{2021-02-14} https://www.wolfram.com/language/elementary-introduction/2nd-ed/03-first-look-at-lists.html]

name::
* McsEngl.Wlfmllt,
* McsEngl.Wlfmllt(list-of-lagWlfm)!⇒Wlfmllt,
* McsEngl.Wlfmloutput'list!⇒Wlfmllt,
* McsEngl.lagWlfm'list!⇒Wlfmllt,

part of Wlfmllt

description::
"Parts of lists are indexed starting at 1, and can be extracted using [[ ... ]]"
[{2021-02-21} https://www.wolfram.com/language/fast-introduction-for-programmers/en/lists/]
· {a,b,c}[[1]] » a
· {a,b,c}[[3]] » c

name::
* McsEngl.Wlfmllt'part,

functions of Wlfmllt

description::
· functions on lists:
* {2,3,4}+{5,6,2} arithmetic on lists
* Sort[{5,7,1}] sort a list into order
* Length[{3,3}] length of a list (number of elements)
* Total[{1,1,2}] total of all elements in a list
* Count[{3,2,3},3] count occurrences of an element
* First[{2,3}] first element in a list
* Last[{6,7,8}] last element in a list
* Part[{3,1,4},2] particular part of a list, also written as {3, 1, 4}[[2]]
* Take[{6,4,3,1},2] take elements from the beginning of a list
* Drop[{6,4,3,1},2] drop elements from the beginning of a list
* IntegerDigits[1234] list of digits in a number
[{2021-02-14} https://www.wolfram.com/language/elementary-introduction/2nd-ed/05-operations-on-lists.html]

name::
* McsEngl.Wlfmlfn.list,
* McsEngl.Wlfmllt'function,

association-(an) of Wlfmloutput

description::
"Associations are a kind of generalization of lists, in which every element has a key as well as a value."
[{2021-02-14} https://www.wolfram.com/language/elementary-introduction/2nd-ed/34-associations.html]
· example: <|a->3,n->2,s->2,i->2,y->2,d->2|>

name::
* McsEngl.Wlfmlan,
* McsEngl.Wlfmlan'(association-of-lagWlfm)!⇒Wlfmlan,
* McsEngl.Wlfmloutput'association!⇒Wlfmlan,
* McsEngl.association@lagWlfm!⇒Wlfmlan,
* McsEngl.lagWlfm'association!⇒Wlfmlan,

Entity of Wlfmloutput

description::
· Entity["Country", "Greece"]
"The Wolfram Language provides access to curated, computable data about millions of entities across hundreds of entity types.
Wolfram Language entities represent physical entities as well as mathematical and other scientific concepts, and can be accessed via natural language input or programmatically retrieved and incorporated into complex computations.
Custom and dynamic entity types can also be introduced, from external entity stores, relational databases, etc. Entity — symbolic representation of an entity"
[{2021-02-22} https://reference.wolfram.com/language/guide/EntityTypes.html]

name::
* McsEngl.Entity@lagWlfm!⇒WlfmlEntity,
* McsEngl.WlfmlEntity,
* McsEngl.Wlfmloutput'Entity!⇒WlfmlEntity,

attribute of WlfmlEntity

description::
· Entity["Country","Greece"]["Population"] » 10473452 people
· EntityValue[Entity["Country","Greece"],"Population"] » 10473452 people

name::
* McsEngl.WlfmlEntity'attribute,

WlfmlEntity.SPECIFIC

description::
* https://reference.wolfram.com/language/guide/EntityTypes.html,

name::
* McsEngl.WlfmlEntity.specific,

pattern-(pn) of Wlfmloutput

description::
"Patterns stand for classes of expressions.
They contain pattern objects that represent sets of possible expressions."
[{2021-02-15} https://reference.wolfram.com/language/tutorial/PatternsAndTransformationRules.html]

name::
* McsEngl.Wlfmloutput!⇒Wlfmlpn,
* McsEngl.Wlfmlpn,
* McsEngl.Wlfmlpn'(pattern-of-lagWlfm)!⇒Wlfmlpn,
* McsEngl.lagWlfm'pattern!⇒Wlfmlpn,
* McsEngl.pattern@lagWlfm!⇒Wlfmlpn,

descriptionLong::
"One of the unique strengths of the Wolfram Language is its powerful and succinct—yet highly readable—symbolic pattern language. Convenient both for immediate use in individual functions, and for systematic large-scale programming, the Wolfram Language's pattern language generalizes concepts like regular expressions to describe general patterns for arbitrary symbolic structures."
[{2021-02-15} https://reference.wolfram.com/language/guide/Patterns.html]

pattern-object of Wlfmlpn

description::
· the-parts of a-pattern.
[{2021-02-15} https://reference.wolfram.com/language/tutorial/PatternsAndTransformationRules.html#8519]

name::
* McsEngl.Wlfmlpn'pattern-object,

info-resource of Wlfmlpn

description::
* https://reference.wolfram.com/language/tutorial/Patterns.html,
* https://reference.wolfram.com/language/guide/Patterns.html,
* https://reference.wolfram.com/language/guide/RulesAndPatterns.html,

name::
* McsEngl.Wlfmlpn'Infrsc,

DOING of Wlfmlpn

usage of Wlfmlpn

description::
·

name::
* McsEngl.Wlfmlpn'usage,

Wlfmlpn.SPECIFIC

description::
* string-pattern,

name::
* McsEngl.Wlfmlpn.specific,

module of Wlfmloutput

description::
"The Wolfram Language normally assumes that all your variables are global. This means that every time you use a name like x, the Wolfram Language normally assumes that you are referring to the same object.
Particularly when you write programs, however, you may not want all your variables to be global. You may, for example, want to use the name x to refer to two quite different variables in two different programs. In this case, you need the x in each program to be treated as a local variable.
You can set up local variables in the Wolfram Language using modules. Within each module, you can give a list of variables which are to be treated as local to the module."
[{2021-02-19} https://reference.wolfram.com/language/tutorial/ModularityAndTheNamingOfThings.html#7693]

name::
* McsEngl.Wlfmloutput'module,
* McsEngl.lagWlfm'module,

block of Wlfmloutput

description::
"Modules in the Wolfram Language allow you to treat the names of variables as local. Sometimes, however, you want the names to be global, but values to be local. You can do this in the Wolfram Language using Block."
[{2021-02-19} https://reference.wolfram.com/language/tutorial/ModularityAndTheNamingOfThings.html#30189]

name::
* McsEngl.Wlfmloutput'block,
* McsEngl.lagWlfm'block,

package of Wlfmloutput

description::
"Wolfram Language packages are files written in the Wolfram Language. They consist of collections of Wolfram Language definitions which "teach" the Wolfram Language about particular application areas."
[{2021-02-19} https://reference.wolfram.com/language/tutorial/ModularityAndTheNamingOfThings.html#3780]

name::
* McsEngl.Wlfmloutput'package,
* McsEngl.lagWlfm'package,

algorithmbase of Wlfmloutput

description::
"For three decades, Wolfram Research has been a world leader in algorithm development—pursuing the long-term mission of creating a complete web of connected algorithms spanning all types of computation.
If there's a known algorithm, we want an optimal implementation; if there isn't, we want to invent one.
Tens of thousands of algorithms is only the beginning. The most visible face of the Wolfram Algorithmbase is not algorithms, but meta-algorithms, which automatically select optimal specific algorithms to use in each unique situation—and effectively allow users to simply define their goals in the Wolfram Language, then let the system take over and automatically work out how best to achieve them."
[{2021-02-20} https://www.wolfram.com/algorithmbase/]

name::
* McsEngl.Wlfmlalgobase,
* McsEngl.Wlfmloutput'algorithmbase!⇒Wlfmlalgobase,
* McsEngl.lagWlfm'algorithmbase!⇒Wlfmlalgobase,

knowledgebase of Wlfmloutput

description::
"Wolfram Knowledgebase™
Making the knowledge of the world computable
Powering Wolfram|Alpha and the Wolfram Language, the continuously growing Wolfram Knowledgebase is by far the world's largest and broadest repository of computable knowledge.
Across thousands of domains, the Knowledgebase contains carefully curated expert knowledge directly derived from primary sources. It includes not only trillions of data elements, but also immense numbers of algorithms encapsulating the methods and models of almost every field.
Major coverage areas
* Units & Measures,
* Dates, Times & Calendars,
* Words & Languages,
* Places & Geography,
* Socioeconomic Data,
* Money & Finance,
* People & History,
* Culture & Media,
* Art & Design,
* Music,
* Math & Statistics,
* Physics & Chemistry,
* Astronomy,
* Life Sciences,
* Earth Sciences,
* Weather & Meteorology,
* Engineering,
* Materials,
* Health & Medicine,
* Food & Nutrition,
* Educational Data,
* Organizations,
* Sports & Games,
* Shopping & Products,
* Transportation,
* Web & Computer Systems,
* Technological Systems,
MAKING WOLFRAM|ALPHA POSSIBLE
The Wolfram Knowledgebase is the largest component of Wolfram|Alpha.
PRIMARY SOURCES, NOT THE WEB
The Wolfram Knowledgebase is derived from primary expert sources usually not available on the web.
THE DATA IS COMPUTABLE
All data in the Wolfram Knowledgebase can immediately be used for computation in the Wolfram Language.
EXPERT KNOWLEDGE BUILT IN
The Wolfram Knowledgebase relies on Wolfram's three decades of computable knowledge acquisition.
NOT JUST DATA, BUT METHODS
The Wolfram Knowledgebase includes not just data, but methods to compute results in every field.
CONTINUOUS DATA FEEDS
Every millisecond of every day, the Wolfram Knowledgebase is updated with the latest data.
LARGE-SCALE AUTOMATED CHECKING
The Wolfram Knowledgebase has been extensively validated using Wolfram's tools and data.
RELIED ON BY EXPERTS
The Wolfram Knowledgebase has become a widely trusted source for information."
[{2021-02-14} https://www.wolfram.com/knowledgebase/]

name::
* McsEngl.Wlfmlkb,
* McsEngl.Wlfmlkb'(knowledge-base-of-lagWlfm)!⇒Wlfmlkb,
* McsEngl.Wlfmloutput'knowledge-base!⇒Wlfmlkb,
* McsEngl.Wolfram-knowledge-base!⇒Wlfmlkb,
* McsEngl.lagWlfm'knowledge-base!⇒Wlfmlkb,

human of lagWlfm

description::
· any human related to lagWlfm.

name::
* McsEngl.Wlfmlhmn,
* McsEngl.lagWlfm'human!⇒Wlfmlhmn,

Wlfmlhmn.Wolfram.Stephen.1959

description::
"Stephen Wolfram (/ˈwʊlfrəm/; born 29 August 1959) is a British-American[6] computer scientist, physicist, and businessman. He is known for his work in computer science, mathematics, and in theoretical physics.[7][8] In 2012, he was named an inaugural fellow of the American Mathematical Society.[9]
As a businessman, he is the founder and CEO of the software company Wolfram Research where he worked as chief designer of Mathematica and the Wolfram Alpha answer engine. His recent work has been on knowledge-based programming, expanding and refining the Wolfram Language, which is the programming language of the mathematical symbolic computation program Mathematica."
[{2021-02-18} https://en.wikipedia.org/wiki/Stephen_Wolfram]

name::
* McsEngl.Stephen-Wolfram.1959!⇒hmnWlfm,
* McsEngl.Wolfram.Stephen.1959!⇒hmnWlfm,
* McsEngl.hmnWlfm,
* McsEngl.hmnWlfm'(Wolfram.Stephen.1959)!⇒hmnWlfm,
* McsEngl.human.Wolfram.Stephen.1959!⇒hmnWlfm,

info-resource of hmnWlfm

description::
* https://www.stephenwolfram.com/about/,

name::
* McsEngl.hmnWlfm'Infrsc,

evaluation of lagWlfm

description::
·

name::
* McsEngl.lagWlfm'evaluation,

Wolfram-Research of lagWlfm

description::
"Wolfram Research is an American multinational company that creates computational technology. Wolfram's flagship product is the technical computing program Wolfram Mathematica, first released on June 23, 1988. Other products include Wolfram Alpha, Wolfram SystemModeler, Wolfram Workbench,[2] gridMathematica, Wolfram Finance Platform,[3] webMathematica, the Wolfram Development Platform,[4] and the Wolfram Programming Lab.[5] Wolfram Research founder Stephen Wolfram is the CEO. The company is headquartered in Champaign, Illinois, United States."
[{2021-02-14} https://en.wikipedia.org/wiki/Wolfram_Research]

name::
* McsEngl.Wolfram-Research,
* McsEngl.lagWlfm'Wolfram-Research,

MISC-ATTRIBUTE of lagWlfm

description::
· any attribute.

name::
* McsEngl.lagWlfm'misc-attribute,

knowledge-based-programming of lagWlfm

description::
"Knowledge-based programming
Build in as much knowledge as possible
Unlike other programming languages, the philosophy of the Wolfram Language is to build as much knowledge—about algorithms and about the world—into the language as possible.
* By far the largest web of algorithms ever assembled
* Includes three decades of state-of-the-art algorithm development in Mathematica
* World's largest collection of computable knowledge
* Continually curated data on thousands of domains, as used in Wolfram|Alpha"
[{2021-02-17} https://www.wolfram.com/language/principles/]

name::
* McsEngl.lagWlfm'knowledge-based-programming,

natural-language-understanding of lagWlfm

description::
"Natural language understanding (NLU)
Mix free-form linguistic input into the language
Building on breakthroughs in Wolfram|Alpha, the Wolfram Language lets you mix ordinary free-form natural language into your code.
* Start using the Wolfram Language with no programming knowledge
* Conveniently specify real-world entities by their everyday names
* Broad NLU, battle-tested in Wolfram|Alpha
* Use NLU to specify real-world objects and concepts when writing programs
* Put natural language understanding into programs you write"
[{2021-02-17} https://www.wolfram.com/language/principles/]

name::
* McsEngl.lagWlfm'NLU'(natural-language-understanding),
* McsEngl.lagWlfm'natural-language-understanding),

info-resource of lagWlfm

description::
* https://reference.wolfram.com/language/,
* https://www.wolfram.com/language/elementary-introduction/2nd-ed/,
* https://www.wolfram.com/language/fast-introduction-for-programmers/en/,
* https://en.wikipedia.org/wiki/Wolfram_Language,
* https://writings.stephenwolfram.com/category/wolfram-language/,
* "the world’s only full computational language" https://writings.stephenwolfram.com/2019/05/what-weve-built-is-a-computational-language-and-thats-very-important/,

name::
* McsEngl.lagWlfm'Infrsc,

evoluting of lagWlfm

description::
"The Wolfram Language is first and foremost an evolution of the symbolic language developed for Mathematica over the course of more than 25 years. But it's considerably more than that—adding the knowledge, knowledge representation and natural language abilities of Wolfram|Alpha, as well as a new symbolic deployment mechanism created with the Wolfram Cloud."
[http://www.wolfram.com/language/for-experts/]

{2020-12-16}-lagWlfm-12.2::
"When we released Version 12.1 in March of this year, I was pleased to be able to say that with its 182 new functions it was the biggest .1 release we’d ever had. But just nine months later, we’ve got an even bigger .1 release! Version 12.2, launching today, has 228 completely new functions!"
[{2021-02-14} https://writings.stephenwolfram.com/2020/12/launching-version-12-2-of-wolfram-language-mathematica-228-new-functions-and-much-more/]

{2014}-lagWlfm-multi-paradigm::
"In June 2014, Wolfram Research officially introduced the Wolfram Language as a new general multi-paradigm programming language.[11] It is the primary programming language used in Mathematica.[12]"
[{2021-02-14} https://en.wikipedia.org/wiki/Wolfram_Research]

{2009}-lagWlfm-WolframAlpha::
"An online frontend for the language, WolframAlpha, was released in 2009. Wolfram implemented this website by translating natural language statements into Wolfram-language queries that link to its database. This frontend greatly enlarged the audience of the language, and the work leading to Wolfram Alpha also means that Wolfram's implementation of the language now has built-in access to a knowledge-base as well as natural language processing functions. Wolfram also added features for more complex tasks, such as 3D modeling.[13]"
[{2021-02-14} https://en.wikipedia.org/wiki/Wolfram_Language]

{1988}-lagWlfm-publication::
"The Wolfram Language was a part of the initial version of Mathematica in 1988."
[{2021-02-14} https://en.wikipedia.org/wiki/Wolfram_Language]

{1986}-lagWlfm-beginning::
"Since the beginning of its development in 1986, the effort spent directly on creating the source code for the Wolfram System is about a thousand developer‐years. In addition, a comparable or somewhat larger effort has been spent on testing and verification.
The source code of the Wolfram System has changed greatly since Version 1 was released. The total number of lines of code in the kernel grew from 150,000 in Version 1 to 350,000 in Version 2, 600,000 in Version 3, 800,000 in Version 4, 1.5 million in Version 5, and 2.5 million in Version 6. In addition, at every stage existing code has been revised—so that Version 6 has only a small percent of its code in common with Version 1.
Despite these changes in internal code, however, the user‐level design of the Wolfram System has remained compatible from Version 1 on. Much functionality has been added, but programs created for the Wolfram System Version 1 will almost always run absolutely unchanged under Version 6."
[{2021-02-21} https://reference.wolfram.com/language/tutorial/TheInternalsOfTheWolframSystem.html#28134]

name::
* McsEngl.lagWlfm'evoluting,

meta-info

this webpage was-visited times since {2021-01-01}

page-wholepath: synagonism.net / worldviewSngo / dirTchInf / lagCnpt

SEARCH::
· this page uses 'locator-names', names that when you find them, you find the-LOCATION of the-concept they denote.
GLOBAL-SEARCH:
· clicking on the-green-BAR of a-page you have access to the-global--locator-names of my-site.
· use the-prefix 'lagCnpt' for sensorial-concepts related to current concept 'knowledge-representation-language'.
LOCAL-SEARCH:
· TYPE CTRL+F "McsLang.words-of-concept's-name", to go to the-LOCATION of the-concept.
· a-preview of the-description of a-global-name makes reading fast.

footer::
• author: Kaseluris.Nikos.1959
• email:
 
• edit on github: https://github.com/synagonism/McsWorld/blob/master/dirTchInf/McsTchInf000007.last.html,
• comments on Disqus,
• twitter: @synagonism,

webpage-versions::
• version.last.dynamic: McsTchInf000007.last.html,
• version.1-0-0.2021-04-09: (0-51) ../../dirMiwMcs/dirTchInf/filMcsLagCnpt.1-0-0.2021-04-09.html,
• filMcsLknlg.0-1-0.2021-01-01.last.html: draft creation,

support (link)