Bigram

A bigram or digram is a sequence of two adjacent elements from a string of tokens, which are typically letters, syllables, or words. A bigram is an n-gram for n=2. The frequency distribution of every bigram in a string is commonly used for simple statistical analysis of text in many applications, including in computational linguistics, cryptography, and speech recognition. Gappy bigrams or skipping bigrams are word pairs which allow gaps (perhaps avoiding connecting words, or allowing some simulation of dependencies, as in a dependency grammar). == Applications == Bigrams, along with other n-grams, are used in most successful language models for speech recognition. Bigram frequency attacks can be used in cryptography to solve cryptograms. See frequency analysis. Bigram frequency is one approach to statistical language identification. Some activities in logology or recreational linguistics involve bigrams. These include attempts to find English words beginning with every possible bigram, or words containing a string of repeated bigrams, such as logogogue. == Bigram frequency in the English language == The frequency of the most common letter bigrams in a large English corpus is: th 3.56% of 1.17% io 0.83% he 3.07% ed 1.17% le 0.83% in 2.43% is 1.13% ve 0.83% er 2.05% it 1.12% co 0.79% an 1.99% al 1.09% me 0.79% re 1.85% ar 1.07% de 0.76% on 1.76% st 1.05% hi 0.76% at 1.49% to 1.05% ri 0.73% en 1.45% nt 1.04% ro 0.73% nd 1.35% ng 0.95% ic 0.70% ti 1.34% se 0.93% ne 0.69% es 1.34% ha 0.93% ea 0.69% or 1.28% as 0.87% ra 0.69% te 1.20% ou 0.87% ce 0.65%

Datasource

A datasource or DataSource is a name given to the connection set up to a database from a server. The name is commonly used when creating a query to the database. The data source name (DSN) need not be the same as the filename for the database. For example, a database file named friends.mdb could be set up with a DSN of school. Then DSN school would be used to refer to the database when performing a query. == Sun's version of DataSource [1] == A factory for connections to the physical data source that this DataSource object represents. An alternative to the DriverManager facility, a DataSource object is the preferred means of getting a connection. An object that implements the DataSource interface will typically be registered with a naming service based on the Java Naming and Directory Interface (JNDI) API. The DataSource interface is implemented by a driver vendor. There are three types of implementations: Basic implementation — produces a standard Connection object Connection pooling implementation — produces a Connection object that will automatically participate in connection pooling. This implementation works with a middle-tier connection pooling manager. Distributed transaction implementation — produces a Connection object that may be used for distributed transactions and almost always participates in connection pooling. This implementation works with a middle-tier transaction manager and almost always with a connection pooling manager. A DataSource object has properties that can be modified when necessary. For example, if the data source is moved to a different server, the property for the server can be changed. The benefit is that because the data source's properties can be changed, any code accessing that data source does not need to be changed. A driver that is accessed via a DataSource object does not register itself with the DriverManager. Rather, a DataSource object is retrieved through a lookup operation and then used to create a Connection object. With a basic implementation, the connection obtained through a DataSource object is identical to a connection obtained through the DriverManager facility. == Sun's DataSource Overview [2] == A DataSource object is the representation of a data source in the Java programming language. In basic terms, a data source is a facility for storing data. It can be as sophisticated as a complex database for a large corporation or as simple as a file with rows and columns. A data source can reside on a remote server, or it can be on a local desktop machine. Applications access a data source using a connection, and a DataSource object can be thought of as a factory for connections to the particular data source that the DataSource instance represents. The DataSource interface provides two methods for establishing a connection with a data source. Using a DataSource object is the preferred alternative to using the DriverManager for establishing a connection to a data source. They are similar to the extent that the DriverManager class and DataSource interface both have methods for creating a connection, methods for getting and setting a timeout limit for making a connection, and methods for getting and setting a stream for logging. Their differences are more significant than their similarities, however. Unlike the DriverManager, a DataSource object has properties that identify and describe the data source it represents. Also, a DataSource object works with a Java Naming and Directory Interface (JNDI) naming service and can be created, deployed, and managed separately from the applications that use it. A driver vendor will provide a class that is a basic implementation of the DataSource interface as part of its Java Database Connectivity (JDBC) 2.0 or 3.0 driver product. What a system administrator does to register a DataSource object with a JNDI naming service and what an application does to get a connection to a data source using a DataSource object registered with a JNDI naming service are described later in this chapter. Being registered with a JNDI naming service gives a DataSource object two major advantages over the DriverManager. First, an application does not need to hardcode driver information, as it does with the DriverManager. A programmer can choose a logical name for the data source and register the logical name with a JNDI naming service. The application uses the logical name, and the JNDI naming service will supply the DataSource object associated with the logical name. The DataSource object can then be used to create a connection to the data source it represents. The second major advantage is that the DataSource facility allows developers to implement a DataSource class to take advantage of features like connection pooling and distributed transactions. Connection pooling can increase performance dramatically by reusing connections rather than creating a new physical connection each time a connection is requested. The ability to use distributed transactions enables an application to do the heavy duty database work of large enterprises. Although an application may use either the DriverManager or a DataSource object to get a connection, using a DataSource object offers significant advantages and is the recommended way to establish a connection. Since 1.4 Since Java EE 6 a JNDI-bound DataSource can alternatively be configured in a declarative way directly from within the application. This alternative is particularly useful for self-sufficient applications or for transparently using an embedded database. == Yahoo's version of DataSource [3] == A DataSource is an abstract representation of a live set of data that presents a common predictable API for other objects to interact with. The nature of your data, its quantity, its complexity, and the logic for returning query results all play a role in determining your type of DataSource. For small amounts of simple textual data, a JavaScript array is a good choice. If your data has a small footprint but requires a simple computational or transformational filter before being displayed, a JavaScript function may be the right approach. For very large datasets—for example, a robust relational database—or to access a third-party webservice you'll certainly need to leverage the power of a Script Node or XHR DataSource.

