[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oasis-charter-discuss] Re: Proposed Charter for OASIS SET TC
Carl & David,
Interesting and thanks for the fast turnaround. I'll pass this on to
the XDI TC members and we'll look for areas where XDI can compliment SET
use, and vice versa. As for SDO, I am personally working on a Data
Access Service (DAS) implementation that connects to an XDI store and
will let you know as soon as I'm ready to release it (will be under an
Open Source license).
Thanks,
Bill
-----Original Message-----
From: carl mattocks [mailto:carlmattocks@gmail.com]
Sent: Tuesday, May 13, 2008 1:12 PM
To: David RR Webber (XML)
Cc: Barnhill, William CTR USAF AFMC AFRL/RIGA; Barnhill,William [USA];
oasis-charter-discuss@lists.oasis-open.org
Subject: Re: [oasis-charter-discuss] Re: Proposed Charter for OASIS SET
TC
I agree they are different yet complementary . As in-
XDI is focused on metadata that specifies
* Defining bindings of this abstract API to concrete transport
protocols such as HTTP, SMTP, SIP, and XMPP, and to invocation protocols
such as SOAP, REST, and RMI.
* Defining the semantics of XDI dictionaries - self-describing
ontologies for use in XDI data sharing.
* Defining the semantics of XDI link contracts - XDI documents
used to govern the terms of XDI data sharing relationships.
Whereas :
SET is focused on metadata for artifacts that support use of data being
shared
SET UBL / CCTS Ontology is for data content within that domain
As an aside - I am quite interested to know where XDI dovetails with the
work of the SDO TC
cheers
carl
On 5/13/08, David RR Webber (XML) <david@drrw.info> wrote:
William,
I think the two are vastly different! Apples and Oranges - both
fruit - but there the similarities end.
-------- Original Message --------
Subject: RE: [oasis-charter-discuss] Re: Proposed Charter for
OASIS SET
TC
From: "Barnhill, William CTR USAF AFMC AFRL/RIGA"
<William.Barnhill.ctr@rl.af.mil>
Date: Tue, May 13, 2008 12:41 pm
To: <oasis-charter-discuss@lists.oasis-open.org>
Cc: "Barnhill, William [USA]" <barnhill_william@bah.com>
Hi,
This looks fascinating, but wouldn't there be a lot of overlap
with XRI
Data Interchange Technical Committee (XDI TC)? XDI is developing
a
mechanism that may achieve all of the goals of the charter as I
understood it, at first pass. I haven't done a write up of a
detailed
comparison yet though. I'd like to first provide the XDI charter
for
reading
( http://www.oasis-open.org/committees/xdi/charter.php ) and
request one
of the SET TC sponsors to let me know how to end-goals are
different
from XDI?
Thanks,
Bill Barnhill
Booz Allen Hamilton
XDI TC Co-Chair, OASIS TAB member
________________________________
From: carl mattocks
Sent: Tue 5/13/2008 11:07 AM
To: Eckenfels. Bernd
Cc: oasis-charter-discuss@lists.oasis-open.org
Subject: Re: [oasis-charter-discuss] Re: Proposed Charter for
OASIS SET
TC
I agree with the statement "SET Process and Semantic Model"
would be
easily applicable to legacy formants, EDI or Inhouse ..
However, I believe a semantic domain scoped by UBL / CCTS is an
excellent and pragmatic goal for the first version of a SET.
highest regards
carl
On 5/13/08, Eckenfels. Bernd <B.Eckenfels@seeburger.de> wrote:
Hello,
I want to comment on the Scope of the SET TC Charter in regards
to the
close/strict relationship with Core Components. I think the
major semantic
modelling work and a framework to describe that is quite
independend from
the actual data representation. A "SET Process and Semantic
Model" would be
easyly applicable to legacy formants, EDI or Inhouse.
I therefore would propose to add this as a secondaryx goal, or
to weaken the
focus, to allow the TC to determine if they only want to support
CCs or not.
...........................................................
For this purpose, first a UBL "Component
Ontology" will be developed.
In the later phases, this ontology will be expanded to cover
other document
standards based on CCTS.
The Component Ontology serves two major purposes:
. Representing the semantics of components: Document
customization
takes
place at the level of individual types and elements; hence,
translation
needs to be done at the same level. When an automated process
compares two
versions of a schema, it needs to be able to identify
corresponding elements
in these schemas.
When document elements are represented as classes of a common
component
ontology, it becomes possible to utilize that ontology for the
computation
of similarities between elements from different schemas.
. Representing the structure of document schemas: Core
component based
document schemas are complex hierarchies including numerous
types and
elements any of which might be modified through customization.
........................................................................
.........................................................
Carl Mattocks
--
Chair OASIS Business Centric Methodology TC
co-Chair (ISO/TS 15000) ebXMLRegistry Semantic Content SC
Ontolog ONION Cop Leader
VP Berkeley Town Underwater Search & Rescue Unit
CEO CHECKMi
vmail (usa) 908 322 8715
CarlMattocks@checkmi.com
http://www.checkmi.com/
CHECKMi:Mate Semantically Savvy Agents
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC
that
generates this mail. You may a link to this group and all your
TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC
that
generates this mail. You may a link to this group and all your
TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Chair OASIS Business Centric Methodology TC
co-Chair (ISO/TS 15000) ebXMLRegistry Semantic Content SC
Ontolog ONION Cop Leader
VP Berkeley Town Underwater Search & Rescue Unit
CEO CHECKMi
vmail (usa) 908 322 8715
CarlMattocks@checkmi.com
www.CHECKMi.com
CHECKMi:Mate Semantically Savvy Agents
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]