Subject: First we took XML then we took RDF

From: Leif Laaksonen <[email-masked]>
Date: Thu, 20 May 1999 07:59:34 +0300 (GTB Daylight Time)

Hi,

I have been following the discussion about XML on the CCList with great
pleasure. Perhaps we chemists aren't that bad after all? The discussion
has floated between many subjects, which all has been somehow connected to
XML. However, when talking about making program output less difficult to
be interpreted by computers we are talking about resource description.

The W3 consortium has also done a great job in the resource description
field.  The vision is that in the future the resources would not just be
readable by computers but also understandable to computers. The Resource
Description Framework (RDF) is the answer to this problem. When we talk
about tagging our program output in one or an other way we really mean
that it should be in a form understandable by computers.

If we go back and think about the root problem. We have the interaction
between three fields:

           Information <==> Knowledge <===> Learning

We have and produce all the time more information but we really don't know
in detail the process how information is turned into knowledge. This is
now a problem in the digital age when old analog information should be
stored digitally. There isn't just enough space to store it! What we
really are aiming at is to store the knowledge but how can we turn
information into knowledge? We computational chemists are in a lucky
positiopn because we have been modelling processes already for a long
time. For example we don't have to document all laboratory measurements
and other details about a chemical reaction because we know the
theoretical machinery behind it and we can always reproduce it using our
models and equations. 

The steps between knowledge and learning is to some extent known through
the work people are doing in the pedagogical field. All this is of course
blurred by the fact that we have an interaction in both directins.
Learning can also result in information or knowledge.

What we really would like the program output to produce is a description
of the knowledge in our calculations in a form that would also be machine
understandable and the answer to this is RDF. 

I doubt too many persons today place their output directly on the network
but if this happens and the output is using RDF we can some time in the
future look into the possibility of having software agents that talk to
each other and exchange information and resources on a particular
calculation. Perhaps they even write the papers and talk to the software
agent at a university directly to apply a job for you. 

Regards,

-leif laaksonen

-------------------------------------------------------------------
Center for Scientific Computing    | Phone:      358 9 4572378
P.O. Box 405                       | Mobile:     358 400425203
FIN-02101 Espoo                    | Telefax:    358 9 4572302
FINLAND                            | Mail:  [email-masked]
-------- URL: http://laaksonen.csc.fi/leif.laaksonen.html ---------

---

From: Konrad Hinsen <[email-masked]>
Date: Thu, 20 May 1999 20:06:24 +0200

On Wed, 19 May 1999, Peter Shenkin wrote:

> One difference among these formats is the degree of nesting of
> data structures they allow.  ASN.1 allows as many as one wants;  
> so does STAR.  But STAR/CIF limits this, and CEX started out with 
> basically the STAR/CIF limits.  I'm not sure about the XML/CML
> proposal, but I suppose it allows as much as you want.  The m2io

XML permits arbitrary nesting, but DTDs can be designed to effectively
limit this (although I see no reason to do so).

> The real difficulty, however, is how semantics are to be handled.  CEX
> had a field called CHARGE.  In CEX work-group discussusions, I used
> to ask, "Is this partial charge or formal charge."  The answer was
> always, "It's whatever you decide to put there."  The net effect
> was that a reading program would not always know how to interpret
> CHARGE when it got this field.  IMHO, it was a failure to resolve
> this sort of issue that limited the success of CEX.

The XML answer to this problem is to use tag attributes. You could
write for example

  <charge type="partial">0.2</charge>

Programs can then easily extract
- all charge data, ignoring the type
- only charge data of a specific type
- all charge data together with the type

The DTD decides if attributes are compulsory or obligatory (perhaps
with a default value) and whether the value can be any string or
one out of a fixed set of values.

> It would be easy to say, "Well, if I put the partial charge in
> the CHARGE field and read it in one of my programs later, then
> I know it's partial charge and it's not a problem."  But if these
> APIs and file formats are to be useful for data interchange with
> someone else's program, I need to know what the other program
> meant by CHARGE.  That means I need not just the file, but 
> also the history of its generation.  There was no standard
> way of encoding this.

That's also my main criticism about CML: the interpretation of many
data items depends on "conventions", and it seems almost necessary for
each program to establish its own one. Of course conventions give more
flexibility, but at the cost of making much data useless without
additional information, which in general would not even exist in
machine-readable form. I'd prefer a more rigid DTD with clear
semantics; it is always possible to extend a DTD in a particular
document if something essential is missing.

> is going to be much harder.  What are the semantics
> of "a hydrogen bond" or "an alpha helix"?  A lot of the 
> difficulties in using PDB files have to do with this.  Of

The essential problem of the PDB format is that there is no provision
for storing additional data in a standardized format. The choice
is between REMARK records and abuse of some fields, leading more
often than not to the latter choice, which permits at least
simple parsing.

> Let tell you how we're dealing with the semantic issue in m2io.
> Part of each data tag may contain a label that identifies a 
> "reader", sort of an intended audience.  

That sounds pretty similar to CML conventions! And it leads to
the same problem: what is a program supposed to do when it
encounters an unknown "reader" type?

> Why did we roll our own, instead of using one of the above choices?
> Well, we did come close to using ASN.1, as I mentioned above.  For
> STAR and XML/CML, we couldn't find readers/parsers that were either
> free or cheap enough -- or, if I recall correctly, for CML, that even
> existed.  The good ones for ASN.1 are expensive, too.  All the above

CML is an XML application and therefore also an SGML application,
there must have been suitable parsers long ago, but perhaps quite
expensive. Today there are several free XML parsers around,
although some people might find GPLed parsers too free ;-)

-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: [email-masked]
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

---

From: "Jesus M. Castagnetto" <[email-masked]>
Date: Thu, 20 May 1999 17:12:09 -0700 (PDT)

Hello Leif and all,

Leif's analysis hits the problem in the head. For any meaningful use of
any XML application (CML, RDF, WDDX, CDF, etc.) there has to be a scaffold
of metainformation about the data, one that can describe the contents and
its meaning to the end application (or to a human being).

The usual way of doing this in XML and SGML has been the use of DTDs, but they
are difficult to extend realiably (no support for inheritance, etc.). There
are in the works several meta-data desciption initiatives (schemas): DCD, 
XML-Data and similar things. Interestingly enough this schema are themselves
written in XML (you can never find a Goedel when you need one :).

In SGML/XML parlance, an application is not refering to a program, but to an
schema, etc. based on the specification of the description language.

Use of RDF (one of several XML applications), does not preclude the concurrent
use of other ones (CML, Bioinformation Sequence Markup Language, WDDX). In
fact, you can use RDF to describe the structure of a repository or database
of XML documents. And also use an XML based query application to search for
the information in the repository, and then use XSL (or even CSS) to display
it to the user.

My feeling is that all of these developments are still in a protean state,
as they evolve further their usefulness will be greater, but it is something
that whether we want it or not is happening and will happen. And chemist
(in particular computational chemist) should be aware of it and contribute
to its development.

Sorry for the longish rant.

--
Jesus M. Castagnetto <[email-masked]> - "Ken Zen Ichi-nyo"
Program Project:   http://www.scripps.edu/research/metallo/ 
Metalloprotein DB: http://metallo.scripps.edu/
Pilot Stuff: http://www.geocities.com/ResearchTriangle/Lab/1059/