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