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

[Fisher, SM (Steve)]

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