In this paper we will describe the formalization of an RDF(S) variant we call O-Telos-RDF, which provides enhanced functionalities for meta-modeling and reified statements. This formalization is based very closely on the formalization of the modeling language O-Telos, which is based on a semantic network model quite similar to RDF(S), and has been used as a (meta) modeling language in various application areas during the last 10 years.
RDF(S) [
RDF(S) falls short however in exploiting both the simplicity
and the expressivity of the underlying semantic network
formalism. The RDF(S) description (see [
In an earlier paper [13], we have pointed out the dual use of
properties like subclass and type both as primitive (metalevel)
concepts to define the RDF(S) concept hierarchy as well as concepts
defined in RDF(S) itself, and have proposed a metamodeling
approach separating these uses, which is more in line with a layered
metamodeling approach such as described in [
In this paper we will use the (meta-) modeling language O-Telos as a basis for an alternative resource description format we call O-Telos-RDF, which retains the basic principles of RDF(S), but extends its meta-modeling and reification functionalities. Primitive concepts like subclass and type are strictly axiomatized in this Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
Copyright 2000 ACM 0-89791-88-6/97/05 ..$5.00
language, and can be used together with the other O-Telos-RDF
concepts to formalize descriptions on all abstraction levels. The
modeling language O-Telos has been defined and axiomatized in
[
The extended functionalities of O-Telos-RDF are based on OTelos’ use of a semantic network (i.e. binary predicates) for modeling in a uniform way all kinds of information (information about objects and specific relationships between these objects, information about classes and relations, information about metaclasses, etc.) This capability is also present in many aspects of RDF(S), but unfortunately not in all, as we will see in this paper. Using semantic networks for modeling has a long tradition, starting with Tarskis use of binary relations [16], and continuing with Abrials semantic datamodel based on such binary relations [1].
We will use the paper by Conen and Klapsing [
O-Telos-RDF graphs are semantic networks, which consist of nodes and (directed) arcs. Nodes represent all kinds of concepts (such as classes, metaclasses etc.) and individuals (such as specific WWW pages and literals), arcs represent specific (property) relationships.
Both nodes and arcs are labeled with atomic values or URIs as
names. They are both first class entities, and therefore are
referenced by IDs (unique within the current namespace), usually in the
form of URIs, which either contain the node or arc label (if it is
an atomic value), or use the label directly as ID (when the labels
Note, that in an earlier version of this report [12], we used a
serialization which did not assume any knowledge about an
O-TelosRDF specific semantics, so that a current RDF parser like SiRPac
[15] could produce the correct O-Telos-RDF tuples from this
serialization. Our current serialization necessitates some small changes
in SiRPac, but is more compact than our previous serialization.
are URLs or instances of primitive types like literals). By
referencing these IDs, arcs can connect any two other entities (i.e. two
nodes, one node and one arc or two arcs), in contrast to RDF(S),
where arcs only connect resources (i.e. nodes). As in RDF(S) [
In the following we will discuss the basic O-Telos-RDF concepts building on this framework in more detail, give examples using both tuple and XML-syntax, and compare the O-TelosRDF concepts with the original O-Telos axioms they are based on, as well as with the usual RDF(S) concepts. We will use the namespace concept of XML and use the namespace “otelos:” throughout this paper, refering to the URI “http://www.kbs.unihannover.de/otelos/2001/08/otelos-rdf-schema#” which contains the O-Telos-RDF definitions of this paper.
To allow easy comparison of O-Telos-RDF with RDF(S), we
mainly follow the structure of [
Basic O-Telos-RDF Concepts and Predicates 2.1.1
All nodes and arcs in an O-Telos-RDF graph are represented by statements of the general form s(sid,x,l,y) where sid represents the statement ID (a unique identifier of the statement), x and y represent identifiers of (possibly other) statements and l is called the label of the statement. All statement identifiers sid are URIs or as URI-like as possible and are unique globally (except when exactly the same statements are made in two different places).
We call x the subject, y the object and l the predicate of a statement. All statements in O-Telos-RDF are implicitly reified, and can be identified by their statement ID. We therefore have the first axiom:
AXIOM 2.1. Statement identifiers uniquely identify statements: We can define auxiliary predicates subject, predicate and object as follows:
Example 1: This example gives a first impression of how the resulting statements look like. The exact definitions of the used constructs will follow in later sections. We want to express that a resource “LectureUnit1” has a property “title” with the value “Lecture Unit 1”.
The XML-serialization (which we keep as similar to RDF(S) as possible - see appendix A for the basic XML serialisation) looks as follows: <otelos:Description ID="LectureUnit1">
<title>Lecture Unit 1</title> </otelos:Description>
The statements for this serialization are s(sid1,sid1,LectureUnit1,sid1) s(sid2,sid1,title,"Lecture Unit 1") s(sid3,sid1,type,otelos:individual) s(sid4,sid2,type,otelos:property)
where sid1=ns:LectureUnit1 sid2=ns:LectureUnit1_title sid3=ns:LectureUnit_type_otelos:individual sid4=bns:LectureUnit1_title_type_otelos:property and “ns:” stands for the current namespace specifying where these metadata can be found (e.g. “http://www.kbs.uni-hannover.de /ai1/metadata.html#”.2 The statement identifiers are generated automatically from the other arguments (we’ll discuss how later), so they do not have to be included in the XML serialization.
Tupels sid3 and sid4 specify membership of sid1 and sid2 in the (predefined) O-Telos-RDF classes otelos:individual and otelos:property respectively (similar to rdfs:class and rdf:property), and are themselves members of the O-Telos-RDF class otelos:type. As we will see in the following sections, membership in these predefined classes is specified by the syntactic form of the statements, and we will not include these type-statements in our later examples, as they can always be reconstructed from the axiomatic membership definition (2.3, 2.5 and 2.10) for these predefined classes.
Example 2: This example states that a web page with the URI “http://.../Definitions.html” has a title called “Definitions”. <otelos:Description
about="http://.../Definition.html"> <title>Definitions</title> </otelos:Description>
The corresponding statements are s(sid1,sid1,http://.../Definitions.html,sid1) s(sid2,sid1,title,"Definitions")
where sid1=http://.../Definitions.html sid2=http://.../Definitions.html_title
Additionally, as already mentioned in example 1, sid1 is instance of otelos:individual while sid2 is instance of otelos:property. Furthermore these two type-statements are instances of otelos:type. 2.1.1.1 Comparison to RDF(S) and O-Telos.
Axiom 2.1 corresponds to the O-Telos axiom 1 (uniqueness of object identifiers). O-Telos-RDF statement identifiers are constructed as URIs or URI-like identifiers in order to be able to reference them easily in other statements. In contrast to O-Telos object identifiers, they are not invisible. Their exact form will be discussed in the following sections. In constrast to RDF(S), there is no difference between “named” and “unnamed” resources, all statements have unique IDs. For Web-Pages, these are the usual URLs.
Axiom 1 of [
In the following, we will abbreviate these URLs to save space, leaving out hostname and directories, and use forms like “http://.../metadata.html#”.
Analogously to RDF(S), we call x the subject, y the object and l the predicate of a statement, although we have not defined them as predefined properties (which we could, though).
All statements in O-Telos-RDF are implicitly reified, and can
be identified by their statement ID. Thus we don’t have to reify a
statement explicitly which contrasts with the axioms 7, 8 and 9 of
[
In order to explicitly distinguish between statements and explicit
reifications thereof similar to RDF(S) (and the [
Nodes in an O-Telos-RDF graph are represented by statements of the form s(o,o,o,o) or s(ns:l,ns:l,l,ns:l), where o and ns:l are URIs, ns is the current namespace and l is an atomic label. We call these statements individuals, they can be used as subjects and objects in statements.
AXIOM 2.2. The set of all statements, abbreviated as otelos:statement is represented by the individual s(otelos:statement,otelos:statement,statement,otelos:statement), where “otelos:” is the namespace for the O-Telos-RDF definitions.
Serialized as XML, this individual is simply declared as <otelos:Individual ID="statement"/>
or, more RDF(S)-like <otelos:Description ID="statement"/>
<type s="otelos:individual"/> </otelos:description>
Again, the type-statement (which will be explained in section 2.2.1) is not really necessary, as membership of statements in the set of individuals is defined by the syntactic form of the statement.
AXIOM 2.3. The set of all individuals is represented by otelos:individual or (in longer form) s(otelos:individual,otelos:individual,individual,otelos:individual).
O-Telos-RDF individuals can represent both classes and instantiated objects (as well as metaclasses, metametaclasses, etc.), there is no syntactic distinction between these different abstraction levels. This makes unrestricted metamodelling hierarchies possible in O-Telos-RDF.
AXIOM 2.4. If the label of an individual is an atom, it is unique within its namespace. Together with its namespace, or if the label is already an URI, it is unique globally. Therefore the statement ID of an individual is unique globally in all cases.
In the following, we will use the statement ID of an individual as an abbreviated name for that individual, i.e. we will be talking about otelos:statement, otelos:individual, etc. As the statement ID is unique and human readable, we can use this ID also to reference all other statements, which are not individuals.
Example 3: The following example declares an individual with the name ”LectureUnit1”: <otelos:Individual ID="LectureUnit1"/> with the corresponding statement s(sid1,sid1,LectureUnit1,sid1)
where sid1=ns:LectureUnit1 2.1.2.1 Comparison to RDF(S) and O-Telos.
In O-Telos-RDF all individuals are resources in the usual RDF(S) sense, and can be used as subjects and objects in statements. O-Telos states the existence of statements in its axioms 18 and 24 which correspond to axiom 2.2 of O-Telos-RDF.
Axioms 1 and 2 of [
Axiom 4 of [
In contrast to RDF(S), O-Telos-RDF requires the declaration of each individual/resource, so each individual is represented by its corresponding tuple. Writing down these explicit individual declarations for all annotated and used URLs can be time consuming, though, and a smart parser can generate the corresponding tuples for each URL automatically. In the following, we will therefore use an XML serialization which does not require explicit individual declarations for URLs, and leave it to the parser to generate the corresponding tuple for each URL it encounters. 2.1.3
We include a short discussion of class at this point, even though class is a schema definition concept, which RDF(S) defines in the schema specification, not in the basic model and syntax specification.
The reason for this is that, in O-Telos-RDF, individuals represent both objects and classes. As all individuals can be instantiated, there is no need to introduce a separate class concept. All RDF(S) classes are represented as O-Telos-RDF individuals, as are their members. Class membership is defined using type-statements (see 2.2.1).
To enhance readability, we define an individual otelos:class, which denotes the same set as otelos:individual, and use both otelos:class and otelos:individual in our XML serialization. Note, however, that the distinction of otelos:class and otelos:individual is purely syntactic sugar and does not indicate any semantic distinction. Both terms are translated into otelos:individual in the tuple representation. 2.1.3.1 Comparison to RDF(S) and O-Telos.
Even though RDF(S) defines the concept rdfs:Class, no special
axioms are defined in [
If we view something as a resource which can be referenced by an identifier, “resource” would correspond to “statement” in O-TelosRDF, though.
Property /5> &O76A A &( & A & A ns:p otelos:statement and ns:p y, and p different from the three & A & A the special case s(ns:p,otelos:statement,p,y), with sid x, sid y,
Arcs are represented by statements of the form s(sid,x,p,y) or by reserved labels type, subClassOf and subPropertyOf. We call these statements properties:
AXIOM 2.6. The set of all properties is denoted by the statement (otelos:property,otelos:statement,property,otelos:statement), abbreviated as otelos:property.
In the first case s(sid,x,p,y), p is an atomic value, and is unique within the current namespace in conjunction with the source object x, which is the unique identifier of another statement. Then the sid is of the form x p, which is unique in the current namespace, and potentially unique globally (except if another namespace specifies a property with the same label for the same x). This naming of the statement identifiers does not guarantee globally unique statement IDs, but is in line with the object scoped way of looking at properties. 4 If the property s(sid,x,p,y) is meant to represent the property definition for p, then (using RDF(S) terminology), x is the domain of p and y is the range of p.
We then call p an object scoped property. This definition corresponds to the class-centric way of defining properties used in frame-based languages like O-Telos.
AXIOM 2.7. Names of “object scoped” properties are unique in conjunction with the source object:
Example 4: The following description defines LectureUnit, which has a property named title of type literal. Note, that duplicate property statements are also possible in RDF(S) between different namespaces. In any case, even if we defined the statement identifiers in a globally unique way (which would be possible by prefixing the ID with the current namespace), integration of statements from different namespaces would still need to be dealt with care, as globally unique statement IDs would only handle uniqueness of statements, but still allow inconsistency of properties (such as multiple values for single valued properties, etc.) with sid1=ns:LectureUnit sid2=ns:LectureUnit_title
sid1 is a member of the set otelos:individual, sid2 is a member of the set otelos:property. Both membership-statements are member of the set otelos:type.
In the second (special) case s(ns:p,otelos:statement,p,y), p is an atomic value, and is a unique label within the current namespace ns. We then call p a globally scoped property, because it can be used as property for all kinds of statements. This definition corresponds to the property-centric way of defining properties in RDF(S).
AXIOM 2.8. For “globally scoped” properties, axiom 2.7 is extended, so that the names of attributes are unique even without conjunction with the source object: 2.1.4.3 Comparison to RDF(S) and O-Telos.
O-Telos-RDF axiom 2.7 corresponds to O-Telos axiom 3. Axioms 2.5 and 2.6 correspond to O-Telos axioms 22 and 26.
RDF(S) regards properties as a projection of the second
argument of the RDF-statement. Therefore [
In contrast to O-Telos und to RDF, O-Telos-RDF allows both globally or object scoped properties, though the globally scoped properties are just a special case of the object scoped properties. So, as can be seen in example 4, the definition of properties is object centered and is included in the class definition rather than written outside of the class definition in separate statements.
If different domains (as in RDF(S)) have to be expressed for a property, this property has to be an object scoped property. When using object scoped properties, different ranges are possible (in contrast to the current RDF(S) specification). 2.1.5
Literals l are represented as individuals s(l,l,l,l). The set of all literals is denoted by the individual otelos:literal. Other primitive types (like the ones defined in the recent XML schema specification, or Integer, Boolean, etc. from O-Telos) can be introduced in the same way.
While the statement IDs for these primitive individuals are no URIs, this representation allows us to use these individuals consistently with current RDF(S)/XML statements, by simply including the value in a statement. 2.1.5.1 Comparison to RDF(S) and O-Telos.
Axioms 5 and 6 of [
Statements of the form s(sid,x,type,y) denote class membership of x in y. We talk about x being an instance of y, where x and y represent either two individuals or two properties.
AXIOM 2.9. Type statements can be written using the auxiliary predicate type(x,y):
AXIOM 2.10. All statements, where subject and object are different from the statement ID and which use the label “type”, are instances of the set otelos:type, represented by the statement s(otelos:type,otelos:statement,type,otelos:statement):
AXIOM 2.11. The label “type” of these statements is unique in conjunction with the source object x and the destination object y. The statement identifier sid has therefore the form x type y:
AXIOM 2.12. Property statements can be written with the name of the property (instead of a new label) by using the auxiliary predicate P(x,m,y):
AXIOM 2.13. Properties P of a subject x are always expressed as a property statement, which is an instantiation of a property definition for the class c of which x is a member of:
AXIOM 2.14. In case x is an instance of two classes c and d, which both define a property m, x has also to be an instance of a class g, which is a subclass of both c and d, and which also defines property m:
The axiom 2.14 handles multiple inheritance/instantiation in case two classes of an object both define a common property, by demanding a third class the object is an instance of, which defines this property and thus makes instantiating the property for x unique.
Example 5: The following example shows the use of typestatements. Let us assume, that there is an individual called LectureUnit that has a property of type String labeled title. Another individual called LectureUnit1 is an instance of LectureUnit and instantiates the property title with the value “Lecture Unit 1”.
Please note that the following examples use the namespaces rdf:, rdfs:, s:, t: and otelos: instead of the URIs with the statementdeclarations. We abbreviated the URIs in order to enhance the readability of the examples. <otelos:OTELOS xmlns:t="http://www.kbs.uni-hannover.de/otelos /2001/08/example-5#" xmlns:otelos="http://www.kbs.uni-hannover.de /otelos/2001/08/otelos-rdf-schema#">
In the rest of the paper, we will not explicitly specify the type statement for properties like “LectureUnit1 title” in the XML serialization, whenever the label of the instantiated property is the same as the label used in the definition of that property and an explicit type statement is included for the object the instantiated property is associated to. In these cases the type definition tuple can be inferred by the O-Telos-RDF parser by using the label to look up the appropriate property definition within the class specified by the type statement for the object containing the instantiated property. This allows an XML serialization very similar to the RDF(S) serialization.
If the label of the instantiated property statement is different from the label used in the property definition5, we will use an XML serialization for instantiated properties which includes the type of the instantiated property as an additional XML-attribute “type=”. Using this serialization, example 5 looks as follows: <otelos:OTELOS
xmlns:t="http://www.kbs.uni-hannover.de/otelos This is usually done for multivalued properties and in metamodeling application (where the property definition is defined for a metaclass, the instantiated property for an instantiation of this metaclass, and therefore will be instantiated a second time). </otelos:OTELOS>
We do not need to specify type statements for membership in otelos:individual, otelos:property and otelos:type because they result from the respective axioms. h 2.2.1.1 Comparison to RDF(S) and O-Telos.
Instantiations of classes using “type” are done in the same way in RDF(S) as in O-Telos-RDF axioms 2.11 and 2.9 (corresponding to the O-Telos axioms 4 and 5). Furthermore, objects can instantiate the attributes defined in their classes in the same way in RDF(S) and O-Telos-RDF (axioms 2.12 and 2.13, corresponding to O-Telos axioms 7, 8 and 9). Axiom 2.10 corresponds to the O-Telos axioms 27 and 20.
In contrast to RDF(S) [
This instantiation of properties is defined in axioms 2.12 and 2.13 (corresponding to O-Telos axioms 7, 8 and 9), and leads to instantiated property statements, which have a (possibly) different label than the property definitions they instantiate, and which can be instantiated again if needed. This is different from RDF(S), where instantiation is only explicit for individuals. 6
Axiom 2.14 (corresponding to O-Telos axiom 17) handles multiple inheritance/instantiation. Such an axiom is not necessary in RDF(S) because properties are defined separately from classes anyway, and a given property can have just one range restriction.
Differently to RDF(S), otelos:type stands on its own and is different from otelos:property (axiom 2.10, corresponding to O-Telos axiom 20).
Axiom 2.12 (corresponding to O-Telos axioms 7 and 8) defines how to state properties in an RDF(S)-like way. We can therefore translate RDF(S)-like property statements like P(x,m,y) into The missing explicit instantiation of properties in RDF(S) is actually the main reason for its restriction to there abstraction levels, as instantiated property statements neither have a label nor statement ID, which makes it impossible to uniquely reference these statements as first class objects. the corresponding O-Telos-RDF statements by generating a unique object identifier and a label for the statement representing the instantiated property statement, plus an additional statement for the instantiation relationship.
Domain and range properties like those in RDF(S) are not needed, as domain and range restrictions are already included in all property definitions. For compatibility reasons, we can define auxiliary predicates domain and range like
or alternatively, as the (globally scoped) properties otelos:domain and otelos:range, defined by the statements s(otelos:domain,otelos:property,domain, otelos:statement) s(otelos:range,otelos:property,range, otelos:statement)
AXIOM 2.15. Subjects and objects in a statement representing an instantiated property are typed by the corresponding property definition:
If no domain or range restrictions are desired for a property p, it can be defined as a globally scoped property in the following way: s(ns:p,otelos:statement,p,otelos:statement) 2.2.2.1 Comparison to RDF(S) and O-Telos.
In contrast to O-Telos-RDF, RDF(S) has to state domain and range using separate properties.
[
Statements of the form s(sid,x,subClassOf,y) denote a subclass relationship between x and y. We talk about x being a subclass of y, where x represents a class and y its superclass. x and y are individuals.
AXIOM 2.16. The label “subClassOf ” in subClassOfstatements is unique in conjunction with the source object x and the destination object y, thus sids are of the form x subClassOf y: ). $.>Q23FG;96HJIUN % 23FGT9U6HJI.N
AXIOM 2.17. We can also define an auxiliary predicate subClassOf(x,y): 1 76/5$<6756;<GP23FGT9U6HJI A A ). $.>Q23FG;96HJIUN "!C &(. )!Z &BN
AXIOM 2.19. All statements with a label “subClassOf ” whose sid is not equal to subject and object are members of the set otelos:subClassOf:
AXIOM 2.18. The set of all subClassOf-statements is represented by the statement s(otelos:subClassOf,otelos:individual, subClassOf,otelos:individual).7
The subClassOf relationship is a partial order on the statement identifiers. This relationship is reflexive as well as transitive, and does not contain cycles, but uses reflexivity to state equality. 2.2.3.1 Comparison to RDF(S) and O-Telos.
Axiom 2.28, 2.19, 2.17 and 2.16 correspond to O-Telos axioms 28, 21, 6 and 4, and define subClassOf similarily to RDF(S).
Contrary to RDF(S), the subClassOf-relationship is defined as a partial order, which is reflexive as well as transitive. However (as in RDF(S)) subclassOf does not contain cycles, and uses reflexivity just to state equality (2.20, 2.21 and 2.22, corresponding to O-Telos axioms 10, 11, 12).
Class membership inherits upwardly to the superclasses in all
formalisms (RDF(S) [
Actually, because O-Telos uses the same label “isA” (corresponding to our “subClassOf”) for subclassing both individuals and properties, the direct translation from O-Telos would be the more general statement s(otelos:subClassOf,otelos:statement,subClassOf,otelos:statement). However, in line with RDF(S) conventions, we will distinguish between the two concepts subClassOf and subPropertyOf.
For compatibility reasons to RDF(S), we define otelos:subPropertyOf separately from subClassOf, even though it has all axioms from subClassOf, plus additional ones which are relevant for subPropertyOf only.
Statements of the form s(sid,x,subPropertyOf,y) denote a subproperty relationship between x and y. We talk about x being a subproperty of y, where x represents a property and y its superproperty. x and y are properties.
AXIOM 2.24. As for “subClassOf ”, the label “subPropertyOf ” in statements is unique in conjunction with the source object x and the destination object y:
AXIOM 2.25. The auxiliary predicate subPropertyOf(c,d) is defined as follows:
The subPropertyOf relationship is a partial order on the statement identifiers. This relationship is reflexive as well as transitive, and does not contain cycles, but uses reflexivity to state equality:
AXIOM 2.30. All subPropertyOf-statements are members of the set otelos:subPropertyOf, which is represented by the state&B. )!* A )N.5IU\* % 23FG;9>HJI. "!#23FG;96HJIU5 32MG0><Q/56067NHJIN "!#$.\Z5> "!#$NI
AXIOM 2.32. Furthermore, O-Telos-RDF requires subproperties of properties to refine subject and object of the properties as well. ment s(otelos:subPropertyOf,otelos:property,subPropertyOf, otelos:property)8, thus sid are of the form x subPropertyOf y:
AXIOM 2.31. Subclasses, which define properties with the same name as properties of their classes, refine these properties:
Example 6: The following example will further clarify things. Two resources are related by a property. Also, these resources are further subclassed, therefore the property has to be subclassed as well. <otelos:OTELOS xmlns:t="http://www.kbs.uni-hannover.de/otelos /2001/08/example-6#" xmlns:otelos="http://www.kbs.uni-hannover.de /otelos/2001/08/otelos-rdf-schema#"> In principle, we could allow the application of subPropertyOf for instances of otelos:type, otelos:subClassOf and otelos:subPropertyOf. This is actually done in O-Telos, as it does not distinguish between subClassOf and subPropertyOf. 2.2.4.1 Comparison to RDF(S) and O-Telos.
O-Telos-RDF treats otelos:subPropertyOf in basically the same
way as otelos:subclassOf (like O-Telos, which does not distinguish
these two concepts at all). This is also consistent with RDF(S),
so [
In RDF(S) this relationship is transitive ([
Property membership in O-Telos-RDF is inherited upwardly to
the superclasses (axiom 2.29, corresponds to O-Telos axiom 13).
[
Axioms 2.31 and 2.32 (corresponding to O-Telos axioms 15 and 16) do not exist in RDF(S). 2.3
RDF(S) has additional utility constructs rdf:Seq and rdf:Bag, used to express sequences and bags. In our opinion, rdf:Bag is not really necessary, as multi-valued properties are expressed simply by more than one instantiated property statement.
As for rdf:Seq, the disadvantage of this construct is, that (similar to the case of the Java Vector class) it introduces untyped relation ends, if it is used as an explicit class. Because O-Telos-RDF has the capability of defining properties with the domain otelos:property, we will use this alternative way in O-Telos-RDF to express sequences.
To express sequences in O-Telos-RDF, we include an additional type called otelos:ordinal. otelos:ordinal is a subclass of otelos:literal. It specialises the literals by using only integer numbers prefixed by “ ” as labels, starting with 1, 2, etc. The respective statements use the label for sid, subject, predicate and object. For example the statement s( 1, 1, 1, 1) represents the ordinal “ 1”.
Furthermore we declare the new property otelos:sequence with the statement s(otelos:sequence,otelos:statement,sequence,otelos:ordinal)
Example 7: Let us assume that we have a multivalued property sid1, and that sid2, sid3 and sid4 are instantiations of that property. Furthermore, we want to represent a sequencing between these three property statements.
We have the following property-statements: s(sid1,Person,name,otelos:Literal) s(sid2,JohnHarrySmith,name1,"John") s(sid3,JohnHarrySmith,name2,"Harry") s(sid4,JohnHarrySmith,name3,"Smith") s(sid5,sid2,type,sid1) s(sid6,sid3,type,sid1) s(sid7,sid4,type,sid1)
Then, the following statements specify the sequencing: s(sid8,sid2,number,_1) s(sid9,sid3,number,_2) s(sid10,sid4,number,_3)
sid4, sid5 and sid6 are of type otelos:sequence, specified by the corresponding type-statements: s(sid11,sid8,type,otelos:sequence) s(sid12,sid9,type,otelos:sequence) s(sid13,sid10,type,otelos:sequence)
The XML serialization looks as follows: <otelos:OTELOS xmlns:t="http://www.kbs.uni-hannover.de/otelos /2001/08/example-7#" xmlns:otelos="http://www.kbs.uni-hannover.de /otelos/2001/08/otelos-rdf-schema#"> <otelos:Class ID="Person">
<name s="otelos:Literal"/> </otelos:Class> <otelos:Individual ID="JohnHarrySmith"> <type s="t:Person"/> <name1 type="t:Person_name">John</name1> <name2 type="t:Person_name">Harry</name2> <name3 type="t:Person_name">Smith</name3> </otelos:Class> <otelos:Property ID="JohnHarrySmith_name1"> <number>_1</number> </otelos:Property> <otelos:Property ID="JohnHarrySmith_name2"> <number>_2</number> </otelos:Property> <otelos:Property ID="JohnHarrySmith_name3"> <number>_3</number> </otelos:Property>
Alternatively, we could use a predefined XML-attribute “number=”, to write this example in an even more abbreviated way: <otelos:OTELOS xmlns:t="http://www.kbs.uni-hannover.de/otelos /2001/08/example-7#" xmlns:otelos="http://www.kbs.uni-hannover.de /otelos/2001/08/otelos-rdf-schema#"> <otelos:Class ID="Person">
<name s="otelos:Literal"/> </otelos:Class> <otelos:Individual ID="JohnHarrySmith"> <type s="t:Person"/> <name1 type="t:Person_name" number="_1"> John</name1> <name2 type="t:Person_name" number="_2"> Harry</name2> <name3 type="t:Person_name" number="_3">
Smith</name3> </otelos:Class> or use an implicit sequencing of multivalued attributes based on the textual order of the statements (which is actually the way sequencing is handled in O-Telos), depending on the O-Telos-RDF parser to generate the necessary sequencing triples for these multivalued attributes: <otelos:OTELOS xmlns:t="http://www.kbs.uni-hannover.de/otelos /2001/08/example-7#" xmlns:otelos="http://www.kbs.uni-hannover.de /otelos/2001/08/otelos-rdf-schema#"> <otelos:Class ID="Person">
<name s="otelos:Literal"/> </otelos:Class> <otelos:Individual ID="JohnHarrySmith"> <type s="t:Person"/> <name1 type="t:Person_name">John</name1> <name2 type="t:Person_name">Harry</name2> <name3 type="t:Person_name">Smith</name3> </otelos:Class> 2.3.1.1 Comparison to RDF(S) and O-Telos.
In order to state sequences, RDF(S) specifies the container rdf:Seq. Instances of rdf:Seq group together the resources of a sequence by using simple ordinal properties. O-Telos-RDF simplifies this approach by using the possibility to state properties about properties. Thus O-Telos-RDF avoids the introduction of untyped containers like rdf:Seq which is preferrable for precise semantical modelling. 2.4 Modelling the lecture Artificial Intelligence
The following example is taken from a model of our lectures. For simplicity reasons it is a small part of the larger model only.
On the class level it states that lecture units belong to a lecture. Lecture units have a title and a description. A lecture unit consists of theory pages, examples, etc. We also include simple subclasses respectivly instances like AI lecture units, etc.
We will start with the appropriate XML-serialisation using RDF(S):
In the following example the URIs of the namespaces rdf:, rdfs:, s:, t: and otelos: are abbreviated with their names. <rdf:RDF xml:lang="en" xmlns:rdf="http://www.w3.org/1999/02 /22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01 /rdf-schema#" xmlns:s="http://www.kbs.uni-hannover.de/otelos /2001/08/example-schema#"> <rdf:Description ID="Lecture">
<rdf:type resource="rdfs:Class"/> </rdf:Description> <rdf:Description ID="LectureUnit">
<rdf:type resource="rdfs:Class"/> </rdf:Description> <rdf:Description ID="title"> <rdf:type resource="rdf:Property"/> <rdfs:range resource="rdfs:Literal"/> <rdfs:domain resource="s:LectureUnit"/> </rdf:Description> <rdf:Description ID="description"> <rdf:type resource="rdf:Property"/> <rdfs:range resource="rdfs:Literal"/> <rdfs:domain resource="s:LectureUnit"/> </rdf:Description> <rdf:Description ID="parentCourse"> <rdf:type resource="rdf:Property"/> <rdfs:range resource="s:Lecture"/> <rdfs:domain resource="s:LectureUnit"/> </rdf:Description> <rdf:Description ID="theoryPage"> <rdf:type resource="rdf:Property"/> <rdfs:range resource="s:TheoryUnit"/> <rdfs:domain resource="s:LectureUnit"/> </rdf:Description> <rdf:Description ID="parentUnit"> <rdf:type resource="rdf:Property"/> <rdfs:range resource="s:LectureUnit"/> <rdfs:domain resource="s:TheoryUnit"/> </rdf:Description> <rdf:Description ID="TheoryUnit">
<rdf:type resource="rdfs:Class"/> </rdf:Description> <rdf:Description ID="AILecture">
<rdf:type resource="s:Lecture"/> </rdf:Description> <rdf:Description ID="LectureUnit1"> <rdf:type resource="s:LectureUnit"/> <title>Lecture Unit 1</title> <description>
Introduction to intelligent agents </description> <parentCourse resource="s:AILecture"/> <theoryPage
resource="http://.../Definitions.htm"/> <theoryPage resource="http://.../Characterisation.htm"/> <theoryPage
resource="http://.../Structure.htm"/> <theoryPage resource="http://.../Types.htm"/> </rdf:Description> <rdf:Description
about="http://.../Definitions.htm"> <rdf:type resource="s:TheoryUnit"/> <parentUnit resource="s:LectureUnit1"/> </rdf:Description> <rdf:Description
about="http://.../Characterisation.htm"> <rdf:type resource="s:TheoryUnit"/> <parentUnit resource="s:LectureUnit1"/> </rdf:Description> <rdf:Description about="http://.../Structure.htm"> <rdf:type resource="s:TheoryUnit"/> <parentUnit resource="s:LectureUnit1"/> </rdf:Description> <rdf:Description about="http://.../Types.htm"> <rdf:type resource="s:TheoryUnit"/> <parentUnit resource="s:LectureUnit1"/> </rdf:Description> </rdf:RDF>
In O-Telos-RDF, this example looks as follows:
Membership in otelos:individual, otelos:property, otelos:type etc. is automatically based on the syntactic form of the statements, so we do not declare any explicit type-statements for these classes. Type-statements for properties, where the instantiated properties have the same label like the property definition, are introduced automatically by the parser, as well as individual-statements of all URLs used in this example. Type-statements for the multiple instantiations of LectureUnit theoryPage are handled using the “type=” XML-attribute.
The statements of the RDF(S)-representation are generated by the SiRPac [15] parser. The prefix online: represents constructs without an URI, genid represents automatically generated IDs.
(Note that we replaced the URIs in the example by the respective namespaces in order to improve the readability.):
Statement (subject,predicate,object) s(online:Lecture,rdf:type,rdfs:Class) s(online:LectureUnit,rdf:type,rdfs:Class)) s(online:title,rdf:type,rdf:Property)) s(online:genid2,resource,rdfs:Literal) s(online:title,rdfs:range,online:genid2) s(online:genid5,resource,s:LectureUnit) s(online:title,domain,online:genid5) s(online:description,type,rdf:Property) s(online:genid8,resource,rdfs:Literal) s(online:description,range,online:genid8) s(online:genid11,resource,s:LectureUnit) s(online:description,domain,online:genid11) s(online:parentCourse,type,rdf:Property) s(online:genid14,resource,s:Lecture) s(online:parentCourse,range,online:genid14) s(online:genid17,resource,s:LectureUnit) s(online:parentCourse,domain,online:genid17) s(online:parentUnit,type,rdf:Property) s(online:genid20,resource,s:LectureUnit) s(online:parentUnit,range,online:genid20) s(online:genid23,resource,s:TheoryUnit) s(online:parentUnit,domain,online:genid23) s(online:theoryPage,type,rdf:Property) s(online:genid26,resource,s:TheoryUnit) s(online:theoryPage,range,online:genid26) s(online:genid29,resource,s:LectureUnit) s(online:theoryPage,domain,online:genid29) s(online:TheoryUnit,type,rdfs:Class) s(online:AILecture,type,s:Lecture) s(online:LectureUnit1,type,s:LectureUnit) s(online:LectureUnit1,online:title,Lecture Unit 1) s(online:LectureUnit1,online:description, Introduction to intelligent agents) 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
Statement (subject,predicate,object) s(online:genid34,resource,s:AILecture) s(online:LectureUnit1,online:parentCourse, online:genid34) s(online:genid37,resource,http://.../Definitions.htm) s(online:LectureUnit1,online:theoryPage, online:genid37) s(online:genid40,resource, http://.../Characterisation.htm) s(online:LectureUnit1,online:theoryPage, online:genid40) s(online:genid43,resource,http://.../Structure.htm) s(online:LectureUnit1,online:theoryPage, online:genid43) s(online:genid46,resource,http://.../Types.htm) s(online:LectureUnit1,online:theoryPage, online:genid46) s(http://.../Definitions.htm,type,s:TheoryUnit) s(online:genid50,resource,s:LectureUnit1) s(http://.../Definitions.htm,online:parentUnit, online:genid50) s(http://.../Characterisation.htm,type,s:TheoryUnit) s(online:genid54,resource,s:LectureUnit1) s(http://.../Characterisation.htm,online:parentUnit, online:genid54) s(http://.../Structure.htm,type,s:TheoryUnit) s(online:genid58,resource,s:LectureUnit1) s(http://.../Structure.htm,online:parentUnit, online:genid58) s(http://.../Types.htm,type,s:TheoryUnit) s(online:genid62,resource,s:LectureUnit1) s(http://.../Types.htm,online:parentUnit, online:genid62)
The O-Telos-RDF statements generated from the XMLrepresentation are appended below. For simplicity, statement IDs are only referenced symbolically, but they can be derived from the rules stated in the earlier sections. s(sid1,sid1,Lecture,sid1) s(sid2,sid2,LectureUnit,sid2) s(sid3,sid2,title,otelos:Literal) s(sid4,sid2,description,otelos:Literal) s(sid5,sid2,parentCourse,sid1) s(sid6,sid2,theoryPage,sid7) s(sid7,sid7,TheoryUnit,sid7) s(sid8,sid7,parentUnit,sid2) s(sid9,sid9,AILecture,sid9) s(sid10,sid9,type,sid1) s(sid11,sid11,LectureUnit1,sid11) s(sid12,sid11,type,sid2) s(sid13,sid11,title,"Lecture Unit 1") s(sid14,sid13,type,sid3) s(sid15,sid11,description,
"Introduction to intelligent agents") s(sid16,sid15,type,sid4) s(sid17,sid11,parentCourse,sid9) s(sid18,sid17,type,sid5) s(sid19,sid11,theoryPage1,sid27) s(sid20,sid19,type,sid6) s(sid21,sid11,theoryPage2,sid31)
For simplicity reasons, we left out statements for declaring the literals used as instances of otelos:literal. Similarly, all type statements are instances of otelos:type, all individuals are instances of otelos:individual and all properties are instances of otelos:property. These statements can be deduced from the respective axioms.
In this paper we described the formalization of an RDF(S) variant called O-Telos-RDF, which provides enhanced functionalities for meta-modeling and reified statements. The formalization is based very closely on the formalization of the modeling language O-Telos, which is based on a semantic network model similar to RDF(S). Axioms and constraints are clearly defined. In the longer report, we include all these axioms in an appendix, together with their counterparts in O-Telos and RDF(S). This exact formalization will hopefully contribute to an understanding of both O-Telos-RDF and (in this context) the current RDF(S) formalization.
Compared with RDF, O-Telos-RDF shows its advantages in allowing easier reification of statements, and in metamodelling applications, where more than three abstraction hierarchies are needed. Furthermore, the class centric approach to property definition allows the definition of properties with the same name for different domains, which have different ranges (not possible in RDF(S)).
These properties seem to make O-Telos-RDF more similar to DAML+OIL than RDF(S) is (in the sense that DAML+OIL is more easily/naturally represented in O-Telos-RDF than in RDF(S)). A detailed discussion of this relationship will be included in a forthcoming report. Similarily, we will discuss reasoning functionalitities for O-Telos-RDF, based on the Datalogn reasoning facilities already present in O-Telos and ConceptBase.
[1] J. R. Abrial. Data semantics. In Klimbie and Koffeman,
editors, Data Base Management. North-Holland Publ., 1974.
[
Uniform Resource Identifiers (URI): Generic Syntax. In Internet Official Protocol Standards (STD 1), RFC. The
::=
The basic XML-serialisation stated here resembles very closely
the basic XML-serialisation of RDF, given in the RDF Syntax and
Model Specification [
As in the RDF Syntax and Model Specification the OTELOS element is a simple wrapper that marks the beginning and end of O-Telos-RDF statements in an XML document.
The EBNF of the basic O-Telos-RDF XML serialisation looks as follows: description label value statementAttr typeAttr numberAttr ordinal number statement -reference IDsymbol name NSprefix string 7) 8) 9)
OTELOS desLabel 3) 4) 5) 6) idAboutAttr aboutAttr idAttr propertyElt 6a) propertyEltExt ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::=