ActivityPub

ActivityPub

ActivityPub is a protocol and open standard for decentralized social networking. It provides a client-to-server (C2S) API for creating and modifying content, as well as a federated server-to-server (S2S) protocol for delivering notifications and content to other servers. ActivityPub is the defining standard of the Fediverse, a decentralised social network of various social interaction models, and content types, which consists of independently managed instances of software such as Mastodon, Pixelfed and PeerTube, among others. ActivityPub is considered to be an update to the ActivityPump protocol used in pump.io, and the official W3C repository for ActivityPub is identified as a fork of ActivityPump. The creation of a new standard for decentralized social networking was prompted by the complexity of OStatus, the most commonly used protocol at the time. OStatus was built using a multitude of technologies (such as Atom, Salmon, WebSub and WebFinger), a product of the infrastructure used in GNU social (the originator and largest user of the OStatus protocol), which made it difficult to implement the protocol into new software. OStatus was also only designed to work with microblogging services, with little flexibility to the types of data that it could hold. The standard was first published by the World Wide Web Consortium (W3C) as a W3C Recommendation in January 2018 by the Social Web Working Group (SocialWG), a working group chartered to build the protocols and vocabularies needed to create a standard for social functionality. Shortly after, further development was moved to the Social Web Community Group (SocialCG), the successor to the SocialWG. == Design == ActivityPub uses the ActivityStreams 2.0 format for building its content, which itself uses JSON-LD. The three main data types used in ActivityPub are Objects, Activities and Actors. Objects are the most common data type, and can be images, videos, or more abstract items such as locations or events. Activities are actions that create and modify objects, for example a Create activity creates an object. Actors are representative of an individual, a group, an application or a service, and are the owners of objects. Every actor type contains an inbox and outbox stream, which sends and receives activities for a user. In order to publish data (for example liking an article), a user creates an activity that declares that they liked an Article object and publishes it to their outbox, where it is then delivered by the ActivityPub server via a POST request to the inboxes listed in the activity's to, bto, cc and bcc fields. The receiving servers then account for the newly received activity and update the article by adding the like action to it. === Example data === An example actor object that represents a user account: An example activity that likes an article object: An example article object: == Project status == The SocialCG previously organized a yearly free conference called ActivityPub Conf about the future of ActivityPub. Triages are held regularly to review issues pertaining to the ActivityPub and ActivityStreams 2.0 specifications as part of the SocialCG. In 2023, Germany's Sovereign Tech Fund donated €152,000 to socialweb.coop with the goal of building a new suite for testing various ActivityPub implementations and their compliance with the specification. === Adoption === The initial wave of adoption for ActivityPub (circa 2016–2018) came from software that was already using OStatus as their federation protocol, such as Mastodon, GNU social and Pleroma. Following the acquisition of Twitter by Elon Musk in 2022, many groups of users that were critical of the acquisition migrated to Mastodon, bringing new attention to the ActivityPub protocol with it. Various major social media platforms and corporations have since pledged to implement ActivityPub support, including Tumblr, Flipboard and Meta Platforms' Threads. Threads introduced crossposting to ActivityPub in 2024 for users outside of the European Economic Area, however full 2-way compatibility remains incomplete as of 2025. == Criticism == === Accidental denial-of-service attacks === Poorly optimized ActivityPub implementations can cause unintentional distributed denial-of-service (DDOS) attacks on other websites and servers, due to the decentralized nature of the network. An example would be Mastodon's implementation of OpenGraph link previews, wherein every instance that receives a post that contains a link with OpenGraph metadata will download the associated data, such as a thumbnail, in a very short timeframe, which can slow down or crash servers as a result of the sudden burst of requests. === Account migration === ActivityPub has been criticized for not natively supporting moving accounts from one server to another, forcing implementations to build their own solutions. While there has been work on building a standardized system for migrating accounts using the Move activity via the Fediverse Enhancement Proposal organization, the current proposal only allows for basic follower migration, with all other data remaining linked to the original account. === Missing content and data === ActivityPub implementations have been criticized for missing replies and parts of reply threads from remote posts, and presenting outdated statistics (e.g. likes and reposts) about remote posts. However, this isn't a problem with the ActivityPub protocol itself, but with implementations not refreshing their content for updated data when needed. == Software using ActivityPub == === Future implementations === Flarum, an internet forum software Forgejo, a Git forge and development platform === Uncertain future implementations === GitLab, a Git forge and development platform which had previously had an open issue discussing the topic, but was later closed due to the development team moving focus to other areas. Tumblr, a microblogging platform. Despite previous statements from Automattic CEO Matt Mullenweg, ActivityPub integration has been delayed indefinitely. The integration would have been implemented with its WordPress migration, as the first-party plugin for interoperability would have been used for federation. Flickr, an image and video hosting site.

