Knowledge as a service (KaaS) is a computing service that delivers information to users, backed by a knowledge model, which might be drawn from a number of possible models based on decision trees, association rules, or neural networks. A knowledge as a service provider responds to knowledge requests from users through a centralised knowledge server, and provides an interface between users and data owners. KaaS is one of several cloud computing-dependent business models in which computer resources are sold on an on-demand and pay-as-you-use basis. == Overview == At the International Semantic Web Conference 2019, it was described how knowledge can be made live and evolve on the web allowing users to learn directly from elaborated knowledge, now appearing in the form of knowledge graphs. KaaS appear when knowledge graphs are accessed via services This is opposed to DaaS which might "compute large volumes of data; integrate and analyzes that data; and publish it in real-time, using Web service APIs" (from Data as a Service) where the KaaS is able to exploit context - both the context of the user in relation to their information requests of the KaaS (where and when they make the request) and also the context of the information in relation to some objective or purpose of the users either understood by the KaaS automatically or indicated to it by the user. == Differentiating knowledge from data == Conceptual models that make such a differentiation such as the so-called DIKW pyramid have existed for perhaps more than 40 years (see a 1974 journal article about this) however definitions are not stable and universally accepted (see the discussion about the conceptualizations of DIKW within the DIKW Wikipedia article that question value of wisdom). The knowledge component of DIKW is generally agreed to be an elusive concept which is difficult to define, however Rowley 2007, in a well known student textbook differentiated knowledge from data by stating that knowledge is "defined with reference to information" and that it contains more than just facts but also "beliefs and expectations". In relation to knowledge graphs, knowledge may be additional content they provide over and above pure data which is the definition of the categories, properties and relations between the concepts, data and entities that substantiate one, many or all domains of discourse (see the definition of Ontology). The ability to represent "beliefs and expectations", or other forms of not so straightforwardly explicit knowledge is an on-going area of improvement in information sciences (see Tacit knowledge) and, with relation to KaaS, the establishment of recent informatics mechanics to do so it critical to the legitimacy of KaaS as it is differentiated from just value-added DaaS. Knowledge graphs' ability to represent context via the definition of the categories, properties and relations between the concepts, data and entities that substantiate one, many or all domains of discourse that they provide (see the definition of Ontology) has led to the idea that supplying access to KNs might be a required competency of a KaaS. == Delivery of knowledge == Much service-delivered content is dependent on a session to provide much of the context that the user (client) needs to understand answers to questions. For example, using current HTTP internet protocols, a GET request to retrieve information identified by a URI, such as a web page, a client (a human or a machine) may have access information supplied automatically to enable that client to bypass paywalls or other content access controls. Such context, in this case about the client's information access allowances, can alter the information provided. In a logical extension to this internet protocols example, a server would receive from the client, either manually or automatically, a full context which would be information about the situation the client is in and this would allow the server to best interpret the client's request. Current internet protocols allow for formats, languages and related preferences to be expressed by clients but make no mention of what a client already knows and what they may understand. The recent Content Negotiation by Profile proposes additions to both the HTTP internet protocols and related services that allow clients to also request information - a response from the server - that accords with an identified information model. This then allows clients to indicate not just formats and languages that they understand (technically that they prefer) but also domains of discourse that that do, which is a step towards comprehensive client context provision.
ISO/IEC JTC 1/SC 24
ISO/IEC JTC 1/SC 24 Computer graphics, image processing and environmental data representation is a standardization subcommittee of the joint subcommittee ISO/IEC JTC 1 of the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), which develops and facilitates standards within the field of computer graphics, image processing, and environmental data representation. The international secretariat of ISO/IEC JTC 1/SC 24 is the British Standards Institute (BSI) located in the United Kingdom. == History == ISO/IEC JTC 1/SC 24 was formed in 1987 from ISO/TC 97 as a result of Resolution 21 at the ISO/IEC JTC 1 plenary. The group's origins began in computer graphics, the standardization of which was originally under ISO/IEC JTC 1/SC 21/WG 2. However, when ISO/IEC JTC 1/SC 24 was created, the standardization activity of ISO/IEC JTC 1/SC 21/WG 2 was carried over to the new subcommittee. The initial five working groups of ISO/IEC JTC 1/SC 24 were titled, “Architecture,” “Application programming interfaces,” “Metafiles and interfaces,” “Language bindings,” and “Validation, testing and registration.” The work of ISO/IEC JTC 1/SC 24 began with the Graphical Kernel System (GKS), which was adopted from ISO/IEC JTC 1/SC 21/WG 2. However, since GKS only addressed 2D functionality, attention turned to the standardization of 3D functionality. This resulted in two standards being published: GKS-3D in 1988 and PHIGS in 1989, both of which addressed 3D functionality. Since 1991, ISO/IEC JTC 1/SC 24 has held plenaries in a number of countries, including the Netherlands, Germany, United States, France, Canada, Japan, Sweden, Korea, United Kingdom, Australia, and Czech Republic. == Scope == The scope of ISO/IEC JTC 1/SC 24 is the “Standardization of interfaces for information technology based applications relating to”: Computer graphics Image processing Environmental data representation Support for the Mixed and Augmented Reality (MAR) Interaction with, and visual representation of, information Included are the following related areas: Modeling and simulation and related reference models Virtual reality with accompanying augmented reality/augmented virtuality aspects and related reference models Application program interfaces Functional specifications Representation models Interchange formats, encodings and their specifications, including metafiles Device interfaces Testing methods Registration procedures Presentation and support for creation of multimedia, hypermedia, and mixed reality documents Excluded are the following areas: Character and image coding Coding of multimedia, hypermedia, and mixed reality document interchange formats JTC 1 work in user system interfaces and document presentation ISO/TC 207 work on ISO 14000 environment management, ISO/TC 211 work on geographic information and geomatics Software environments as described by ISO/IEC JTC 1/SC 22 == Structure == ISO/IEC JTC 1/SC 24 is made up of four active working groups, each of which carries out specific tasks in standards development within the field of computer graphics, image processing and environmental data representation, together with ITU-T Study Group 16. As a response to changing standardization needs, working groups of ISO/IEC JTC 1/SC 24 can be disbanded if their area of work is no longer applicable, or established if new working areas arise. The focus of each working group is described in the group's terms of reference. Active working groups of ISO/IEC JTC 1/SC 24 are: == Collaborations == ISO/IEC JTC 1/SC 24 works in close collaboration with a number of other organizations or subcommittees, both internal and external to ISO or IEC, in order to avoid conflicting or duplicative work. Organizations internal to ISO or IEC that collaborate with or are in liaison to ISO/IEC JTC 1/SC 24 include: ISO/IEC JTC 1/WG 7, Sensor Networks ISO/IEC JTC 1/SC 29, Coding of audio, picture, multimedia and hypermedia information ISO/IEC JTC 1/SC 32, Data management and interchange ISO/TAG 14, Imagery and technology ISO/TC 130, Graphic Technology ISO/TC 184/SC 4, Industrial data ISO/TC 211, Geographic information/Geomatics ISO/TC 215, Health informatics IEC TC 100, Audio, video and multimedia system and equipment Some organizations external to ISO or IEC that collaborate with or are in liaison to ISO/IEC JTC 1/SC 24 include: Defence Geospatial Information Working Group (DGIWG) Digital Imaging and Communications in Medicine (DICOM) International Hydrographic Organization (IHO) The Khronos Group NATO - Joint Intelligence Surveillance and Reconnaissance Capability Group (JISRCG) OMG Robotics DTF Open CGM Open Geospatial Consortium (OGC) SEDRIS Organization Simulation Interoperability Standards Organization (SISO) US National Imagery Transmission Format Standard (NITFS) Technical Board (US NTB) Web3D Consortium World Intellectual Property Organization (WIPO) World Wide Web Consortium (W3C) == Member countries == Countries pay a fee to ISO to be members of subcommittees. The 11 "P" (participating) members of ISO/IEC JTC 1/SC 24 are: Australia, China, Egypt, France, India, Japan, Republic of Korea, Portugal, Russian Federation, United Kingdom, and United States. The 22 "O" (observer) members of ISO/IEC JTC 1/SC 24 are: Argentina, Austria, Belgium, Bosnia and Herzegovina, Bulgaria, Canada, Cuba, Czech Republic, Finland, Ghana, Hungary, Iceland, Indonesia, Islamic Republic of Iran, Italy, Kazakhstan, Malaysia, Poland, Romania, Serbia, Slovakia, Switzerland, and Thailand. == Published standards == ISO/IEC JTC 1/SC 24 currently has 80 published standards under their direct responsibility within the field of computer graphics, image processing, and environmental data representation, including:
Metadirectory
A metadirectory system provides for the flow of data between one or more directory services and databases in order to maintain synchronization of that data. It is an important part of identity management systems. The data being synchronized typically are collections of entries that contain user profiles and possibly authentication or policy information. Most metadirectory deployments synchronize data into at least one LDAP-based directory server, to ensure that LDAP-based applications such as single sign-on and portal servers have access to recent data, even if the data is mastered in a non-LDAP data source. Metadirectory products support filtering and transformation of data in transit. Most identity management suites from commercial vendors include a metadirectory product, or a user provisioning product.
Two-phase commit protocol
In transaction processing, databases, and computer networking, the two-phase commit protocol (2PC, tupac) is a type of atomic commitment protocol (ACP). It is a distributed algorithm that coordinates all the processes that participate in a distributed atomic transaction on whether to commit or abort (roll back) the transaction. This protocol (a specialised type of consensus protocol) achieves its goal even in many cases of temporary system failure (involving either process, network node, communication, etc. failures), and is thus widely used. However, it is not resilient to all possible failure configurations, and in rare cases, manual intervention is needed to remedy an outcome. To accommodate recovery from failure (automatic in most cases) the protocol's participants use logging of the protocol's states. Log records, which are typically slow to generate but survive failures, are used by the protocol's recovery procedures. Many protocol variants exist that primarily differ in logging strategies and recovery mechanisms. Though usually intended to be used infrequently, recovery procedures compose a substantial portion of the protocol, due to many possible failure scenarios to be considered and supported by the protocol. In a "normal execution" of any single distributed transaction (i.e., when no failure occurs, which is typically the most frequent situation), the protocol consists of two phases: The commit-request phase (or voting phase), in which a coordinator process attempts to prepare all the transaction's participating processes (named participants, cohorts, or workers) to take the necessary steps for either committing or aborting the transaction and to vote, either "Yes": commit (if the transaction participant's local portion execution has ended properly), or "No": abort (if a problem has been detected with the local portion), and The commit phase, in which, based on voting of the participants, the coordinator decides whether to commit (only if all have voted "Yes") or abort the transaction (otherwise), and notifies the result to all the participants. The participants then follow with the needed actions (commit or abort) with their local transactional resources (also called recoverable resources; e.g., database data) and their respective portions in the transaction's other output (if applicable). The two-phase commit (2PC) protocol should not be confused with the two-phase locking (2PL) protocol, a concurrency control protocol. == Assumptions == The protocol works in the following manner: one node is a designated coordinator, which is the master site, and the rest of the nodes in the network are designated the participants. The protocol assumes that: there is stable storage at each node with a write-ahead log, no node crashes forever, the data in the write-ahead log is never lost or corrupted in a crash, and any two nodes can communicate with each other. The last assumption is not too restrictive, as network communication can typically be rerouted. The first two assumptions are much stronger; if a node is totally destroyed then data can be lost. The protocol is initiated by the coordinator after the last step of the transaction has been reached. The participants then respond with an agreement message or an abort message depending on whether the transaction has been processed successfully at the participant. == Basic algorithm == === Commit request (or voting) phase === The coordinator sends a query to commit message to all participants and waits until it has received a reply from all participants. The participants execute the transaction up to the point where they will be asked to commit. They each write an entry to their undo log and an entry to their redo log. Each participant replies with: either an agreement message (participant votes Yes to commit), if the participant's actions succeeded; or an abort message (participant votes No to commit), if the participant experiences a failure that will make it impossible to commit. === Commit (or completion) phase === ==== Success ==== If the coordinator received an agreement message from all participants during the commit-request phase: The coordinator sends a commit message to all the participants. Each participant completes the operation, and releases all the locks and resources held during the transaction. Each participant sends an acknowledgement to the coordinator. The coordinator completes the transaction when all acknowledgements have been received. ==== Failure ==== If any participant votes No during the commit-request phase (or the coordinator's timeout expires): The coordinator sends a rollback message to all the participants. Each participant undoes the transaction using the undo log, and releases the resources and locks held during the transaction. Each participant sends an acknowledgement to the coordinator. The coordinator undoes the transaction when all acknowledgements have been received. ==== Message flow ==== Coordinator Participant QUERY TO COMMIT --------------------------------> VOTE YES/NO prepare/abort <------------------------------- commit/abort COMMIT/ROLLBACK --------------------------------> ACKNOWLEDGEMENT commit/abort <-------------------------------- end An next to the record type means that the record is forced to stable storage. == Disadvantages == The greatest disadvantage of the two-phase commit protocol is that it is a blocking protocol. If the coordinator fails permanently, some participants will never resolve their transactions: After a participant has sent an agreement message as a response to the commit-request message from the coordinator, it will block until a commit or rollback is received. A two-phase commit protocol cannot dependably recover from a failure of both the coordinator and a cohort member during the commit phase. If only the coordinator had failed, and no cohort members had received a commit message, it could safely be inferred that no commit had happened. If, however, both the coordinator and a cohort member failed, it is possible that the failed cohort member was the first to be notified, and had actually done the commit. Even if a new coordinator is selected, it cannot confidently proceed with the operation until it has received an agreement from all cohort members, and hence must block until all cohort members respond. == Implementing the two-phase commit protocol == === Common architecture === In many cases the 2PC protocol is distributed in a computer network. It is easily distributed by implementing multiple dedicated 2PC components similar to each other, typically named transaction managers (TMs; also referred to as 2PC agents or Transaction Processing Monitors), that carry out the protocol's execution for each transaction (e.g., The Open Group's X/Open XA). The databases involved with a distributed transaction, the participants, both the coordinator and participants, register to close TMs (typically residing on respective same network nodes as the participants) for terminating that transaction using 2PC. Each distributed transaction has an ad hoc set of TMs, the TMs to which the transaction participants register. A leader, the coordinator TM, exists for each transaction to coordinate 2PC for it, typically the TM of the coordinator database. However, the coordinator role can be transferred to another TM for performance or reliability reasons. Rather than exchanging 2PC messages among themselves, the participants exchange the messages with their respective TMs. The relevant TMs communicate among themselves to execute the 2PC protocol schema above, "representing" the respective participants, for terminating that transaction. With this architecture the protocol is fully distributed (does not need any central processing component or data structure), and scales up with number of network nodes (network size) effectively. This common architecture is also effective for the distribution of other atomic commitment protocols besides 2PC, since all such protocols use the same voting mechanism and outcome propagation to protocol participants. === Protocol optimizations === Database research has been done on ways to get most of the benefits of the two-phase commit protocol while reducing costs by protocol optimizations and protocol operations saving under certain system's behavior assumptions. ==== Presumed abort and presumed commit ==== Presumed abort or Presumed commit are common such optimizations. An assumption about the outcome of transactions, either commit, or abort, can save both messages and logging operations by the participants during the 2PC protocol's execution. For example, when presumed abort, if during system recovery from failure no logged evidence for commit of some transaction is found by the recovery procedure, then it assumes that the transaction has been aborted, and acts accordingly. This means that it does not matter if aborts are logged at all, and such logging can be saved under this assumption. Typical
Secure Electronic Delivery
Secure Electronic Delivery (SED) is a service created in 2003 and provided by the British Library Document Supply Service (BLDSS). Its purpose is to enable faster delivery of digital materials as encrypted, copyright-compliant PDF Documents, to a personal e-mail address. These documents are supplied from the British Library via its On Demand service. When the British Library supplies articles electronically, it sends them securely in order to ensure its usage is permitted (research purposes) and copyright law is observed. == Methods == As the publishing industry, authors and creators become highly protective of their assets and intellectual property, they impose strict rules on delivery methods to prevent copyright infringement. Nowadays, DRM-enabled secure delivery appears to be the most widely used solution to address issues faced by libraries in supplying ebooks and digital materials to their users. SED, one of these solutions, is using Adobe LiveCycle Digital Rights Management (LCDRM) as an encryption method to deliver documents. == Advantages == SED offers convenience, quality and speed as documents are delivered upon request at any location and on any device. Requested articles are scanned for high quality reproduction, opened anywhere on any machine, including mobile devices. == Restrictions == The following are restrictions hold in a SED service implementation: The digital material is accessible only for 14 days via a link sent to a personal message. Due to copyright reasons, the material can be opened only once, saved for 14 days and does not allow a copy-paste action. Upon display, the material must be printed from the same device and reprinted only once. The On Demand encryption technology works best on the default Safari browser although other browsers may accommodate it.
Containerization (computing)
In software engineering, containerization is operating-system-level virtualization or application-level virtualization over multiple resources so that software applications can run in isolated user spaces called containers in any cloud or non-cloud environment, regardless of type or vendor. The term "container" has different meanings in different contexts, and it is important to ensure that the intended definition aligns with the audience's understanding. == Usage == Each container is basically a fully functional and portable cloud or non-cloud computing environment surrounding the application and keeping it independent of other environments running in parallel. Individually, each container simulates a different software application and runs isolated processes by bundling related configuration files, libraries and dependencies. But, collectively, multiple containers share a common operating system kernel (OS). In recent times, containerization technology has been widely adopted by cloud computing platforms like Amazon Web Services, Microsoft Azure, Google Cloud Platform, and IBM Cloud. Containerization has also been pursued by the U.S. Department of Defense as a way of more rapidly developing and fielding software updates, with first application in its F-22 air superiority fighter. == History == The concept of containerization in computing originated from early operating system–level isolation mechanisms. One of the earliest implementations was the chroot system call introduced in Version 7 Unix in 1979, which changed the apparent root directory for a process and its children, providing a basic form of filesystem isolation. In the early 2000s, more advanced forms of operating system–level virtualization were developed. FreeBSD introduced "jails" in 2000, which extended isolation by restricting processes to a subset of system resources. Around the same time, Solaris introduced "zones" (also known as Solaris Containers), providing similar capabilities with resource management and isolation features. Linux later incorporated comparable functionality through kernel features such as namespaces and control groups (cgroups), which enabled isolation of process IDs, network stacks, filesystems, and resource allocation. These features formed the foundation for Linux Containers (LXC), which provided a userspace interface for managing containers. The widespread adoption of containerization accelerated with the release of Docker in 2013, which introduced a standardized format for packaging applications and their dependencies, along with tooling for image distribution and container management. == Types of containers == OS containers Application containers == Security issues == Because of the shared OS, security threats can affect the whole containerized system. In containerized environments, security scanners generally protect the OS, but not the application containers, which adds unwanted vulnerability. == Container management, orchestration, clustering == Container orchestration or container management is mostly used in the context of application containers. Implementations providing such orchestration include Kubernetes and Docker swarm. == Container cluster management == Container clusters need to be managed. This includes functionality to create a cluster, to upgrade the software or repair it, balance the load between existing instances, scale by starting or stopping instances to adapt to the number of users, to log activities and monitor produced logs or the application itself by querying sensors. Open-source implementations of such software include OKD and Rancher. Quite a number of companies provide container cluster management as a managed service, like Alibaba, Amazon, Google, and Microsoft.
Reference data
Reference data is data used to classify or categorize other data. Typically, they are static or slowly changing over time. Examples of reference data include: Units of measurement Country codes Corporate codes Fixed conversion rates e.g., weight, temperature, and length Calendar structure and constraints Reference data sets are sometimes alternatively referred to as a "controlled vocabulary" or "lookup" data. Reference data differs from master data. While both provide context for business transactions, reference data is concerned with classification and categorisation, while master data is concerned with business entities. A further difference between reference data and master data is that a change to the reference data values may require an associated change in business process to support the change, while a change in master data will always be managed as part of existing business processes. For example, adding a new customer or sales product is part of the standard business process. However, adding a new product classification (e.g. "restricted sales item") or a new customer type (e.g. "gold level customer") will result in a modification to the business processes to manage those items. == Externally-defined reference data == For most organisations, most or all reference data is defined and managed within that organisation. Some reference data, however, may be externally defined and managed, for example by standards organizations. An example of externally defined reference data is the set of country codes as defined in ISO 3166-1. == Reference data management == Curating and managing reference data is key to ensuring its quality and thus fitness for purpose. All aspects of an organisation, operational and analytical, are greatly dependent on the quality of an organization's reference data. Without consistency across business process or applications, for example, similar things may be described in quite different ways. Reference data gain in value when they are widely re-used and widely referenced. Examples of good practice in reference data management include: Formalize the reference data management Use external reference data as much as possible Govern the reference data specific to your enterprise Manage reference data at enterprise level Version control your reference data