digir-protocol

[Digir-protocol] tModel values for schema differentiation

[Kevin W. <kf...@co...>]

--Concept--
Should the DiGIR community consider using multiple tModel values
to differentiate between provider sites offering alternate or
extended schema representations of provider data?

--Discussion--
As extensions to the Darwin Core schema proliferate within the DiGIR
provider community how are services based on alternate or extended
schemas supposed to differentiate themselves from strict DWC sites?
Should multiple schemas representing a provider data resource be
co-mingled?

Portal code, or more specifically the presentation layer of the portal
engine, separates provider resource lists based on the various conceptual
schemas returned by discovery requests. This may be confusing to the
portal user not knowing which data resources were available by schema.
Automatons can resort to filtering based on specific DiGIR-Resource
tags, but discovery or metadata requests risk overstated inventory
counts if numerous resource schemas mapped to a single data set are
'mixed' together.

Separate tModel values based on schema enforce a stronger provider
identity which can result in more specific WSDL entries.

Some may consider this a solution to a problem that doesn't exist,
while others may find that the separation of provider services based
on schema enhances the service.

Comments?



KFW

Re: [Digir-protocol] tModel values for schema differentiation

[Renato De G. <re...@cr...>]

Hi Kevin,

Even if we had separate tModels for each conceptual schema, it seems 
that there could be a problem for DiGIR networks to use that in UDDI. 
tModels are associated with a "bindingTemplate", or in other words, 
with a "real" service end point. And as you know, a DiGIR service can 
have several "resources" underneath, each one with potentially 
different conceptual schemas. So at this level, there's a granularity 
mismatch between DiGIR and UDDI, because your network might be 
interested only in a specific resource from a provider - not all of 
its resources - and UDDI will always return you service end points.

We tried to avoid that in TAPIR by "forcing" each data source (same 
as resource in the DiGIR jargon) to have its own access point. So in 
this case, I believe it will be safe to use such a tModel strategy.

Regards,
--
Renato

On 6 Dec 2005 at 13:39, Kevin Webb wrote:

> --Concept--
> Should the DiGIR community consider using multiple tModel values
> to differentiate between provider sites offering alternate or
> extended schema representations of provider data?
> 
> --Discussion--
> As extensions to the Darwin Core schema proliferate within the DiGIR
> provider community how are services based on alternate or extended
> schemas supposed to differentiate themselves from strict DWC sites?
> Should multiple schemas representing a provider data resource be
> co-mingled?
> 
> Portal code, or more specifically the presentation layer of the portal
> engine, separates provider resource lists based on the various
> conceptual schemas returned by discovery requests. This may be
> confusing to the portal user not knowing which data resources were
> available by schema. Automatons can resort to filtering based on
> specific DiGIR-Resource tags, but discovery or metadata requests risk
> overstated inventory counts if numerous resource schemas mapped to a
> single data set are 'mixed' together.
> 
> Separate tModel values based on schema enforce a stronger provider
> identity which can result in more specific WSDL entries.
> 
> Some may consider this a solution to a problem that doesn't exist,
> while others may find that the separation of provider services based
> on schema enhances the service.
> 
> Comments?
> 
> 
> 
> KFW

Re: [Digir-protocol] tModel values for schema differentiation

[Kevin W. <kf...@co...>]

Greetings Renato!

My thought was, and this might be a departure from DiGIR's operating
model, that provider sites be classified by schema, and that a particular
provider site would only offer resources based on a specific schema. If a
data set was to be provided via more than one schema representation
then there would be more than one provider, or service point, associated with
that data set.

I might be trying to solve a problem that doesn't justify the effort, and 
in fact
the only downside to mingling multiple schema representations that I can
identify is record inflation due to multiply-defined resources. Take for 
example
a data set containing 1,000,000 records. If I create a DiGIR provider resource
that 'provides' this data in a strict Darwin Core schema, and then I create 
a second
DiGIR provider resource that 'provides' this data using an extended schema, 
then
the metadata response for that DiGIR provider shows an aggregate of 2,000,000
records when in reality there is only one set of 1,000,000 records that exist.
Like I said earlier, this issue might not justify the effort.

Your comment about Tapir has caught my attention, as I have heard
references made to the project. Other than knowing the extension
of the acronym - TDWG Access Protocol for Information Retrieval,
I can't find any development resources on line for the project. Are there
any information or on-line resources that can be shared with respect
to this project?