Human–robot collaboration

Human-Robot Collaboration is the study of collaborative processes in human and robot agents work together to achieve shared goals. Many new applications for robots require them to work alongside people as capable members of human-robot teams. These include robots for homes, hospitals, and offices, space exploration and manufacturing. Human-Robot Collaboration (HRC) is an interdisciplinary research area comprising classical robotics, human-computer interaction, artificial intelligence, process design, layout planning, ergonomics, cognitive sciences, and psychology. Industrial applications of human-robot collaboration involve Collaborative Robots, or cobots, that physically interact with humans in a shared workspace to complete tasks such as collaborative manipulation or object handovers. == Collaborative Activity == Collaboration is defined as a special type of coordinated activity, one in which two or more agents work jointly with each other, together performing a task or carrying out the activities needed to satisfy a shared goal. The process typically involves shared plans, shared norms and mutually beneficial interactions. Although collaboration and cooperation are often used interchangeably, collaboration differs from cooperation as it involves a shared goal and joint action where the success of both parties depend on each other. For effective human-robot collaboration, it is imperative that the robot is capable of understanding and interpreting several communication mechanisms similar to the mechanisms involved in human-human interaction. The robot must also communicate its own set of intents and goals to establish and maintain a set of shared beliefs and to coordinate its actions to execute the shared plan. In addition, all team members demonstrate commitment to doing their own part, to the others doing theirs, and to the success of the overall task. == Theories Informing Human-Robot Collaboration == Human-human collaborative activities are studied in depth in order to identify the characteristics that enable humans to successfully work together. These activity models usually aim to understand how people work together in teams, how they form intentions and achieve a joint goal. Theories on collaboration inform human-robot collaboration research to develop efficient and fluent collaborative agents. === Belief Desire Intention Model === The belief-desire-intention (BDI) model is a model of human practical reasoning that was originally developed by Michael Bratman. The approach is used in intelligent agents research to describe and model intelligent agents. The BDI model is characterized by the implementation of an agent's beliefs (the knowledge of the world, state of the world), desires (the objective to accomplish, desired end state) and intentions (the course of actions currently under execution to achieve the desire of the agent) in order to deliberate their decision-making processes. BDI agents are able to deliberate about plans, select plans and execute plans. === Shared Cooperative Activity === Shared Cooperative Activity defines certain prerequisites for an activity to be considered shared and cooperative: mutual responsiveness, commitment to the joint activity and commitment to mutual support. An example case to illustrate these concepts would be a collaborative activity where agents are moving a table out the door, mutual responsiveness ensures that movements of the agents are synchronized; a commitment to the joint activity reassures each team member that the other will not at some point drop his side; and a commitment to mutual support deals with possible breakdowns due to one team member's inability to perform part of the plan. === Joint Intention Theory === Joint Intention Theory proposes that for joint action to emerge, team members must communicate to maintain a set of shared beliefs and to coordinate their actions towards the shared plan. In collaborative work, agents should be able to count on the commitment of other members, therefore each agent should inform the others when they reach the conclusion that a goal is achievable, impossible, or irrelevant. == Approaches to Human-Robot Collaboration == The approaches to human-robot collaboration include human emulation (HE) and human complementary (HC) approaches. Although these approaches have differences, there are research efforts to develop a unified approach stemming from potential convergences such as Collaborative Control. === Human Emulation === The human emulation approach aims to enable computers to act like humans or have human-like abilities in order to collaborate with humans. It focuses on developing formal models of human-human collaboration and applying these models to human-computer collaboration. In this approach, humans are viewed as rational agents who form and execute plans for achieving their goals and infer other people's plans. Agents are required to infer the goals and plans of other agents, and collaborative behavior consists of helping other agents to achieve their goals. === Human Complementary === The human complementary approach seeks to improve human-computer interaction by making the computer a more intelligent partner that complements and collaborates with humans. The premise is that the computer and humans have fundamentally asymmetric abilities. Therefore, researchers invent interaction paradigms that divide responsibility between human users and computer systems by assigning distinct roles that exploit the strengths and overcome the weaknesses of both partners. == Key Aspects == Specialization of Roles: Based on the level of autonomy and intervention, there are several human-robot relationships including master-slave, supervisor–subordinate, partner–partner, teacher–learner and fully autonomous robot. In addition to these roles, homotopy (a weighting function that allows a continuous change between leader and follower behaviors) was introduced as a flexible role distribution. Establishing shared goal(s): Through direct discussion about goals or inference from statements and actions, agents must determine the shared goals they are trying to achieve. Allocation of Responsibility and Coordination: Agents must decide how to achieve their goals, determine what actions will be done by each agent, and how to coordinate the actions of individual agents and integrate their results. Shared context: Agents must be able to track progress toward their goals. They must keep track of what has been achieved and what remains to be done. They must evaluate the effects of actions and determine whether an acceptable solution has been achieved. Communication: Any collaboration requires communication to define goals, negotiate over how to proceed and who will do what, and evaluate progress and results. Adaptation and learning: Collaboration over time require partners to adapt themselves to each other and learn from one's partner both directly or indirectly. Time and space: The time-space taxonomy divides human-robot interaction into four categories based on whether the humans and robots are using computing systems at the same time (synchronous) or different times (asynchronous) and while in the same place (collocated) or in different places (non-collocated). Ergonomics: Human factors and ergonomics are one of the key aspects for a sustainable human-robot collaboration. The robot control system can use biomechanical models and sensors to optimize various ergonomic metrics, such as muscle fatigue.

