[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]