The Daim Project

Daim

This is a tiny project that has little or no value for anyone but myself (http://purl.org/net/benny). The project goal is to develop a language for the Semantic Web that will never be used. It is simply done to increase my own knowledge in the area. The development starts with a theoretical model and then a language with an extremely simple and useless syntax is created.

(The name Daim has no meaning whatsoever; it was simply the first name that appeared in my mind.)

Status
Axioms and clarifications
Model - General introduction
Model - Formal specification
Syntax - General introduction
Mapping model onto syntax

Status

The project has started. Working on it right now (20010925). This document (project space) will evolve, i.e. it is not a static document. I have to apologize in advance for all the spelling and grammatical errors that might be found here. This is only a draft.

Axioms and clarifications

There are a few things that I assume about the model and language that is important to consider. First of all, the language is not a new N3, BSWL, RDF version or something like that. In fact, the language developed here is quite different from RDF:

Model - General Introduction

This section develops a model that is to be serialized/implemented by the language developed in this project. This is perhaps not the usual order of work when developing a language, but I think it's better this way since it emphasizes that the semantics is more important than the syntax.

The framework for the model has influences from [Peacock, 1998] who developed an abstract model (set theory model) for RDF WD 16 Feb 1998. The model developed here is different in a number of places from Peacocks - partly because this model is not dedicated to RDF - especially the interpretation of properties.

To begin, lets look at the basics of the model. The universe (domain of individuals) of the model is a set of objects called OBJECTS. These objects are at this point considered general. The OBJECTS set is further divided into two disjoint sets: C and P. To explain the difference between these sets, and since this language is to be a Semantic Web language, I will explain them and the model in terms of statements and meta statements.

A statement in the model is a 3-ary relation between three objects. The different roles an object has in the statement are object, attribute, and the value role (subject, predicate, object in the RDF-world). E.g. the statement "object a has the property b with value c" is a relation (a, b, c). Note: Using a property in a statement adds a member to the "property relation" (in the example the statement adds the member (a,c) to the property relation b). The set P contains all objects that can be used in the attribute (property) role in a statement. In the example b has to be a member of P for the relation to be a statement in the model. Further, the objects that are in P could also be used in the object and value role in a statement. The set C contains all the objects that can be used in the object and value role. The sets are disjoint.

STATEMENTS is the set of all statements (i.e. it contains relations). E.g. the set could look like this: STATEMENTS = {(a, b, c), (d, e, f)...} (where (a, b, c) and (d, e, f) are statements). Making a statement purely creates a relation, and this relation becomes an element of the STATEMENTS set.

The important feature of this model is that when making a statement, the statement (the relation) becomes an object in another "level" (subset) of the set C. The different "levels" (or subsets) are identified with a subscript, e.g. C1. An "empty" model (i.e. nothing has been stated) only contains a few primitive objects in C0. Statements about objects in P or C create objects in a subset of C, i.e. statements about objects in C1 will become elements in C2 and so on. This is illustrated below.

Use of properties

In the image above the statement is really a relation involving three objects (the statement is a member of STATEMENT) but the statement is illustrated this way to be more distinct. The object and attribute are objects in the set C0. The property (attribute) is a member of the set P0. The statement itself becomes an object, a, in the set C1 (an object in C1 is not present/represented in C0).

Image 2

In the image above a statement about a statement is illustrated. The elements of the statements are from C0 and C1 (object a). The property is, as before, a member of P0. This (meta-) statement will become an object (b in the image) at "level 2", i.e. a member of set C2. This last example illustrates how statements become objects, and how these objects are used in statements to make statements about statements. (Statement object b is a meta statement about statement object a.)

How about creating new properties (attributes)? Properties are objects that need to be treated a bit different. The model needs to distinguish properties from "general" objects. The set P (the property set) contains all objects that are properties, as said before. This set can, as with C, be divided into "levels"/subsets. P0 contains primitive properties that are needed to create new properties, or other important language functions (these primitives are language constructs that needs to be standard). (A empty model has only a few elements in P0 and no elements in other "levels" of P.) Using these primitive properties other properties could be created, and those properties will be present at "higher levels" of P. Thus, level 0 is primitive properties (e.g. a form of type property) and other levels are "user defined"

Making a statement that creates a new property (e.g. the statement (age, type, property) states that age is a property) is also a statement that will become an object in C (all statements are objects). This is important since one sometimes needs to be able to make statements about statements that create properties. What is also important (and something that will be further explained later) is that a non-property object (from C) also represents the created property. Thus, creating a property does two things: (1) creates a property (a new object in P), and (2) assigns an object to represent the property in C. This mapping from a property to a object is represented in a relation PROPOBJ. (This might seem a bit odd, but it will be explained later.) From now on, a property a is written PROPa and an object a is simply written a. Thus, creating a property PROPa creates a mapping (PROPa,a).

Creating new properties

In the image above a new property d is created. The statement (a,o,v) (where o is the element in C0 that represent the object interpretation of the new property, a is a primitive property in P0 used to create new properties, and v is a primitive object in C0 that is used to create new properties) becomes as previous an element in C1. Thus, f is the object representing the statement, d is the new property (PROPd). To use the new property a statement should use d (PROPd) in the attribute (property) position.

Short NSFAQ (not so frequently asked questions):

Model - Formal specification

(Please forgive me for using non-standard characters and images in the formulas below.)

The things that need to be defined are the sets P and C. Further, the creation of statements and properties need to be defined. At this point there are only sparse explanations of the definitions.

The set C0 is a subset of OBJECTS.

Image 1

C0 contains a few primitive objects but also some generic objects (this will perhaps be more evident when the mapping to the language is shown). At this point (and since the language developed later is only a simple version) there is only two primitive objects: property and class (the semantics of these two terms is not defined here, but they have the common meaning as in e.g. RDF).

Image 1.1

These objects are used in statements like (colour, type, property).

P0 is a subset of OBJECTS and also contains a few primitive objects (but not any generic objects).

Image 1.2

At this point (and since the language developed later is only a simple version) there are only three primitive properties: type, subClassOf and subPropertyOf (the semantics of these terms is not defined here, but they have the common meaning as in e.g. RDF). To better show the difference between members of P from members of C the members of P has PROP as a prefix and the name of the property as a subscript. Thus, P0 contains the elements as defined below:

Image 4

A object from OBJECTS can not be a member of both P0 and C0, i.e.:

Image 1.4

C0 also contains the object representation of PROPtype, PROPsubClassOf, and PROPsubPropertyOf. The object names are type, subClassOf, and subPropertyOf.

So far, only the "starting point" of the model has been specified. Now it is time to define P and C for other "levels" than 0. Using operator T that is defined in terms of P and C below does this.

Image 7

Image 8

Image 9

C at level i contains all statements made with objects at lower levels. That is illustrated below.

Image 2

The definition of Ci above also incorporates the object representation of the property, but the mapping is still not defined.

The complete set of all levels of C is

Image 3

and the same goes for P

Image 6

Image 5

NOTE! This is not complete yet! C and P are not properly defined yet, there are things missing. Working on this right now (20010904).

Syntax - General introduction

The syntax developed here is quite stupid. It is not intended to be used at all. The important part of the project is the model.

Everything is built with four-tuples: (context, object, attribute, value). Each element must be a URIF - a URI with possible a fragment ID appended. (To ease the burden of writing all plain names are assumed to be usual URIFs and names that start with # are also URIF:s but I will refer to them as contexts.)

Statements

A simple statement looks like this:

(#context, object, attribute, value)

A example could look like this:

(#s1, benny, knows, jim)

Meta statements

(#s2, #s1, not, true) is a meta statement about the statement identified/represented by #s1. Contexts are identifiers for statements.

Bags, sets, and normal contexts

To make a bag were individual members could be "identified" the below construct needs to be used:

(#my_bag
(_1,jim,member,club)
(_2,tim,member,club)
)

Making a statement about #my_bag is a statement about the set, and a statement about #my_bag_1 or #my_bag_2 (where the context of the "inner" context is appended) is about the individual statements - members.

Statements about properties

(#s1, age, type, property)

To make a statement about the relation (the relation created with the property) or to use the property one only needs to use the name, in this case the age name. To make a statement about the property (the object representing a property, in this case a URIF) one needs to add a syntax construct: $age (very, very randomly chosen!)

NOTE! Not complete! Working on it.

Mapping model onto syntax

The model M for language L is:

M = (OBJECTS, αobj, αrel)

OBJECTS is a set of objects that is the universe of the model as before. An element of this set could correspond to a URI or a URIF (a URI with possible a fragment ID appended) in a language syntax under a certain interpretation, but the objects could otherwise be considered to be general. αobj is the object interpretation and arel is the relation interpretation.

NOTE! Not complete!

This distinction of these interpretations is necessary because a property could be the subject of a statement and the statement could be about either the object that represents the property or the relation. E.g. there is an interpretation issue in statements like "The creator of property P is Benny" and "Property P is transitive". The first statement is under one interpretation about the object that represents the property and under another about the relation/set. The second example is a statement about the set. Thus, statements that have properties as subject or object could sometimes be interpreted in two ways and this distinction has to be made at the syntax level.

References

[Peacock, 1998] Ian Peacock, 1998, A formulation of the RDF data model, http://www.ukoln.ac.uk/metadata/resources/set-theory/

Created with AmayaConforms to HTML4