Positional-Slotted Object-Applicative (PSOA) RuleML has been used for graph-relational data and knowledge representation in an executable presentation syntax. In support of interoperation, the XML specifications of Deliberation RuleML Versions 1.02 and 1.03 are extended for Deliberation PSOA RuleML V. 1.03 (PSOA RuleML/XML 1.03). To specify PSOA RuleML's new kinds of atoms (e.g., allowing dependent slots and explicit tuples) and functional expressions, RuleML's MYNG-defined schema system is extended and modified. The PSOAextended modular Relax NG schemas, in Compact syntax (RNC), are transformed to monolithic XSD schemas by application of the Trang Schema Converter, followed by an XSLT postprocessor previously developed for Deliberation RuleML. Validation of a PSOA rulebase instance can thus be performed w.r.t. RNC, XSD, or dual RNC+XSD schemas. The earlier XSLT-based Deliberation RuleML normalizer is likewise extended for PSOA RuleML. As for all of RuleML, a "normalidation" workflow, where rulebases undergo "first normalization, second validation", prevents false negatives on direct validation against the XSD or RNC+XSD schemas.
Advanced AI systems need to be based on both data (e.g., variableless facts) and knowledge (e.g., rules), where knowledge can be engineered by humans and/or learned by machines from data. The data and knowledge representation language Positional-Slotted Object-Applicative (PSOA) RuleML [Bol11,BZ19,Bol18] as realized by the execution system PSOATransRun [ZB16,Zou18] has been employed in various graph-relational use cases, including ATC KB [DMA + 19]. 1 For this, PSOA RuleML's (plain-text) presentation syntax has mostly been utilized. However, data and knowledge validation, transformation, interchange, and reuse benefit from serialization (XML) syntaxes as provided by RuleML 2 . A translator from versions of PSOA RuleML/XML to PSOA presentation syntax has established a link in one direction [ARBB12] 3 .
The specification of RuleML itself has usually employed both presentation and serialization syntaxes. Of these, RuleML/XML is normatively specified with Relax NG schemas [AB11] while informative XSD schemas are (Trang+XSLT)generated for major languages, called "anchor languages", including hornlog.
PSOA RuleML Version 1.0 4 was specified with model-theoretic semantics and transformational realizations over an EBNF and -in PSOATransRun -ANTLRdefined presentation syntax, also initializing the XML syntax. Moreover, the specification of RuleML starting with Version 1.02 5 permits the definition of semantic styles, including predefined styles 6 , one of which being for Horn-PSOA Tarski 7 .
In general, a RuleML logic is considered as a (syntactic) language paired with a (semantic) style [Bol16] 8 . The PSOA RuleML page thus specifies syntaxes 9 and semantics 10 . In particular, the PSOA RuleML logic of interest here is the hornlogPSOA language of the PSOA RuleML/XML Version 1.03 family paired with the semantic style Horn-PSOA Tarski.
PSOA RuleML/XML Version 1.03 is specified on the RuleML website 11 -carrying through the sketch in [Bol15], Section 6 -and described in the current paper. PSOA RuleML/XML 1.03 extends the XML specifications of Deliberation RuleML Versions 1.02 (released) and 1.03 (ongoing). PSOA RuleML's extended "psoa atoms" (e.g., allowing dependent slots and explicit tuples) lead to extensions of Deliberation PSOA RuleML/XML Version 1.03 (relative to Deliberation RuleML/XML Version 1.03) focused on new modules that define the new PSOA features (dependent slots and explicit tuples) and modifications of the modules that define serialization-sensitive named patterns 12 for atoms and functional expressions. From there, because of the modular structure of the Relax NG schemas, the PSOA-schema extensions are applied to the rest of the syntac-tic structures, including to queries and rules, whenever the new PSOA modules are included in the governing driver schema. Existing RuleML languages, whose drivers do not include the PSOA modules, are not affected by these extensions. This paper describes the current prerelease of PSOA RuleML/XML 1.0313 as a major addition to RuleML's open-source repository:
-PSOA-enabling changes are made to the existing named patterns in the Relax NG schema modules that define the content models of atoms (Node: Atom) and functional expressions (Nodes: Expr and Plex). -Four completely new modules are introduced in order to define new elements: the element slotdep (to complement existing slot), edge elements tup and tupdep, as well as a Node element, Tuple. -New anchor languages for PSOA's existing collection14 , as previewed in the left branch of Fig. 1 (which will be explained in Section 5.4):
Next, following this introduction, the paper will give PSOA/XML examples (Section 2). Then, complete instance documents will be exposed in the sequence of "first validation, second normalization"15 (Section 3). After the preceding two sections' presentation of the "what", the subsequent four sections will proceed to the "how". To provide context, the existing RuleML V. 1.03 schema methodology will be reviewed (Section 4). Then, PSOA changes to the schema system will be explained (Section 5). Continuing the expository sequence, PSOA changes to the normalizer will be discussed (Section 6). Shifting perspective to the level of supporting infrastructure, configuration and test scripts will be discussed (Section 7). The paper will conclude with hints for future work (Section 8). Finally, online validation (Appendix A) and normalization (Appendix B) will be demonstrated.
Examples will be given in a "relaxed" XML serialization (containing and merging both "compact" and "normalized" serializations as well as adding positional freedom), where aligned XML comments will show the corresponding presentation syntax.
Dependent slots as discussed in [BZ19] are employed for making slot names unambiguous by interpreting them under the perspective of a predicate. A use case for dependent slots and other PSOA RuleML features is explained in [DMA + 19].
Fig. 1. Hasse diagram for a subset of the RuleML language semilattice with infimum corresponding to the Datalog language (anchor datalog min) and suprema corresponding to the PSOA language (anchor naffologeqPSOA) and the non-PSOA language (anchor naffologeq). All of the vertices of the depicted semilattice are identified by their myng-codes. The myng-code for Datalog is shown in its entirety, while for other vertices only the components that differ from their nearest sublanguage are shown.
Dependent-Slotted Fact (Reduced to its Atom) Example S1. Purchase record with dependent slots. An OID transaction200 is typed by the predicate purchase, which is applied to three purchase-dependent slots. A slot name like item is thus disambiguated to be the item-of-the-purchase. Because this atom is oidful, slotted, and dependent, according to the metamodel of [BZ19] it is an example of a pairpoint.
Dependent-Slotted Rule Example S2. Liability rule based on purchase record. An independent-slotted version of this was introduced elsewhere 16 . The slot name item changes its dependence from the predicate purchase (item-of-the-purchase) in the condition to the predicate liability (item-of-the-liability) in the conclusion. The slot filler-variable b moves from slot name buyer in the condition to slot name bearer in the conclusion. The rule is applicable to the dependent-slotted fact of Example S1, deducing a liability record (conclusion: <then> part) from that purchase record (condition: <if> part), where a fresh liability OID, liabilityID(transaction200), is generated as a functional expression from the purchase OID, transaction200. Example T3. Cyclic-purchase rule based on one or more purchase tuples. The condition (first child of Implies) 18 detects a tuple, anywhere amongst the tuples, for which there also is, again anywhere, an 'inverse' tuple (where the buyer x and seller y are swapped to y and x while the item i is kept the same). A special case of this cyclicity condition is x = y (someone purchasing from themselves). The conclusion (second child of Implies) 18 alerts about such a cyclic purchase by showing the tuple of the involved buyer, seller and item, hence provides more information than the 'falsity' conclusion of a corresponding integrity rule would. The rule is applicable, in two possible ways, to the dependent-tupled fact of Example T1.B, deducing two alert tuples: +[Pedro Amy Tabby] and +[Amy Pedro Tabby].
Based on examples of the previous section, the current section discusses characteristic XML processing of instance documents, which for RuleML are rulebases (including facts): their validation w.r.t. schemas and their XML-to-XML transformation (here, normalization).
Deliberation RuleML's RNC-& XSD-based validation checks whether instances conform to its RNC-& XSD-schema definition. 19 This has been extended for PSOA RuleML's additional features of dependent slots and explicit tuples, as will be explained in Section 5.
For example, the dependent-slotted fact in Section 2.1 can be completed to a PSOA RuleML instance document with <RuleML> and <Assert> wrappers:
This instance is valid w.r.t. the RNC & XSD schemas. An instance with, e.g., one instead of two <slotdep> children such as <slotdep><Ind>buyer</Ind> </slotdep>, is invalid. Readers are encouraged to try these and other instances online (cf. Appendix A).
Deliberation RuleML's XSLT-based normalizer (see Section 4.3) fills in skipped edges and sorts elements into a canonical order.20 Again, this has been extended for PSOA RuleML's additional features, as will be explained in Section 6.
Much of the PSOA RuleML normalizer's functionality can be seen for Example T3 of Section 2.2, which becomes transformed thus: An equivalent normal form is obtained from the various non-normal forms of Example T3, e.g. with only some of the edges skipped. Readers are again encouraged to try these and other instances online (cf. Appendix B).
In this section, we review the RuleML schema methodology that was developed, primarily, for RuleML V. 1.0 [AB11]22 . In the subsequent Versions 1.01 [AB14], 1.02 [ABP15] and 1.03 23 of Deliberation RuleML, the schema modularization system has been extended and enhanced, while upholding the original design principles. The following subsections described the aspects of RuleML's schema system relevant to the new PSOA/RuleML XML extension, including modularization design principles, and serialization, normalization, initialization, pivotschema, customization, and test-automation methodologies.
Beginning with Version 1.0, Deliberation RuleML introduced a modularization approach, based on a restriction of Relax NG [AB11], whereby a RuleML syntax is defined by a set of RNC module inclusions in a driver schema. The restricted Relax NG is monotonic, meaning when two drivers are combined, i.e. by forming the union of the module inclusions in a larger driver, the syntax defined by the larger driver contains both of the smaller syntaxes [AB14]. Because of this monotonicity property, the more than one hundred Deliberation RuleML schema modules 24 may be freely (orthogonally) combined to define a fine-grained poset lattice of RuleML syntaxes, with a partial order based on syntactic containment.
As may be seen in the schema snippets in Section 5, the RuleML RNC schema employs element definition conventions consisting of several layers of named patterns, in order to optimize schema extensibility.
In summary, the main design principles of the RuleML schema modularization system are:
-Monotonicity -Orthogonality -Extensibility
There are four serializations of Deliberation RuleML -normalized, relaxed, mixed, and compact.
The "normalized" serialization requires all content models to have a canonical ordering of their child elements. For example, the canonical ordering for atoms requires positional arguments to precede slots, should both occur in the same atom. The canonical ordering of the contents of functional expressions is maintained to be identical to that of atoms.
The "relaxed" serialization allows significantly more positional freedom in content models. It also allows certain edges to be skipped, provided they can be reconstructed unambiguously.
In general, the RNC patterns for the relaxed serialization content models are similar to that of the corresponding normalized serialization patterns after substitution of the interleave symbol '&' for commas in the definition of sequences. RuleML takes advantage of this convenient RNC mechanism for implementing positional freedom in content models to define the relaxed serialization. However, the interleave pattern cannot be accurately translated into XSD, due to the XSD requirement of deterministic models25 . The "mixed" serialization (of some language) is constructed to be the greatest subset of the relaxed serialization (of that language) with the most positional freedom that can still be defined within XSD (see Section 4.5).
The "compact" serialization is similar to the normalized one in that it requires the same canonical ordering of elements. It differs from the normalized one in that it requires all edges skippable in the relaxed serialization to be skipped.
Elements whose content models have some positional freedom among their children in the relaxed and mixed serializations, including atomic formulas (Atom) and functional expressions (Expr and Plex), have their content models for the four serializations specified in three RNC serialization modules26 27 28 , resp. The main exception to the RuleML schema design principle of orthogonality occurs in regard to serialization: a (valid) driver schema may have only one serialization module inclusion.
The goals of the RuleML normalizer include the following:
-Reconstruct all skipped edge tags to produce a fully striped form (since edge tags correspond to Resource Description Framework (RDF) [29] properties, this simplifies interoperation between RuleML/XML and, e.g., directed labeled RDF graphs) -Perform canonical ordering of sibling elements (this reduces the complexity of equality comparison across RuleML/XML serializations, for both humans and machines)
We say that using this normalizer followed by schema-based RuleML validation performs "normalidation" on RuleML instances. That is, not only are missing edge elements inserted and sibling elements sorted in the XSLT output, but this transformed instance is subsequently validated syntactically to ensure that Node and edge elements only appear in correct positions, and with permitted content. Normalidation is required when using the XSD schemas for validation of general RuleML instances, because the positional freedom allowed by the relaxed serialization of the Relax NG schemas is beyond the expressivity of XSD. This is to prevent valid instances being deemed as invalid ("false negatives").
Another exception to the orthogonality principle is required in order to support the development and implementation of the (otherwise) orthogonal system: the inclusion of the initialization module29 , containing vacuous (either empty or not allowed) definitions of many named patterns, is required in all (valid) drivers so that named patterns that are used in an included module but defined in an excluded module are never left undefined in the inclusion closure of the driver. In particular, singleton inclusion sets (a driver containing only one module inclusion) are not valid, in general, within the RuleML modularization system. Such drivers become valid upon inclusion of the initialization module, enabling fine-grained validation during development as well as ensuring orthogonality in implementation.
The RNC schemas act as normative "pivot schemas"30 that define the XSD schemas for Deliberation RuleML languages by translation using Trang31 followed by XSLT post-processing [AB11]. The XSD schema for the normalized serialization of a Deliberation RuleML language is obtained in a straightforward manner by this translation mechanism. In order to define a 'more relaxed' XSD schema having as much positional freedom in content models as possible, while still remaining deterministic, the 'mixed' serialization is used. The Relax NG for the mixed serialization implements this trade-off through involved regular expressions.
In order to manage the large number of RuleML syntaxes generated by the above modularization approach, the Modular sYNtax confiGurator (MYNG) application [Ath11] was developed to provide a unified parameterized RNC schema accessible either directly, using a REST interface implemented in PHP, or through a GUI32 that exposes the REST interface. The parameters which specify directly the features of the syntax, and indirectly the module inclusion set needed to define those features, are efficiently captured in a string called the "myng-code". The myng-code is partitioned into sets of features called "option facets". Each feature of a facet is assigned a unique bit position, from zero up, where a digit of 1 in that position indicates the feature is selected and 0 otherwise. Although myng-codes are interpreted according to their binary representation, they are expressed and transmitted in hexadecimal for brevity.
RNC and XSD schemas for RuleML anchor languages are obtained from human-readable URLs via URL redirects to the MYNG PHP engine with the specifying myng-code parameters expressed in the query string. The redirects are implemented through a .htaccess file that is auto-generated by a configuration bash script.
RuleML's automated testing procedures include Jing validation of RNC modules and driver schemas, as well as JAXB33 validation of XSD schemas. Cross-testing of the schemas is carried out by auto-generating XML instances from the XSD schemas and validating them against the RNC schemas.
The modifications necessary to implement the new PSOA/XML syntax, described below, are guided by the structure and principles of the RuleML schema system as reviewed in Section 4. Validation of PSOA RuleML instances against PSOA schemas is illustrated in Appendix A.
The PSOA feature of dependent slots in atoms and functional expressions is implemented, in part, by means of the introduction into the modular RNC schema system of one new module 34 .
The new module defining the dependent slot element is essentially identical to the existing module defining the independent slot element35 after substitution of slotdep for most occurrences of slot. An RNC snippet of the module is shown below.
The PSOA feature of explicit tuples in atoms and functional expressions is partially implemented in the modular RNC schema system by means of the introduction of three new modules36 37 38 . RNC snippets from these modules are shown below.
From tuple expansion module.rnc Tuple-node.choice |= Tuple.Node.def ## The children of a generalized list (tuple) are divided into two sections, ## a header section for modifiers, and a main section for the list arguments. Tuple.Node.def = ## A collection of (ordered) arguments (optionally enclosed by <arg>) and/or (unordered) user-defined slots (<slot>), ## identical to an uninterpreted expression (<Expr in="no">) except not having a user-specified function name (equivalent ## to having a system-specified constructor 'Tuple').
Rest variables (<repo> and <resl>) are also permitted. ... ## within repo element Tuple { Tuple.type.def } Tuple.type.def = Tuple.attlist, Tuple.header, Tuple.main Tuple.attlist &= commonNode.attlist? ## Generalized lists accept the header pattern common to Nodes. Tuple.header &= Node.header? # For the declaration of the Node header, see the modules meta_expansion_module). The tup expansion module.rnc module is similar to that of the already discussed tupdep expansion module.rnc.
For the canoncial ordering of the normalized serialization, an XML realization of the left-tuple, left-dependent canonical ordering is used that was given in [BZ19] for the PSOA presentation syntax. One reason for preferring this ordering is that the basic atoms of relationships, which are single-tuple, should be captured such that their arguments do not need to be moved when more descriptors are added.
The RNC snippet specifying this canonical ordering for PSOA atomic formulas is as follows: In support of the orthogonality principle, the new named patterns introduced for a sequence of dependent slots are initialized (see Section 4.4) as zero-length sequences to accommodate non-PSOA languages having no dependent slots. The RNC snippet from the initialization module that accomplishes this is as follows: The RNC for the relaxed serialization is similar to that of the normalized serialization shown above after substitution of the interleave symbol '&' for commas in the definition of sequences, as described in Section 4.2.
The XSDs for PSOA RuleML anchor languages are auto-generated as described in Section 4.5.
The myng-code (specifying Deliberation RuleML syntaxes, see Section 4.6) is extended to accommodate the PSOA/XML features. Three unused bits (binary positions 13 through 15) of the terms option facet are utilized for the features of dependent slots, dependent tuples, and independent tuples, respectively.
The inclusion of the slotdep expansion module.rnc module in a myngcode-specified driver schema occurs whenever its myng-code (expanded from hexadecimal to binary) has 1 as the binary digit in position 13 (2 13 ) of the terms option facet. Similarly, the tupdep expansion module.rnc and tup expansion module.rnc modules are associated with positions 14 and 15 of this facet. The inclusion of the tuple expansion module.rnc module is required if either tupdep expansion module.rnc or tup expansion module.rnc are included, since both edges are required to contain a Tuple element -thus, it is not an orthogonal feature.
Consequently, myng-codes for RuleML languages having full PSOA capability have the value 'e' or 'f' in hexadecimal position three (16 3 ) of the terms option facet, e.g. bf-d7-a7-l1-p3cf-i7-tef0f-q1-e3-s4c for hornlogPSOA normal.
A portion of the PSOA-extended RuleML anchor language semilattice depicting the new PSOA anchor languages and their nearest non-PSOA counterparts is shown in Fig. 1. The first row of vertices above the infimum corresponds to additional features of RuleML's datalog and datalogPSOA languages that are not part of textbook Datalog, differing from each other only with respect to the PSOA features (tef0f vs. tf0f) and rest variables (q1 vs. q7). The vertices in the second row above the infimum correspond to the additional feature characteristic of Horn logic, i.e. functional expressions (bf for Expr and e3 for Plex). The third row of vertices above the infimum corresponds to additional features characteristic of First-Order Logic (b3f), as well as weak negation (p3ff), equations (tef3f), and set-valued and interpreted expressions (ef).
<xsl:with-param name="tag">arg</xsl:with-param> </xsl:call-template> </xsl:template>
The normalizer is further modified to canonically order slots and tuples in atoms as follows.
<xsl:template match="ruleml:Atom" mode="phase-2"> <xsl:copy> ... <xsl:apply-templates select="ruleml:oid" mode="phase-2"/> ... <xsl:apply-templates select="ruleml:op" mode="phase-2"/> ... <xsl:apply-templates select="ruleml:tupdep" mode="phase-2"/> <xsl:apply-templates select="ruleml:tup" mode="phase-2"/> ... <xsl:apply-templates select="ruleml:slotdep" mode="phase-2"/> <xsl:apply-templates select="ruleml:slot" mode="phase-2"/> ... </xsl:copy> </xsl:template>
Updates and improvements have been made to RuleML's bash scripts40 for (anchor-language) configuration and (XSD-schema) testing.
The modified configuration text files used by the configuration scripts (in bash) implement the URL redirects for the new PSOA anchor languages. In the configuration file snippet below, the second and third columns contain the facet portion of the myng-code for the normalized and relaxed serializations, respectively, for the anchor language stem in the first column.
For example, execution of the configuration bash script will add a redirect to the .htaccess file that redirects a request for http://deliberation.ruleml.org/ 1.03-psoa/relaxng/hornlogPSOA_normal.rnc to http://deliberation.ruleml. org/1.03-psoa/relaxng/myng-b0f-d7-a7-l1-p3cf-i07-tef0f-q1-e3-s4c.rnc Similar redirects have been implemented for XSD schemas and simplified RNC schemas.
Among other tests, RuleML testing procedures have always performed JAXB validation of XSD schemas. However, upon detailed examination of the output from JAXB validation of RuleML XSD schemas during the development of the PSOA extension, it has been determined that only the schemas for the normalized serialization produce effective Java classes, even though the JAXB validation of the mixed serialization XSD schemas do not generate validation errors. Therefore, the test scripts have been modified to perform JAXB validation only on the XSD schemas for the normalized serialization. The mixed serialization XSD schemas are instead validated manually using Xerces41 .
In the PSOA relaxed serializations, it is allowed to reverse the canonical order of slotdep with slot or tupdep with tup. However, this aspect of positional freedom is not allowed in the mixed serialization (the most permissive serialization used in the XSD schemas, see Section 4.2). Therefore, the extended test suite applies the XSLT normalizer to the RNC test suites, which include such instances in the relaxed serialization.
In conclusion, this paper connects PSOA RuleML work based on its presentation syntax with Deliberation RuleML work based on its serialization syntax. The paper describes the prerelease of PSOA RuleML/XML 1.03 for the representation and processing of data (facts) and knowledge (rules). Deliberation RuleML's syntactic definition via a MYNG-defined schema system, as developed in V. 1.0 and enhanced in subsequent versions through V. 1.03, is further extended and modified to accommodate PSOA RuleML. The focus is on the validation as well as normalization of rulebases utilizing the new PSOA features of dependent slots and explicit tuples.
Future work42 encompasses the completion of the PSOA RuleML/XML 1.03 release 43 . This includes syntactic completion, e.g. by incorporating XML elements for Subclass ('##'), which was already used in other RuleML languages, e.g. for SWSL, and Equal ('='), which was already used in several Deliberation RuleML languages, e.g. in hornlogeq.
Conversely, while OIDs, e.g. for functional expressions, already are optional only, they could be entirely prohibited for expressions in a hornlogPSOA-restricting anchor language that defines a more precise, Expr-oidless and Plexless syntax for the semantic style Horn-PSOA Tarski realized by PSOATransRun.
Similarly, while the "extended PSOA" introduced in [Bol15], Section 6, allowing a "positional rest" within a tuple, has been adopted from Deliberation RuleML's schemas as an option by PSOA RuleML V. 1.03, it could be entirely prohibited in "pure PSOA" (anchor) languages.
Moreover, in a merged Deliberation PSOA RuleML, a PSOA-derived semantic style for built-in "slotribution" [Bol11] could be alternated with a Deliberationderived semantic style for an explicit "rest of slots" [Bol15].
Completion of the release also includes technical completion, e.g.:
-Update the MYNG GUI (in Javascript) to accommodate PSOA features that are already implemented in the MYNG PHP engine.
-Extend for PSOA the V. 1.03 compact serialization and associated transformer (compactifier).
-Automate the PSOA validation of mixed-serialization XSD schemas.
-Implement PSOA features as syntactic options within the RuleML Holog syntax. This is particularly important for restoring a single supremum to the Deliberation RuleML syntactic structure in a release merging Deliberation RuleML V. 1.03 and PSOA RuleML V. 1.03.
As the abstract inverse of the translator from PSOA RuleML/XML to PSOA presentation syntax [ARBB12], a translator from PSOA presentation syntax to PSOA RuleML/XML should be written. This could be layered on PSOATrans-Run's ANTLR-based parser for PSOA presentation syntax into Abstract Syntax Trees (ASTs) [ZPPBR12], adding an AST tree walker that generates PSOA RuleML/XML.
The results of the current work on PSOA-extended Deliberation RuleML should be transferred to Reaction RuleML and Consumer RuleML [ABP15], which could then target a further developed PSOA Prova [GBP18] engine. Support for (PSOA) RuleML/XML editing, validation, and transformation could be enhanced through the development of plugins or frameworks in professional tools, e.g. the Oxygen XML Editor suite44 , which is aware of Relax NG as well as XSD.
Strengthening an early connection, it would be interesting to compare PSOA RuleML logics with N3Logic [BLCK + 08], building, e.g., on the PhD work of Gen Zou [Zou18], Chapter 6, and of Dörthe Arndt [ASDRV19] as well as work by the W3C Notation 3 (N3) Community Group 45 . This can lead to the definition of a new RuleML logic customized for a revised N3.
The following PHP snippet shows the modifications to the MYNG engine which implement the extension of the myng-code for PSOA features.