[infod-wg] discussion around 'description' field and entity managers
Stephen Davey
sdavey at nesc.ac.uk
Mon Apr 3 10:45:37 CDT 2006
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
More information about the infod-wg
mailing list