OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

egov-registry message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [egov-registry] eGov regrep


Farrukh,

That's correct (or will be once Maewyn has reviewed it). The document is
mis-named because originally I was looking at the mapping as well, but you
and Duane had offered to do that.

Duane has replied to me on his views on mapping. He also seems to be in
favour of (b), and I am leaning more that way after some extensive reading.
I suggest we go with that.

Duane sent me two documents: the "Recommendation for placement of CPSIN IJI
Data Dictionary Data Elements into an ebXML / ISO-IEC 11179 Metadata
Facility", which he has already circulated to the eGov group and another
document that I don't know whether we can publish or not. Duane - if it is
publishable, could you send it to the list? Duane is also working on
serialising metadata. Ultimately, we will need to support various
serialisations, for example the eGMS has a serialisation method, as does
Dublin Core.

This was his comment:

====
When you examine most use cases for what people need to do with the
metadata, a simple RIM binding will not suffice.  If I am using a piece
of Metadata (perhaps a schema fragment) in a way that it is dynamically
linked to from another schema (using xs:import), I cannot presume that
all users will have ebXML Registry client software installed to properly
resolve the RIM data that is serialized and returned via instances
constrained by the RSS.  Furthermore, I may require some sort of
persistence at the client who is doing many activities (modelling,
validation, transactional state management, etc..)   This requires that
any metadata must be a self contained serialization of the registry object.

The attached two document outline our approach so far to this problem.
 I urge you to consider this as the basis for a solution since it is
also the easiest to understand and takes into account forwards
compatibility and future, unknown requirements.  The way the XML is
designed, users can add other things later to the XML schema constrained
instances that capture the metadata without breaking existing
implementations. To me, that use case alone validates the approach since
it would be arrogant of us to think we are looking at the complete
problem today.

Most of the XML is designed like this...

<!--properties of the metadata object as asserted by one agency.  Other
agencies are free to make other assertions.-->
<Properties assertedBy="PaulSpencer">
    <Property  name="myProperty" value="myValue"
qualifier="ifNeededCanGoHere"/>
    ...
    <!--repeat as necessary.  If a new one is added, it will NOT BREAK
any implementations-->

etc...
====

Regards

Paul

> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
> Sent: 11 June 2004 16:28
> To: Paul Spencer
> Cc: Egov-Registry
> Subject: Re: [egov-registry] eGov regrep
>
>
> Paul Spencer wrote:
>
> >Maewyn,
> >
> >One thing we need to do for the registry pilot is to look at how
> to map the
> >metadata that will be stored in the registry. I have looked at
> what I think
> >we need to support, both in the proof of concept and the longer term. The
> >attached describes this just for the e-GMS metadata set. Farrukh
> will then
> >look at mapping this to the Registry Information Model.
> >
> >
> Hi Paul,
>
> As I understand it the document you posted identifies the subset of
> e-GMS data for us to focus on within the POC.
> Thanks for getting this step done. The mapping step requires us to
> decide between:
>
> a) mapping directly to ebRIM (probably ClassificationScheme) or
>
> b) mapping to CCTS and then using CCRIM to map to ebRIM
>
> As I understand based upon our email discussion, Carl is in favor of
> (b), you maybe in favor of (a), I am unsure yet but leaning towards (b)
> and we are waiting on Duane to weigh in on the mapping decision.
>
> If we do (a) then I volunteer to map to ebRIM
> If we do (b) then I believe Carl has volunteered to do mapping to CCTS.
>
> Can we get closure on the choice between mapping approach (a) and (b) in
> this thread?
>
> I can provie a sample direct ebRIM mapping for one term (say Audience)
> by tomorrow if it helps people decide between (a) and (b). Carl could
> you do same for mapping Audience to CCTS? Does this tactical step make
> sense?
>
> Thanks.
>
> --
> Regards,
> Farrukh
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]