[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Proposal to resolve info model issues
1) I am somewhat troubled by Associations and Classification not inheriting from ManagedObject. for example, I use associations to create a package of ManagedObjects, and by removing an association (deprecate, or delete), a ManagedObject can be removed from a package, but is NOT removed from the Registry. Therefore I am managing associations. It is an IntrinsicObject too, since associations are critical to the nature of a registry (if I am intrepreting this correctly). I have had concerns about the Contact, Organization, and Address classes not inheriting from ManagedObject too, since there are subject to versioning , but I am less concerned about those classes as I am about associations. the begging question is when I update address information, do I replace it or version it? ditto with contacts etc. 2) I am happy with modeling the concepts of extrinsic and intrinsic, versus debating whether we are modeling the repository. I believe there is no benefit adding a class for the ACTUAL content in a repository, since the metadata ABOUT the content is more than sufficient and should give me a "handle" to the actual object when I need it (to download, to parse, etc). I believe a classification is an extention of the metadata, further describing the ManagedObject. 3) I perceive there is still a conceptual difference between Classification Scheme and Classification. To me, a classification scheme is special ManagedObject that consists of classification nodes, and Classification is a special link between a ManagedObject and a classification scheme (e.g., linked to a specific node within the scheme). If we are trying to equate the two concepts, we need to explicitly state how classification accomplishes the representation of a scheme. I strongly believe as you try to clarify that, that you will see my point in issue #1. Regards, Scott -----Original Message----- From: Farrukh Najmi - JavaSoft East [mailto:Farrukh.Najmi@East.Sun.COM] Sent: Monday, December 04, 2000 12:10 PM To: ebxml-regrep@lists.ebxml.org Subject: Proposal to resolve info model issues Hi Team, Len and I have been working to get our ideas to fit together. Here is the our current thinking on the chanhes needed on the info model. Please see attached GIF file for reference: Based on Friday's discussion we had identified the need to model two types of Registry Content (as meta data). Note names were given today: 1. IntrinsicObject: Sub-class of ManagedObject that provides metadata on content that is known to the Registry 2. ExtrinsicObject: Sub-class of ManagedObject that provides metadata on content that is not knownn intrinsicaly to the Registry For dictionary definition of intrinsic and extrinsic see: http://www.webster.com/cgi-bin/dictionary Note that not all Registry content known to Registry is derived from IntrinsicObject since some have minimal metadata requirements and are derived from Object. Note that: -Object only has GUID attribute now. -major and mindor version are now in Versionable -ManagedObject has registryStatus, description and submission -ExtrinsicObject have url, name, type and mimeType -IntrinsicObject has no attributes identified so far Please note that this is a joint proposal by Len and I and naturally we are in agreement on this. There may be some details to iron out but there is a strong desire and ability for us to work as a team and get through these issues in teh next few week. Lets all work hard to make the Jan 12 drop dead deadline for all our Release 1 spec work to be submitted to QR so we can all be proud of what we have accomplished. -- Regards, Len and Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC