1 / 21

Supporting Complete Reference Data Life Cycle

Supporting Complete Reference Data Life Cycle. David Price July 2007. Agenda. RD Life Cycle Issues, Goals and Practices Protege Repository Capabilities The development approach The OASIS publication approach. RD Life Cycle Issues. RD Ontology and Class life cycle has

kasimir-sullivan
Download Presentation

Supporting Complete Reference Data Life Cycle

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Supporting Complete Reference Data Life Cycle David Price July 2007

  2. Agenda • RD Life Cycle Issues, Goals and Practices • Protege Repository Capabilities • The development approach • The OASIS publication approach

  3. RD Life Cycle Issues • RD Ontology and Class life cycle has • Stages : Developer Draft, Committee Draft, Public Review Draft, Committee Specification • Versions : 1, 2, … • Collaborative RD development is necessary but • OWL tools do not yet address complete life cycle • Sourceforge DEXLib host collaboration is CVS/file-based • Approaching first OASIS ballot and registration

  4. Goals of Development Approach • Remove as many error-prone actions as possible • limit cut and paste between OWL files • limit URI and OWL import changes • Enable more that one ballot at a time • Support “post-registration of V1” environment • Deal with two kinds of post-registration customers • Those who always want the latest-and-greatest RD • Those who want to use specific versions of the RD

  5. Better practices • Keep RD identifiers (URI) stable over their life • Use Protégé and related tool capabilities to limit cut and paste errors • Give everyone better view of big picture once Version 1 published • V 1 is the basis for development, not other personal developer files • Allow industry users to test committee-draft and public-review-draft without breaking their current environments

  6. Protégé 3.2.1 and newer Repositories • New concept of “Ontology Repository” • List of repositories under user control • List searched in user-defined order • can be set as read-only • can be local folder/file or on Web (HTTP) • are specific to a Protégé Project (so David’s set of repositories can be different from Rob’s) • “Same” ontology (same URI) can be in every Repository, Protégé uses the first on it find • When user changes repository list, ontologies are “reloaded”

  7. Repositories and RD Development • An “Ontology Repository” is a relative folder under dexlib/data/refdata • Can pull “Committee Specification” or better RD off the Web if desired though • Can also pull other reusable RD OWL ontologies off the Web • From earlier life cycle repositories, more stable repositories are read-only • From developer-draft, committee-draft and public-review-draft and committee-specification are read-only • From public-review-draft, committee-specification is read-only • Users control order of repositories for search, for example • developer-draft first, then committee-specification • developer-draft first, then public-review-draft, then committee-specification • public-review-draft first, then committee-specification

  8. Select OWL – Ontology Repositories

  9. Repository Manager Controls Add Repository To List (plus) Remove From List (minus) Move Up/Down List (arrow) Read-Only Flag

  10. What’s In Each Repository? Yes, Standard RD is in more than one place. That’s good for developers! They can choose to see “as-is” or “to-be” by changing order in Repository list developer-draft David Work Standard RD Standard RD committee-draft Standard RD public-review-draft Dublin Core PLCS EXPRESS committee-specification Standard RD

  11. “Standard RD” is in every folder! • committee-specification, public-review-draft and committee-draft folders are all treated similarly • All classes defined in plcs-std-rdl ontology • When “approved for next stage” entire plcs-std-rdl ontology is simply copied over to next folder • Note that the annotation properties for the classes are reset everywhere when this happens • See next slides for more details on each folder

  12. “committee-specification” Repository • Committee Specification Standard RD in plcs-std-rdl • Does not read from earlier life cycle folders • Other repositories read Dublin Core and PLCS EXPRESS read-only from here • Dublin Core in two OWL files: elements and terms • PLCS EXPRESS in one OWL file • Into committee-specification = copy and replace of entire file from public-review-draft or merge of several ballots, “expert user” should perform this action • Out of committee-specification = plcs-std-rdl copied over to OASIS Web site for public availability, so an “expert user” action • See later slide on OASIS PLCS RD availability

  13. “public-review-draft” Repository • committee-specification plus public-review-draft Standard RD in plcs-std-rdl • Does not contain any other files • If required, more than one public-review-draft-<id> folder could be created to manage multiple ballots • Examples: public-review-draft-2007, public-review-draft-organization, public-review-draft-TLSS • If this happens, then manual merge before copy into committee-specification folder is required • Into public-review-draft = copy and replace of entire file from committee-draft, still “expert user” should perform this action • Out of public-review-draft = upon ballot issue resolution, entire finalized plcs-std-rdl file is copied to committee-specification Repository, an “expert user” action

  14. “committee-draft” Repository • committee-specification plus public-review-draft plus committee-draft Standard RD in plcs-std-rdl • Does not contain any other files • Into committee-draft = cut and paste from developer-draft, so an “expert user” should perform this action • Out of committee-draft = when ready for ballot, entire finalized plcs-std-rdl file is copied over to public-review-draft folder, “expert user” action

  15. “developer-draft” Repository • committee-specification plus public-review-draft plus committee-draft plus “ready to share” Standard RD in plcs-std-rdl • Individual developments in plcs-rdl-<user> files contain “not ready to share” classes • As an alternative, users could keep individual files local and private only putting “ready to share” on DEXLib • When “ready to share”, classes are cut and paste into developer-draft plcs-std-rdl, “normal user” action • Alternatively, if CVS clashes are an issue then “expert user” action or normal users could announce and agree when “ready to share” happens

  16. dpe std std std std Normal DEXLib RD Cycle public- review-draft committee-draft committee- specification developer-draft 1 : Create new class in dpe 3 : When RD set ready, set stage=CD, copy file to c-d Pump: Ver1, Rev0, Stage=CD Pump: Ver1, Stage=CS Pump: Ver1, Rev0, Stage=PRD Pump 4 : When RD set ready, set stage=PRD, copy file to p-r-d, empty c-d std file, update d-d std file stages 5 : When RD set ready, set stage=CS, copy file to c-s, empty p-r-d std file, update d-d std file stages 2 : Move class to std to share, set ver, stage, rev 6 : Delete revision in CS Pump: Ver1, Rev0, Stage=DD

  17. std std Revisions in DEXLib RD Cycle committee-draft public- review-draft Pump: Ver1, Rev2, Stage=CD Pump: Ver1, Rev0, Stage=PRD Revision reset to ‘0’ at start of next stage Pump: Ver1, Rev1, Stage=CD Inside a stage issues may be raise, when addressed raise revision Pump: Ver1, Rev0, Stage=CD

  18. Versions of RDL at OASIS docs site • Some implementers will want latest-and-greatest at all times • Some implementers may want to adopt one version and stay with that even when a new version is released • Latest and greatest always at • http://docs.oasis-open.org/plcs/plcs-std-rdl.owl • Versions kept at • http://docs.oasis-open.org/plcs/Vn/plcs-std-rdl.owl • Users can adopt same “repository” approach to control which specific PLCS RD they use • Can switch PLCS RD versions when they choose without any change to their RD extensions • Allows them to try out public-review-draft and committee-draft using same approach

  19. To Publish on OASIS • Set Version Number in plcs-std-rdl ontology annotation • The ontology URI does not change, so no change forced on users • Create Vn folder for newly approved version of RD on OASIS Web site, for example • http://docs.oasis-open.org/plcs/v1 • http://docs.oasis-open.org/plcs/v2 • Copy newly released plcs-std-rdl to Vn folder and to “latest and greatest” approved PLCS RD on OASIS Web site • http://docs.oasis-open.org/plcs/ • Yes, newest RD available in two places - but that protects adopters of current version not wanting to be affected by next version

  20. Other minor • OASIS guidance is to use HTTP URIs, not URNs • Problem with Dublin Core “purl.org” so need to use “plcs.org” instead • Remove Protégé version of Dublin Core from Global Repository and any Project Repositories • Switch to RDF-XML file format (not abbreviated format) • More regular so DEXLib code works more easily • RDF-XML is not the default in Protégé, so take care • File names now plcs-std-rdl.rdf-xml.owl

  21. Remove Dublin Core from Global List

More Related