xml-dev - Re: Compressability (WAS RE: XML Schemas: the wrong name)

[Martin Bryan <mtbryan@sgml.u-net.com>]

Len

> It would be interesting to read your comments on
>
> http://www.ph.surrey.ac.uk/~phs1it/papers/layer7.htm
>
> and Greenwald's levels of representation diagram therein.

I was reading Thompson's paper this afternoon while waiting for the local
vampires to get their teeth into me (its Churchdown's day for a visit from
the UK National Blood Service - which takes out more blood than it puts
back!). While doing so I was trying to map Thompson's model to XML Schemas
and ebXML.

> Note that in that diagram for human cognition, schemata
> are at the top of the five levels, but categorization
> is in the middle.  Thus
>
> schemata <-> propositions <-> categories <-> objects <-> features

I prefer Thompson's paradigm <-> model <-> classes <-> relations <-> objects
<-> images view.

From the XML Schema point of view this would seem to equate to
Schema Metamodel <-> schema <-> elements <-> substituion group <-> complex
type <-> simple type

I tried to do the same for ebXML, where I came up with

Business Process Metamodel <-> Business Process  <-> Business Document <->
Functional Unit <-> Aggregate Core Component <-> Basic Core Component

Not absoulutely convinced this is the best representation for the ebXML
material, but it looks like a starting point.

> Note the emphasis or recognition of patterns to properly
> name new instances, and the concern of the author that
> most approaches have emphasized relations within a level
> over relations between levels.

What I found particularly interesting is that the relations between levels
are best expressed as parallel operations, whereas the internal ones were
more traditional arcs, which I consider to be serial in nature.

> Since I am not very familiar
> with RDF models being applied although I understand the basics
> of RDF, I wonder how or if designers are handlingthis.

Look at the XML Schema for ISO 13250 Topic Maps that I published last night
at http://www.diffuse.org/TopicMaps/schema.html. This illustrates nicely the
application of the XML Schema version of the model that I gave above.

David Megginson is convinced that he can do the same with RDF, but I still
question the efficiency with which you can use RDF to describe parallel
relationships (which is what topics actually describe).

>My intuition
> is that just as these authors describe, RDF semantic models
> must be able to be layered and relations between levels
> are critical for compressability to work well.

Agreed. The key thing to look at, as far as I am concerned, is the purpose
of describing the relationships. All the RDF examples I've seen are
concerned with assigning metadata to a single resource, not describing the
relationships between sets of resources. In library terms RDF is like
writing out a single catalogue card describing a particular resource. Topic
maps are more like building a subject catalogue from a set of catalogue
cards. Topics identify a set of resources that share common characteristics.

> By compressability,
> note the use of automated classification techniques to
> create higher level representations that are more efficient
> and the enabling of higher level operations based on the
> outputs of the lower level processes.

How this can be generalized in XML terms I am at present unclear. XPath
would not seem to help, but it might be possible to do this by means of XSLT
processes associated with XML Schema substitution groups. Unfortunately XSLT
is not really built for parallel processing.

> If we are to use semantic networks well, QOS issues become
> germane quickly.  A user of a high-level representation
> should not have to rely on deep knowledge of the network
> to wire it into an advanced workflow.  On the other hand,
> unless the QOS numbers indicate a highly reliable component
> operating on an authoritative, credible model, this is a
> dicey thing to try without lots of testing.  Exhaustive
> testing seems unreasonable to require, but are there
> alternatives other than "ship it and wait for customer
> feedback".

This is where reusable core components fits into my view of the overall
picture. If we have a reusable abstract component then users can apply this,
or restrictions or extensions thereof, to particular objects (XML elements),
which can then be treated as members of a substituion group that will be
understood by a knowledge agent that is keyed to the relevant type model.
This "functional unit" has known properties, but different representations,
and local "tweaks". The user only needs to know the function within a
particular interchange mechanism (business document) for a specific process,
not its internal representation.

Martin Bryan