Locative media

Locative media or location-based media (LBM) is a virtual medium of communication functionally bound to a location. The physical implementation of locative media, however, is not bound to the same location to which the content refers. Location-based media delivers multimedia and other content directly to the user of a mobile device dependent upon their location. Location information determined by means such as mobile phone tracking and other emerging real-time locating system technologies like Wi-Fi or RFID can be used to customize media content presented on the device. Locative media are digital media applied to real places and thus triggering real social interactions. While mobile technologies such as the Global Positioning System (GPS), laptop computers and mobile phones enable locative media, they are not the goal for the development of projects in this field. == Description == Media content is managed and organized externally of the device on a standard desktop, laptop, server, or cloud computing system. The device then downloads this formatted content with GPS or other RTLS coordinate-based triggers applied to each media sequence. As the location-aware device enters the selected area, centralized services trigger the assigned media, designed to be of optimal relevance to the user and their surroundings. Use of locative technologies "includes a range of experimental uses of geo-technologies including location-based games, artistic critique of surveillance technologies, experiential mapping, and spatial annotation." Location based media allows for the enhancement of any given environment offering explanation, analysis and detailed commentary on what the user is looking at through a combination of video, audio, images and text. The location-aware device can deliver interpretation of cities, parklands, heritage sites, sporting events or any other environment where location based media is required. The content production and pre-production are integral to the overall experience that is created and must have been performed with ultimate consideration of the location and the users position within that location. The media offers a depth to the environment beyond that which is immediately apparent, allowing revelations about background, history and current topical feeds. == Locative, ubiquitous and pervasive computing == The term 'locative media' was coined by Karlis Kalnins. Locative media is closely related to augmented reality (reality overlaid with virtual reality) and pervasive computing (computers everywhere, as in ubiquitous computing). Whereas augmented reality strives for technical solutions, and pervasive computing is interested in embedded computers, locative media concentrates on social interaction with a place and with technology. Many locative media projects have a social, critical or personal (memory) background. While strictly spoken, any kind of link to additional information set up in space (together with the information that a specific place supplies) would make up location-dependent media, the term locative media is strictly bound to technical projects. Locative media works on locations and yet many of its applications are still location-independent in a technical sense. As in the case of digital media, where the medium itself is not digital but the content is digital, in locative media the medium itself might not be location-oriented, whereas the content is location-oriented. Japanese mobile phone culture embraces location-dependent information and context-awareness. It is projected that in the near future locative media will develop to a significant factor in everyday life. == Enabling technologies == Locative media projects use technology such as Global Positioning System (GPS), laptop computers, the mobile phone, Geographic Information System (GIS), and web map services such as Mapbox, OpenStreetMap, and Google Maps among others. Whereas GPS allows for the accurate detection of a specific location, mobile computers allow interactive media to be linked to this place. The GIS supplies arbitrary information about the geological, strategic or economic situation of a location. Web maps like Google Maps give a visual representation of a specific place. Another important new technology that links digital data to a specific place is radio-frequency identification (RFID), a successor to barcodes like Semacode. Research that contributes to the field of locative media happens in fields such as pervasive computing, context awareness and mobile technology. The technological background of locative media is sometimes referred to as "location-aware computing". == Creative representation == Place is often seen as central to creativity; in fact, "for some—regional artists, citizen journalists and environmental organizations for example—a sense of place is a particularly important aspect of representation, and the starting point of conversations." Locative media can propel such conversations in its function as a "poetic form of data visualization," as its output often traces how people move in, and by proxy, make sense of, urban environments. Given the dynamism and hybridity of cities and the networks which comprise them, locative media extends the internet landscape to physical environments where people forge social relations and actions which can be "mobile, plural, differentiated, adventurous, innovative, but also estranged, alienated, impersonalized." Moreover, in using locative technologies, users can expand how they communicate and assert themselves in their environment and, in doing so, explore this continuum of urban interactions. Furthermore, users can assume a more active role in constructing the environments they are situated in accordingly. In turn, artists have been intrigued with locative media as a means of "user-led mapping, social networking and artistic interventions in which the fabric of the urban environment and the contours of the earth become a 'canvas.'" Such projects demystify how resident behaviors in a given city contribute to the culture and sense of personality that cities are often perceived to take on. Design scholars Anne Galloway and Matthew Ward state that "various online lists of pervasive computing and locative media projects draw out the breadth of current classification schema: everything from mobile games, place-based storytelling, spatial annotation and networked performances to device-specific applications." A prominent use of locative media is in locative art. A sub-category of interactive art or new media art, locative art explores the relationships between the real world and the virtual or between people, places or objects in the real world. == Examples == Notable locative media projects include Bio Mapping by Christian Nold in 2004, locative art projects such as the SpacePlace ZKM/ZKMax bluecasting and participatory urban media access in Munich in 2005 and Britglyph by Alfie Dennen in 2009, and location-based games such as AR Quake by the Wearable Computer Lab at the University of South Australia and Can You See Me Now? in 2001 by Blast Theory in collaboration with the Mixed Reality Lab at the University of Nottingham. In 2005, the Silicon Valley–based collaborators of C5 first exhibited the C5 Landscape Initiative, a suite of four GPS inspired projects that investigate perception of landscape in light of locative media. In William Gibson's 2007 novel Spook Country, locative art is one of the main themes and set pieces in the story. Narrative projects which engage with locative media are sometimes referred to as Location-Aware Fiction, as explored in "Data and Narrative: Location Aware Fiction" a 2003 essay by Kate Armstrong. This location-aware fiction is also known as locative literature, where locative stories and poems can be experienced via digital portals, apps, QR codes and e-books, as well as via analogue forms such as labelling tape, Scrabble tiles, fridge magnets or Post-It notes, and these are forms often used by the writer and artist Matt Blackwood. The Transborder Immigrant Tool by the Electronic Disturbance Theater is a locative media project aimed at providing life saving directions to water for people trying to cross the US / Mexico border. The project attracted global media attention in 2009 and 2010. Articles included a Los Angeles Times cover story focusing on Ricardo Dominguez and an AP story interviewing Micha Cárdenas and Brett Stalbaum. The articles focused on concerns over the legality of the project and the ensuing investigations of the group, which are still underway. The Transborder Immigrant Tool has recently been included in a number of major exhibitions including Here, Not There at the Museum of Contemporary Art San Diego and the 2010 California Biennial at the Orange County Museum of Art. Invisible Threads by Stephanie Rothenberg and Jeff Crouse is a locative media project aimed at creating embodied awareness of sweatshops and just-in-time production t

Temporal resolution

Temporal resolution (TR) refers to the discrete resolution of a measurement with respect to time. It is defined as the amount of time needed to revisit and acquire data for the same location. When applied to remote sensing, this amount of time is influenced by the sensor platform's orbital characteristics and the features of the sensor itself. The temporal resolution is low when the revisiting delay is high and vice versa. Temporal resolution is typically expressed in days. == Physics == Often there is a trade-off between the temporal resolution of a measurement and its spatial resolution, due to Heisenberg's uncertainty principle. In some contexts, such as particle physics, this trade-off can be attributed to the finite speed of light and the fact that it takes a certain period of time for the photons carrying information to reach the observer. In this time, the system might have undergone changes itself. Thus, the longer the light has to travel, the lower the temporal resolution. == Technology == === Computing === In another context, there is often a tradeoff between temporal resolution and computer storage. A transducer may be able to record data every millisecond, but available storage may not allow this, and in the case of 4D PET imaging the resolution may be limited to several minutes. === Electronic displays === In some applications, temporal resolution may instead be equated to the sampling period, or its inverse, the refresh rate, or update frequency in Hertz, of a TV, for example. The temporal resolution is distinct from temporal uncertainty. This would be analogous to conflating image resolution with optical resolution. One is discrete, the other, continuous. The temporal resolution is a resolution somewhat the 'time' dual to the 'space' resolution of an image. In a similar way, the sample rate is equivalent to the pixel pitch on a display screen, whereas the optical resolution of a display screen is equivalent to temporal uncertainty. Note that both this form of image space and time resolutions are orthogonal to measurement resolution, even though space and time are also orthogonal to each other. Both an image or an oscilloscope capture can have a signal-to-noise ratio, since both also have measurement resolution. === Oscilloscopy === An oscilloscope is the temporal equivalent of a microscope, and it is limited by temporal uncertainty the same way a microscope is limited by optical resolution. A digital sampling oscilloscope has also a limitation analogous to image resolution, which is the sample rate. A non-digital non-sampling oscilloscope is still limited by temporal uncertainty. The temporal uncertainty can be related to the maximum frequency of continuous signal the oscilloscope could respond to, called the bandwidth and given in Hertz. But for oscilloscopes, this figure is not the temporal resolution. To reduce confusion, oscilloscope manufacturers use 'Sa/s' instead of 'Hz' to specify the temporal resolution. Two cases for oscilloscopes exist: either the probe settling time is much shorter than the real time sampling rate, or it is much larger. The case where the settling time is the same as the sampling time is usually undesirable in an oscilloscope. It is more typical to prefer a larger ratio either way, or if not, to be somewhat longer than two sample periods. In the case where it is much longer, the most typical case, it dominates the temporal resolution. The shape of the response during the settling time also has as strong effect on the temporal resolution. For this reason probe leads usually offer an arrangement to 'compensate' the leads to alter the trade off between minimal settling time, and minimal overshoot. If it is much shorter, the oscilloscope may be prone to aliasing from radio frequency interference, but this can be removed by repeatedly sampling a repetitive signal and averaging the results together. If the relationship between the 'trigger' time and the sample clock can be controlled with greater accuracy than the sampling time, then it is possible to make a measurement of a repetitive waveform with much higher temporal resolution than the sample period by upsampling each record before averaging. In this case the temporal uncertainty may be limited by clock jitter.

Open Mashup Alliance

The Open Mashup Alliance (OMA) is a non-profit consortium that promotes the adoption of mashup solutions in the enterprise through the evolution of enterprise mashup standards like EMML. The initial members of the OMA include some large technology companies such as Adobe Systems, Hewlett-Packard, and Intel and some major technology users such as Bank of America and Capgemini. According to Dion Hinchcliffe, "Ultimately, the OMA creates a standardized approach to enterprise mashups that creates an open and vibrant market for competing runtimes, mashups, and an array of important aftermarket services such as development/testing tools, management and administration appliances, governance frameworks, education, professional services, and so on." == Specification development == The initial focus of the OMA is developing EMML, which is a declarative mashup domain-specific language (DSL) aimed at creating enterprise mashups. The EMML language provides a comprehensive set of high-level mashup-domain vocabulary to consume and mash a variety of web data sources. EMML provides a uniform syntax to invoke heterogeneous service styles: REST, WSDL, RSS/ATOM, RDBMS, and POJO. EMML also provides the ability to mix and match diverse data formats: XML, JSON, JDBC, JavaObjects, and primitive types. The OMA website provides the EMML specification, the EMML schema, a reference runtime implementation capable of running EMML scripts, sample EMML mashup scripts, and technical documentation. The OMA is developing EMML under a Creative Commons Attribution No Derivatives license. The eventual objective of the OMA is to submit the EMML specification and any other OMA specifications to a recognized industry standards body.

