[infod-wg] Minutes from 16 June conference call

[Dieter Gawlick]

Steve,

I think that the specification has plenty of information about the 
subscription. I attached a note that describes the various features that 
we have captured so far; I hope it is not too much a repeat. Obviously, 
the use case are the place to show cases this specifications and 'bring 
them to live.'

I tried to highlight the various functions of subscriptions very 
carefully; however, the real work has to be done in the use cases.

Dieter


Steve Fisher wrote:

>On Thu, Jun 16, 2005 at 09:37:23AM -0700, Cecile Madsen wrote:
>  
>
>>
>>
>>Attendees: Shailendra, Chris, Dieter, Steve, Stephen, Susan, Vijay, Arjun,
>>Susan, Cecile
>>Apologies: Abdeslem
>>
>>Minutes:
>>
>>We reviewed John's summary/understanding of INFOD specs:
>>
>>His review is an accurate summary of INFOD specs; his assumptions are
>>correct and his comments summarize earlier comments we've had
>>on the specs (uniqueness of disseminator, unclear how registry knows
>>whom to notify, simplifying the interface section by concentrating on
>>artifact
>>descriptions, not duplicating operations, etc.)
>>
>>Discussion on need for subscriber entity; resolution is to describe a
>>scenario that pinpoints that need, namely attaching vocabulary to
>>subscriber so that consumers can filter on such information.
>>
>>Discussion on weight of subscription; John/the specs don't position
>>it as the first class artifact that it is. Need to work more on this.
>>Subscriptions have evolved historically (subject-based, content-based,
>>state, etc.) and INFOD should position its subscription on top of the
>>chain...
>>it can also drive publications...
>>    
>>
>
>While trying to do my use case (at last) I wondered where to put the
>information which is used to express the interest of a consumer in
>some information or potential information. I looked at Cecile's note:
>
>INFOD_resource_creation_scenarios-1.doc
>
>and noticed that all such information is going into the
>consumption. There is *no* mention of subscription information.
>
>I think that (some of) our problems will be solved by merging the
>consumption and subscription into something which we just call the
>subscription. Part of the subscription can be how the data should be
>processed. I am sure this will be much easier for people to
>understand.
>
>Steve
>
>
>
>  
>
>>TO-DOs by next conf call:
>>
>>- Cecile - use John's suggestion - simplify interface section of specs
>>- Stephen - review the Animation scenario wrt specs - Cecile to help with
>>questions
>>- Dieter - follow-up on a to-do from June f2f (send description on
>>retention)
>>- All - consumption terminology still open...
>>- All - review summary notes from f2f on May 31/June 1 for to-dos that were
>>assigned
>>
>>
>>Next Conf Call:
>>
>>8AM PST June 23  (note earlier time again... separate note will be sent
>>with meeting notice)
>>
>>
>>The INFOD team
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/infod-wg/attachments/20050619/5f5a6e3e/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: A Note About Subscriptions.doc
Type: application/msword
Size: 31744 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20050619/5f5a6e3e/attachment.doc 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dieter.gawlick.vcf
Type: text/x-vcard
Size: 228 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20050619/5f5a6e3e/attachment.vcf