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