[infod-wg] discussion around 'description' field and entity managers

[RONNY.FEHLING at ORACLE.COM]

Steve,

That is strange. I actually referred to our discussion over the phone where I had asked precisely that question. I drafted the email directly afterwoods.
Anyway, if that was not your intention we can leave it as is. 

I disagree with putting the description field to xsd:string. This field does not have to be analyzed by the registry and serves no purpose for the registry. It could represent a backdoor for additional functionality which is only discussed directly between publisher and consumer and should therefore be arbitary.


Ronny Fehling
Solutions Architect Manager
Oracle Strategic Development
Tel/Fax: +1 514 905-8633
Mobile: +1 514 880-8633
ronny.fehling at oracle.com
www.oracle.com
View my Calendar

--- Original Message ---
> Ronny,
> 
> You seem to have misunderstood what I meant. 
>     
> > -----Original Message-----
> > From: owner-infod-wg at ggf.org [mailto:owner-infod-wg at ggf.org] 
> > On Behalf Of Ronny Fehling
> > Sent: 31 March 2006 03:21
> > To: infod-wg at ggf.org
> > Subject: [infod-wg] discussion around 'description' field and 
> > entity managers
> > 
> > Hi,
> > 
> > 
> > Steve and I agreed to move our discussion from today's call 
> > onto an email thread where everybody can participate.
> > 
> > 
> > Basically, there are two suggestions that came from Steve 
> > with regards to the interfaces.
> > 
> > 1.	To merge
> > 	
> > 
> > BasePublisherManager
> > BaseSubscriberManager
> > BaseConsumerManager
> > 
> > into a common entity manager. They look a lot alike and have 
> > essentially the same operations. 
> 
> I did *not* propose this !!!
> 
> > I don't know Steve, what you want to do with the 
> > BaseSubscriptionManager as it is quite different to the rest...
> > 
> > As Dieter had pointed out a while ago, these Entity-manager 
> > interfaces could be viewed as a special case of the internal 
> > INFOD vocabulary; so theoretically, it makes sense to see 
> > them joined. One counter argument is if it makes the 
> > interfaces too cumbersome. I actually don't know what the 
> > original reason was to separate them as I wasn't part of 
> > INFOD back then. Input?
> > 
> > 2.	The second discussion point is a little more sensible. 
> > Basically, Steve observed that by me adding a description 
> > field to each interface (as discussed at GGF16), there was an 
> > explicit vocabulary reference within the entity management interface:
> > 
> >         <wsinfod:PublisherDescription Vocabulary="xsd:anyURI">
> > 	     { any } ?
> > 	</wsinfod:PublisherDescription> ?
> > 
> >  Although intended to be merely a way to include arbitrary 
> > descriptions (potentially opening up a work-around for 
> > not-yet implemented functionalities), one could regard this 
> > from the view of a vocabulary that is referenced this way by 
> > the entity as an implicit instantiation of that vocabulary.
> > 
> > So, rather than having to create a separate instance of a 
> > vocabulary and bind it to an entity, we could have the entity 
> > explicitly reference a vocabulary and with that become 
> > implicitly an instantiation of that vocabulary.
> > 
> > However, this will have a couple of impacts:
> > 
> > <!--[if !supportLists]-->a.       <!--[endif]-->We allow 
> > multiple vocabulary references for an entity. This means that 
> > to manage them, alterEntity interface would have to be used - 
> > is this conceptually correct?
> > 
> > <!--[if !supportLists]-->b.       <!--[endif]-->As we allow 
> > multiple instances of one vocabulary, is the management of 
> > vocabulary change and the potential impact on the entities a 
> > harder problem now?
> > 
> > 
> > c.       <!--[endif]-->As we allow multiple associations, is 
> > the management a harder problem now?
> > 
> > Also, before, the Description field could hold any 
> > 'blob'-vocabulary and the registry wouldn't care as it 
> > wouldn't have to parse it. Now, the description vocabulary 
> > and entry needs to be verified by the registry. We therefore 
> > loose the back-door for advanced features that we had before. 
> > 
> > Also, the Description field used to be an aid to the 
> > discovery for entities that could facilitate the search for 
> > specific entities by 'savant' end-users (who could parse the 
> > description field with its arbitrary vocabulary). We would 
> > loose that ability - if we don't add a new free-form 
> > description field.
> > 
> >  These are some of the thoughts I had on Steve's comment 
> > (after finally understanding what he meant in his email ;-) ). 
> > Any Input / comments?
> 
> I think that wsinfod:PublisherDescription should just be
> xsd:string and
> not be associated with any vocabulary. It might say for example
> "Purveyor of sausages and fine meats since 1910" or "Widgets
> made within
> 24 hours".
> 
> The problem I had was the reference "See 3.6 for more details
> on how to
> define a vocabulary for such descriptions." I think this used
> to be a
> string.
> 
> If it does have a vocabulary then it is doing the job of the
> CreatePropertyVocabularyInstance
> 
> Steve
> 
>  
>