RE: Including Semantics

Including Semantics

  I think it really boils down to how the information is going to be >used<.
Most information in business documents ends up either being printed or
displayed for human consumption, or mapped to some internal format to
populate information in an ERP system say. In both these cases you need a
very clear definition of the meaning of the data that either a human can
understand as help when viewing a document or can be used by another human
to do a good map between external and internal formats. I don't see how RDF
would help with this and I can't imagine a software tool that could make
good use of it in this context.

  For computer processing RDF gives you a good framework and it can also
contain information for human consumption (e.g. HTML formatted text). But
practically speaking, we're still at the point where people do all that
work, so what we need is way to annotate the information and present some
textual information to the user.

  XSDL, WSDL and most other recent specifications have ways of annotating
definitions. Ideally you should be able to annotate any definition, not just
a top-level one, e.g. a particle in the XSDL content, an operation from a
port type, etc.

  The namespace by itself is insufficient because you can have multiple
definitions in the same namespace. But often some of the semantics is
captured by the namespace on its own. For example,
http://example.com/trading/futures may indicate that all related definitions
deal with trading in futures. It won't tell you what a specific data type
means, or what a particular operation does. But when you browse a repository
of type/service/process definitions, it lets you easily determine what
context you are looking at.

  arkin


  I accept I may be completely missing something - can anyone clarify?

  David
    -----Original Message-----
    From: Assaf Arkin [mailto:arkin@intalio.com]
    Sent: Wednesday, February 12, 2003 9:49 PM
    To: Burdett, David; 'Duane Nickull'
    Cc: www-ws-arch@w3.org
    Subject: RE: 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/>