Eduroam

eduroam (a portmanteau of education and roaming) is an international Wi-Fi internet access roaming service for users in research, higher education and further education. It provides researchers, teachers, and students network access when visiting an institution other than their own. Users are authenticated with credentials from their home institution, regardless of the location of the eduroam access point. Authorization to access the Internet and other resources are handled by the visited institution. Users do not have to pay to use eduroam. In some countries, Internet access via eduroam is also available at other locations than the participating institutions, e.g. in libraries, public buildings, railway stations, city centres and airports. It is also available at many primary and secondary education institutions in Brazil and the US. == History == The eduroam initiative started in 2002 when during the preparations for the creation of TERENA's task force TF-Mobility, Klaas Wierenga of SURFnet shared the idea of combining a RADIUS-based infrastructure with IEEE 802.1X technology to provide roaming network access across research and education networks. Initially, the service was joined by institutions in the Netherlands, Germany, Finland, Portugal, Croatia and the United Kingdom. Later, other NRENs in Europe embraced the idea and started joining the infrastructure, which was then called eduroam. Since 2004, the European Union co-funded further research and development work related to the eduroam service through the GN2 and GN3 projects. From September 2007, the European Union also funded through these projects the continued operation and maintenance of the eduroam service at the European level. The first non-European country to join eduroam was Australia, in December 2004. In Canada, eduroam started as an initiative of the University of British Columbia, which was later taken over by CANARIE as a service of its Canadian Access Federation. In the United States, eduroam was initially a pilot project between the National Science Foundation and the University of Tennessee (UTK). In 2012, Internet2 announced the addition of eduroam to its NET+ service offerings. AnyRoam LLC, a private company, was formed by former UTK staff to serve as an Internet2 active corporate member administering the US top-level servers. In 2021, Internet2 assumed direct management of the eduroam service for US-based organizations. == Technology == The eduroam service uses IEEE 802.1X as the authentication method and a hierarchical system of RADIUS servers. The hierarchy typically consists of RADIUS servers at the participating institutions, national RADIUS servers run by the National Roaming Operators, and regional top-level RADIUS servers for individual world regions. In some cases, institutions contact each other directly via DNS lookups () When a user visits a remote institution, the user's device presents their credentials to the local RADIUS server. That RADIUS server discovers that it is not responsible for the realm of the user's home institution and proxies the access request to another RADIUS server, typically the national RADIUS server. If the visited institution is in a different country than the home institution, the request is in turn proxied to the regional top-level RADIUS server, and then to the national RADIUS server of the user's home country. That national server forwards the credentials to the home institution, where they are verified. The RADIUS response travels back over the proxy-hierarchy to the visited institution and the user is granted access. In eduroam, the user credentials are always presented in the form of an EAP method (). The EAP method is responsible for ensuring that the users credentials are secure, and private. The users credentials can then travel via a number of intermediate servers, not under the control of the home institution of the user. This requirement limits the types of EAP methods that can be used. EAP methods which do not provide for security or privacy of user credentials cannot be used in eduroam. The most commonly used EAP methods in eduroam are EAP-TLS, PEAP, and EAP-TTLS. The methods used generally fall into two broad categories: those that use credentials in the form of some public-key mechanism with certificates and those that use so-called tunnelled authentication with "inner" passwords or other credentials. Most institutions use a tunnelled authentication method that requires a server certificate. These server certificates are used to set up a secure tunnel between the mobile device and the authentication server, through which the user credentials (e.g. name and password) are securely transported. A complication arises if the user's home institution does not use a two-letter country-code top-level domain as part of its realm, but a generic top-level domain such as .edu or .org. By inspection of such realms, it is not possible to determine which national RADIUS server the request should be routed to. Such domains will thus, by default, fail to work in international roaming. The workaround for this problem involves the creation of exceptions in the international RADIUS request routing tables; however, this workaround does not scale as the number of exception entries grows. Several solutions have been proposed to eliminate this workaround in the future, the most promising of which is RADIUS over TLS with Dynamic Discovery, which does not rely on static routing tables inside a RADIUS server configuration to route requests to their proper destination. Instead, the participating institution adds one NAPTR DNS resource record to its own domain's DNS zone, which states by which server eduroam authentication for the domain is handled. == Governance == GÉANT has established a lightweight global governance structure. Recognising the large variety in the organisation and funding of research and education (networking) in different countries and regions, rules imposed on the operations of eduroam are limited to technical and administrative requirements that are necessary to ensure the smooth and secure operations of eduroam worldwide. Moreover, the eduroam operators have the leading role in creating and maintaining the rules of the global eduroam governance. The Global eduroam Governance Committee (GeGC) has the central role in the global eduroam governance structure. While its structure has evolved over time, it presently has three representatives from each of five regions — mirroring those used by the Regional Internet registries — serving a two-year term. In addition, GÉANT may appoint one or more experts as non-voting members of the GeGC. == Geographical deployment == eduroam is available at selected locations in countries with a National Roaming Operator that has signed the eduroam Compliance Statement. Those sixty-seven countries are listed below. In addition, there may be pilot deployments in countries that are in the process of joining eduroam. === Middle East === eduroam is deployed in: === Europe === The NRENs that are members of the consortium of the GN3 project have joined the European eduroam confederation by signing the confederation's policy that requires its members to comply with a set of technical and organisational requirements, which are more specific than those in the global eduroam Compliance Statement. As a consequence, eduroam is deployed in the following countries: In addition, three NRENs that are associate members of the consortium of the GN3 project without voting rights joined the European eduroam confederation; they represent Belarus (UIIP), Moldova (RENAM) and Russia (Joint Supercomputer Center of the Russian Academy of Sciences). Finally, five NRENs not involved in the GN3 project joined the European eduroam confederation on a voluntary basis, enabling the deployment of the service in: The European top-level RADIUS servers are operated by SURFnet and Forskningsnettet. === Asia-Pacific === eduroam is deployed in the following countries and economies: The Asia-Pacific top-level RADIUS servers are operated by AARNet and by the University of Hong Kong. === North America === eduroam is deployed in: === Latin America === eduroam is deployed in: === Africa === eduroam is deployed in: The inter-African RADIUS servers are operated by West-African research and education network WACREN, the UbuntuNet Alliance and TENET.

