  RDF to describe XML::Edifact Namespaces
  Michael Koehne, ( kraehe@bakunin.north.de )
  Tue Jun 22 18:11:01  1999

  XML::Edifact 0.3 is using Namespaces to avoid name clashes between
  segment, composite and element definitions. Using RDF meta data to
  describe those namespaces is planed for the 0.5 version. This would
  allow to use RDF files provided by third parties to describe their
  UN/EDIFACT code list extension. This paper was written with the inten-
  sion to offer some time for comments and discussion before I start to
  code the RReessoouurrccee DDeessccrriippttiioonn FFrraammeewwoorrkk for XML::Edifact.
  ______________________________________________________________________

  Table of Contents:

  1.      Subject - Predicate - Object

  2.      RDF to describe XML::EDIFACT namespaces

  3.      RDF to describe EDITEUR code list extension

  4.      Lean XML/EDI and RDF
  ______________________________________________________________________

  11..  SSuubbjjeecctt -- PPrreeddiiccaattee -- OObbjjeecctt

  The Resource Description Framework is based on the SPO paradigm.  The
  SPO paradigm is drawn from the knowledge representation community and
  well suited to express complex coherencies in a formal way. Three
  typical sentences can be made with SPO.

               [Subject] has [Predicate] [Object]
       or      [Object] is [Predicate] of [Subject]
       or      [Predicate] of [Subject] is [Object]

  For further information refer to http://www.w3.org/TR/REC-rdf-syntax.

  22..  RRDDFF ttoo ddeessccrriibbee XXMMLL::::EEDDIIFFAACCTT nnaammeessppaacceess

  XML::Edifact has several default namespaces. Those are called edifact,
  trsd, trcd, tred, uncl, anxs, anxc, anxe, unsl and unknown.  The
  edifact namespace is intended to cover the overall message, while the
  four character namespaces are extracted from their UN/EDIFACT batch
  directory counterparts.

  But XML document type definitions are badly suited to constrain
  Edifact messages. While any valid UN/EDIFACT message will produce a
  valid XML::Edifact message, it would be possible to hack a valid
  XML::Edifact message, where the conforming UN/EDIFACT is not even well
  formed!

  Once a UN/EDIFACT message is parsed, translated to XML and stored in a
  DOM, it may have elements in the unknown namespace, most likely to
  come from unknown codes. As those elements from the unknown namespace
  are not defined in the edifact document type definition, a validating
  parser would trigger further checks. The parser now has to query a
  resource description framework to find a resolution for the unknown
  namespace. The Document now has migrated in namespace.  Now it's not
  an edifact:message, but perhaps an editeur or etis:message or even a
  kraehe:message, if we agree on private extensions.  Even if a
  resolution cant be found the document would migrate in namespace
  becoming an unknown:message as unknown:message's can have unknown
  elements.

  Further checks using the RDF are now necessary. The current document
  has a generic type and is just a sequential collection of translated
  UN/EDIFACT segments. The parser may check those segments using the RDF
  files provided for each namespace, when designing new messages. Most
  important are checks in the top level RDF the document type will
  migrate from the generic edifact:message to edifact:invoic or
  edifact:orders, the structure of segment groups will be patched into
  the DOM on that time.

  A last check using trading partner and document type as index on a RDF
  will round up for trade partner constrains. Now the message can be
  further processed.

  33..  RRDDFF ttoo ddeessccrriibbee EEDDIITTEEUURR ccooddee lliisstt eexxtteennssiioonn

  To step back to the SPO paradigm, using EDITEUR as example.

       base of editeur:message is edifact:message
       extension of editeur:message is editeur:item.characteristic.coded
       replacement of tred:item.characteristic.coded is editeur:item.characteristic.coded
       codelist of editeur:item.characteristic.coded is editeur:7081
       translation of editeur:7081:010 is Author Name
       similar of editeur:7081:010 is uncl:7081:76

  So RDF would allow translations between UN/EDIFACT and EDITEUR as it
  would allow a native use of EDITEUR messages. As similar SPO sentences
  can also be made about the ETIS extension, I hope RDF is well suited
  to describe UN/EDIFACT and its extension.

  44..  LLeeaann XXMMLL//EEDDII aanndd RRDDFF

  If its possible to agree on PPrreeddiiccaatteess and SScchheemmaa for XML::Edifact and
  to code it, it should be possible to inherit from this schema to map a
  lean XML/EDI to XML::Edifact and therefor to UN/EDIFACT.

  Think about following vapor ware message:

          <newbooks:orders>
             <party
                  qualifier="supplier"
                  id="0123456789"
                  name="Missing Link"
                  />
             <party
                  qualifier="customer"
                  id="9876543210"
                  name="Michael Koehne"
                  />
             <reference
                  date="Wed Jun 23 18:47:27  1999"
                  number="234"
                  />
             <item
                  number="1"
                  isbn="0-12-345678-9"
                  author="anon"
                  title="the book never written"
                  publisher="nowhere press"
                  />
          </newbooks:bookorder>

  Compared to the lengthly messages XML::Edifact produces, this lean
  format may be better suited for transfer on the Internet.  If newbooks
  now provides a RDF for his lean XML/EDI mapping between
  newbooks:orders and edifact:orders can be done.

