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

 


Help: OASIS Mailing Lists Help | MarkMail Help

rights-specification message

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


Subject: RE: [rights-specification] CR00002


Title: RE: [rights-specification] CR00002

More excellent info from Eve:

Of course, you're absolutely right that some kind of "locking-down" is
needed in order to know which meaning of a code is intended.  Note that
UBL layers itself on top of the ebXML Core Components, in which the
Code.Type core component type has been assigned version (and other)
metadata for the purpose of semantic clarity of a code.  Thus, UBL just
borrows the entire notion of semantic clarity from ebXML, and doesn't
dictate the form of the version information -- so I can't give you an
"official UBL answer" here.  But I can give suggestions.

What's ideal is for you to get guidance from the ISO code list owners
themselves about how to refer uniquely to the desired code lists using
the standard metadata.  If they had supplied you with a ready-made
schema for country codes, as UBL is suggesting they do, they would have
indicated the expected version values, and might have provided
additional metadata fields for you to use as well.

(I suspect that the ebXML folks haven't gone quite far enough in
specifying/advising on the proper usage of version information.  I will
pass along this observation.  BTW, may I forward this email exchange to
the ubl-comment list for their perusal as well?)

In the meantime, I would suggest that you provide as much metadata as
you think is necessary for clarity (including, for example, introduction
dates if you think it's appropriate), and that you also try to use the
canonical version field to match some approximation of a version, such
as "V-5".  Your usage of this field should be documented in some
fashion.  In other words, until you can get the code list owner to solve
this problem for you, you'll need to solve it for yourself.

        Eve

DeMartini, Thomas wrote:
>         What follows is some idea of the history, to see where they are
> coming from:
>
> --
>
> XrML 2.0 had a simple type with an enumeration of country codes, a
> snap-shot of the codes at one point in time.  Concern was raised that
> this made the schema too big and didn't provide any value-add and wasn't
> consistent with MPEG-7 way of defining country codes.
>
> Thus, XrML 2.1 adopted the MPEG-7 way of defining country codes: having
> a simple type with a restriction specifying the format of the string
> (two/three characters, letters/numbers, etc.).  Concern was raised that
> this did not account for codes like "AI" which "represented 'French
> Affars and Issas' (today Djibouti) in ISO 3166-1 until 1977, [and] was
> [later] reused for Anguilla."  This is a problem when rights expressions
> lie around for 50 years or so and the meaning of their territory changes
> because of this.
>
> Thus, the need for a versioning scheme was identified.  MPEG did some
> research leading up to the CR00002 that was submitted.  The following
> things were discovered:
>
> --
>
> Q. Will ISO reuse codes again in the future?
> A. "The ISO 3166/MA can and will make use of this possibility of
> reassignment if no other reasonable solution can be found."  and "During
> a transitory period of at least five years after the withdrawal the code
> elements will not be reassigned to different country names."
>
> --
>
> Q. How can one reference a particular meaning of an ISO code?
> A. "Yes that's a problem, ISO 3166-1 is being updated continually. So
> the list that is valid now is not the one given in the fifth edition of
> ISO 3166-1 from 1997. This does not mean however, that the basic
> document is reissued and reprinted. Standards are revised normally every
> five years. ISO 3166-1 will be revised by a standards committee starting
> this year. That means that the rules under which the standard operates
> are revised if necessary and that an up-to-date list of country codes
> will be included in the standard.
>
> In order to identify the status of your list of codes you can say
> something like: ISO 3166-1:1997 plus ISO 3166-1 Newsletters up to and
> including No. V-5 (NB: The V in the Newsletter numbers means fifth
> edition). That says that your basic list is from the 1997 edition and
> you have included all Newsletter since then."
>
> Thus, it seems that V-5 is not actually a version number so much as a
> newsletter number.  Perhaps it could be used as a version number, but is
> that the intent?  Is this the version number that UBL uses, or is the
> version number there a version number assigned by the person writing the
> schema?
>
> --
>
> Concern was also raised about implementations being forward compatible. 
> For instance, if I have an implementation written in 1977 that
> recognizes "US" as "United States" and "AI" as "French Affars and Issas"
> and I encounter a license written in 1987 with code "US", how do I know
> that the meaning of that code hasn't changed and that I can go ahead and
> process it, whereas I cannot process "AI"?  Thus, the idea was to use
> the date of introduction so, in 1987, "US" would still have an
> introduction date of 1977 and be recognizable to the 1977
> implementation, whereas "AI" introdate 1987 wouldn't be.
>
> Maybe it is hard to look up the introduction date, though, as I seem
> only to be able to find the latest version.
>
> --
>
> So I guess there are two questions: do we use date or version?  If we
> use date, do we use date or introductionDate?  If we use version, do we
> use version or introductionVersion?

-----Original Message-----
From: Krishna Sankar [mailto:ksankar@cisco.com]
Sent: Thursday, August 29, 2002 7:28 PM
To: 'Rights-Specification (E-mail)'
Cc: eve.maler@sun.com
Subject: [rights-specification] CR00002


Hi,

        Here is Eve Maler's excellent summary (as usual).

Tom/Hari, can you invite Eve for our next spec con call ? The only
problem could be that, next spec call succeeds the general body call and
so we might not be able to fix a time. But a con call discussion with
Eve would be the next POA on CR000000002.

cheers

-----Original Message-----
From: Eve L. Maler [mailto:eve.maler@sun.com]
Sent: Thursday, August 29, 2002 8:20 AM
To: Krishna Sankar
Subject: Re: Hi


Hi Krishna,

Nice to hear from you!  I'll try to answer your questions/issues very
briefly here, but it might be easiest to join your telecon and do a
better job of it interactively.  (I assume you mean Wednesday September
4 at 2pm PT/5pm ET?  I can be free then.)  A few notes below:

Krishna Sankar wrote:
> Eve,
>
>       Long time no see. Heard that you did a good job with the forum
> panel.
>
>       Anyway, we, in the Rights Language TC have a change request
> which I think you could solve ! We read thru your UBL Code List rules
> specification.
>
>       Let me start at the beginning. We have a Change Request from
> MPEG on country codes (attached) which occasionally change and
sometimes
> the codes are reused :o( So we are exploring schemes that capture some
> related metadata to make the country code unique. We are looking at
ISO
> and the UBL Code List specification.
>
>       Have a few questions on the UBL :
>
>       What does an Agency stand for ? From what I know, it would be
> things line UNSPC for prod codes. I assume the utility of an agency is
> when there are multiple organizations defining things in a domain.

Typically in real deployments, the agency ID is a code, which itself
should theoretically need its own second-order code metadata to be
uniquely identified.  We haven't solved this yet because the easiest way

would be to get the ebXML Core Components folks to recognize this.

>       In the XrML domain, version is not possible but a date could be
> used. Do you see a use for it in the general specs ?

If you're using an ISO code list, it does have a version.  A date could
also serve as the version for the whole code list.  From the document
you forwarded, it appears the date is desired for individual codes,
which I'm not familiar with.  From my understanding,
backwards-incompatible changes in real (commercially managed) code lists

are extremely rare, so I'm not sure what's going on here.  I think I
need to know more, but in short, our recommendations don't prevent
anyone from adding *more* metadata if they wish -- but the version is
required.

>       Is there a schema ? Or is the UBL Code List document a
> recommendation/best practice ?

The document is a recommendation for how to *create* schemas for code
lists used in a certain fashion, so in a sense it's a meta-schema.  It's

normative for any UBL-native code lists, but merely a recommended best
practice for others.  If XrML uses a particular official code list, for
example, ideally you'd want to simply import the code list schema module

that the owner (ISO or UN/ECE or UCC or whoever) created.

>       Do you have a namespace for this ?

Each code list module would have its own namespace.

>       If we want to use this, do you expect us to extend it ? For
> example chuck the version and add a date element.

If you're following the recommendations and want to achieve true
semantic clarity according to the ebXML Core Components ontology, you
need version.  But you could add date.

>       I had suggested to the group to see if you would be available
> for a con call Wed 2:00 PST. I think we could use your information
> modeling skills and get some direction on this. (You are welcome to
> attend our f2f in Cisco September 11,12,13!)

Sorry, can't attend the F2F!  But could join the call if I'm right about

the date.

Best,

        Eve

--
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



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


Powered by eList eXpress LLC