FORTH COMMENTS ON RDF Schema: Last Call

    
 Dear all

 I am sending you this mail to record FORTH comments w.r.t the RDF/S
 specs. Our objections concerns the following aspects:

 (a) RDF/S Metaclasses & Abstraction Layers

 (b) RDF/S Properties Instantiation

 (c) RDF/S Properties Domain/Range

 (d) RDF/S Datatyping

 (e) RDF/S Class Cycles

 In the sequel you can find a section from our last journal publication
 summarizing our critic w.r.t. the current RDF/S specs.

 Best Regards

 Vassilis

 -------------------------------------------------------------------------
 Abstraction Layers

 In RDF/S and recently proposed RDF Semantics, the distinction of
 abstraction layers (data, schema, metaschema) is not explicitly
 stated. Even though these specifications do not assume the existence
 of abstraction layers, they do not prohibit them. Thus, a class may
 have instances from different layers, like other classes, properties
 or resource URIs. Unlike well-known knowledge representation languages
 like UML or Telos, all RDF/S information (i.e., tokens, classes and
 metaclasses) is uniformly represented in the form of a graph. On the
 other hand, in DAML+OIL and OWL, the metaschema is fixed and they do
 not allow its extension with user-defined metaclasses (although the
 RDF/S root metaclasses, rdfs:Class and rdf:Property, are refined to
 define the DAML+OIL metamodel). As indicated in
 http://139.91.183.30:9090/RDF/publications/iswc02.pdf, the above
 flexibility may cause semantic inconsistency problems to application
 developers. The RQL type system makes a clear distinction of the
 different RDF/S abstraction layers while it provides appropriate
 interpretation functions to pass from one layer to another.

 Instantiation of properties

 Furthermore, although the RDF/S specification claims that properties
 are first-class citizens, properties are not treated as equally as
 classes. In RDF/S, both a metaclass of classes and a metaclass of
 properties is a class, in contrast to Telos, where a metaclass of
 individuals is a class, but a metaclass of properties (metaproperty)
 is a property. Hence, while in Telos a metaproperty can have domain
 and range, in the RDF/S model it cannot. Furthermore, at the data
 layer, a property cannot be of type property, as in the case of
 resources and classes. This is attributed to the fact that the
 rdf:type property is applicable only for classes and RDF/S does not
 provide us with an instantiation mechanism for properties at the data
 layer. The current version of the RQL data model preserves this kind
 of asymmetry in the manipulation of properties.

 Properties domain/range

 Regarding the domain and range of properties, the RQL data model
 enforces the constraint that the domain and range of a property must
 always be defined and be unique. This constraint is opposed to the RDF
 Semantics, which permits an optional declaration of multiple domains
 and ranges, while considering a conjunctive (i.e., intersection)
 semantics on endpoint classes of properties. However, a property with
 undefined domain/range may have as values both resources and
 literals. For instance, in the example of
 http://139.91.183.30:9090/RDF/VRP/Examples/demo/rdf_graph.gif, if the
 property technique has an undefined range, then the token
 oil-on-canvas may be interpreted both as a string and a resource
 URI. Since the intersection of the rdfs:Class and rdfs:Literal is
 empty (i.e., the sets of resource URIs and literals), this freedom
 lead to semantic inconsistencies: resources should be uniquely
 identified by their URIs while literals by their values. Otherwise,
 changing the literal value oil-on-canvas to aquarelle implies that all
 properties with value oil-on-canvas will be updated with aquarelle as
 a new value. Moreover, unlike the RQL data model, RDF Semantics
 introduce rules to infer that the source node of a property is of type
 domain and the target node is of type range. For instance, if a title
 is attributed to &r2 then this resource will be automatically
 classified under all the classes declared in the domain of title
 (i.e., intersection semantics). However, classifying &r2 as Painting
 and/or ExtResource should be under the entire responsibility of
 application developers.  In addition, in the above specifications,
 specialized properties do not preserve set inclusion semantics of
 their domain and range. For example, the subproperty sculpts of
 creates may have as domain (range) a superclass of Artist
 (Artifact). The semantics of properties become completely unclear when
 subproperties are defined with multiple domains and ranges. We believe
 that such representation flexibility combined with the previous
 inference rules (so-called generative interpretation) impose serious
 modeling and scalability limitations for real-scale Semantic Web
 applications especially when numerous namespaces of interconnected
 schemas are used (e.g., in semantic P2P systems).

 Datatyping

 With the schema datatype one can specify what type of data will make
 sense in the context of a particular property. With the new
 rdf:datatype (specifying the instance datatype) one can distinguee
 between, e.g., a string "123" and the integer 123. However, when new
 datatype definitions will arise there are some open issues. How we
 can compare different datatype definitions in order to validate RDF/S
 schemas or resource descriptions? How the schema datatype of a
 property can be compared with the instance datatype of a resource
 description? Is it easy enough that people will understand it and
 will use it in the right way? Why the schema datatype of a property
 is not sufficient to interpret its data value?

 Class Cycles

 Finally, contrary to the new RDFS specification and the RDF Semantics,
 the RQL formal model forbids the existence of cycles in the
 subsumption hierarchies. Cycles are also allowed in DAML+OIL and
 OWL. According to these specifications if a resource is declared to be
 an instance of one classes in a subsumption cycle, then it will also
 be an instance of all the other classes of the cycle. In other words,
 all classes participating in the cycle will have the same
 extent. Thus, cycles in a subsumption hierarchy are mainly used to
 provide different names for the same (meta)class or property. The
 rationale behind this modeling choice is the inference of class
 equivalence. However, the introduction of cycles may considerably
 affect the semantics of already created RDF/S schemas and resource
 descriptions, especially when the subclass declarations are provided
 in many, different namespaces. Once more, declaring versus inferring
 class equivalences is more preferable for developers mastering the
 semantics of their applications. Note that DAML+OIL and OWL also
 support explicit mechanisms for the declaration of equivalent classes
 or properties with the use of the properties equivalentTo,
 samePropertyAs and sameClassAs. The RQL type system can easily capture
 such property types having as domain and range metaclasses.

 -------------------------------------------------------------------------

Received on Monday, 17 February 2003 11:45:20 UTC