FW: Core component catalogue V1.0 comments

[John McClure <hypergrove@olympus.net>]

This list confuses sub-types and properties, or I am mightily confused
reading your list. Address is not a subtype of Party. For a breakdown of a
Party into sub-types, I encourage you to review our dictionary, under the
"Actor" resource-type. I considered using "Party" at one time, but rejected
it for lots of reasons. Actors always play roles, don't they.
John
Hypergrove Engineering
211 Taylor Street, Suite 32-A
Port Townsend, WA 98368
360-379-3838 (land)
360-301-1102 (cell)

For a discussion group about the Data Consortium Namespace, please
http://groups.yahoo.com/group/DCNArchitecture/join

For the latest Data Consortium Namespace Specification, please see
http://www.dataconsortium.org/namespace/DCN150.DTD.pdf or
http://www.dataconsortium.org/namespace/DCN150.DTD.doc or
http://www.dataconsortium.org/namespace/DCN150.DTD.htm

For the latest Data Consortium Dictionary, please see
http://www.dataconsortium.org/namespace/DCD100.pdf or
http://www.dataconsortium.org/namespace/DCD100.xml (IE5)


> -----Original Message-----
> From: Martin Bryan [mailto:mtbryan@sgml.u-net.com]
> Sent: Thursday, March 15, 2001 8:48 AM
> To: Mike Conroy; ebXML Core
> Cc: F.De_Vos@mail.eurofer.be
> Subject: Re: Core component catalogue V1.0 comments
>
>
> As part of an analysis of the Party definition while preparing a
> comment on
> the ebXML Core Component work for the CEN/ISSS Defining and Managing
> Semantics and Datatypes working group I came to a similar
> conclusion to Mike
> Conroy about the need to split out information relevant to people (who I
> have chosen to call Persons) from those relevant to enterprises (which I
> have chosen to call Organizations). Being simple-minded, and having to aim
> my document at managers, I did not formally model my definitions, but
> instead defined a simple classification hierarchy for the definition of
> parties, as follows:
>
> Party
>    Person
>        FamilyName
>        GivenName
>             Initial
>        MiddleName
>             Initial
>        Title
>        Gender
>        Nationality
>        BirthDate
>        TaxIdentifier
>    Organization
>        Name
>        IncorporationDate
>        TaxIdentifier
>    PostalAddress
>         Building
>              Name
>              Identifier
>              Suite
>              Floor
>              MailDeliveryPoint
>         Street
>              Lot
>              Block
>         District
>         Town
>         State
>             Region
>             County
>         PostCode
>         Country
>         POBox
>         UnstructuredLine
>    Location
>         Identifier
>         Type
>         Description
>         Position
>         WhenAvailable
>            Date
>            Time
>                ZoneOffset
>         Sequence
>    CommunicationDetails
>         Environment
>             WhenAvailable
>               Date
>               Time
>                   ZoneOffset
>         Mode
>             SecurityInformation
>         Number
>              CountryCode
>              AreaCode
>              SubscriberNumber
>              Extension
>    Account
>         Identifier
>         Name
>             Nickname
>         Servicer
>              Type
>              InterestRate
>              Charge
>         Owner
>         Country
>         Currency
>         CardExpiry
>               Date
>    Language
>         Code
>         Purpose
>    FreeTextDescription
>
> Hopefully you will find this as easier to understand than the
> spreadsheet or
> formal models used to date to describe the relationships between the
> information that needs to be recorded about a party. It should
> also be noted
> that such a tree represents a hierarchy that can easily be
> recorded in XML.
>
> Martin Bryan
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>