Consistency (database systems)

In database systems, consistency (or correctness) refers to the requirement that any given database transaction must change affected data only in allowed ways. Any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This does not guarantee correctness of the transaction in all ways the application programmer might have wanted (that is the responsibility of application-level code) but merely that any programming errors cannot result in the violation of any defined database constraints. In a distributed system, referencing CAP theorem, consistency can also be understood as after a successful write, update or delete of a Record, any read request immediately receives the latest value of the Record. == As an ACID guarantee == Consistency is one of the four guarantees that define ACID transactions; however, significant ambiguity exists about the nature of this guarantee. It is defined variously as: The guarantee that database constraints are not violated, particularly once a transaction commits. The guarantee that any transactions started in the future necessarily see the effects of other transactions committed in the past. As these various definitions are not mutually exclusive, it is possible to design a system that guarantees "consistency" in every sense of the word, as most relational database management systems in common use today arguably do. == As a CAP trade-off == The CAP theorem is based on three trade-offs, one of which is "atomic consistency" (shortened to "consistency" for the acronym), about which the authors note, "Discussing atomic consistency is somewhat different than talking about an ACID database, as database consistency refers to transactions, while atomic consistency refers only to a property of a single request/response operation sequence. And it has a different meaning than the Atomic in ACID, as it subsumes the database notions of both Atomic and Consistent." In the CAP theorem, you can only have two of the following three properties: consistency, availability, or partition tolerance. Therefore, consistency may have to be traded off in some database systems.

Majal (organization)

Majal is a regional not-for-profit organization focused on "amplifying voices of dissent" throughout the Middle East and North Africa via digital media. Founded in Bahrain, the organization "creates platforms and web applications that promote freedom of expression and social justice." Majal, which relies on open source platforms, like WordPress and Ruby on Rails, was launched in 2006 by Esra'a Al Shafei as a simple group-blogging idea. However, it has changed course to focus on the development of unique applications and tools. == Objectives and means == Majal's content, in addition to its projects and applications, is free open source content to ensure right to access information for everyone. The organization uses a broad spectrum of social media tools, ranging from written blogs, podcasts, vlogs, comics, video animation and pictures to live broadcasting through radio. == Projects and applications == Majal runs various active projects that include Alliance for Kurdish Rights, The Muslim Network for Baháʼí Rights, a discussion tool for Arab LGBT youth and various Mobile apps. == Funding == Majal is funded through private donations and grants from non-governmental organizations, as well as any potential revenues earned through freelance development. Its primary funders are the Shuttleworth Foundation and the Omidyar Network. In 2008, Majal won the Berkman Award from the Berkman Klein Center for Internet & Society at Harvard University in the Human Rights/Global Advocacy category. This $10,000 award was Majal’s first source of funding. This award is presented to “people or institutions that have made a significant contribution to the Internet and its impact on society over the past decade.” In 2009, the March 18 Movement, a project of Majal, received the Think Social Award, which demonstrates how social media can be used to solve the world’s problems. Esra'a Al-Shafei was named a 2009 Echoing Green Fellow for Civil and Human Rights, a seed funding award for young entrepreneurs engaged in social change. Financially, the fellowship consists of a $60,000 stipend paid over two years. Most recently, MEY has received a grant from the Arab Fund for Arts and Culture for its Mideast Tunes website. == Awards == Winner of Human Rights Tulip 2014 Human Rights Tulip - Human rights - Government.nl Ashoka Changemakers Citizen Media competition in 2011 for their CrowdVoice project. Monaco Media Prize 2011 for Majal founder and director Esra'a Al Shafei in 2011. The BOBS Special Topic Human Rights award in 2011 for the Majal website Migrant Rights. ThinkSocial Award in 2009, as powerful model for how social media can be used to address global problems. Echoing Green, 2009 Fellowship. TEDGlobal 2009 Fellowship. Berkman Award for Internet Innovation from Berkman Klein Center for Internet & Society at Harvard Law School in 2008 for the outstanding contributions to the internet and its impact on society. The Global Journal selected Majal as one of the Top 100 NGOs in 2013. 2013-2014 Shuttleworth Foundation Fellowship. == Leadership == Majal team is led primarily by women. The organization was founded by Esra'a Al Shafei, a blogger from Bahrain in 2006. Ahmed Zidan of Egypt has served for over three years as the Editor-in-Chief of Majal Arabic, and is the co-founder of Ahwaa, and is also a podcaster. Other team members include Mona Kareem, Rima Kalush, Abir Ghattas, Namita Malhotra, and Vani Saraswathi. == 2011 Middle East and North Africa protests == Blogs and video played a role in the documentation of protests throughout the Middle East and North Africa during 2010-2011, also known as the Arab Spring. During this period, MEY's project, CrowdVoice (launched in 2010) helped curate and archive the large amounts of videos, images, and eye-witness reports being aggregated and crowdsourced from across the region. As a result, it had been censored temporarily in Yemen and is still censored in Bahrain. == Media coverage == Majal claims to have received various coverage from news agencies, TV satellite channels, radio stations, newspapers, magazines. For instance, Sky News, CNN, New York Times, BBC, The Guardian, NPR, Time, MTV political blog "Act", VH1, Daily Telegraph, Die Zeit, Frankfurter Rundschau FR-online, Toronto Star, TechCrunch, Rolling Stone Middle East, Abu Dhabi TV, Gulf News, Al-Hasnaa' magazine, ReadWriteWeb, Mashable, The Next Web, Radio Sawt Beirut International, Radio Farda among many others.

