Linked Open Usable Data Principles
•Download as PPTX, PDF•
8 likes•2,624 views
The document discusses making linked open data usable. It emphasizes the importance of understanding the audience and their needs when developing linked open data. Key points include knowing the audience, meeting them on their terms, having a conversation to understand their needs, and providing opportunities for meaningful participation. Other tips discussed are focusing on the right abstraction, keeping barriers to entry low, ensuring the data is comprehensible, providing documentation and examples, minimizing exceptions, and designing consistently for JSON-LD. The overall message is that usability must be a central consideration for linked open data to be successful and useful.
Recommended
Recommended
More Related Content
Similar to Linked Open Usable Data Principles
Similar to Linked Open Usable Data Principles (20)
More from Robert Sanderson
More from Robert Sanderson (15)
Recently uploaded
Recently uploaded (20)
Linked Open Usable Data Principles
- 1. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu Shout it Out: LOUD Rob Sanderson Semantic Architect J. Paul Getty Trust rsanderson@getty.edu @azaroth42
- 3. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu The (Imagined) Semantic Web But not how they thought it would
- 8. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu Usable? … usability is the degree to which [a thing] can be used by specified consumers to achieve [their] quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use. who what how where Usability is dependent on the Audience https://en.wikipedia.org/wiki/usability “ ”
- 9. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu Who? With thanks to Patrick Hochstenbach, @hochstenbach
- 12. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu What? How? Where? 1. Know Your Audience 2. Meet on Their Terms 3. Have a Conversation 4. Create Opportunities for Meaningful Participation /ht Catherine Bracy, @cbracy
- 13. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu Usability 1. Know Your Audience 2. Meet on Their Terms 3. Have a Conversation 4. Create Opportunities for Meaningful Participation
- 14. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu 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 “ ”
- 15. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu What is the API for LOD? Provide useful information about what a name identifies when it's looked up, using open standards such as RDF, SPARQL, etc. In LOD, the ontology determines the API This is not meeting on the audience’s terms “ ” -- TimBL
- 17. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu Usable (API) vs Complete (Model)
- 22. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu Five Stars of Linked Open Usable Data ⭐ right Abstraction for the audience ⭐ few Barriers to entry ⭐ Comprehensible by introspection ⭐ Documentation with working examples ⭐ few Exceptions, many consistent patterns
- 23. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu A is for the right Abstraction https://www.flickr.com/photos/emilgh/2801393221/
- 24. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu A is for the right Abstraction
- 25. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu A is for the right Abstraction https://www.flickr.com/photos/markmorgantrinidad/14860681369/ https://www.flickr.com/photos/57293605@N07/14345959147/
- 26. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu B is for few Barriers to Entry https://www.flickr.com/photos/tfpc/6112503326/
- 27. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu C is for Comprehensible { "@context": "https://linked.art/ns/v1/linked-art.json", "id": "https://example.museum/data/object/1", "type": "ManMadeObject", "identified_by": { "type": "Name", "value": "Example Painting” }, "made_of": { "id": "aat:300015045", "type": "Material", "label": "watercolor" } }
- 28. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu D is for Documentation https://www.w3.org/TR/annotation-model/
- 29. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu E is for few Exceptions M.C. Escher, Two Birds (No. 18)
- 30. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu E is for few Exceptions
- 32. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu Five Core Design Principles 1. Require Use Cases, with Data 2. As Simple as Possible 3. Don’t Break the Web 4. Define Success, Not Failure 5. Design for JSON-LD, Consistently
- 33. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu Require Use Cases, with Data! Uses Cases, supported by data, keep LOD grounded in reality and help find the correct abstraction
- 34. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu As Simple as Possible Image source: Alamy
- 35. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu Don’t Break the Web https://www.flickr.com/photos/patchattack/10784011155/
- 36. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu Define Success, Not Failure https://en.wikipedia.org/wiki/Jon_Postel
- 37. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu Design for JSON-LD, Consistently 10% - 20% of all websites have JSON-LD data (schema.org) json api xml api https://trends.google.com/trends/explore?date=all&q=json%20api,xml%20api (Feb 2018) https://w3techs.com/technologies/details/da-jsonld/all/all (Nov 2017) http://webdatacommons.org/structureddata/2017-12/stats/stats.html
- 38. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu RDF: Not In My Backyard! Image By Z22 - https://commons.wikimedia.org/w/index.php?curid=30929934Title: http://manu.sporny.org/2012/nuclear-rdf/
- 40. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy LinkedOpen UsableData @azaroth42 rsanderson @getty.edu Insights to Take Away ⭐ right Abstraction ⭐ few Barriers ⭐ Comprehensible ⭐ Documentation ⭐ few Exceptions ⭐ Require Use Cases ⭐ Simple as Possible ⭐ Don’t Break the Web ⭐ Define Success ⭐ Consistent JSON-LD Ensure Your Data is LOUD
Editor's Notes
- RDF and the "Semantic Web" changed the way we think about data in general. Instead of relational tables hidden behind an HTML interface, without standards for the data, we began to think about managing information in a graph with shared definitions for the relationships and classes.
- But it was initially focused on consumption in the same way as a relational database: as input to our own internal processing with a grand vision of powering a web-scale semantic artificial intelligence. Lovely for academics writing papers, but the only practical, broadly adopted effect was to change the way we think about our data.
- Linked Open Data, with its five stars of excellence, then changed the way we publish data on the web. It gave us a short and very practical checklist that we could use to go from thinking to doing. It promotes open-ness as a necessity for re-use. It promotes standards as a necessity for re-use. It promotes linking between systems as a necessity for re-use.
- But … all of the stars are concerns of publishing systems, not consumers. It's like Sir Tim came down the mountain with 10 commandments but only gave us the publishing tablet. Maybe he dropped the other one, maybe it was too heavy to carry. So, while LOD brought about a massive the upsurge in publishing of data, I believe that it's also not enough.
- The web community has started to recognize that we're missing the other 5 stars. If our data isn't used, there's no value gained from the resources that were invested in its creation, publication, maintenance and improvement. And if we want our data to be used, the data needs to be …
- Usable. And, I argue, it needs to be designed to be usable. We need Linked Open *Usable* Data. LOUD not just LOD.
- What do I mean by “Usable”? In a well established tradition, the wikipedia definition clarifies that .. So, * who wants to do * what, * how and in * what environment. Unlike the entirely objective five stars of publishing, any recommendations about usability need to take into account the consumer. * Usability is thus dependent on, and determined by, the Audience
- And who is the audience for Linked Open Data, as published by cultural heritage organizations such as ourselves? My reaction in thinking about this was initially “researchers”. And researchers quite broadly, with school students being just as important as university professors.
- But I was falling into the “south park gnomes” trap. There is a * “magic happens here” step before we get to * “profit”.
- And that magic is carried out by Developers! Researchers (that could not also be considered as developers) interact with visualizations and user interfaces, not the raw data directly. We need the developer role in the middle, to translate the unreadable RDF into a web application that can be understood by many.
- If the “who” is Developers, how can we get to the What, How and in which Context of Usability? For this, I turn to Catherine Bracy’s four points on community. Know your Audience … who are you targeting with your product, or who is participating in your community? Meet on their terms … if you’re looking to expand your community or product usage, you need to talk to your audience in a way that makes them comfortable and included, not in your own internal language Have a Conversation … don’t just present at them, or direct them to read the documentation, discuss the XXXXX Create Opportunities … While you’re discussing, and afterwards, give them ways to participate, not just consume. The feeling of ownership is an important motivator. Okay … so … usability?
- The audience is developers, and Usability is meeting on their terms. Steps 3 and 4 bring them in to the community, and then keep them engaged, thereby building usage. Having a conversation lets you customize that for the particular needs of individuals within the community, if possible.
- Or put another way, the API is the User Interface of the Developer. As a New Zealander, I must regretfully announce that the Australians have this absolutely 100% correct. The Australian government wrote a fantastic API Design Guide in 2015 that nails it on core principles and the important notion of requiring empathy for developers, the same way that that any user interface should be accessible and comfortable for its audience.
- In Linked Open Data, the API is built on top of HTTP like any other web API. It’s ReST-ful – when you dereference a URI, you receive useful information about the resource that is identified by that URI. That response uses open standards such as … ahhh :( In Linked Open Data, the ontology determines the API up front. The ontology is almost exclusively designed to meet the requirements of the publisher of the data, and not the consumer. This is not meeting on the audience’s terms. Lets go back to Pat’s wonderful picture, but add in the core metric for success for each step…
- The model is successful when it is semantically complete and precise, but the output is successful when the API is Usable. If that information is also accurate, then the researcher is happy. So the question for us is how to optimize between the success of the model and the success of the API: Complete vs Usable.
- If you only need half of the completeness, you should not be punished in terms of usability. Should be able to get close to the maximum usability for the particular use case’s completeness requirements.
- If you only need half of the completeness, you should not be punished in terms of usability. Should be able to get close to the maximum usability for the particular use case’s completeness requirements.
- As easy as ABC … or it would be if there were three stars. So also D and E.
- Don’t learn new vocabulary.
- We expect users to understand a website’s UI in seconds or leave, but for developers to read documentation on their UI (the API) for hours before doing anything.
- Learning by introspection gets you started quickly, but clear and complete documentation about the data is just as important. With complete, relevant examples that work if you cut and paste them into your system … because that’s exactly what people are going to do.
- Consistent patterns.
- Inconsistency, no matter that it fits, is very jarring. Every exception needs to be memorized separately, rather than the rule to follow.
- With apologies for the resume slide …
- All of these specifications, and many others, follow five design principles towards ensuring usability.
- All of the projects required use cases for every feature. And not only use cases, but data to support those use cases, and preferably implementations that made use of the data. This avoided infinitely long and pointless discussions about how many hypothetical E39 Actors could dance on the head of an E22 Man-Made Object… except the location of an E7 Activity must be an E53 Place, requiring a … you get the picture.
- Another core principle is the maxim attributed to Einstein – As simple as possible, and no simpler. IIIF has done a great job meeting this principle by avoiding technology dependencies, and only adding complexity when those use cases are shared by multiple organizations. This increases the likelihood of adoption and reuse, in which IIIF has been very successful. As simple as possible means fewest barriers to entry.
- As recognized from the beginning of LOD, it’s important to be of the web, not just on the web. This means a resource oriented paradigm, such that web caches are used to their full potential, and to make it easier for static implementations that just put files on disk. The more cacheable, the more performant with no additional cost. The web also runs on standards, and adopting appropriate standards and best practices is essential.
- This is a derivation of Postel’s Law: Be liberal in what you accept, and conservative in what you send. When applied to Linked Open Data and APIs, it means that clients should expect to see data that they don’t understand, and publishers should be careful to respect the model where specified. This facilitates experimentation with extensions as part of iterative development towards new versions. It is especially important for linked.art to allow unknown features from the rest of CIDOC-CRM without getting in the way of the core profile.
- I think Many Sporny perfectly captured the sentiment that JSON-LD aims to avoid: When developers hear “RDF” they think: Not in my back yard!