<!doctype linuxdoc system>
<article>

<title>
	RDF to describe XML::Edifact Namespaces
<author>
	Michael Koehne,
( <htmlurl url="mailto:kraehe@bakunin.north.de" name="kraehe@bakunin.north.de"> )
<date>
	Tue Jun 22 18:11:01  1999
<abstract>
	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 intension to
	offer some time for comments and discussion before I start
	to code the <tt/Resource Description Framework/ for XML::Edifact.

</abstract>
<!-- Table of contents -->
<toc>
<!-- Begin the document -->

<sect>
	Subject - Predicate - Object
<p>
	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.

<tscreen><verb>
	[Subject] has [Predicate] [Object]
or	[Object] is [Predicate] of [Subject]
or	[Predicate] of [Subject] is [Object]
</verb></tscreen>

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

<sect>
	RDF to describe XML::EDIFACT namespaces
<p>
	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.
<p>
	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!
<p>
	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.
<p>
	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.
<p>
	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.

<sect>
	RDF to describe EDITEUR code list extension
<p>
	To step back to the SPO paradigm, using EDITEUR as example.

<tscreen><verb>
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
</verb></tscreen>

	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.

<sect>
	Lean XML/EDI and RDF
<p>
	If its possible to agree on <tt/Predicates/ and <tt/Schema/ 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.
<p>
	Think about following vapor ware message:
<tscreen><verb>
	&lt;newbooks:orders>
	   &lt;party
	   	qualifier="supplier"
	   	id="0123456789"
	        name="Missing Link"
		/>
	   &lt;party
	   	qualifier="customer"
	   	id="9876543210"
	   	name="Michael Koehne"
		/>
	   &lt;reference
	   	date="Wed Jun 23 18:47:27  1999"
	   	number="234"
		/>
	   &lt;item
	   	number="1"
	   	isbn="0-12-345678-9"
	   	author="anon"
	   	title="the book never written"
	   	publisher="nowhere press"
	   	/>
	&lt;/newbooks:bookorder>
</verb></tscreen>

	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.
</article>
