1 / 19

Conflicting design goals when modeling standards

Conflicting design goals when modeling standards. Dr. Brigitte Mathiak. Economics of standardization. Data model A. Total cost = (Size of data model in fields + number of fields to map * estimated number of data integrations )* 500$ Or : C no standard = s + s external *i.

haracha
Download Presentation

Conflicting design goals when modeling standards

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. Conflicting design goalswhenmodelingstandards Dr. Brigitte Mathiak

  2. Economics ofstandardization Data model A Total cost= (Size ofdatamodel in fields + numberoffieldstomap* estimatednumberofdataintegrations)* 500$ Or: Cnostandard= s + sexternal*i Individual mappingcostsroughly 500 $ per fieldtobemapped (domainexperts, parser, mappinglogic, …)This isaboutasmuchasprogrammingit in thefirstplace. Data model B

  3. Economics ofstandardization Data model A Standard All thisisnowfree Data model B

  4. Economics ofstandardization This coststhe same Data model A Standard All thisisnowfree Data model B

  5. The catch This coststhe same Cstandard = 3*(s+sstandard_unused) + sremainder*i Data model A Standard This costs extra forboth Data model B Programmingagainst a standardcostsroughlythreetimesasmuch. Communications of the ACM, Vol. 55 No. 3, Pages 52-53

  6. Formulae Cstandard = 3*(s+sstandard_unused) + sremainder*i Cnostandard= s + sexternal*i Shouldbelow Cstandard- Cnostandard= 2*s + 3*sstandard_unused- (sexternal-sremainder)*i Fazit: The standardshould fit myexternaldata just so Shouldbe high Fazit 2: i shouldbe larger than 3

  7. Data exchangestandard Precision anddetaillevel Computer understandable Computer readable Human understandable

  8. Data modelimplementation Flexibilityrequiredofthestandard/ coststoimplementit Requirements (on average) Explicit model underspecified Optimization, denormalization

  9. Data quality Curveexpectedfromstandardization Numberoffieldsanddetaillevel

  10. Standard Model Less expensive (noneedforparser) Standard Model/Framework Data model A Standard Core Data model B Relativelycheaptransformation

  11. Best practice: GML (ISO 19136)Core model Object Geometry coords Feature Point LineString Placemark Disclaimer: This is an excerptfrom an excerptwithsomeconfusionaddedfrom different versions

  12. Howdoes a Road looklike? Object Much text on whatcoordsmean in generalandthiscontextspecificallywith a lotof additional links tootherstandardsandvocabularies, bestpractices, includingformulaeforcalculatingdistances, projections, compression, etc. Geometry coords Feature • Too rare tobe an explicit partofthestandard, insteaditisdefined in a user-made XML Schema • Verifiable • Can beusedtodefineinput • Encouragesdocumentationof individual changes Point LineString Placemark Lots ofniftysemanticdescriptionsofgeneral, re-usableassociations, whichyoumayuseinsteadofthegeneralpurposeones, but do not haveto centerLineOfowns=„true“ Road Disclaimer: This is an excerptfrom an excerpt, …

  13. Howdoesthisapplyto DDI? • More strictnessforthecoreentities (less OR) • Syntacticalframeworkwith lots ofabstraction, meanttogive additional informationtohumans • Designatedareasforextension (both individual andcommunityeffort)

  14. Pleasekeep in mindhowmuchyoucostothers!

  15. Empty on purpose

  16. Communication Quality Assurance Implementation Data structure Flexible for producers, rigid for consumers Flexible to catch all corner cases Rigid but extendable Interoperabilitywithstandards To avoid duplication Only standards that meet the quality criteria Defined use of foreign standards Structuredness Keep it simple Detailed with mandatory elements Detailed and flexible Technical requirements XML as wide spread standard, no need for an API PDF reader API! Usability Easy to use and understand optimized for domain experts optimized for developers Semantic precision Tolerance needed Extremely important, especially on higher levels Important to avoid losses between process steps, mainly in detailed information Involved institutions Heterogeneous Homogeneous, usually inside one institution It depends

  17. Communication Quality Assurance Process Support XML Schema/RDF PDF documentation/Scripts Java API Simple UML model

  18. Communication (QA level 0) Quality Assurance Process Support (QA level 1) XML Schema/RDF PDF documentation/Scripts Java API <StudyUnit id=„abcd“> <Title>my</Title> <Description> a little text for describing the study </Description> … </StudyUnit> QA level 1 A studymust have a meaningful title (Title) and description (Description). It should be documented in english and the study language. … Class StudyUnit createNew(String id) setTitle(String title) getTitle() setDescription(…) getDescription() checkQA(String level) … verification annotation representation StudyUnit Title Description … transformation implementation Simple UML model

  19. Howdoesgeneralextensibilitywork? Object Geometry coords Feature Point LineString This mayincludeotherstandards, e.g. Dublin Core Placemark This mayincludedatayouhave in thedatamodel, whichis not covered in the ExtendedData Disclaimer: This is an excerptfrom an excerpt, … Any XML <with an externalschema> Typed Data<with a document-definedschema> Untyped Key/Value pairs

More Related