Line integral convolution

In scientific visualization, line integral convolution (LIC) is a method to visualize a vector field (such as fluid motion) at high spatial resolutions. The LIC technique was first proposed by Brian Cabral and Leith Casey Leedom in 1993. In LIC, discrete numerical line integration is performed along the field lines (curves) of the vector field on a uniform grid. The integral operation is a convolution of a filter kernel and an input texture, often white noise. In signal processing, this process is known as a discrete convolution. == Overview == Traditional visualizations of vector fields use small arrows or lines to represent vector direction and magnitude. This method has a low spatial resolution, which limits the density of presentable data and risks obscuring characteristic features in the data. More sophisticated methods, such as streamlines and particle tracing techniques, can be more revealing but are highly dependent on proper seed points. Texture-based methods, like LIC, avoid these problems since they depict the entire vector field at point-like (pixel) resolution. Compared to other integration-based techniques that compute field lines of the input vector field, LIC has the advantage that all structural features of the vector field are displayed, without the need to adapt the start and end points of field lines to the specific vector field. In other words, it shows the topology of the vector field. In user testing, LIC was found to be particularly good for identifying critical points. == Algorithm == === Informal description === LIC causes output values to be strongly correlated along the field lines, but uncorrelated in orthogonal directions. As a result, the field lines contrast each other and stand out visually from the background. Intuitively, the process can be understood with the following example: the flow of a vector field can be visualized by overlaying a fixed, random pattern of dark and light paint. As the flow passes by the paint, the fluid picks up some of the paint's color, averaging it with the color it has already acquired. The result is a randomly striped, smeared texture where points along the same streamline tend to have a similar color. Other physical examples include: whorl patterns of paint, oil, or foam on a river visualisation of magnetic field lines using randomly distributed iron filings fine sand being blown by strong wind === Formal mathematical description === Although the input vector field and the result image are discretized, it pays to look at it from a continuous viewpoint. Let v {\displaystyle \mathbf {v} } be the vector field given in some domain Ω {\displaystyle \Omega } . Although the input vector field is typically discretized, we regard the field v {\displaystyle \mathbf {v} } as defined in every point of Ω {\displaystyle \Omega } , i.e. we assume an interpolation. Streamlines, or more generally field lines, are tangent to the vector field in each point. They end either at the boundary of Ω {\displaystyle \Omega } or at critical points where v = 0 {\displaystyle \mathbf {v} =\mathbf {0} } . For the sake of simplicity, critical points and boundaries are ignored in the following. A field line σ {\displaystyle {\boldsymbol {\sigma }}} , parametrized by arc length s {\displaystyle s} , is defined as d σ ( s ) d s = v ( σ ( s ) ) | v ( σ ( s ) ) | . {\displaystyle {\frac {d{\boldsymbol {\sigma }}(s)}{ds}}={\frac {\mathbf {v} ({\boldsymbol {\sigma }}(s))}{|\mathbf {v} ({\boldsymbol {\sigma }}(s))|}}.} Let σ r ( s ) {\displaystyle {\boldsymbol {\sigma }}_{\mathbf {r} }(s)} be the field line that passes through the point r {\displaystyle \mathbf {r} } for s = 0 {\displaystyle s=0} . Then the image gray value at r {\displaystyle \mathbf {r} } is set to D ( r ) = ∫ − L / 2 L / 2 k ( s ) N ( σ r ( s ) ) d s {\displaystyle D(\mathbf {r} )=\int _{-L/2}^{L/2}k(s)N({\boldsymbol {\sigma }}_{\mathbf {r} }(s))ds} where k ( s ) {\displaystyle k(s)} is the convolution kernel, N ( r ) {\displaystyle N(\mathbf {r} )} is the noise image, and L {\displaystyle L} is the length of field line segment that is followed. D ( r ) {\displaystyle D(\mathbf {r} )} has to be computed for each pixel in the LIC image. If carried out naively, this is quite expensive. First, the field lines have to be computed using a numerical method for solving ordinary differential equations, like a Runge–Kutta method, and then for each pixel the convolution along a field line segment has to be calculated. The final image will normally be colored in some way. Typically, some scalar field in Ω {\displaystyle \Omega } (like the vector length) is used to determine the hue, while the grayscale LIC output determines the brightness. Different choices of convolution kernels and random noise produce different textures; for example, pink noise produces a cloudy pattern where areas of higher flow stand out as smearing, suitable for weather visualization. Further refinements in the convolution can improve the quality of the image. === Programming description === Algorithmically, LIC takes a vector field and noise texture as input, and outputs a texture. The process starts by generating in the domain of the vector field a random gray level image at the desired output resolution. Then, for every pixel in this image, the forward and backward streamline of a fixed arc length is calculated. The value assigned to the current pixel is computed by a convolution of a suitable convolution kernel with the gray levels of all the noise pixels lying on a segment of this streamline. This creates a gray level LIC image. == Versions == === Basic === Basic LIC images are grayscale images, without color and animation. While such LIC images convey the direction of the field vectors, they do not indicate orientation; for stationary fields, this can be remedied by animation. Basic LIC images do not show the length of the vectors (or the strength of the field). === Color === The length of the vectors (or the strength of the field) is usually coded in color; alternatively, animation can be used. === Animation === LIC images can be animated by using a kernel that changes over time. Samples at a constant time from the streamline would still be used, but instead of averaging all pixels in a streamline with a static kernel, a ripple-like kernel constructed from a periodic function multiplied by a Hann function acting as a window (in order to prevent artifacts) is used. The periodic function is then shifted along the period to create an animation. === Fast LIC (FLIC) === The computation can be significantly accelerated by re-using parts of already computed field lines, specializing to a box function as convolution kernel k ( s ) {\displaystyle k(s)} and avoiding redundant computations during convolution. The resulting fast LIC method can be generalized to convolution kernels that are arbitrary polynomials. === Oriented Line Integral Convolution (OLIC) === Because LIC does not encode flow orientation, it cannot distinguish between streamlines of equal direction but opposite orientation. Oriented Line Integral Convolution (OLIC) solves this issue by using a ramp-like asymmetric kernel and a low-density noise texture. The kernel asymmetrically modulates the intensity along the streamline, producing a trace that encodes orientation; the low-density of the noise texture prevents smeared traces from overlapping, aiding readability. Fast Rendering of Oriented Line Integral Convolution (FROLIC) is a variation that approximates OLIC by rendering each trace in discrete steps instead of as a continuous smear. === Unsteady Flow LIC (UFLIC) === For time-dependent vector fields (unsteady flow), a variant called Unsteady Flow LIC has been designed that maintains the coherence of the flow animation. An interactive GPU-based implementation of UFLIC has been presented. === Parallel === Since the computation of an LIC image is expensive but inherently parallel, the process has been parallelized and, with availability of GPU-based implementations, interactive on PCs. === Multidimensional === Note that the domain Ω {\displaystyle \Omega } does not have to be a 2D domain: the method is applicable to higher dimensional domains using multidimensional noise fields. However, the visualization of the higher-dimensional LIC texture is problematic; one way is to use interactive exploration with 2D slices that are manually positioned and rotated. The domain Ω {\displaystyle \Omega } does not have to be flat either; the LIC texture can be computed also for arbitrarily shaped 2D surfaces in 3D space. == Applications == This technique has been applied to a wide range of problems since it first was published in 1993, both scientific and creative, including: Representing vector fields: visualization of steady (time-independent) flows (streamlines) visual exploration of 2D autonomous dynamical systems wind mapping water flow mapping Artistic effects for image generation and stylization: pencil drawing (auto

