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

[Stephen Davey]

Hi there,

Looking at the minutes/notes from GGF16 (and Ronny's updated chapter 3)
I thought the format of the Description field was now going to be:

 

<wsinfod:PublisherDescription>
                 { any } ?
</wsinfod:PublisherDescription> ?

 

I.e. No vocabulary is specified, and that the purpose of the description
is just a free form string to aid the reader who might be browsing the
Registry. (Perhaps the type should be changed to xsd:string?)

Although I notice that in the interfaces document the subsequent
description of the PublisherDescription field should also be updated
because it still says:

 

"/wsinfod:PublisherDescription

 

            An optional attribute that associates descriptive terms for
the publisher entity. If such 

            properties are defined, any INFOD entity may query this
attribute to determine which INFOD 

            publisher(s) best fit their needs.

 

            See 3.6 for more details on how to define a vocabulary for
such descriptions."

 

I.e. It shouldn't mention querying or defining vocabularies.

 

Cheers, Stephen.

 

--------------------------

Stephen Davey, 

National e-Science Centre,

Edinburgh, UK.

  _____  

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 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:

a.       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?

b.       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.       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?

 
Ronny Fehling
Solutions Architect Manager
Oracle Strategic Development 
Tel/Fax: +1 514 905-8633
Mobile: +1 514 880-8633
ronny.fehling at oracle.com <mailto:ronny.fehling at oracle.com> 
www.oracle.com <http://www.oracle.com/>  
View my Calendar
<http://collabsuite.oracle.com/global-bin/ocas.fcgi?sub=web&web=gbl&viw=
%85%97%97%94%82%f2%9b%9b%97%ac%a8%ac%a4%a4%aa%b4%a6%ab%a5%af%c5%af%a2%a3
&xen=%e5%ea%e1%e2%f4%e9%ed%ee> 



-----Original Message-----
>From Steve Fisher <S.M.Fisher at rl.ac.uk>
Sent Wed 3/29/2006 11:34 AM
To infod-wg at ggf.org
Subject [infod-wg] Clarification

Hi,

Can somebody remind me please:

For each entity -e.g. create publisher we have the
PublisherDescription of type any. This is I preume for storing the
properties of the entity subject to the rules defined in the
corresponding vocab. So what is the CreatePropertyVocabularyInstance
doing? This is certainly in line with the property vocabs.

Why do we have both?

I have also noticed PublisherPolicy and PublisherProcess - do we
really need these in the base spec. They seem to be poorly defined at
the moment. If we need it can't it just be part of the property vocab?
and so not explicit in the specs?

Steve




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/infod-wg/attachments/20060403/7f5d96c4/attachment.html