Re: Need a few basic Classes in RDFS

Dear people,

This posting is a reply to the following postings of early August:
Anand C. Patel, "RDF as a general purpose format for expressing any data?
(not just metadata?)"
Alain Michard, "Need a few basic Classes in RDFS"

Lately I have tried to understand RDF enough to tell in which applications
it can be used. I came to the same conclusion as Mr. Patel; RDF ought to be
useful for creating general data models, not only meta data models. Mr.
Patel mentions that RDF might be used as kind of an interchange format for
data bases.

At Kvaser we have put some effort in investigating the requirements for
general purpose technical descriptions of distributed embedded control
systems in general and CAN (Controller Area Network, a serial communication
protocol) systems in particular. For more information about CAN please

Furthermore, at Kvaser we have chosen to be active in standardization
activities. Until recently we have mostly been engaged in technical
standards related to CAN, but lately we have become involved in
standardization of an "Application Framework", providing primitives and "a
set of rules" to describe any distributed embedded control system using CAN
for data transmission. This is part of the work performed within ISO

Basically during our internal work so far we have followed three axioms:
- The _representation_ of a technical description must be a long lasting
text format. In principle any human readable SGML/XML format would serve
the purpose. Eventually we chose a simple homegrown XML format which we
call XTF (Extensible Tree Format). In order to support data modelling, we
have support for building XTF Models, a simple content model management.

- A bottom-up approach is needed when developing basic classes/models in
order to unambiguously describe data. So far we have modeled e.g. basic
types for XTF internal use (i.e. {integer, range [-32768, 32767]} or
{character, range ISO 8859-1) and also types related to machine dependent
data representation (i.e. {integer, signed two-complementary, 16 bit,
little endian} or {character, ISO 8859-1, 8 bit, little endian})

- A top-down approach is needed in order to understand what the user or
agent want to use the data for. The top-down approach quickly revealed that
it is necessary to describe the same system for a multitude of agents, all
wanting different non-disjunct sets of the complete system description.

Well then, in what way do this relate to RDF?
As far as I can see the RDF, completed with a dedicated higher layer, can
provide an alternative representation of the same technical description
that we now represent by using our homegrown XTF format. In that case RDF
would serve the purpose that Mr. Patel already has mentioned; "a general
purpose format for expressing any data". To successfully achieve this I
would suggest a connection between RDF and UML (Unified Modeling Language).
It is probable that this will be developed when RDF is mature enough and
RDF tools becomes available. Actually I do not feel that we are in a hurry
in this respect.

There is one thing though, that it is urgent to specify now. It is the
basic classes that M. Michard mentions in his posting. M. Michard talks
about the risk for defining the same objects in different namespaces. At
Kvaser we are a bit worried about this problem. As M. Machel mentions, a
multitude of classes describing the same objects causes severe
interoperability problems. Any pair of classes defined to handle the same
kind of objects must be handled separately when verifying interoperability.

Recently we made comments to a draft standard for CAN communication
dedicated for a wide range of applications. This draft standard included a
set of machine dependent data representations that were incompatible with
anything else I have seen hitherto:
normal:  {integer, unsigned, 16 bit, little endian, range [0, 65535]}
draft:   {integer, unsigned, 16 bit, little endian, numeric range [0,
65532], reserved values 65533="reserved" 65534="data not available"
65535="out of range"}

Actually this kind of reserved values at _representation_ level are rarely
useful in implementations (i.e. at _application_ level) in open systems
because of semantic ambiguity problems. But apart from that, this example
illustrates which kinds of interoperability problems (different numeric
ranges, implicit status management, not to mention the syntax) that may
occur when there is no common basic set of classes available.

I would like to invite anyone interested in this area to discuss this issue
further. I do not feel that the RDF comment list is the right forum, but I
would be glad if someone from the RDF community would like to participate.
At Kvaser we have already made a lot of effort in data representation
management, including quantity representation (SI unit representation
etc.). Anyone interested in sharing our conclusions so far, commenting and
adding their experience to the work, please contact me. The pro and cons of
standardization is debated in some fora, but regarding the bottom-up
upproach in data representation I can see only advantages with
standardization when trying to achieve interoperability.

Best regards,
/Magnus Frid
Magnus Frid            Fax: +46 31 886343
Kinnahult, Sweden

Received on Thursday, 24 September 1998 07:40:25 UTC