Re: [regrep-cc-review] Issue #3: P.12 Example in the Registy

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<Quote1>
>QUESTION: Do we need 2 new Association Types here - "ExtendedFrom" and
>"RestrictedFrom"? Or just simply one Association Type named
>"DerivedFrom?" If so, should we handle this the same as W3C Schema? > That is, an extension would contain only the additional BCCs, and a
>restriction would contain the BCCs from the "base" ACC that are being
>carried over.
>  
>
mm1: I would prefer Association type.
</Quote1>

Did you mean 1 Association Type or 2?

Joe

<Quote2>
mm1: Joe, as I was in an offsite on Thursday.  Did the team agree to 
OfficeAddress. Details as an ACC?
Thanks.
<Quote2>

Yes - we believe it should be considered an ACC rather than an ABIE, for
several reasons:

(1) We do not see any connection between "Office" and any of the 8
context categories

(2) Even if we did, we believe registry users *must* have the ability to
quantify ACCs using terms that do not fall under one of the 8 context
categories (we would be doing our users/implementers a great disservice
if we did not)

(3) Furthermore regarding classification schemes and qualifiers: We
believe that it would be highly inefficient to force users to create a
classification scheme each time type wanted to qualify an ACC. Using the
"OfficeAddress. Details" example, a registy user should not be forced to
create a classification scheme with 2 nodes - "Office" and "Home" - just
to create the "OfficeAddress. Details" ACC from the "Address. Details"
ACC. 

It is also likely that a user may want to simply quantify "Address.
Details" as a "one-time" case - that is, with an "Office" qualifier and
without giving the registry any knowledge of a "Home" qualifier. Thus, a
user should be able to simply add the qualifier "Office" through a
registy interface without having to create a classification scheme
consisting of only one node.

Joe


Monica Martin wrote:
> 
> Chiusano Joseph wrote:
> 
> >Team,
> >
> >Here is the next issue from the 8/21 Registry TC review. It relates to
> >the CCTS spec p.12 example:
> >
> >In the example, it is assumed that the "Address. Details" ACC is not
> >directly joined to the "Person. Details" ACC; rather, there is an
> >"intermediary term" ("Residence" or "OfficialAddress") that "linls" the
> >2 ACCs together. The CCTS spec calls these Association Core Components
> >(ASCCs).
> >
> >We are not planning to store ASCCs as Core Components as defined in the
> >CCTS spec; rather, we are planning to represent them as Associations.
> >Having said that: There are multiple ways to construct this example in
> >the registry. Here is the approach we have been referencing in our
> >discussions - please review it *carefully* and *pick it apart* step by
> >step, word by word. It's critical that we have agreement on this
> >approach. I will cite clarifications that we've already had in the
> >recent past from the CCTS Team as necessary.
> >
> >*** Please note that if there is not sufficient enough feedback on this
> >issue by 9/5/03, we will proceed in our Technical Note in the manner
> >described below. ***
> >
> >We will consider "Address. Details" a "base" ACC, from which other ACCs
> >(e.g. "ResidenceAddress. Details") as "derived" ACCs.
> >
> >Consider the following steps (I've inserted some questions along the
> >way):
> >
> >1. Create BCCs for "Address. Details" ACC (Street, etc.)
> >
> >2. Create the "Address. Details" ACC - use Associations between each BCC
> >and the ACC
> >
> >3. Create BCCs for "Person. Details" ACC (Name, etc.)
> >
> >4. Create the "Person. Details" ACC - use Associations between each BCC
> >and the ACC
> >
> >(Now we create "derived" ACCs from "Address. Details")
> >
> >5. Create a new BCC called "MailStop" - it will be used for the
> >"OfficeAddress. Details" ACC below
> >
> >6. Create the "OfficeAddress. Details" ACC - use the "Address. Details"
> >ACC as a basis, and *extend or restrict it*; use Associations between
> >the "OfficeAddress. Details" ACC and the "Address. Details" ACC
> >
> >QUESTION: Do we need 2 new Association Types here - "ExtendedFrom" and
> >"RestrictedFrom"? Or just simply one Association Type named
> >"DerivedFrom?" If so, should we handle this the same as W3C Schema? That
> >is, an extension would contain only the additional BCCs, and a
> >restriction would contain the BCCs from the "base" ACC that are being
> >carried over.
> >
> >
> mm1: I would prefer Association type.
> 
> >QUESTION: Should the Association be between "OfficeAddress. Details"
> >and "Address. Details" only? Or, should there also be an Association
> >between "OfficeAddress. Details" and "Person. Details", so that an
> >"assembler" does not have to route through "Address. Details" to
> >assemble together "Person. Details" and "OfficeAddress. Details"?
> >
> >Now, suppose that a change takes place to the "Address. Details" ACC - a
> >BCC's name is changed. If an implementation allows, that change can
> >propagate to all derived ACCs.
> >
> >
> mm1: Joe, as I was in an offsite on Thursday.  Did the team agree to
> OfficeAddress. Details as an ACC?
> Thanks.
> 
> >That's all...
> >
> >Joe
> >
> >You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php
> >
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard