GNU social (and its predecessor StatusNet) is a largely defunct free and open-source microblogging social networking service that implements the OStatus and ActivityPub standards for interoperability between installations. While offering similar functionality to social networks such as Twitter, GNU social seeks to provide the ability for open and federated communication between different microblogging communities, known as 'instances'. Both enterprises and individuals can install and control their own instances and user data. At its peak in popularity, GNU social had been deployed on hundreds of interconnected instances, however has since fallen into disuse as competing software like Mastodon and Pleroma have taken its position as the dominant federated microblogging services. Later on in its lifespan, the project split into two separate branches, with "v2" being a continuation of the original codebase for maintenance of existing instances, with "v3" being a complete redesign of the project meant to integrate further ActivityPub support and modernization of the user experience and its technological back-end. As of August 15, 2022, there had been no new commits to the v2 branch, with the v3 branch also no longer being actively developed not long after by November 25, 2022, with the project essentially abandoned. Despite its modern obsolescence and dated design compared to modern platforms, GNU social and StatusNet is regarded to be the origin of the Fediverse network and has had a major influence on the design of more modern decentralized social networks that succeeded it. == History == While being the main project within its lineage, GNU social originally began as a fork of StatusNet. The software was first developed for a service called identi.ca from Evan Prodromou, which offered free microblogging accounts to the public. The software quickly became one of the first popular examples of a decentralized social network, as identi.ca allowed any other server that was running the software to communicate with it, something which had not previously been attempted before in social media at such a large scale. === StatusNet === Originally, StatusNet (named Laconica at the time) was launched with a communication protocol designed specifically for the project called OpenMicroBlogging (OMB). With version 0.8.1, the name of the software was changed to StatusNet. Version 0.9.0 was released soon after in March 3, 2010, with the developers implementing a newly designed protocol dubbed OStatus, with support for OMB being dropped not long after. Compared to OpenMicroBlogging, OStatus could handle and federate more events and actions than the basic plaintext communication that OMB provided and was based on a variety of other web technologies, allowing for easier adoption of new implementations of the protocol for servers and clients compared to the fully custom architecture of OMB. With the StatusNet name change, the company developing both the software and OStatus as well as managing identi.ca rebranded from Control Yourself to StatusNet Inc. In August 2010, the company raised a new round of venture capital funds to establish a hosting service under the status.net domain from sources such as First Mark Capital, BOLDstart Ventures, iNovia Capital and Montreal Start Up, raising over $2.3 million in funding up to that point. The hosting service allowed anyone to establish their own StatusNet instance without maintaining a server, similar to WordPress.com and other blogging platforms. New registrations on identi.ca along with the ability to create new status.net instances was disabled in December 2012, in preparation for a migration to pump.io that has since been named by users of StatusNet and OStatus as "the Pumpocalypse". pump.io was a brand new software package like StatusNet, but with a new protocol designed for general purpose activity streams outside of microblogging and ease-of-use for developers building on the technology, much like the transition from OMB to OStatus. The announcement was seen as unexpected among identi.ca users, who were concerned about the possibility of their statuses being deleted with the transition. At the same time, server administrators running third-party instances and their users who were left behind on StatusNet were also worried, as it was unclear at the time whether future development of the software would be picked up by a new maintainer. The transition for identi.ca users to pump.io was completed on 12 July 2013. ==== Previous names ==== The original name of StatusNet was Laconica, a reference to the Laconic phrase; a particularly brief statement commonly attributed to the leaders of Sparta (Laconia being the Greek region containing Sparta). In microblogging, all messages are designed to be very short due to the traditional 140-character limit on message size, a limitation imported from SMS. Beginning with version 0.8.1, the name was changed to StatusNet. The developers said that the new name "simply reflects what our software does: send status updates into your social network." === GNU social === GNU social originally began as a side project of GNU FM (Libre.fm) maintainer Matt Lee, with the goal of being able to federate messages between Last.fm and other instances of GNU FM using StatusNet plugins. Around the same time, a developer named Mikael Nordfeldth forked StatusNet with the intention of maintaining it as a personal project, dubbing it "Free Social". However, following identi.ca's transition to pump.io and its developers' sudden abandonment of StatusNet, the projects received more attention from server administrators and other users looking for an actively updated alternative. Shortly after LibrePlanet 2012, a plan was formed to merge all three projects into a single service. On June 8, 2013, it was announced that along with Free Social, StatusNet would be merged into the GNU social project and stewarded by the Free Software Foundation, with the project since becoming the dominant variant of StatusNet. During GNU social's lifespan, a popular theme for the user interface named Quitter was used, which was similar to an earlier Twitter interface. Many instances were made specifically using the name Quitter such as Quitter.se, an instance created by the developer of the theme. Before the establishment of Mastodon's popularity and dominance within the network, Quitter was noted as a frequent location for users of Twitter to migrate to when users disagreed with moderation policies or feature updates, such as when an algorithmic feed was added to Twitter. A fork of GNU social was made called postActiv, which planned to rewrite the backend and user interface of GNU social, as well as to add compatibility for Diaspora's protocol. == Features == A basic GNU social instance takes the form of a microblogging service with a reverse chronological timeline that features status updates and small messages from followed accounts, similar to other services such as Twitter or Weibo. While users could see their own customized timeline, they could access another timeline that showcased every message that the instance knows of, including from other instances that were connected to each other if someone on the instance followed an account from it. Users could also create and join groups, which allows for discussion and collaboration on specific topics. Administrators can also customize their server via the plugin system, which allows developers to create new features or modify existing plugins to suit the needs of the instance via PHP. A notable plugin built for GNU social was Quitter, a revamp of the user interface that resembles an earlier version of Twitter's user interface.
Instance-based learning
In machine learning, instance-based learning (sometimes called memory-based learning) is a family of learning algorithms that, instead of performing explicit generalization, compare new problem instances with instances seen in training, which have been stored in memory. Because computation is postponed until a new instance is observed, these algorithms are sometimes referred to as "lazy." It is called instance-based because it constructs hypotheses directly from the training instances themselves. This means that the hypothesis complexity can grow with the data: in the worst case, a hypothesis is a list of n training items and the computational complexity of classifying a single new instance is O(n). One advantage that instance-based learning has over other methods of machine learning is its ability to adapt its model to previously unseen data. Instance-based learners may simply store a new instance or throw an old instance away. Examples of instance-based learning algorithms are the k-nearest neighbors algorithm, kernel machines and RBF networks. These store (a subset of) their training set; when predicting a value/class for a new instance, they compute distances or similarities between this instance and the training instances to make a decision. To battle the memory complexity of storing all training instances, as well as the risk of overfitting to noise in the training set, instance reduction algorithms have been proposed.
ISLRN
The ISLRN or International Standard Language Resource Number is Persistent Unique Identifier for Language Resources. == Context == On November 18, 2013, 12 major organisations (see list below) from the fields Language Resources and Technologies, Computational Linguistics, and Digital Humanities held a cooperation meeting in Paris (France) and agreed to announce the establishment of the International Standard Language Resource Number (ISLRN), to be assigned to each Language Resource. Among the 12 organisations, 4 institutions constitute the ISLRN Steering Committee (ST) ADHO ACL Asian Federation of Natural Language Processing ST COCOSDA, International Committee for the Coordination & Standardisation of Speech Databases and Assessment Techniques ICCL (COLING) European Data Forum ELRA ST IAMT, International Association for Machine Translation Archived 2010-06-24 at the Wayback Machine ISCA LDC ST Oriental COCOSDA ST RMA, Language Resource Management Agency == Size and Content == The Joint Research Centre(JRC), the [European Commission]'s in-house science service, was the first organisation to adopt the ISLRN initiative and requested. 2500 resources and tools have already been allocated an ISLRN. These resources include written data (Annotated corpus, Annotated text, List of misspelled word, Terminological database, Treebank, Wordnet, etc.) and speech corpora (Synthesised Speech, Transcripts and Audiovisual Recordings, Conversational Speech, Folk Sayings, etc.) == Objectives == Providing Language Resources with unique names and identifiers using a standardized nomenclature ensures the identification of each Language Resources and streamlines the citation with proper references in activities within Human Language Technology as well as in documents and scientific publications. Such unique identifier also enhances the reproducibility, an essential feature of scientific work.
Backend as a service
Backend as a service (BaaS), sometimes also referred to as mobile backend as a service (MBaaS), is a service for providing web app and mobile app developers with a way to easily build a backend to their frontend applications. Features available include user management, push notifications, and integration with social networking services. These services are provided via the use of custom software development kits (SDKs) and application programming interfaces (APIs). BaaS is a relatively recent development in cloud computing, with most BaaS startups dating from 2011 or later. Some of the most popular service providers are AWS Amplify and Firebase. == Purpose == Web and mobile apps require a similar set of features on the backend, including notification service, integration with social networks, and cloud storage. Each of these services has its own API that must be individually incorporated into an app, a process that can be time-consuming and complicated for app developers. BaaS providers form a bridge between the frontend of an application and various cloud-based backends via a unified API and SDK. Providing a consistent way to manage backend data means that developers do not need to redevelop their own backend for each of the services that their apps need to access, potentially saving both time and money. Although similar to other cloud-computing business models, such as serverless computing, software as a service (SaaS), infrastructure as a service (IaaS), and platform as a service (PaaS), BaaS is distinct from these other services in that it specifically addresses the cloud-computing needs of web and mobile app developers by providing a unified means of connecting their apps to cloud services. == Features == BaaS providers offer different set of features and backend tools. Some of the most common features include: Database management. Most BaaS solutions provide SQL and/or NoSQL database management services for applications. Developers can store their app data without deploying and managing databases themselves. BaaS usually provides client SDKs, REST and GraphQL APIs for the frontend to interact with databases. File storage. BaaS providers often offer storage solutions for media files, user uploads, and other binary data. Applications can upload, download, and delete files through provided SDKs and APIs. Authentication and authorization. Some BaaS offer authentication and authorization services that allow developers to easily manage app users. This includes user sign-up, login, password reset, social media login integration through OAuth, user group and permission management etc. Notification service. Some BaaS providers such as Firebase and AWS Amplify have notification services that can send custom emails to users and push native notifications on mobile platforms. This is especially useful for applications that need to send messages, alerts, and reminders. Cloud functions. Some BaaS allow developers to deploy and run serverless functions. The functions are usually stateless and can be triggered by various ways including HTTP requests, SDK invocation, background server events, and cloud scheduled executions. Different providers offer runtime support for different languages, some of the popular languages are JavaScript/TypeScript (Node.js, Deno), Python, Java/Kotlin. Cloud functions extend the potential and flexibility of BaaS by allowing developers to write custom functionalities for their apps, working in a way similar to a traditional REST API backend framework. Usage analytics. Analytics data about application usage is often included in BaaS. This allows developers to monitor user behaviors and make decisions correspondingly in marketing strategies and performance optimizations. UI design. Some BaaS providers, such as AWS Amplify and Backendless, offer user interface designing tools that help developers design the frontend UI of web and mobile apps. While this may be useful for small teams and individual developers, UI design assistance may not be conventional in BaaS as it goes beyond the scope of backend infrastructure. Real-Time. Real-time features in a BaaS platform ensure that data updates and synchronizations occur instantly across all clients, making changes immediately visible to users. This is crucial for applications like live chat and collaborative tools, using technologies like WebSockets to maintain continuous server-client connections. == Service providers == BaaS providers have a broad focus, providing SDKs and APIs that work for app development on multiple platforms with different technology stacks, such as JavaScript (for Web apps), Flutter, Java/Kotlin (for Android apps), Swift/Objective-C (for iOS/MacOS/WatchOS/TvOS apps), .NET (for Windows) and others. BaaS providers also come in different types, suiting developers of different needs. === Cloud-based BaaS === Most BaaS providers host backend platforms on their cloud servers. They also manage the infrastructure, security, and scalability of the platforms. Developers can access the backend services via a web interface or the provided APIs. Some examples of cloud-based BaaS include Firebase (hosted on Google Cloud Platform), AWS Amplify (hosted on Amazon Web Services), and Microsoft Azure Mobile Apps (hosted on Microsoft Azure). === Self-hosted BaaS === Self-hosted BaaS allow developers to host backend on their own servers, providing more flexibility and potential to customization compared to cloud-based BaaS, which often is more difficult to migrate from. However, developers are also in charge of managing the infrastructure, security, and scalability of their servers. === Mobile BaaS === Mobile backend as a service (MBaaS) is a type of BaaS specifically for applications deployed in mobile systems. While some references use MBaaS interchangeably for BaaS, BaaS can have a wider variety of support such as for web apps and desktop apps. == Business model == BaaS providers generate revenue from their services in various ways, often using a freemium model. Under this model, a client receives a certain number of free active users or API calls per month, and pays a fee for each user or call over this limit. Alternatively, clients can pay a set fee for a package which allows for a greater number of calls or active users per month. There are also flat fee plans that make the pricing more predictable. Some of the providers offer the unlimited API calls inside their free plan offerings. Another business model that has been used by a lot of BaaS providers is PAYG (pay as you go), which has a flexible cost based on developers' usage of database, storage, bandwidth, function calls, user numbers etc.
Scale-space axioms
In image processing and computer vision, a scale space framework can be used to represent an image as a family of gradually smoothed images. This framework is very general and a variety of scale space representations exist. A typical approach for choosing a particular type of scale space representation is to establish a set of scale-space axioms, describing basic properties of the desired scale-space representation and often chosen so as to make the representation useful in practical applications. Once established, the axioms narrow the possible scale-space representations to a smaller class, typically with only a few free parameters. A set of standard scale space axioms, discussed below, leads to the linear Gaussian scale-space, which is the most common type of scale space used in image processing and computer vision. == Scale space axioms for the linear scale-space representation == The linear scale space representation L ( x , y , t ) = ( T t f ) ( x , y ) = g ( x , y , t ) ∗ f ( x , y ) {\displaystyle L(x,y,t)=(T_{t}f)(x,y)=g(x,y,t)f(x,y)} of signal f ( x , y ) {\displaystyle f(x,y)} obtained by smoothing with the Gaussian kernel g ( x , y , t ) {\displaystyle g(x,y,t)} satisfies a number of properties 'scale-space axioms' that make it a special form of multi-scale representation: linearity T t ( a f + b h ) = a T t f + b T t h {\displaystyle T_{t}(af+bh)=aT_{t}f+bT_{t}h} where f {\displaystyle f} and h {\displaystyle h} are signals while a {\displaystyle a} and b {\displaystyle b} are constants, shift invariance T t S ( Δ x , Δ y ) f = S ( Δ x , Δ y ) T t f {\displaystyle T_{t}S_{(\Delta x,\Delta _{y})}f=S_{(\Delta x,\Delta _{y})}T_{t}f} where S ( Δ x , Δ y ) {\displaystyle S_{(\Delta x,\Delta _{y})}} denotes the shift (translation) operator ( S ( Δ x , Δ y ) f ) ( x , y ) = f ( x − Δ x , y − Δ y ) {\displaystyle (S_{(\Delta x,\Delta _{y})}f)(x,y)=f(x-\Delta x,y-\Delta y)} semi-group structure g ( x , y , t 1 ) ∗ g ( x , y , t 2 ) = g ( x , y , t 1 + t 2 ) {\displaystyle g(x,y,t_{1})g(x,y,t_{2})=g(x,y,t_{1}+t_{2})} with the associated cascade smoothing property L ( x , y , t 2 ) = g ( x , y , t 2 − t 1 ) ∗ L ( x , y , t 1 ) {\displaystyle L(x,y,t_{2})=g(x,y,t_{2}-t_{1})L(x,y,t_{1})} existence of an infinitesimal generator A {\displaystyle A} ∂ t L ( x , y , t ) = ( A L ) ( x , y , t ) {\displaystyle \partial _{t}L(x,y,t)=(AL)(x,y,t)} non-creation of local extrema (zero-crossings) in one dimension, non-enhancement of local extrema in any number of dimensions ∂ t L ( x , y , t ) ≤ 0 {\displaystyle \partial _{t}L(x,y,t)\leq 0} at spatial maxima and ∂ t L ( x , y , t ) ≥ 0 {\displaystyle \partial _{t}L(x,y,t)\geq 0} at spatial minima, rotational symmetry g ( x , y , t ) = h ( x 2 + y 2 , t ) {\displaystyle g(x,y,t)=h(x^{2}+y^{2},t)} for some function h {\displaystyle h} , scale invariance g ^ ( ω x , ω y , t ) = h ^ ( ω x φ ( t ) , ω x φ ( t ) ) {\displaystyle {\hat {g}}(\omega _{x},\omega _{y},t)={\hat {h}}({\frac {\omega _{x}}{\varphi (t)}},{\frac {\omega _{x}}{\varphi (t)}})} for some functions φ {\displaystyle \varphi } and h ^ {\displaystyle {\hat {h}}} where g ^ {\displaystyle {\hat {g}}} denotes the Fourier transform of g {\displaystyle g} , positivity g ( x , y , t ) ≥ 0 {\displaystyle g(x,y,t)\geq 0} , normalization ∫ x = − ∞ ∞ ∫ y = − ∞ ∞ g ( x , y , t ) d x d y = 1 {\displaystyle \int _{x=-\infty }^{\infty }\int _{y=-\infty }^{\infty }g(x,y,t)\,dx\,dy=1} . In fact, it can be shown that the Gaussian kernel is a unique choice given several different combinations of subsets of these scale-space axioms: most of the axioms (linearity, shift-invariance, semigroup) correspond to scaling being a semigroup of shift-invariant linear operator, which is satisfied by a number of families integral transforms, while "non-creation of local extrema" for one-dimensional signals or "non-enhancement of local extrema" for higher-dimensional signals are the crucial axioms which relate scale-spaces to smoothing (formally, parabolic partial differential equations), and hence select for the Gaussian. The Gaussian kernel is also separable in Cartesian coordinates, i.e. g ( x , y , t ) = g ( x , t ) g ( y , t ) {\displaystyle g(x,y,t)=g(x,t)\,g(y,t)} . Separability is, however, not counted as a scale-space axiom, since it is a coordinate dependent property related to issues of implementation. In addition, the requirement of separability in combination with rotational symmetry per se fixates the smoothing kernel to be a Gaussian. There exists a generalization of the Gaussian scale-space theory to more general affine and spatio-temporal scale-spaces. In addition to variabilities over scale, which original scale-space theory was designed to handle, this generalized scale-space theory also comprises other types of variabilities, including image deformations caused by viewing variations, approximated by local affine transformations, and relative motions between objects in the world and the observer, approximated by local Galilean transformations. In this theory, rotational symmetry is not imposed as a necessary scale-space axiom and is instead replaced by requirements of affine and/or Galilean covariance. The generalized scale-space theory leads to predictions about receptive field profiles in good qualitative agreement with receptive field profiles measured by cell recordings in biological vision. In the computer vision, image processing and signal processing literature there are many other multi-scale approaches, using wavelets and a variety of other kernels, that do not exploit or require the same requirements as scale space descriptions do; please see the article on related multi-scale approaches. There has also been work on discrete scale-space concepts that carry the scale-space properties over to the discrete domain; see the article on scale space implementation for examples and references.
Document-oriented database
A document-oriented database, or document store, is a computer program and data storage system designed for storing, retrieving, and managing document-oriented information, also known as semi-structured data. Document-oriented databases are one of the main categories of NoSQL databases, and the popularity of the term "document-oriented database" has grown alongside the adoption of NoSQL itself. XML databases are a subclass of document-oriented databases optimized for XML documents. Graph databases are similar, but add another layer, the relationship, which allows them to link documents for rapid traversal. Document-oriented databases are conceptually an extension of the key–value store, another type of NoSQL database. In key-value stores, data is treated as opaque by the database, whereas document-oriented systems exploit the internal structure of documents to extract metadata and optimize storage and queries. Although in practice the distinction can be minimal due to modern tooling, document stores are designed to provide a richer programming experience with modern programming techniques. Document databases differ significantly from traditional relational databases (RDBs). Relational databases store data in predefined tables, often requiring an object to be split across multiple tables. In contrast, document databases store all information for a given object in a single document, with each document potentially having a unique structure. This design eliminates the need for object-relational mapping when loading data into the database. == Documents == The central concept of a document-oriented database is the notion of a document. Although implementations vary in their specific definitions, document-oriented databases generally treat documents as self-contained units that encapsulate and encode data in a standardized format. Common encoding formats include XML, YAML, JSON, as well as binary representations such as BSON. Documents in a document store are equivalent to the programming concept of an object. They are not required to adhere to a fixed schema, and documents within the same collection may contain different fields or structures. Fields may be optional, and documents of the same logical type may differ in composition. For example, the following illustrates a document encoded in JSON: A second document might be encoded in XML as: The two example documents share some structural elements but also contain unique fields. The structure, text, and other data within each document are collectively referred to as the document's content and can be accessed or modified using retrieval or editing operations. Unlike relational databases, in which each record contains the same fields and unused fields are left empty, document-oriented databases do not require uniform fields across documents. This design allows new information to be added to some documents without affecting the structure of others. Document databases often support the storage of additional metadata alongside the document content. Such metadata may relate to organizational features, security, indexing, or other implementation-specific features. === CRUD operations === The core operations supported by a document-oriented database for manipulating documents are similar to those in other databases. Although terminology is not perfectly standardized, these operations are generally recognized as Create, Read, Update, and Delete (CRUD). Creation (C): Adds a new document to the database. Retrieval (R): Retrieves documents or fields based on queries. Update (U): Modifies the contents of existing documents. Deletion (D): Removes documents from the database. === Keys === Documents in a document-oriented database are addressed via a unique identifier. This identifier, often a string, URI, or path, can be used to retrieve the document from the database. Most document stores maintain an index on the key to optimize retrieval, and in some implementations the key is required when creating or inserting a new document. === Retrieval === In addition to key-based access, document-oriented databases typically provide an API or query language that enables retrieval based on document content or associated metadata. For example, a query may return all documents with a specific field matching a given value. The available query features, indexing options, and performance characteristics vary across implementations. Document stores differ from key-value stores in that they exploit the internal structure and metadata of stored documents. In many key-value stores, values are treated as opaque or "black-box" data, meaning the database system does not interpret their internal structure. By contrast, document-oriented databases can classify and interpret document content. This enables queries that distinguish between types of data––for example, retrieving all phone numbers containing "555" without also matching a postal code such as "55555." === Editing === Document databases typically provide mechanisms for updating or editing the content or metadata of a document. Updates may involve replacing the entire document or modifying individual elements or fields within the document. === Organization === Document database implementations support a variety of methods for organizing documents, including: Collections: Groups of documents. Depending on the implementation, a document may be required to belong to a single collection or may be allowed in multiple collections. Tags and non-visible metadata: Additional data stored outside the main document content. Directory hierarchies: Documents organized in a tree-like structure, often based on path or URI. These organizational structures may differ between logical and physical representations (e.g. on disk or in memory). == Relationship to other databases == === Relationship to key-value stores === A document-oriented database can be viewed as a specialized form of key-value store, which is itself a category of NoSQL database. In a basic key-value store, the stored value is typically treated as opaque by the database system. By contrast, a document-oriented database provides APIs or a query and update language that allows queries and modifications based on the internal structure of the document. For users who do not require advanced query, retrieval, or update capabilities, the distinction between document-oriented databases and key-value stores may be minimal. === Relationship to search engines === Some search engine and information retrieval systems, such as Apache Solr and Elasticsearch, provide document storage and support core document operations. As a result, they may meet certain functional definitions of a document-oriented database, although their primary design goals differ. === Relationship to relational databases === In a relational database, data is organized into predefined types represented as tables. Each table contains rows (records) with a fixed set of columns (fields), so all records in a table share the same structure. Administrators typically define indexes on selected fields to improve query performance. A central principle of relational database design is database normalization, in which data that might otherwise be repeated is stored in separate tables and linked using keys. When records in different tables are related, a foreign key is used to associate them. For example, an address book application may store a contact's name, image, phone numbers, mailing addresses, and email addresses. In a normalized relational design, separate tables might be created for contacts, phone numbers, and email addresses. The phone number table would include a foreign key referencing the associated contact. To reconstruct a complete contact record, the database retrieves related information from each table using the foreign keys and combines it into a single record. In contrast, a document-oriented database stores all data related to an object within a single document, and stored in the database as a single entry. In the address book example,the contact's name, image, and contact information may be stored together in one document. The document is retrieved using a unique key, and all related information is returned together, without needing to look up multiple tables. A key difference between the document-oriented and relational models is that the data formats are not predefined in the document case. In most cases, any sort of document can be stored in a database, and documents can change in type and form over time. For example, a new field such as COUNTRY_FLAG can be added to new documents as they are inserted without affecting existing documents. To aid retrieval, document-oriented systems generally allow the administrator to provide hints to the database for locating certain types of information. These hints work in a similar fashion to indexes in relational databases. Many systems also allow additional metadata outside the content of the document itself
AFNLP
AFNLP (Asian Federation of Natural Language Processing Associations) is the organization for coordinating the natural language processing related activities and events in the Asia-Pacific region. == Foundation == AFNLP was founded on 4 October 2000. == Member Associations == ALTA – Australasian Language Technology Association ANLP Japan Association of Natural Language Processing ROCLING Taiwan ROC Computational Linguistics Society SIG-KLC Korea SIG-Korean Language Computing of Korea Information Science Society == Existing Asian Initiatives == NLPRS: Natural Language Processing Pacific Rim Symposium IRAL: International Workshop on Information Retrieval with Asian Languages PACLING: Pacific Association for Computational Linguistics PACLIC: Pacific Asia Conference on Language, Information and Computation PRICAI: Pacific Rim International Conference on AI ICCPOL: International Conference on Computer Processing of Oriental Languages ROCLING: Research on Computational Linguistics Conference == Conferences == IJCNLP-04: The 1st International Joint Conference on Natural Language Processing in Hainan Island, China IJCNLP-05: The 2nd International Joint Conference on Natural Language Processing in Jeju Island, Korea IJCNLP-08: The 3rd International Joint Conference on Natural Language Processing in Hyderabad, India ACL-IJCNLP-2009: Joint Conference of the 47th Annual Meeting of the Association for Computational Linguistics (ACL) and 4th International Joint Conference on Natural Language Processing (IJCNLP) in Singapore IJNCLP-11: The 5th International Joint Conference on Natural Language Processing in Chiang Mai, Thailand