• asn07

asn07 is a language for defining information structures. Each complete asn07 definition, or schema, specifies a class hierachy and a set of typed properties (also called fields or slots) for each class in the hierarchy. An earlier version of this work was called asn06.

asn07 is intended to be used for some of the same purposes as UML, EBNF, OWL, XML Schema, IDL, ER-Diagrams, and SQL Table definitions. It does not attempt to subsume or replace any of them, in all their detail, but rather to encompass a simplified aspect of each of them. Specifically, asn07 is intended to allow programmers to conceptualize a particular pattern of data (a data interface), independent of the technology, methodology, or platform. Tools can be written to convert between asn07 and these other languages, given certain conventions about how somewhat-different concepts are mapped between the languages

An asn07 schema defines which information structures must be present in a conforming information container, such as a network packet, Web document, or database. The schema allows us to talk, for instance, about what is present in a RIF "BLD Ruleset" without committing ourselves to XML or Java or other technology platforms. This is particularly useful for RIF because of its goal of being deeply independent of platform. Although RIF-WG is committed to using XML for public interchange, we do not want to require XML technology to be used deeply within all RIF-conformant systems.

1. Examples

Here are some example asn07 schemas, which may help form an intuitive sense of what the language does, and how it works.

1.1. Purchase Order

This example comes from the XML Schema Primer.

  class PurchaseOrder      property orderDate: string      property shipTo: PersonAtAddress      property billTo: PersonAtAddress      property comment: string      property items: List(item)    class PersonAtAddress      property name: string      property street: string      property city: string      property state: string      property zip: string    class Item       property partNum: string      property productName: string      property quantity: int      property USPrice: decimal      property comment: string 

1.2. First Order Logic

Here's a schema for First Order Logic using fairly conventional terminology:

     class Term               subclass Constant           property name: string         subclass Variable           property name: string          subclass LogicFunction           property functor: string           property arguments: List(Term)      class Formula         subclass AtomicFormula           property predicate: string           property arguments: List(Term)         subclass Conjunction             property left: Formula             property right: Formula         subclass Disjunction             property left: Formula             property right: Formula         subclass Negation             property negated: Formula         subclass Implication             property if: Formula             property then: Formula         subclass Biconditional             property left: Formula             property right: Formula          subclass QuantifiedFormula             property variable: Variable+             property subformula: Formula              subclass ExistentiallyQuantifiedFormula              subclass UniversallyQuantifiedFormula  

2. Syntax

Here's the EBNF for asn07:

File ::= NamespaceDeclaration* Import* ClassDeclaration*  NamespaceDeclaration ::= "default"? "namespace" PREFIX STRING ENDLINE  Import ::= "import" (PREFIX | STRING) ENDLINE  ClassDeclaration ::= "class" ClassDeclarationBody  ClassDeclarationBody ::= QNAME INDENT Entry* DEDENT  Entry ::= "property" QNAME ":" ValueType ENDLINE         | "subclass" ClassDeclarationBody  ValueType ::= QNAME CardinalityType             | "List(" QNAME ")"  CardinalityType ::=  | "?" | "+" | "*"  

The PREFIX and QNAME (Qualified Name) terminals are defines as in Namespaces in XML 1.0. The STRING terminal is a surrounded by double quotes and any double quotes or backslashes in it are escaped by a preceding backslash.

The INDENT and DEDENT terminals are defined as in Python, and function grammatically like traditionally block wrappers "{" ... "}", but use indentation levels to signal blocks.

3. Semantics

In addition to being probably incomplete, this section is quite informal. It may be formalized at some point in the future.

3.1. Information Structures

The abstract information container that an asn07 schema constrains has the following qualities:

• Zero or more objects

• Each object has exactly one class

• Each object has zero or more properties (fields, slots, ...)
• Each property has zero or more values, which may be ordered or unordered. If the values are unordered, duplicates are not maintained.
• The values of properties may be references to other objects in the collections, or they may be literal data values (with a data type as in XML Schema).

These object semantics are a subset of RDF, but not align perfectly with most other systems, but instead aim for a common ground which is close enough to other systems that the difference are easy to account for. For instance, this model aligns with Java if the Java class and field names are mapped to IRIs and the field values are always Collections.

3.1.1. ASN07 schema for reference object container

Here is an asn07 schema for the abstracted collection of information which each asn07 schema is imagined to contstrain. Here it is called InformationContainer.

class InformationContainer property object: InformationObject*   class InformationObject    property property: Property*  class Property    property valueType: ValueType     subclass OrderedProperty    # List of values     subclass UnorderedProperty  # Set of values  class ValueType        subclass InformationObject     subclass DataValue  class DataValue    property lexicalRepresentation: xs:string    property datatype: xs:anyURI 

3.2. Slots

The primary element in an asn07 schema is the slot definition and its reference from the class definition:

class Class    property classIRI: anyIRI    property subclass: Class*    property slot: Slot*  class Slot    property propertyIRI: anyIRI    property valueType: ValueType     subclass UnorderedSlot       property cardinalityType: CardinalityType     subclass OrderedSlot  class CardinalityType     subclass ExactlyOne    subclass OneOrMore    subclass ZeroOrMore    subclass ZeroOrOne  

What this means is that every instance of the given class has the given property, propertyIRI, and that the values of that property are as detailed here:

3.3. Subclasses

The subclass relation between two asn07 classes has several effects:

First, a class inherits properties from its superclasses (and the superclasses' superclasses, recursively). Because slots are not ordered, superclass inheritance does not need to be ordered either. If the same slot name is used repeatedly in a class, such as via inheritance, the resulting valueType is the intersection of valueTypes if there is one (or an error, if not.)

Second, subclasses stand in for their superclasses as ValueTypes. When the valueType for a slot is given as class C, and C has a subclass D, then D is a valid value type for the slot.

Finally, only leaf classes (classes with no subclasses) may be present in an information container. Superclasses are an organizational tool only; they do not manifest in the information content.

3.4. Datatypes

To be done.

(The syntax probable needs a 'datatype' declaration.)

3.5. Namespaces and Imports

To be done.