[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Thoughts on Classification support in RS
hi len, thanks for the links and the information. i attempted to connect to the last two links listed in your message: ... and with a couple of example submission packages in ftp://xsun.sdct.itl.nist.gov/regrep/OasisEntityPkg.txt and ftp://xsun.sdct.itl.nist.gov/regrep/OasisElementPkg.txt . and i get the following error from an IE5 browser. any advice would be appreciated. The XML page cannot be displayed Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later. ---------------------------------------------------------------------------- ---- An XML element is not allowed inside a DTD. Line 1, Position 1 <HTML> ^ thanks, joel munter -----Original Message----- From: Len Gallagher [mailto:LGallagher@nist.gov] Sent: Friday, September 15, 2000 2:29 PM To: ebxml repository Subject: Re: Thoughts on Classification support in RS ebXML regrep folks, I just joined the regrep email list this morning, so this is my first communication with the list. Hello! I'm working with Lisa Carnahan at NIST and have been active in helping to develop the OASIS regrep specification. I'm interested in the topic of Classifications and Classification Schemes, so invite you to take a peek at what the OASIS Registry/Repository specification does to support definition and representation of a wide variety of different types of classification schemes. All of the following are important considerations: - A Registered Object may point to an arbitrary number of Classification Schemes and provide various Classifications for that object based on one or more values taken from each Classification Scheme. - The notion of Classification Scheme is general enough to capture any of the following types of information content: simple domain sets, named classification hierarchies, coded classification hierarchies, subset classifications, prioritized lists, user-provided content, etc. See examples on pages 18-22 of ftp://xsun.sdct.itl.nist.gov/regrep/OasisModel.pdf - Each referenced Classification Scheme is itself a registered object, so it is not necessary for the Classification of another registered object to re-define the structure and semantics of a classification scheme each time one is referenced. A single coded value may provide a host of classification information, that can be cut many different ways for different kinds of accessibility. - The relationships among RegisteredObjects, Classifications, and ClassificationSchemes can be represented by a small number of static structures, all represented by a relatively simple UML Class diagram. See page 15 of ftp://xsun.sdct.itl.nist.gov/regrep/OasisModel.pdf Since the structures are static, they could be queried quite easily. - Simple XML is sufficient for the definition and representation of quite sophisticated classification schemes. See pages 24 and 30 of ftp://xsun.sdct.itl.nist.gov/regrep/OasisXML.pdf - Simple XML is sufficient to represent the various Classifications of a registered object. See pages 10-11 of ftp://xsun.sdct.itl.nist.gov/regrep/OasisXML.pdf If you take a closer look at the overall Information Model for the Oasis Registry/Repository ftp://xsun.sdct.itl.nist.gov/regrep/OasisModel.pdf you'll see an attempt at simple structures with flexible content. Thus the entire Registry can be represented in UML by a small number of static structures and relationships (pages 13-16). The flexible content allows registration of many different kinds of registerable objects (e.g. ebXML Profiles, TPA's, business processes, core components, etc) in a single registry, with a complete history of who added what content and when, whereas the static structure allows a simple interface for query and maintenance of the Registry itself. In particular see the XML interface proposed by the Request Elements section of ftp://xsun.sdct.itl.nist.gov/regrep/OasisXML.pdf with the important Submission DTD extracted as ftp://xsun.sdct.itl.nist.gov/regrep/Submission.txt and with a couple of example submission packages in ftp://xsun.sdct.itl.nist.gov/regrep/OasisEntityPkg.txt and ftp://xsun.sdct.itl.nist.gov/regrep/OasisElementPkg.txt . Sincerely, Len Gallagher >>Date: Thu, 14 Sep 2000 08:55:11 -0400 >>From: Farrukh Najmi <Farrukh.Najmi@east.sun.com> >>Subject: Thoughts on Classification support in RS >>To: ebxml repository <ebxml-regrep@lists.ebxml.org> >>Organization: Java Software East >>X-Mailer: Mozilla 4.7 [en] (WinNT; I) >>X-Accept-Language: en >>List-Owner: <mailto:ebxml-regrep-help@lists.ebxml.org> >>List-Post: <mailto:ebxml-regrep@lists.ebxml.org> >>List-Subscribe: <mailto:ebxml-regrep-request@lists.ebxml.org?body=subscribe> >>List-Unsubscribe: >><mailto:ebxml-regrep-request@lists.ebxml.org?body=unsubscribe> >>List-Archive: <http://lists.ebxml.org/archives/ebxml-regrep> >>List-Help: <http://lists.ebxml.org/doc/email-manage.html>, >> <mailto:ebxml-regrep-request@lists.ebxml.org?body=help> >> >> >>I have spent the last few days think through the classification support >>issue that was identified as a major hole in RS v0.4 by >>the team. I have been educating myslef by talking to numerous people and >>have gotten excellent feedback and ideas from Bob Haugen from BP, Chris >>Ferris from TP, Yutaka Yoshida from RR and others. I have spent the >>yesterday and most of last night studying >>David's proposal for classification support. This note is a brain dump >>of my current thinking based on what I have learned. >> >>The good news is that the team has rallied to Scott's call for action in >>the last meeting. I am very appreciative of the hard work David put in >>on the issue. >> >>The bad news is that IMHO, we are quite far from meeting the >>requirements as I understand them based on the current proposal (CP). >>So let me start with requirements and then identify where we have holes. >>I will then follow up with some very specific recommendations on how to >>meet the requirements. >> >>Requirements >>========= >> >>General Requirements >>---------------------- >>o Need tight alignment with BP, CC, TP meta-model work >>o Need all access to objects and to RS to be over ebXML TRP >> >>Object MetaData Requirements >>-------------------------------- >>o Need to associate meta-data attributes with objects. Such attributes >>may be specialized based on the type of object >> >> >>Classification Requirements >>--------------------------- >>o Need to classify objects on multiple dimensions >>o Need to allow an extensible user defined classifications on an Object >>o Need to define any number of associations between objects >>o Classification scheme mechanism should be general enough that >>classification can be provided by project team in the same manner as >>user defined (or industry defined) classification schemes. >>o Need to support standard coded schemes >> >> >>Query Requirements >>--------------------- >>o Need to support conjugation (AND, OR, NOT) of simple predicates into >>complex predicates. E.g. Find all Parties that sell computers AND are >>located in the Boston area >>o Need to support inheritance in classification schemes. E.g. Find all >>parties that sell automobiles should find all parties that sell cars or >>trucks if there is an inheritance relatioship between automobile, car >>and truck >>o Need to support range of values in a concept. E.g. Response time is >>BETWEEN 0 AND 6 hours >>o Need to support membership in a set. E.g. Find all parties that sell >>o Need to support sorting. E.g. Find all parties that sell Digital >>Cameras and list them sorted by their customer satisfaction rating >>o Need to support comparison operators. E.g. Find all suppliers of >>CoolPix990 where the price is < 830. >>o Need to support aggregate expersion (MIN, MAX, Average, SUM) etc. for >>cheapest price, longest warranty etc., better than average performance >> >>Issues With Current Proposal >>==================== >> >>I first started listing which requirements where *not* being met by CP. >>When it seemed like they were unfortunately a large >>list I decide to invert things and list which requirements from above >>*ARE* being met: >> >>The following requirements do seem to be met in CP. >> >>-Need to associate meta-data attributes with objects. >>-Need to support standard coded schemes >> >>The following general issues were observed: >> >>-Specific technology is being recommended (e.g. WebDav/DASL). This is >>not consistent with ebXML vision and purpose >> >>Please forgive me if I have misinterpretted anything or missed any other >>requirement that is being met. Reading through >>a 26 page document can have its limitations. All in all I feel that this >>proposal is too far off the mark. Please understand that I have been >>very objective and fair. I do not just want to find nits in hard work >>put in by my esteemed team-mates. I would like to humbly recommend some >>alternatives we should consider that will make us meet the requirements. >> >>Recommended Approach >>================= >> >>Registry Information Model >>---------------------------- >> >>The registry information model defines: >> >>o How managed objects are organized in the Registry >>o Is based on ebXML meta-models from various working groups >>o Provides a basis for relational or object schemas for an RS >>implementation >> >>Managed Objects >>------------------ >>o Define some built-in types of ManagedObjects based on WG meta-models >>(e.g. TPA, TPAElement, Schema, SchemaElement, BusinessProcess etc.) >>o It should be possible to have any number user defined managed objects >>that are of the generic ManagedObject type. >>o A built-in object type may provide methods for supported associations >>(e.g. A TPA may provide a method to get its Parties), that can be used >>in queries. >>o Each identified managed object typedefines its own unique meta-dat >>attributes as well inherits such attributes from its super class in the >>meta-model. >>o RS supports queries on these attributes defined for managed objects. >> >>Associations Between Managed Object >>----------------------------------------- >>A managed object may be associated with 0 or more managed objects. >> >>An association has the following attributes: >>o An association has name >>o An association has a type >>o An association may be directed or may be bi-directional. >> >>Classification By Concepts >>--------------------------- >>A concept is the basis for a classification scheme: >> >>A Concept is: >>o Are ManagedObjects >>o Have an id (code) >>o Have a name >>o Support inheritance >>o Support containment >>o Support associations >>o Support collections >> >>Classification Scheme Support >>------------------------------- >>o Objects are classified by their having an Association with a Concept >>o An Object can be classified in multiple dimensions by having multiple >>associations with multiple concepts >> >>Query Support >>========== >> >>Much more on this later. Running out of time but suffice to say it will >>address all the query requirements. >>Forgive the typing errors. My final recommendation is that I put the >>above ideas down in more detail and clarity >>for your review by next week. >> >>Lets talk about this in the meeting. >> >>-- >>Regards >>Farrukh ************************************************************** Len Gallagher LGallagher@nist.gov NIST Work: 301-975-3251 Bldg 820 Room 562 Home: 301-424-1928 Gaithersburg, MD 20899-8970 USA Fax: 301-948-6213 **************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC