OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Meeting reminder and agenda for meeting TODAY

This is a reminder and the agenda for our telecon Thursday, June 24th,
from 1:30-3:30.  

Call in information is below.

USA domestic toll free number: 1-866-235-8350
International number: 206-655-2988
Pass code: 669014#
Here is the phone number for the operator if you have any problems:
206-655-2254. 

Agenda:
	1. Minute taker
 
	2. Approval of minutes from last meeting

	3. eGov report

	4. WSRP report
 
	5. SCM subcommittee report

	6. cc Review subcommittee report

	7. Specs status

	8. Proposal for more flexible object ref
 <<Re: [regrep] PROPOSAL:  More flexible ObjectRef>> 
	9. IHE ITI supplement
 <<Re: [regrep] FW: [Fwd: IHE ITI Technical Framework Supplement
published for Public>> 
	10. Update on Publishing Web Services
  <<Re: [regrep] [Paper on Federated Registries] Re: [Fwd: Semantic Web
Services Architecture Committee Requirements   Document]>> 
	11. Survey discussion

	12. Other issues/items
 
	13. Next meeting

Please let me know if there are additional items for the agenda. 



Kathryn Breininger
CENTRAL Project Manager
Emerging Technologies
Boeing Library Services

425-965-0182 phone
425-237-3491 fax
kathryn.r.breininger@boeing.com
--- Begin Message --- 
Monica J. Martin wrote:

> Farrukh Najmi wrote:
>
>> Nikola Stojanovic wrote:
>>
>>> <Farrukh>
>>>
>>> > My proposal is to add a new logical id attribute to the set of
>>> > registry versioning attributes, and otherwise improving ObjectRef to
>>> > allow selection of a particular version of an object.
>>>
>>> +1 on being able to reference a logical object in a version independent
>>> manner.
>>>
>>> This is exactly what the lid attribute is for in the versioning spec
>>> being added to version 2.6.
>>>
>>> I think that the use case you raise can (and should) be addressed very
>>> easily by extending the ObjectRef class to have a choice of:
>>>
>>> a) a static "hard-wired" reference to a specific version of a specific
>>> object (current capability)
>>>
>>> b) a dynamic "late-binding" reference to a logical object which is
>>> determined at run-time (de-refence time).
>>> I could see this being done via a second attribute named "dynamic". 
>>> When
>>> dynamic is false (default) the registry
>>> assumes that the id attribute references the referenced object. When
>>> dynamic is true, the registry assumes that the id attribute MUST be 
>>> to a
>>> stored query that dynamically determines the referenced objects.
>>>
>>> This is a very powerful concept. Thanks Matt for seeding this idea. I
>>> hope we can discuss this over email prior to next telecon. Thanks.
>>>
>>> </Farrukh>
>>>
>>> I also see this as a very valid and a needed Use Case and that 
>>> LateBinding approach is interesting. However, I think that we have a 
>>> solution that doesn't need LateBinding. It would be something like 
>>> this:
>>>
>>> - subscribe to relevant event(s); in this case it is Update of the 
>>> objects that are members of the package.
>>>
>>> - implement "Web Service" that is going to be triggered by the above 
>>> event and that is going to adjust relevant object references.
>>>
>>> As one looks at the context of the two, LateBinding would incur 
>>> lookups whenever object references need to be resolved and 
>>> EventNotification will be invoked when relevant events happen. One 
>>> would assume that occurrence frequency of the first is higher then 
>>> of the second.
>>>
>> Interesting point that Matt's use case is already addressable via the 
>> Event Notification feature. So as I understand your suggestion the 
>> reference that needs to always be to the latest version of an object 
>> could be updated from one version  of an object to another by a web 
>> service that is an Event Notification Listener  service that gets 
>> invoked whenever a new version of the object is created.
>>
>> I agree with the point that your alternative is more efficient than 
>> late binding Object Reference approach and requires no additional work.
>>
>> I now reconsider the idea of doing late binding of object references 
>> now. Instead we should keep it in our future candidate work items and 
>> rely on your Event Notification based approach to address Matt's use 
>> case for now.
>>
>> Any one disagree with this proposed resolution?
>
>
> mm1: I don't disagree but wish to ask a question that applies to not 
> only late binding but the event notification approach where object 
> references are updated.  In ebBP, we found that LateBinding is not a 
> black-white situation. For example, when we started to talk about 
> conditional attributes such as time to perform, we determined that 
> LateBinding could have a duration, may or may not be allowed, and 
> constraints could be applied (when changed, if changed where does the 
> value come from, etc). This raises questions:
>
>    * Can you update the object references to the latest version?

Yes. For the latest object at the time of update.

>    * Are there conditions that apply? Are all objects in the package
>      updated?

Lets focus on the simpler case of Object A wishing to reference latest 
version of Object B.

The answer is that:

-If late binding is used then the object A updated when the object B is 
updated since the late binding ObjectRef stays unchanged.

-If event notification is used to update the reference in Object A then 
Object A will be updated (and likely new version created) when Object B 
is updated.

This is a significant difference between the two solutions.

>    * Does the owner define the duration, parameters or constraints of
>      when they can be changed?

Object B can change any time its owner (or delegate) updates it. Object 
A's owner (or delegate) controls the criterea for the dynamic reference 
but has no control over when Object B is updated.

>
> As well, in our work on time to perform, we found the conditional 
> aspects to be best expressed as an element not an attribute. 

In the late binding approach the conditional aspects are expressed in a 
stored query so an attribute with the query's id is sufficient.

Thanks for the though provoking questions.

-- 
Regards,
Farrukh



To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
--- End Message ---
--- Begin Message --- 
Breininger, Kathryn R wrote:

>I am forwarding this request for review and comments on four supplements
>to the IHE ITI Technical Framework, rev. 1.0.  Comments are due by July
>15th.  We can discuss this at our next telecon as well.
>  
>
FYI...

The following is the link to the IHE specification which references the 
ebXML Registry specs:

http://www.himss.org/content/files/IHE_ITI_Cross-enterprise_Doc_Sharing_PC_2004-06-15.pdf

This is great news for the adoption of our work. Congratulations to all.


-- 
Regards,
Farrukh


>Kathryn 
>
>-----Original Message-----
>From: bill@nist.gov [mailto:bill@nist.gov] 
>Sent: Wednesday, June 16, 2004 7:28 AM
>To: Breininger, Kathryn R
>Cc: lisa.carnahan@nist.gov
>Subject: [Fwd: IHE ITI Technical Framework Supplement published for
>Public
>
>
>Kathryn
>
>IHE (http://rsna.org/IHE/index.shtml) is issueing a profile for the use
>of the ebXML Registry Standard in healthcare. The profile is named
>"Cross-Enterprise Clinical Documents Sharing (XDS)".
>
>For now it is only being distributed to interested parties that are
>likely to provide comments.  The comment period ends July 15, 2004.
>After that, changes will be made based on the comments and a final
>document will be released.
>
>The purpose of an IHE profile is to involve industry in providing
>implementations, both client and server, to the healthcare environment.
>The publishing of a profile leads to industrial collaboration through
>the fall, a connect-a-thon in January and then a public display at HIMSS
>in February.
>
>We, NIST, showed a registry at HIMSS last February as part of a joint
>HL7/IHE booth. It was based on Farrukh's work. This is the first time a
>profile has been attempted for this technology by IHE.
>
>We would appreciate your review and distribution to others you think
>would want to see it. I have already sent this notice to Farrukh Najmi
>and Brett Trusko.
>
>Thanks,
>Bill Majurski
>NIST
>
>
>--------------------------------- Original Message
>---------------------------------
>Subject: IHE ITI Technical Framework Supplement published for Public
>Comment From:  
> "Sensmeier, Joyce" <JSensmeier@himss.org>
>Date:    Wed, June 16, 2004 12:29 am
>To:      ihenews@rsna.org
>         iheinfra@rsna.org
>------------------------------------------------------------------------
>------------
>
>IHE Participants and Interested Observers,
>
>IT Infrastructure Technical Framework
>2004-2005 Supplements for Public Review
>The IHE IT Infrastructure Technical Committee has published the
>following four
>supplements to the IHE ITI Technical Framework, rev. 1.0 for public
>review.  
>*	Audit Trail and Node Authentication
>*	Cross-Enterprise Clinical Documents Sharing (XDS)
>*	Patient Demographics Query
>*	Personnel White Pages
>These documents are available for download and review at
>www.rsna.org/IHE/tf/ihe_tf_index.shtml
><http://www.rsna.org/IHE/tf/ihe_tf_index.shtml>.  The HIMSS IHE web site
>www.himss.org/ihe will also be updated within the next few days to
>reflect recent IHE additions/changes.
>
>Public comment on these supplements is invited through July 15, 2004 and
>can be submitted using the online discussion
>http://forums.rsna.org/forumdisplay.php?s=14ee53e2a361a541138249d99caa50
>9b&forumid=270>
>	Regards,
>	Joyce
>
>Joyce Sensmeier MS, RN,BC, CPHIMS
>Director of Professional Services
>HIMSS
>230 East Ohio St., Suite 500
>Chicago, IL 60611
>312-915-9281
>jsensmeier@himss.org
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>  
>
--- End Message ---
--- Begin Message --- 
Thanks for sharing Joe.

This reminds me of the need for doing an update on the Publishing Web 
Services TN to add details on how to publish QoS attributes for Web 
Services and how to use those QoS attributes for Service discovery. Our 
existing specs handle this use case already but the details need to be 
spelled out.

I propose we add this to our next TC meeting's agenda. Thanks.

-- 
Regards,
Farrukh



Chiusano Joseph wrote:

>FYI: I sent the e-mail below to the SCM subcomittee, then noticed one of
>the citations [1] which was a paper on "Discovery of Web Services in a
>Federated Registry Environment" - so I thought it might be of interest
>to the full TC. Includes references to both UDDI and ebXML Registry.
>
>This University of Georgia (US) paper discusses the METEOR-S Web Service
>Discovery Infrastructure[2][3], which provides an ontology based
>infrastructure to provide access to registries divided based on business
>domains and grouped into federations. It also discusses how Web Service 
>discovery is carried out within a federation.
>
>[1] http://lsdis.cs.uga.edu/Library/download/MWSDI-ICWS04-final.pdf
>[2] http://lsdis.cs.uga.edu/proj/meteor/mwsdi.html
>[3] http://lsdis.cs.uga.edu/Projects/METEOR-S/index.php
>
>Joe
>
>Joseph Chiusano wrote:
>  
>
>>Just announced: The Semantic Web Services Initiative (SWSI) has released
>>architecture requirements for Semantic Web Services. Highlights are
>>included below - including service lifecycle and ontology management.
>>
>>[1] http://www.daml.org/services/swsa/swsa-requirements.html
>>
>>Thanks,
>>Joe
>>
>>HIGHLIGHTS:
>>
>>(1) Semantic Web Services are viewed as a way to extend the capabilities
>>of web services in the direction of dynamic interoperability, thereby
>>making it possible for clients to successfully utilize web services
>>without prior arrangements between people that are realized in rigid
>>software protocols, and immutable ontologies or meta-data.
>>
>>(2) The functions addressed by the Semantic Web Services Architecture
>>will include:
>>
>>* Dynamic Service Discovery: The capability for a software agent to
>>identify candidate services for particular objectives; includes
>>candidate service matchmaking and brokering functions.
>>
>>* Service Selection and Composition: The capability to dynamically
>>select and compose services to achieve some objective; includes failure
>>recovery and compensation mechanisms, as well as choreography
>>interpretation and execution. Also includes ontology translation
>>services.
>>
>>* Negotiation and Contracting: Ability for two agents to mutually
>>formulate a shared agreement in terms of performance to be provided;
>>includes dispute resolution and compliance.
>>
>>* Semantic Web Community Support Services: Capabilities associated with
>>sharing semantic descriptions, ontologies, ontology mappings, and
>>service catalogs within and across communities, and managing these items
>>as well.
>>
>>* Semantic Web Service Lifecycle and Resource Management Services:
>>Capability to management the lifecycle of Semantic Web Services.
>>
>>* Other: Includes QoS requirements (time, cost, reliabilty, operational
>>metrics, etc.), and the capability to discover a service based on these
>>factors.
>>
>>-------- Original Message --------
>>Subject: Semantic Web Services Architecture Committee Requirements
>>Document
>>Resent-Date: Thu,  3 Jun 2004 11:28:16 -0400 (EDT)
>>Resent-From: public-sws-ig@w3.org
>>Date: Thu, 03 Jun 2004 11:28:06 -0400
>>From: Mark Burstein <burstein@bbn.com>
>>To: public-sws-ig@w3.org
>>
>>The Architecture Committee of the Semantic Web Services Initiative
>>(SWSI)
>>has spent the last few
>>months putting together an overview of the functional requirements that
>>a
>>comprehensive approach to architectures for semantic web services should
>>include.  While different communities will need more or
>>less of some of the features covered, we felt it was worthwhile to try
>>to
>>take a longer term view in this exercise.
>>
>>The document is available for review and comment from the SWSA committee
>>home page at
>>http://www.daml.org/services/swsa/
>>
>>The document itself is located at
>>
>>http://www.daml.org/services/swsa/swsa-requirements.html
>>
>>Comments can be sent to public-sws-ig or to me personally at the address
>>below.
>>    
>>
>
>  
>




To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
--- End Message ---

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]