Embedded analytics

Embedded analytics enables organisations to integrate analytics capabilities into their own, often software as a service, applications, portals, or websites. This differs from embedded software and web analytics (also commonly known as product analytics). This integration typically provides contextual insights, quickly, easily and conveniently accessible since these insights should be present on the web page right next to the other, operational, parts of the host application. Insights are provided through interactive data visualisations, such as charts, diagrams, filters, gauges, maps and tables often in combination as dashboards embedded within the system. This setup enables easier, in-depth data analysis without the need to switch and log in between multiple applications. Embedded analytics is also known as customer facing analytics. Embedded analytics is the integration of analytic capabilities into a host, typically browser-based, business-to-business, software as a service, application. These analytic capabilities would typically be relevant and contextual to the use-case of the host application. == History == The term "embedded analytics" was first used by Howard Dresner: consultant, author, former Gartner analyst and inventor of the term "business intelligence" said Howard Dresner while he was working for Hyperion Solutions, a company that Oracle bought in 2007. Oracle started then to use the term "embedded analytics" at their press release for Oracle Rapid Planning on 2009 . == Considerations with embedded analytics == When evaluating embedding analytics, consideration would normally be given to integration at various levels, these would likely include: security integration, data integration, application logic integration, business rules integration, and user experience integration. This is in contrast to traditional BI, which expects users to leave their workflow applications to look at data insights in a separate set of tools. This immediacy makes embedded analytics much more intuitive and likely to be valued by users. A December 2016 report from Nucleus Research found that using BI tools, which require toggling between applications, can take up as much as 1–2 hours of an employee's time each week, whereas embedded analytics eliminate the need to toggle between apps.