- From: Assaf Arkin <arkin@intalio.com>
- Date: Wed, 12 Feb 2003 21:48:32 -0800
- To: "Burdett, David" <david.burdett@commerceone.com>, "'Duane Nickull'" <duane@xmlglobal.com>
- Cc: <www-ws-arch@w3.org>
- Message-ID: <IGEJLEPAJBPHKACOOKHNEEALDDAA.arkin@intalio.com>
Including Semantics -----Original Message----- From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On Behalf Of Burdett, David Sent: Wednesday, February 12, 2003 4:30 PM To: 'Duane Nickull' Cc: www-ws-arch@w3.org Subject: Including Semantics Duane asked ... >>>One missing component I would like to see is semantics. David - do you think there is a way to leverage the semantics of UBL, CCTS for the WSAG?<<< Semantics is a whole big topic on its own, but here's my take of the semantic information that you might need to define. Note I'm looking at this from a "business use" perspective: 1. Document Semantics. At the highest level a namespace identifies a document as consisting of a set of fields. Within this there are two additional levels to consider: a) Individual fields. Each field needs to be defined, e.g. what does "CustomerId" mean, e.g. is it the ID by which the Customer identifies themselves or the id which the supplier uses to identify the customer? b) Fields within a document, e.g. The Customer ID could appear can appear in multiple places in the document - how does its meaning vary depending on where it exists. 2. Context Dependent Semantics. The content of a message can also depend on the context in which it is being used, for example an Invoice in Europe is different from an Invoice in the US as it contains different fields. Similarly an Invoice used in the travel industry contains additional line item information (e.g flight segments) that other industries (e.g. the chemical industry) don't need. 3. Message Semantics. Messages >can< consist of multiple parts where you could describe each "part" as a document. You then need to, in the context of the message, define what each document mean, for example you might want to attach a supplier generated delivery note when requesting a "return materials advice" for some faulty goods. In this case the delivery note is evidence that delivery occured. This is different from its first use when the delivery note informs the buyer of what the supplier has shipped, but not yet delivered. 4. Transaction Semantics. The same message with the same structure and same semantics can be treated differently depending on where it is being sent and the context in which it is being used. For example sending an Order Message to an off-site archival service for archiving would have different meaning than sending the "identical" message to a supplier. So yes I think you could leverage the semantics of UBL etc, but that is just the start and my best >guess< is that you could use header information in a SOAP message to codify the semantics of the message ... although this sound very non-RESTafarian ;) Also ... this is a trout hole ... how does the W3C work on the Semantic Web fit in with all of this ;) Just looking at the perspective of Semantic Web, could we not use RDF to create maps of semantic information? For example, I can describe the semantics of a type using RDF (customerID) by referencing the type definition, but also the semantics of the content of a type (order/billing/address vs. order/shipping/address) if I can reference an XSD particle. And I can have both semantics, one that applies to address in isolation, and one that extends that semantics when address is used in some context. I would guess that the same is possible for transactions. For example, e.g. the address of the invoice that is sent by activity X of transaction Y. All I need is a way to reference a resource that can be part of a larger resource in the RDF description and then provide that semantic in the RDF. arkin David -----Original Message----- From: Duane Nickull [mailto:duane@xmlglobal.com] Sent: Wednesday, February 12, 2003 4:00 PM To: Burdett, David Cc: www-ws-arch@w3.org Subject: Re: Layers in the WSA (was RE: [Fwd: UN/CEFACT TMG Releases e-Bus ines s Architecture Technical Specification for Public Review]) <SNIP/>
Received on Thursday, 13 February 2003 00:49:44 UTC