Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Compressability (WAS RE: XML Schemas: the wrong name)
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
