[infod-wg] discussion around 'description' field and entity managers
Cecile Madsen
madsen at us.ibm.com
Wed Apr 5 20:25:42 CDT 2006
FYI...
Q: I actually don't know what the original reason was to separate
them as I wasn't part of INFOD back then. Input?
A: The reason it was replaced by the specific entity managers that exist
today was usability:
it was argued, at that time, that the level of abstraction introduced by
one generic entity model
was too high which made the job of infod implementors too hard: having to
define and understand
the interaction between these entities. So we went with the different
managers we have now. It was also
argued that this choice brings infod specs closer to the wsn specs
(subscription manager concept).
Cecile
"Fisher, SM
(Steve)"
<S.M.Fisher at rl.ac To
.uk> "Ronny Fehling"
Sent by: <RONNY.FEHLING at ORACLE.COM>,
owner-infod-wg at gg <infod-wg at ggf.org>
f.org cc
Subject
04/05/2006 02:43 RE: [infod-wg] discussion around
PM 'description' field and entity
managers
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/infod-wg/attachments/20060405/e420f24d/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20060405/e420f24d/attachment.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic09368.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20060405/e420f24d/attachment-0001.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20060405/e420f24d/attachment-0002.gif
More information about the infod-wg
mailing list