asn07 - W3C RIF-WG Wiki

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.

*** Issue: Should we switch to using {...} or an "end" keyword? ***

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:

`OrderedSlot`	The value of the property is a list of elements, each element being of the type valueType
`UnorderedSlot`	The property has `CardinalityType` values, each of the type valueType

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.