Re: 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

Since you refer to the RDF Semantics, I will take the liberty of 
responding in order to ask for clarification of some of your comments.

>  -------------------------------------------------------------------------
>  Abstraction Layers
>
>  In RDF/S and recently proposed RDF Semantics, the distinction of
>  abstraction layers (data, schema, metaschema) is not explicitly
>  stated.

Indeed. Can you refer me to a precise statement of the meanings of 
the terminology you use to make these distinctions? They are not 
meaningful to me. In particular, I do not know what you (and others) 
mean by 'layer'.

>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.

The uniformity of the representation is common to all logic-based KR 
languages. The particular choice of a graph syntax is special to RDF, 
however. Which aspect are you particularly concerned with?

>On the
>  other hand, in DAML+OIL and OWL, the metaschema is fixed and they do
>  not allow its extension with user-defined metaclasses

I am not aware of any difference in principle between RDF and DAML or 
OWL in this respect. Can you explain this point further?

>(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.

Can you be more precise about the problems you feel may be caused?

>The RQL type system makes a clear distinction of the
>  different RDF/S abstraction layers

What different layers are you referring to?

>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.

I believe it is fair to say that they are treated exactly similarly. 
Properties can be viewed as classes of pairs; then rdfs:subPropertyOf 
is exactly similar (on properties) to rdfs:subClassOf (on classes). 
The extent of the parallelism can be judged by comparing the Lbase 
axiomatic translations for subproperty and subclass.

>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.

That seems incoherent to me as stated, unless by a metaclass of 
properties you mean a superproperty of properties.  Can you elaborate 
further?

>Hence, while in Telos a metaproperty can have domain
>  and range, in the RDF/S model it cannot.

If P is a property and R is a superproperty of P then R can have a 
domain and range.

>  Furthermore, at the data
>  layer, a property cannot be of type property, as in the case of
>  resources and classes.

I do not understand. All properties in RDF are of type rdfs:Property.

>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.

Again, I do not understand what is being said here. Can you explain 
further, perhaps with a simple example?

>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

It is not opposed to it. This was an issue in the design of the RDF 
semantics, in fact: many people felt that any superclass of a domain 
(range) should also, as a logical requirement, be considered a domain 
(range). The sematnics does not take this line, however, and allows 
the possibility of domains and ranges being restricted, and possibly 
unique.

>, which permits an optional declaration of multiple domains
>  and ranges, while considering a conjunctive (i.e., intersection)
>  semantics on endpoint classes of properties.

It permits it, but it does not require it. Ranges and domains can be unique.

>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.

That kind of ambiguity is explicitly forbidden by the RDF graph syntax rules.

>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.

I do not follow your reasoning here. In your example, the token 
"oil-on-canvas" is intended, I presume, to be an untyped literal? If 
so, it is required by the basic RDF semantics to denote itself, ie to 
be a string.  Strings however are resources, so I do not see any 
semantic inconsistency.

>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.

Such a change does not have that implication, and I do not follow why 
you think it does.

>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).

True, in the sense that these classifications will be valid entailments.

>However, classifying &r2 as Painting
>  and/or ExtResource should be under the entire responsibility of
>  application developers.

It is.  I do not follow the implication of your use of "however" here.

>  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).

That is true, it may. However, if P subproperty Q and Q range R, then 
one might as well assume that P range R also, since there is an 
inference chain which has a similar effect:

a P b  --> a Q b (subproperty)  --> b type R (range of Q)

>The semantics of properties become completely unclear when
>  subproperties are defined with multiple domains and ranges.

They can become rather complicated if stated carelessly, but the 
implications of any particular case are relatively easy to work out, 
if necessary by purely mechanical means.

>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).

Can you state this comment more precisely, eg by giving examples of 
the kind of behavior you feel is inappropriate?

>
>  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.

True, there are many open issues in datatyping. I think it would be 
fair to describe the RDFS treatment of datatyping as minimal.

>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.

That is correct.

>Thus, cycles in a subsumption hierarchy are mainly used to
>  provide different names for the same (meta)class or property.

I think this is slightly misleading. The central point is less that 
cycles are *used* to provide equivalent names - that would indeed be 
rather a silly way to use them deliberately - but rather more that 
when putting together pieces of information from divergent sources, 
one might *discover* that two different hierarchies have the 
conclusion, when put together, that some classes are in fact all the 
same class.

>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.

I am not sure what you mean. The point is not that cycles will be 
introduced, but that they will be discovered. Once discovered, one 
has two options: to consider this an error, or to consider it a 
discovery.

>Once more, declaring versus inferring
>  class equivalences is more preferable for developers mastering the
>  semantics of their applications.

Is your point that it should be impossible to infer class equivalences?

Thanks for your help in clarifying your points.

Pat Hayes


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Tuesday, 18 February 2003 17:03:54 UTC