Introduction to Application Profiles


Published on

Presented January 18, 2010 to the ALCTS Committee on Cataloging: Description and Access (CC:DA) as an introduction to RDF data, and application profiles. Presenters were Jon Phipps, Karen Coyle and Diane Hillmann.

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Introduction to Application Profiles

  1. 1. Jon Phipps: Overview<br />Karen Coyle: Step-by-Step<br />Diane Hillmann: Context<br />Application Profiles<br />
  2. 2. What&apos;s an Application Profile?<br /> <br />
  3. 3. What&apos;s an Application Profile?<br />It&apos;s a document<br />
  4. 4. What&apos;s an Application Profile?<br />It&apos;s a document of an agreement<br />
  5. 5. What&apos;s an Application Profile?<br />It&apos;s a document of an agreement on a model<br />
  6. 6. What&apos;s an Application Profile?<br />It&apos;s a document of an agreement on a model of our stuff in the world<br />
  7. 7. What&apos;s an Application Profile?<br />It&apos;s a document of an agreement on a model of how we describe our things in our world<br />
  8. 8. What&apos;s an Application Profile?<br />It&apos;s a document of an agreement on a model of how we describe ourthings in our world (domain) in the context of the global web of data<br />
  9. 9. Things?<br /> <br />
  10. 10. Things?<br />have a formal definition...<br />
  11. 11. Things?<br />have a formal definition...<br />Every individual in the OWLworld is a member of the classowl:Thing.<br />
  12. 12. OWL?<br /> <br />
  13. 13. OWL?<br />Web Ontology Language<br />
  14. 14. OWL?<br />Web Ontology Language<br />A language that can be used to formalize a domain by defining classes, the relations between them, and properties of those classes<br />
  15. 15. OWL<br />Web Ontology Language<br />can define the semantics of an Application Profile<br />
  16. 16. Semantics?<br />
  17. 17. Semantics?<br />What we mean when we define a class called &apos;book&apos; and describe it with a property called &apos;title’.<br />
  18. 18. Semantics?<br />What we mean when we define a class called &apos;book&apos; and describe it with a property called &apos;title&apos;.<br />The &apos;Semantic Web&apos; is a web of meaning that uses the RDF model<br />
  19. 19. RDF?<br />Resource Description Framework<br />
  20. 20. RDF?<br />Resource Description Framework<br />
  21. 21. RDF?<br />Resource Description Framework<br />“is a framework for representing information in the Web”<br />
  22. 22. RDF?<br />“has a simple data model that is easy for applications to process and manipulate.”<br />
  23. 23. RDF?<br />“has a formal semantics which provides a dependable basis for reasoning about the meaning of an RDF expression.”<br />
  24. 24. RDF?<br />“URI references are used for naming all … things in RDF.”<br />
  25. 25. RDF?<br />“is an open-world framework that allows anyone to make statements about any resource.”<br />
  26. 26. RDF?<br />“The underlying structure of any expression in RDF is a collection of triples”<br />
  27. 27. Triples?<br />consist of a subject, a predicate and an object. A set of triples is called an RDF graph<br />
  28. 28. Triples?<br />consist of a resource, a property and a value surrogate. <br />
  29. 29. Value Surrogate?<br />Not a value, but some thing that denotes the value<br />
  30. 30. Value Surrogate?<br />can be a Literal or a non-Literal<br />
  31. 31. Literal?<br />Can be a Plain Literal or a Typed Literal<br />
  32. 32. Plain Literal?<br />Is just a string with an optional (in this case totally unnecessary) language type<br />Plain Literal: <br />“Samuel Clemens”@en-US<br />
  33. 33. Typed Literal?<br />A string that must be interpreted<br />Typed Literal: <br />“27” ^^xsd:integer<br />
  34. 34. Typed Literal?<br />A string that must be interpreted<br />Typed Literal: <br />“27” ^^xsd:integer<br />denotes the number 27 <br />
  35. 35. Non-Literal?<br />A URI that refers to a resource<br />
  36. 36. Non-Literal?<br /><br />Identifies the skos:Concept labeled<br />“sounds”@en-US<br />In the skos:ConceptScheme identified by the URI<br /><br />
  37. 37. URI?<br />A resource identifier.<br />
  38. 38. URI?<br />A globally unique resource identifier.<br />“All URIs share the property that different persons or organizations can independently create them, and use them to identify things.”<br />
  39. 39. Predicate?<br />A URI<br />that identifies the property of the subjectof the triple<br />
  40. 40. Predicate?<br />“Since RDF uses URIs instead of words to name things in statements, RDF refers to a set of URIs (particularly a set intended for a specific purpose) as a vocabulary”<br />
  41. 41. Property?<br /> the property labeled<br />“Place of production”<br />in the vocabulary identified by<br />
  42. 42. Property?<br />A vocabulary can declare a property to be a subproperty of another property.<br />
  43. 43. Property?<br />A vocabulary can declare a property to be a subproperty of another property.This creates a formal relationship between the properties<br />
  44. 44. Can we talk about APs now?<br />Please?<br />
  45. 45. An AP defines Semantics<br /><ul><li>The Classes of resources your metadata is describing
  46. 46. The Vocabularies that you will use as properties to describe them</li></li></ul><li>Classes?<br />OMG<br />Please, don’t start that again<br />
  47. 47. An AP defines Syntax<br /><ul><li>Valid value ranges and datatypes for each property
  48. 48. Valid lists of values (controlled vocabularies) for properties
  49. 49. Cardinality of each property</li></li></ul><li>An AP defines Syntax<br />Dublin Core defines this validation profile for each property as a“Statement Template”<br />
  50. 50. An AP defines Syntax<br />A set of Statement Templates is a “Description Set”<br />
  51. 51. An AP defines…<br />An AP can describe multiple Description Sets.<br />
  52. 52. An AP defines…<br />An AP can describe multiple Description Sets.<br />The full set of Description Sets is a “Description Set Profile”<br />
  53. 53. Application Profiles<br />Step-by-Step<br />1/18/2010<br />52<br />CC:DA Application Profile Intro<br />
  54. 54. 1. Domain model<br />Person<br />WEMI<br />Topic<br />FRBR<br />1/18/2010<br />53<br />CC:DA Application Profile Intro<br />
  55. 55. 2. Determine elements<br />Work<br />Title<br />Format<br />etc<br />1/18/2010<br />54<br />CC:DA Application Profile Intro<br />
  56. 56. 3. Identify vocabularies<br />1/18/2010<br />55<br />CC:DA Application Profile Intro<br />
  57. 57. Identify vocabularies<br />1/18/2010<br />56<br />CC:DA Application Profile Intro<br />
  58. 58. Identify vocabularies<br />1/18/2010<br />57<br />CC:DA Application Profile Intro<br />
  59. 59. Vocabulary do&apos;s & don&apos;ts<br />Do not select elements based on their names or labels<br />Do select elements based on their definitions<br />Do pay attention to what values can be used<br />Don&apos;t think that you can select an element that doesn&apos;t quite match your need, and use it anyway<br />Do think: INTEROPERABILITY<br />1/18/2010<br />58<br />CC:DA Application Profile Intro<br />
  60. 60. One vocabulary<br />Vocabulary<br />AP<br />1/18/2010<br />59<br />CC:DA Application Profile Intro<br />
  61. 61. More than one vocabulary<br />Vocabulary A<br />Vocabulary B<br />AP<br />1/18/2010<br />60<br />CC:DA Application Profile Intro<br />
  62. 62. Rolling your own<br />Vocabulary<br />AP<br />1/18/2010<br />61<br />CC:DA Application Profile Intro<br />
  63. 63. Rolling your own<br />Vocabulary<br />All elments must be defined outside of the AP. <br />AP<br />1/18/2010<br />62<br />CC:DA Application Profile Intro<br />
  64. 64. &quot;Constraints&quot;<br />Mandatory/optional<br />Repeatability<br />Values (cannot conflict with defined element)‏<br />Free text<br />Controlled list of values<br />Formatted text (e.g. dates)‏<br />1/18/2010<br />63<br />CC:DA Application Profile Intro<br />
  65. 65. What is the impact of all this on our world?<br />The Context for Application Profiles <br />
  66. 66. In the world we knew, interoperability was ensured by “compliance with standards”<br />All of used the same ones in a closed world<br />Data created by humans under strict guidelines<br />In an open world, interoperablity depends on:<br />Technologies that reach beyond one community<br />Data built in a variety of ways by people with different ideas of the world<br />Machines that act broadly based on human oversight<br />Understanding Interoperability<br />1/18/2010<br />65<br />CC:DA Application Profile Intro<br />
  67. 67. We’ve long accepted the limits of requiring upfront consensus to ensure interoperability<br />In a world of APs we can specialize beyond the core of generally useful data<br />We don’t need humans to ‘dumb down’ specialist data to enable sharing and interoperability<br />Machines can invoke relationships to generalize specialist data when necessary, without removing the value of extended specialized data for specialists<br />Why This Approach Instead?<br />1/18/2010<br />66<br />CC:DA Application Profile Intro<br />
  68. 68. We can’t afford to “go it alone”<br />We can’t afford to ignore the world of data outside libraries<br />We can’t afford to create all our data with humans<br />We can’t afford NOT to rethink how we operate<br />The Value of an Open World<br />1/18/2010<br />67<br />CC:DA Application Profile Intro<br />
  69. 69. It’s often free and easily available<br />It’s ‘good enough’ (our stuff isn’t perfect either)<br />It takes us where we can’t go with our current data<br />It’s maintained by someone else <br />We can choose to use data or not, APs allow us to document that use, automate the process, and expose the data to others<br />What’s Out There? Data!<br />1/18/2010<br />68<br />CC:DA Application Profile Intro<br />
  70. 70. Records can be aggregated from statements when we need them<br />Statement-based data can be managed and improved more easily than record-based data<br />Statement-based data can carry provenance for each statement, allowing quality decisions to be made at a more granular level<br />Changing Our Data Management Ideas<br />1/18/2010<br />69<br />CC:DA Application Profile Intro<br />
  71. 71. Getting From Here to There<br />1/18/2010<br />70<br />CC:DA Application Profile Intro<br />
  72. 72. The RDA Vocabularies<br />The principles of extension inherent in the RDF Vocabulary standards used<br />Our experience in building and using data<br />Using What We Already Know<br />1/18/2010<br />71<br />CC:DA Application Profile Intro<br />
  73. 73. Proliferating our ideas and experience with bibliographic data to the broader Web world<br />Using newer technology to achieve more efficiency, transparency, and functionality<br />If retrenchment is the only answer, the end point is zero<br />Saving our precious human resources to think, evaluate, ensure quality, and innovate<br />To Build Ourselves a New Future<br />1/18/2010<br />72<br />CC:DA Application Profile Intro<br />
  74. 74. We can map it in a variety of ways for a variety of uses<br />We can still use MARC as a [lossy] exchange format as long as we need it<br />It offers insufficient flexibility as the basis for a new data world inter-connected to the Web<br />We can use our skills and our understanding of bibliographic description to lead the way forward<br />What About Our Legacy Data?<br />1/18/2010<br />73<br />CC:DA Application Profile Intro<br />
  75. 75. Specialist communities are already thinking about what they need that RDA doesn’t provide<br />Using the extensibility of RDF vocabularies allows them to choose from a number of options <br />Moving proposals through the RDA process<br />Extending the vocabularies through their community domain<br />Chosing the extension option reflects the reality that consensus has its limits, and specialist data may be better managed at a different level<br />Some Concrete Suggestions<br />1/18/2010<br />74<br />CC:DA Application Profile Intro<br />
  76. 76. With Application Profiles we can:<br />Document our decisions clearly<br />Measure compliance with our own intentions<br />Express our decisions in a machine-actionable way<br />Make connections with other data communities by re-using their data semantics<br />RDA expresses this ideal in its stated goals<br />What Do We Gain?<br />1/18/2010<br />75<br />CC:DA Application Profile Intro<br />
  77. 77. Less one-at-a-time creation and more data design, data improvement, data evaluation<br />Ability to look at our contrained resources and reduced budgets as the opportunity to reinvent ourselves<br />Rethinking Our Role<br />1/18/2010<br />76<br />CC:DA Application Profile Intro<br />
  78. 78. Guidelines for Dublin Core Application Profiles<br /><br />RDA Vocabularies<br /><br />Thanks! Links! Questions?<br />1/18/2010<br />77<br />CC:DA Application Profile Intro<br />