Doubao

Doubao (Chinese: 豆包) is an artificial intelligence assistant developed by ByteDance. == History == The chatbot was launched in August 2023. By November 2024, it had become China's most popular AI chatbot, with approximately 60 million monthly active users according to industry analytics. == Design == Doubao is powered by Volcano Engine (Volcengine), 120 trillion tokens consumed per day. == Variants == === Dola === The international version of Doubao is Dola which was launched in August 2023 as Cici. Dola is powered by OpenAI's GPT series of large language models and by Google's Gemini.

HTTP cookie

An HTTP cookie (also called web cookie, Internet cookie, browser cookie, or simply cookie) is a small block of data created by a web server while a user is browsing a website and placed on the user's computer or other device by the user's web browser. Cookies are placed on the device used to access a website, and more than one cookie may be placed on a user's device during a session. Cookies serve useful and sometimes essential functions on the web. They enable web servers to store stateful information (such as items added in the shopping cart in an online store) on the user's device or to track the user's browsing activity (including clicking particular buttons, logging in, or recording which pages were visited in the past). They can also be used to save information that the user previously entered into form fields, such as names, addresses, passwords, and payment card numbers for subsequent use. Authentication cookies are commonly used by web servers to authenticate that a user is logged in, and with which account they are logged in. Without the cookie, users would need to authenticate themselves by logging in on each page containing sensitive information that they wish to access. The security of an authentication cookie generally depends on the security of the issuing website and the user's web browser, and on whether the cookie data is encrypted. Security vulnerabilities may allow a cookie's data to be read by an attacker, used to gain access to user data, or used to gain access (with the user's credentials) to the website to which the cookie belongs (see cross-site scripting and cross-site request forgery for examples). Tracking cookies, and especially third-party tracking cookies, are commonly used as ways to compile long-term records of individuals' browsing histories — a potential privacy concern that prompted European and U.S. lawmakers to take action in 2011. European law requires that all websites targeting European Union member states gain "informed consent" from users before storing non-essential cookies on their device. == Background == === Origin of the name === The term cookie was coined by web-browser programmer Lou Montulli. It was derived from the term magic cookie, which is a packet of data a program receives and sends back unchanged, used by Unix programmers. === History === Magic cookies were already used in computing when computer programmer Lou Montulli had the idea of using them in web communications in June 1994. At the time, he was an employee of Netscape Communications, which was developing an e-commerce application for MCI. Vint Cerf and John Klensin represented MCI in technical discussions with Netscape Communications. MCI did not want its servers to have to retain partial transaction states, which led them to ask Netscape to find a way to store that state in each user's computer instead. Cookies provided a solution to the problem of reliably implementing a virtual shopping cart. Together with John Giannandrea, Montulli wrote the initial Netscape cookie specification the same year. Version 0.9beta of Mosaic Netscape, released on 13 October 1994, supported cookies. The first use of cookies (out of the labs) was checking whether visitors to the Netscape website had already visited the site. Montulli applied for a patent for the cookie technology in 1995, which was granted in 1998. Support for cookies was integrated with Internet Explorer in version 2, released in October 1995. The introduction of cookies was not widely known to the public at the time. In particular, cookies were accepted by default, and users were not notified of their presence. The public learned about cookies after the Financial Times published an article about them on 12 February 1996. In the same year, cookies received a lot of media attention, especially because of potential privacy implications. Cookies were discussed in two U.S. Federal Trade Commission hearings in 1996 and 1997. The development of the formal cookie specifications was already ongoing. In particular, the first discussions about a formal specification started in April 1995 on the www-talk mailing list. A special working group within the Internet Engineering Task Force (IETF) was formed. Two alternative proposals for introducing state in HTTP transactions had been proposed by Brian Behlendorf and David Kristol respectively. But the group, headed by Kristol himself and Lou Montulli, soon decided to use the Netscape specification as a starting point. In February 1996, the working group identified third-party cookies as a considerable privacy threat. The specification produced by the group was eventually published as RFC 2109 in February 1997. It specifies that third-party cookies were either not allowed at all, or at least not enabled by default. At this time, advertising companies were already using third-party cookies. The recommendation about third-party cookies of RFC 2109 was not followed by Netscape and Internet Explorer. RFC 2109 was superseded by RFC 2965 in October 2000. RFC 2965 added a Set-Cookie2 header field, which informally came to be called "RFC 2965-style cookies" as opposed to the original Set-Cookie header field which was called "Netscape-style cookies". Set-Cookie2 was seldom used, however, and was deprecated in RFC 6265 in April 2011 which was written as a definitive specification for cookies as used in the real world. No modern browser recognizes the Set-Cookie2 header field. == Terminology == === Session cookie === A session cookie (also known as an in-memory cookie, transient cookie or non-persistent cookie) exists only in temporary memory while the user navigates a website. Session cookies expire or are deleted when the user closes the web browser. Session cookies are identified by the browser by the absence of an expiration date assigned to them. === Persistent cookie === A persistent cookie expires at a specific date or after a specific length of time. For the persistent cookie's lifespan set by its creator, its information will be transmitted to the server every time the user visits the website that it belongs to, or every time the user views a resource belonging to that website from another website (such as an advertisement). For this reason, persistent cookies are sometimes referred to as tracking cookies because they can be used by advertisers to record information about a user's web browsing habits over an extended period of time. Persistent cookies are also used for reasons such as keeping users logged into their accounts on websites, to avoid re-entering login credentials at every visit. (See § Uses, below.) === Secure cookie === A secure cookie can only be transmitted over an encrypted connection (i.e. HTTPS). They cannot be transmitted over unencrypted connections (i.e. HTTP). This makes the cookie less likely to be exposed to cookie theft via eavesdropping. A cookie is made secure by adding the Secure flag to the cookie. === Http-only cookie === An http-only cookie cannot be accessed by client-side APIs, such as JavaScript. This restriction eliminates the threat of cookie theft via cross-site scripting (XSS). However, the cookie remains vulnerable to cross-site tracing (XST) and cross-site request forgery (CSRF) attacks. A cookie is given this characteristic by adding the HttpOnly flag to the cookie. === Same-site cookie === In 2016 Google Chrome version 51 introduced a new kind of cookie with attribute SameSite with possible values of Strict, Lax or None. With attribute SameSite=Strict, the browsers would only send cookies to a target domain that is the same as the origin domain. This would effectively mitigate cross-site request forgery (CSRF) attacks. With SameSite=Lax, browsers would send cookies with requests to a target domain even it is different from the origin domain, but only for safe requests such as GET (POST is unsafe) and not third-party cookies (inside iframe). Attribute SameSite=None would allow third-party (cross-site) cookies, however, most browsers require secure attribute on SameSite=None cookies. The Same-site cookie is incorporated into a new RFC draft for "Cookies: HTTP State Management Mechanism" to update RFC 6265 (if approved). Chrome, Firefox, and Edge started to support Same-site cookies. The key of rollout is the treatment of existing cookies without the SameSite attribute defined, Chrome has been treating those existing cookies as if SameSite=None, this would let all website/applications run as before. Google intended to change that default to SameSite=Lax in Chrome 80 planned to be released in February 2020, but due to potential for breakage of those applications/websites that rely on third-party/cross-site cookies and COVID-19 circumstances, Google postponed this change to Chrome 84. === Supercookie === A supercookie is a cookie with an origin of a top-level domain (such as .com) or a public suffix (such as .co.uk). Ordinary cookies, by contrast, have an origin of a specific domain name, such as ex