Thank you.


KFW




At 09:04 AM 12/7/2005, Renato De Giovanni wrote:
>Hi Kevin,
>
>Even if we had separate tModels for each conceptual schema, it seems
>that there could be a problem for DiGIR networks to use that in UDDI.
>tModels are associated with a "bindingTemplate", or in other words,
>with a "real" service end point. And as you know, a DiGIR service can
>have several "resources" underneath, each one with potentially
>different conceptual schemas. So at this level, there's a granularity
>mismatch between DiGIR and UDDI, because your network might be
>interested only in a specific resource from a provider - not all of
>its resources - and UDDI will always return you service end points.
>
>We tried to avoid that in TAPIR by "forcing" each data source (same
>as resource in the DiGIR jargon) to have its own access point. So in
>this case, I believe it will be safe to use such a tModel strategy.
>
>Regards,
>--
>Renato
>
>On 6 Dec 2005 at 13:39, Kevin Webb wrote:
>
> > --Concept--
> > Should the DiGIR community consider using multiple tModel values
> > to differentiate between provider sites offering alternate or
> > extended schema representations of provider data?
> >
> > --Discussion--
> > As extensions to the Darwin Core schema proliferate within the DiGIR
> > provider community how are services based on alternate or extended
> > schemas supposed to differentiate themselves from strict DWC sites?
> > Should multiple schemas representing a provider data resource be
> > co-mingled?
> >
> > Portal code, or more specifically the presentation layer of the portal
> > engine, separates provider resource lists based on the various
> > conceptual schemas returned by discovery requests. This may be
> > confusing to the portal user not knowing which data resources were
> > available by schema. Automatons can resort to filtering based on
> > specific DiGIR-Resource tags, but discovery or metadata requests risk
> > overstated inventory counts if numerous resource schemas mapped to a
> > single data set are 'mixed' together.
> >
> > Separate tModel values based on schema enforce a stronger provider
> > identity which can result in more specific WSDL entries.
> >
> > Some may consider this a solution to a problem that doesn't exist,
> > while others may find that the separation of provider services based
> > on schema enhances the service.
> >
> > Comments?
> >
> >
> >
> > KFW
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>Digir-protocol mailing list
>Dig...@li...
>https://lists.sourceforge.net/lists/listinfo/digir-protocol

Re: [Digir-protocol] tModel values for schema differentiation

[Renato De G. <re...@cr...>]

Hi Kevin,

Computing the total number of records per provider can indeed be 
risky. The protocol doesn't even try to deal with that notion - DiGIR 
metadata responses only show the number of records by resource (one 
cannot tell whether two resources under the same provider share the 
same database and "root table", or not).

TAPIR still needs some polishing before its first "official" release 
and it doesn't have a specification yet. A good starting point to get 
more information is:

http://ww3.bgbm.org/protocolwiki/FrequentlyAskedQuestions

Best regards,
--
Renato

On 7 Dec 2005 at 9:42, Kevin Webb wrote:

> Greetings Renato!
> 
> My thought was, and this might be a departure from DiGIR's operating
> model, that provider sites be classified by schema, and that a
> particular provider site would only offer resources based on a
> specific schema. If a data set was to be provided via more than one
> schema representation then there would be more than one provider, or
> service point, associated with that data set.
> 
> I might be trying to solve a problem that doesn't justify the effort,
> and in fact the only downside to mingling multiple schema
> representations that I can identify is record inflation due to
> multiply-defined resources. Take for example a data set containing
> 1,000,000 records. If I create a DiGIR provider resource that
> 'provides' this data in a strict Darwin Core schema, and then I create
> a second DiGIR provider resource that 'provides' this data using an
> extended schema, then the metadata response for that DiGIR provider
> shows an aggregate of 2,000,000 records when in reality there is only
> one set of 1,000,000 records that exist. Like I said earlier, this
> issue might not justify the effort.
> 
> Your comment about Tapir has caught my attention, as I have heard
> references made to the project. Other than knowing the extension of
> the acronym - TDWG Access Protocol for Information Retrieval, I can't
> find any development resources on line for the project. Are there any
> information or on-line resources that can be shared with respect to
> this project?
> 
> Thank you.
> 
> 
> KFW