The Importance of being LOUD
•Download as PPTX, PDF•
2 likes•4,497 views
Presentation about usability of linked data, following LODLAM 2020 at the Getty. Discusses JSON-LD 1.1, IIIF, Linked Art, in the context of the design principles for building usable APIs on top of semantically accurate models, and domain specific vocabularies. In particular a focus on the different abstraction layers between conceptual model, ontology, vocabulary, and application profile and the various uses of the data.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to The Importance of being LOUD
Similar to The Importance of being LOUD (20)
More from Robert Sanderson
More from Robert Sanderson (10)
Recently uploaded
Recently uploaded (20)
The Importance of being LOUD
- 1. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 The Importance of Being LOUD Rob Sanderson Semantic Architect rsanderson@getty.edu @azaroth42 http://w3.org/TR/json-ld11 https://iiif.io/ https://linked.art/model/
- 2. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 RDF is a Pain People think RDF is a pain because it is complicated. The truth is even worse. RDF is painfully simplistic, but it allows you to work with real-world data and problems that are horribly complicated. -- Dan Brickley and Libby Miller http://book.validatingrdf.com/bookHtml005.html “ ”
- 3. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 RDF: Not In My Backyard! Image By Z22 - https://commons.wikimedia.org/w/index.php?curid=30929934Title: http://manu.sporny.org/2012/nuclear-rdf/
- 4. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Data: Easy to Use … by Humans
- 5. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 LOD: Easy to Use … by Machines <http://vocab.getty.edu/aat/300015045> <http://www.w3.org/1999/02/22-rdf-syntax- ns#type> <http://www.cidoc-crm.org/cidoc-crm/E57_Material> . <http://vocab.getty.edu/aat/300015045> <http://www.w3.org/2000/01/rdf- schema#label> "Terracotta" .<http://vocab.getty.edu/aat/300148696> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.cidoc- crm.org/cidoc-crm/E55_Type> .<http://vocab.getty.edu/aat/300148696> <http://www.w3.org/2000/01/rdf-schema#label> "Amphora" . <https://data.getty.edu/museum/11733> <http://www.cidoc-crm.org/cidoc- crm/P108i_was_produced_by> <https://data.getty.edu/museum/11733/create> . <https://data.getty.edu/museum/11733> <http://www.cidoc-crm.org/cidoc- crm/P2_has_type> <http://vocab.getty.edu/aat/300148696> . <https://data.getty.edu/museum/11733> <http://www.cidoc-crm.org/cidoc- crm/P45_consists_of> <http://vocab.getty.edu/aat/300015045> . <https://data.getty.edu/museum/11733> <http://www.w3.org/1999/02/22-rdf-syntax- ns#type> <http://www.cidoc-crm.org/cidoc-crm/E22_Man-Made_Object> . <https://data.getty.edu/museum/11733> <http://www.w3.org/2000/01/rdf- schema#label> "Attic Black-Figure Neck Amphora" . <https://data.getty.edu/museum/11733/create> <http://www.w3.org/1999/02/22-rdf- syntax-ns#type> <http://www.cidoc-crm.org/cidoc-crm/E12_Production> .< https://data.getty.edu/museum/11733/create> <http://www.w3.org/2000/01/rdf- schema#label> "Creation event" .
- 6. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 LOUD: Easy to Use … by Humans { "@context": "https://linked.art/ns/v1/linked-art.json", "id": "https://data.getty.edu/museum/11733", "type": "HumanMadeObject", "_label": "Attic Black-Figure Neck Amphora", "classified_as": [{ "id": ”http://vocab.getty.edu/aat/300148696", "type": "Type", "_label": "Amphora" }] "produced_by": { "id": " https://data.getty.edu/museum/11733/create", "type": "Production", "_label": "Creation event"} }
- 7. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 With thanks to Patrick Hochstenbach, @hochstenbach LOUD: Easy to Use … by ... Humans?
- 8. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 LOUD: Easy to Use … by Developers!
- 9. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 The API is the Developers' User Interface When it comes to APIs, developers are your users. The same principles of user- centred-design apply to the development and publication of APIs (simplicity, obviousness, fit-for-purpose etc) http://apiguide.readthedocs.io/en/latest/principles/empathy.html “ ”
- 11. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Successful APIs … • Solve actual challenges, documented as use cases • Using data that is captured and available • Allow consistent implementation of shared use cases • Allow for addition of further functionality • Can be productively used • Via easy-to-implement services • With easy-to-implement applications • Provide interoperability between data and systems • Are clearly documented with relevant examples
- 12. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Successful APIs … Are developed … • Iteratively • Build upon success and learn from failure • Responsively • Adapt in response to feedback • Responsibly • Consider changes/features carefully • Collaboratively • Engage with the community and stakeholders
- 13. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Evaluation? /ht Michael Barth, Ulm University Abstraction level Comprehensibility Consistency Discoverability / Documentation Domain Correspondence Few Barriers to Entry Extensibility Infrastructure
- 14. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 A Community that develops APIs, implements them in Software, and exposes interoperable Content
- 15. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 APIs: Agreement Preceding Interaction* Presentation Search Image Authentication (* API is really: Application Programming Interface)
- 17. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 IIIF Image API http://iiif.io/api/image/ URL pattern to access pixels and technical information
- 18. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 IIIF Presentation API Just enough structure & description data to drive a viewer
- 20. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 IIIF Design Patterns 1. Scope design through shared use cases 2. Design for international use 3. As simple as possible, but no simpler 4. Make easy things easy, complex things possible 5. Avoid dependency on specific technologies 6. Use REST / Don’t break the web 7. Separate concerns, keep APIs loosely coupled 8. Design for JSON-LD, using LOD principles 9. Follow existing standards, best practices, when possible 10. Define success, not failure (for extensibility) https://iiif.io/api/annex/notes/design_patterns/
- 21. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Is IIIF Actually LOUD? • IIIF is JSON-LD ... used as if it were JSON • IIIF APIs are focused on Presentation, not Semantics • Usability considered more important than Precision • Document structure / graph boundary is enforced by the API specifications • Presentation: Collection, Manifest • Image: Info.json • Discovery, Search: Stream/Results, Page
- 22. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Is IIIF Actually LOUD? • Discovery (and paging) use W3C ActivityStreams • Also not very Linked • Also very successful • Annotations are the only core affordance that cross institutional boundaries • Services and Extensibility are important facets that rely on Linked Data • Image and Presentation 3.0 use JSON-LD 1.1 as it is intended to be used …
- 23. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Appropriate Level of Abstraction For one audience, JSON is the right level of abstraction. For another audience, RDF is the right level. JSON-LD’s magic is that both can be the same syntax. Other JSON[-LD] work: • Verifiable Claims, Distributed Identifiers • Web of Things • Web Annotation, ActivityStreams • All of which is (currently) dwarfed by …
- 24. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Schema.Org is JSON-LD 28.8% of all websites have JSON-LD data json api xml api https://trends.google.com/trends/explore?date=all&q=json%20api,xml%20api (Jan 2020) https://w3techs.com/technologies/details/da-jsonld/all/all
- 25. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Sidebar: JSON-LD 1.1 in 2020 • Process • In Candidate Recommendation • Second CR coming end of Feb • Final before June • New Features! • Contexts scoped to Class or Predicate • Protected contexts that can’t be redefined • Better Internationalization support • Formalizes Framing algorithm • ... Plus many more! http://w3.org/TR/json-ld11
- 26. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Non-Separable Abstraction Levels? • Ontology • Available Classes, Properties and their meaning • API • How to interact with the data over the network • LOD does not separate Ontology and API by requiring the syntax to directly encode the model • JSON-LD contexts allow them to be pulled apart enough to improve usability for non-RDF usage
- 27. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Abstraction Levels: Further Separation • Conceptual Model • Abstract way to think about the world • Ontology • Shared format to write down that thinking • Vocabulary • Selected set of domain specific terms • Application Profile • Selection and application of model, ontology vocabulary and format for specific domain
- 28. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 W3C Priority of Constituencies In case of conflict, consider … https://www.w3.org/TR/html-design-principles/ “ ” users … over authors … over implementors … over theoretical purity. Developers Data Editors Tool Builders Ontology
- 29. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Linked Art Model A Linked Open Usable Data model, collaboratively designed to work across cultural heritage organizations, that is easy to publish and enables a variety of consuming applications. Design Principles: • Focused on Usability, not 100% precision / completeness • Consistently solves actual challenges from real data • Development is iterative, as new use cases are found • Solve 90% of use cases, with 10% of the effort
- 30. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Linked Art Collaboration Working to formalize the profile, funded by Kress & AHRC • Getty • Rijksmuseum • Louvre • Metropolitan Museum of Art • Smithsonian • MoMA • V&A • NGA • Philadelphia Art Museum • Indianapolis Art Museum • The Frick Collection • Harvard University • Princeton University • Yale Centre for British Art • Oxford University • Academica Sinica • ETH Zurich • FORTH • Zeri Foundation (U. Bologna) • Canadian Heritage Info. Network • American Numismatics Society • Europeana
- 31. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Usable vs Complete: Target Zone
- 32. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Linked Art is LOUD https://linked.art/
- 33. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Conceptual Model From 50,000 Feet what when who where / how
- 34. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Progressive Enhancement Principle • Legacy Records • No “things”, just descriptions • Data for Humans • Core entities, with attached descriptions • Data for Machines • Linked entities with machine-readable values • Data for Research • Sufficient precision to answer research questions from aggregated data
- 40. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Title
- 47. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Data for Machines: From Strings to Values
- 52. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Data for Machines: Linking Entities
- 56. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Data for Machines: Linking Across Institutions • Part of the Web • Not just on the web • Shared Cataloging • No need for everyone to describe everything • Improved Discovery • By leveraging the connections for search • Better Research Results • By taking into account more information
- 62. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Core Patterns • Class versus Classification • Names and Identifiers • Statements • Partitioning • Subdivision of thing, concept, activity, place • Human Activity • Human involvement is critical for art
- 63. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy TheImportanceof BeingLOUD @azaroth42 Linked Art: Easy to Use … by Humans! { "@context": "https://linked.art/ns/v1/linked-art.json", "id": "https://data.getty.edu/museum/11733", "type": "HumanMadeObject", "_label": "Attic Black-Figure Neck Amphora", "classified_as": [{ "id": ”http://vocab.getty.edu/aat/300148696", "type": "Type", "_label": "Amphora" }] "produced_by": { "id": " https://data.getty.edu/museum/11733/create", "type": "Production", "_label": "Creation event"} }
Editor's Notes
- I think Many Sporny perfectly captured the sentiment: When developers hear “RDF” or “the Semantic Web” or “SPARQL” they think: Not in my back yard, people have died from that stuff!
- Michael Barth has six fundamental features for API evaluation, which relate directly to the value of the API as a standard for use. This seems like a good starting point for standards for digital interoperability. Abstraction Level -- is the abstraction of the data and functionality appropriate to the audience and use cases. An end user of the "car" API presses a button or turns a key. A "car" developer needs access to engine directly. Comprehensibility -- is the audience able to understand how to use it to accomplish their goals Consistency -- if you know the "rules" of the API, how well does it stick to them? Or how many exceptions are there to a core set of design principles Documentation -- How easy is it to find out the functionality of the API? Domain Correspondence -- If you understand the core domain of the data and API, how closely does the understanding of the domain align with an understanding of the data? And what barriers to getting started are there? There are two more that I think are important.
- Need to have the rules of the game before two systems can interact
- Need to have the rules of the game before two systems can interact
- The core functionality. Not just an image tag, but also not photoshop on the web.
- Just enough information to present the context of the images in a way that the user can understand what they’re interacting with. Structure of the object and its metadata in a pre-processed form for rendering in a client … so not a semantic metadata API.
- The community engagement with JSON-LD has been unprecedented, notably due to Google’s adoption of it and the usability focus of schema.org.
- Intent of a profile is to select only the relevant parts of the lower level definitions that are needed.
- Further restrict the model / ontology to ensure that the data is usable.
- Less important for IIIF to be complete as it’s about presentation not semantics. But for semantic description…
- E22 HumanMadeObject is the ontology term for the class of Human Made Objects in the conceptual model, and type is the relationship between things and their classes. The label is a constructed piece of text to label the resource, in the absence of any other data. Intended for developers looking at the data, not intended for directly being displayed to “real” humans.
- Turns out that there are two sorts of things that speak in numbers … computers, and librarians.
- That should help. We use the Getty’s Art and Architecture Thesaurus.
- That should help. We use the Getty’s Art and Architecture Thesaurus.
- We know that this is the primary name, because it was called title, not alternate title.
- We know that this is the primary name, because it was called title, not alternate title.
- And now we’re at the 50’ foot view, with an activity in the middle and who, what, when and where around the outside. Models for all of these other entities as well to capture useful knowledge for shared use cases.
- No one has all of the knowledge, and to try to gather everything together and keep it persistently available and up to date is impossible below the scale of Google.
- No one has all of the knowledge, and to try to gather everything together and keep it persistently available and up to date is impossible below the scale of Google.