Download to read offline
![@azaroth42
rsanderson
@getty.edu
IIIF:Interoperabilituy
Standardsand
Communities
@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
â â](https://image.slidesharecdn.com/jcdl2019keynotestandardscommunities-190604163108/85/Standards-and-Communities-Connected-People-Consistent-Data-Usable-Applications-41-320.jpg)
![@azaroth42
rsanderson
@getty.edu
IIIF:Interoperabilituy
Standardsand
Communities
@azaroth42
rsanderson
@getty.edu
[Standards] By the People, For the People](https://image.slidesharecdn.com/jcdl2019keynotestandardscommunities-190604163108/85/Standards-and-Communities-Connected-People-Consistent-Data-Usable-Applications-54-320.jpg)
![@azaroth42
rsanderson
@getty.edu
IIIF:Interoperabilituy
Standardsand
Communities
@azaroth42
rsanderson
@getty.edu
[Standards] By the People, For the People
Functional Comprehensible
Complete Usable
Publisher Consumer
âŠ
âŠ
âŠ](https://image.slidesharecdn.com/jcdl2019keynotestandardscommunities-190604163108/85/Standards-and-Communities-Connected-People-Consistent-Data-Usable-Applications-55-320.jpg)
Uploaded byRobert Sanderson
Standards and Communities: Connected People, Consistent Data, Usable Applications
The document discusses interoperability standards and communities in digital libraries, emphasizing the importance of collaboration and user-centric design. Key features include the necessity of engaging various stakeholders, creating meaningful participation opportunities, and prioritizing usability over mere functionality. It outlines different scales of project involvement, from limited domains to global standards, advocating for an iterative and flexible approach to standards development.
TechnologyâŠ
More Related Content
Similar to Standards and Communities: Connected People, Consistent Data, Usable Applications
![Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/apachesparkgettingstarted-260203175547-8361bcc3-thumbnail.jpg?width=640&height=640&fit=bounds)
Standards and Communities: Connected People, Consistent Data, Usable Applications
- 1. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Standards and Communities: ConnectedPeople, Consistent Data, Usable Applications Rob Sanderson Semantic Architect J. Paul Getty Trust rsanderson@getty.edu @azaroth42
- 2. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Continuing the Conversation? Photoby RahenZ, Flickr âą Innovation âą Sustainability âą Adaptability âą Community
- 3. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu The nice thingabout standards is thereâs so many to choose from - Andrew S. Tanenbaum Digital Library Standards
- 4. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu âą Z39.50 âą SRU+CQL âąOAI-PMH âą Resource Sync âą OAI-ORE âą Memento âą Open Annotation âą IIIF âą LOUD - Linked Art âMyâ Digital Library Standards ?
- 5. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu âMyâ Digital LibraryStandards âą Z39.50 âą SRU+CQL âą OAI-PMH âą Resource Sync âą OAI-ORE âą Memento âą Open Annotation âą IIIF âą LOUD - Linked Art âą Implementer (ZIG) âą Editor âą Implementer âą Editor âą Editor âą Editor âą Editor âą Editor âą Editor
- 6. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Why? Interoperability! Facets ofInteroperability: 1. Interoperating Entities (People, Organizations) 2. Objects of Interaction 3. Functional Perspective of Interoperability 4. Linguistic Interoperability (Multilingualism) 5. Design and User Perspectives 6. Technological Standards Stefan Gradman, doi 10.1.1.363.6311
- 7.
- 8. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Digital is aMeans Not an End W3C â 20th Anniversary, October 2014
- 9. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Working Together âWithout Meetings Bernard Spragg, Flickr, Keas at Mt Hutt, NZ
- 10. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Working Together âWithout Meetings Airflore, Flickr, Kea Mangeur
- 11.
- 12. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Who can beinvolved? How can they be involved? Who is it for? How can they be involved? Standards and Communities
- 13. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Process Features? Key featuresof successful standards work: ⹠Focused: Solve real problems from within ⹠Open: Requirement is participation not reputation ⹠Active: Constant attention to product & process ⹠Flexible: Adapt to changing situation Or ⊠FOAF
- 14. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Project Scale: OpenArchives Initiative Scale: 1 project at once Who: Herbert & Carl plus invited Process: Email, Meetings, Releases Audience: Limited domain, Limited involvement Outreach: Participants at existing conferences Outreach events Benefits: Focused, Flexible But: Not very Open, hard to keep Active/Attention * * Yes, Memento is not OAI
- 15. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Scale: 1 projectat once Who: LC plus invited implementers Process: Email, Meetings, Documentation Audience: Limited domain, Limited Involvement Outreach: Participants at existing conferences Benefits: Focused, Flexible But: Not very Open, hard to keep Active/Attention Project+ Scale: Library of Congress
- 16. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Community Scale: IIIF Scale:2.5 projects at once Who: Open community, Non-gating consortium Process: Formal, agile process defined, Releases Audience: Community, Open Involvement Outreach: Participants at existing conferences Outreach events Dedicated conference Benefits: Focused (-ish), Open, Active, Flexible (enough) But: How to resist the slippery slope of success?
- 17. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Web Scale: W3C Scale:25-30 projects at once Who: Gating consortium + invited experts Process: Formal process defined Audience: Web, Community Groups Outreach: Dedicated conferences, Workshops Press releases, Member organizations Conferences, Outreach, ⊠Benefits: Focused? Open? Active? Flexible? But: Easy to argue against the above! ?
- 18.
- 19. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Global Scale: ISO,ICOM Scale: ????? projects at once Who: Member countries / organizations Process: Formal processes Audience: Everyone? Outreach: ????? Benefits: ????? But: !!!!!!
- 20. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Standards are MadeOf By People Linked Art, 2019 IIIF, 2016 W3C TPAC, 2014
- 21.
- 22. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Community Leadership 1. KnowYour Audience 2. Meet on Their Terms 3. Have a Conversation 4. Create Opportunities for Meaningful Participation /ht Catherine Bracy, @cbracy
- 23.
- 24. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Evaluation /ht Michael Barth,Ulm University ïŒ Abstraction level ïŒ Comprehensibility ïŒ Consistency ïŒ Discoverability / Documentation ïŒ Domain Correspondence ïŒ Few Barriers to Entry ïŒ Extensibility ïŒ Infrastructure
- 25. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Evaluation â TradeOffs? 1. Basic: Functionality vs Comprehensibility 2. Ease: API Publisher vs API Consumer 3. Scale: Community vs Audience (+ Abstraction & Domain)
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu 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 10. Define success, not failure (for extensibility) https://iiif.io/api/annex/notes/design_patterns/
- 38. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu W3C Priority ofConstituencies In case of conflict, consider ⊠https://www.w3.org/TR/html-design-principles/ â â users ⊠over authors ⊠over implementors ⊠over theoretical purity. Everyone Annotators Tool Builders Ontology
- 39.
- 40.
- 41. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Usable? ⊠usability isthe 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 â â
- 42. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu With thanks toPatrick Hochstenbach, @hochstenbach Who is the Audience for LOD?
- 43.
- 44. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu The API isthe 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 â â
- 45. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu W3C Priority ofConstituencies 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
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Linked Art Profile ALinked Open Usable Data model, collaboratively designed to work across cultural heritage organizations, that is easy to publish and enables a variety of consuming applications. Main 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
- 53. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu Linked Art Collaboration Workingto 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
- 54.
- 55. @azaroth42 rsanderson @getty.edu IIIF:Interoperabilituy Standardsand Communities @azaroth42 rsanderson @getty.edu [Standards] By thePeople, For the People Functional Comprehensible Complete Usable Publisher Consumer ⊠⊠âŠ
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
Editor's Notes
- #2Â Thank you.
- #3Â And thank you especially to Patricia for starting us off on such a thought provoking topic! I donât have her courage for a short talk and lots of questions, but I believe Iâll have a loud 5 minute warning about 10am. Iâd like to focus in a little on the interactions between standards and communities â their creation, adoption, and maintenance, rather than the technical details of the standards themselves. How we can make those interactions, and this one, a dialogue and not just consumption. How can we balance innovation, with consistency and sustainability? What are some of the pitfalls that prevent good standards from reaching the necessary critical mass, such that as a community, we can provide better, sustainable services.
- #4Â That sounds like a big topic for a year long course, let alone a single discussion! Iâll focus on digital cultural heritage standards that Iâve had some part in across a variety of organizations and timeframes, and the lessons that I have learnt along the way.
- #5Â I realize this is kind of a CV slide, but I promise this is the only one. And if you donât know me, itâs actually a pretty good introduction. Non-web protocol for search and browse of library catalogs. A web-oriented attempt to capture the good parts of Z39.50 A web service for harvesting metadata records, same time as SRU A more recent attempt to bring PMH into the modern web stack, via sitemaps An early ontology for Linked Data aggregations of web resources Time-travel for the web! HTTP layer access to web archives. Linked Data model and protocol for Annotations of web resources Access to Images and presentation information to render them And weâll get to this one towards the end!
- #6Â Apart from Z39.50 and OAI-PMH, Iâve been part of the editorial group for all of these specifications. I was part of the Z39.50 Implementers Group or ZIG, and spoke often with folks in the early days of PMH while I was working on SRU, and implemented both. Why spend so much time working on standards?
- #7Â Standards are important for consistency. Consistency of models, of data, of systems. And consistency is a prerequisite for interoperability of systems, which is the important thing. I borrow Stefan Gradmanâs division of interoperability into six facets, but intend focus on technological standards, through the lens of the interactions between people, organizations and communities. [Functional = goals]
- #8 Okay, I still havenât answered why I really care about standards. To me itâs about Impact â In order to connect people with the information theyâre seeking, and with each other, we need standards for interoperability, because achieving that aim cannot be done in isolation. Connected systems and connected, consistent data are needed to truly connect people with knowledge and the worldâs cultures. And that connection, where the water hits the rock, is where impact is generated. As an aside, I have taken this exact photo, but my personal photography digital library is just a year by year folder backed up to dropbox. Which brings me to âdigitalââŠ
- #9 To me, Digital Libraries are just libraries, because âDigitalâ is a means and not an end. Similarly, Digital is not just the web, although we might be excused for thinking that way these days, to Vint Cerfâs horror. I believe that Digital is really shorthand for âconnected to the networkâ, which exists to connect people with each other and with knowledge and culture. Or ads and cat videos, as it turns out ⊠to everyoneâs horror.
- #10Â To put it another way, standards let us work together, without having hundreds of people in hundreds of meetings. They let us implement technologies and create information independently, safe in the knowledge that the standards weâre conforming to will ensure consistent data and APIs, that in turn will drive highly usable applications. That they successfully separate and balance the concerns of the data publisher and the data consumer. Why a photograph of keas, other than the New Zealand connection? Keas will work together to accomplish their objectives, to the same degree as chimpanzees.
- #11Â Sometimes those objectives are a bit harder to achieve, like figuring out how to get into your car or what the windshield wipers do. Some standards are very successful. Some have seen very little adoption, regardless of how good they might be in isolation. What Iâm going to explore is the interactions at a personal and community level, not the technical details of how to unlock the doors and replace windshield wiper blades. How people interact in the context of defining and using technical interoperability standards, rather than how the machines that work for us interact.
- #12Â Which is why I was so happy to see the theme of this yearâs conference! Standards are developed by connecting people that share similar goals, that would be advanced by working together. This raises questions about the scale of the organization or standards body, the related scope for the potential audience and the process by which the standards are created, disseminated, adopted, and maintained.
- #13 There are four questions to answer about the interaction between the standards process, and the relevant communities. [âŠ] The answers are different at different scales, from small groups up to global organizations.
- #14 And in thinking about the scale of communities, how should we consider the effects of it on the standards, the process and their adoption? Direction and vision are required... the focus of the community needs to be articulated clearly and convincingly. Communities need awareness and understanding of the problems that they are facing, and the motivation to work together to overcome them. There needs to be leadership, but not at the expense of being open and welcoming. Participation is the key requirement in solving practical challenges, not reputation. And Active participation, not just lurking. The community needs to not only think about the end result, but actively consider and adapt how it is getting there. So Flexible, not Agile? I prefer the notion of the community being flexible but strong â when the willow tree sways with the wind itâs flexible, but is true to its purpose. A cat agilely avoiding a dangerous situation doesnât address the challenge, it just avoids it. Agility lets you dance around the problem, Flexibility lets you overcome it. Focused, Open Active, Flexible ⊠or FOAF. That should be google unique, right?
- #15Â PMH, ResourceSync, ORE. I know Memento is not an OAI spec, instead itâs RFC7089, but the participants and scale are approximately the same. OAI work is typically funded by grants, rather than by the participating institutions. This provides some benefits in terms of diversity, funding dedicated work and holding outreach events, but conversely makes it harder to sustain once the money runs out. At project scale, itâs much harder to be involved. Either youâre part of the project, or youâre not. There arenât clear on-ramps to bring people in to the work, or for how they can participate meaningfully. Project scale relies heavily on brilliant, strong leaders with a great vision.
- #16Â This may look familiar! LC as an organization has more pans in the fire than just Z39.50 or SRU, there were connections between MARC development and Z39.50 development of course. Which brings it up slightly towards community scale, but without most of the benefits of that scale. The biggest challenge for work at the project scale is the same as for any research project â sustainability not of the documentation, but of the community of implementers. The constant attention needed to grow the active user base is very hard when many participants have moved on to something else.
- #17Â $10k or $2500 to be part of the consortium, but it doesnât limit access to participation. Slippery slope â hope the front row didnât /feel/ that.
- #18Â From $8k to $80k for big commercial organizations, and does limit participation other than for world class experts.
- #20 ISO has 164 countries as its members. The US representative is ANSI, which has 270 thousand members. It accredits NISO, which has 221 members, as the US representative to TC46 for information standards. NISO then also works with other groups to provide more recognized support for standards work, such as Z39.99 ⊠or Resource Sync. ICOM, the International Council of Museums and thus MUCH smaller than ISO, still has 40 thousand members. It then has a documentation committee, CIDOC, which has a subcommittee for the CIDOC Conceptual Reference Model. Which is foreshadowing for what this Linked Art thing is. Why this slide with so much punctuation, and so little content?
- #21Â Standards are made by people, and it is hard to generate consensus with more than about 20 people in a room. The W3C recognizes this and explicitly says that working groups should be about 20 people, and should be split if they grow much larger. As more people get involved, it is harder for everyone to participate meaningfully, the process needs to be more formal, and building consensus takes longer. The global organizations are simply member management, and do not work directly on the standards, instead they subdivide back down again to a manageable scale. And here is the primary conundrum of standards work -- if only 20 people can work on a specification, how can there be a community that is involved?
- #22Â Katherine Skinner, Executive Director of Educopia introduced me to this notion of the community engagement pyramid. There are a few people at the top of the pyramid, and increasingly many as you move down the tiers. In the IIIF community, for example, there are probably 5 or so active leaders, but a good 20+ experts and advocates, maybe 50-100 contributors, 500 or more members that aren't constantly engaged but are actively following, and then an impossible to determine number of people on the edges looking in. Or rather, looking up. The point is not to have a hierarchical and fixed structure, but to recognize that people look upwards and it is the sign of a healthy community when everyone on the tier above is reaching down to help those who want to take on a bigger role to do so. In order to be successful, we need to have a solid understanding of how to work together strategically, while advancing our own organizations' immediate goals.
- #23Â Catherine Bracy gave an outstanding keynote at the Museum Computer Network conference when she was Director of Community for Code for America, where she explained these four requirements for successful community leadership. First, know your audience. Who is the community, and who, as a community leader, do you need to be working directly with. Secondly, reach out to those people on their terms, not on yours. You need them to participate, and for that, they need to understand and agree with the goals and direction. Thirdly, have a continuing conversation with the community about everything! And make opportunities for people to actively and meaningfully participate. Through participation you're building the ladders to bring them to the next level of the pyramid.
- #24Â Given those two notions of the pyramid and the necessity for intentionally creating opportunities to participate at all of the levels, what sort of design principles are needed for the process and structure of standards? How do we engage with the community, such that they feel confident in adopting the work and more importantly contributing to it because it meets their immediate needs.
- #25Â 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.
- #26 Several of these factors are not orthogonal, but instead correlate in some fashion. I think there are three areas where trade-offs between the factors become unavoidable. The first is the basic trade-off between functionality and comprehensibility. As you add more functionality, it becomes harder to understand. Without enough functionality, you donât have a product that anyone wants. Without comprehensibility, everyone might want it, but no one is willing to make it. Secondly there is always some trade off between the publisher of the API or data, and the consumer of it. For example, publishing a plain JSON document statically on the web is very easy for the publisher, but can make for a lot of network requests and following links for the consumer. Conversely, something like GraphQL allows the consumer to specify by example exactly the information and structure that it needs, but takes a lot more work for the publisher. And finally thereâs a complex interdependency around the scale and overlap of the people defining the specification, and the scale of the intended audience. There are two other factors here, the correct abstraction and domain correspondence are dependent on the audience ⊠but being managed by the community defining the standard. Okay, some opinions that will maybe cause some controversy, as to where each of the standards fall on these axes.
- #27Â Iâve learnt that the easiest way to generate controversy or at times outrage is to present personal, qualitative opinions in a quantitative style. So here are some graphs that look like real data, but really just represent my opinions for you to disagree with at the end ï
- #29Â Scope creep drags up the functionality and down in comprehension.
- #38Â Observing the effects of these sorts of qualities of APIs, and their effect on adoption and the engagement of the community, has then been codified in various design principles or design patterns documents. The IIIF community has the following patterns, which address the points from the previous graphs.
- #39 The design principles for perhaps the most successful information standard ever, HTML, is also based on the interaction of the standard with people, and termed the priority of constituencies. [âŠ] Wait, a *semantic* architect is agreeing that theoretical purity of the ontology is the lowest priority? Is the world ending? What have I done with the real Rob Sanderson??
- #40 This is where we get to consistency of data, and its interaction with people. I am strongly convinced that LOD is the right technical solution ⊠but it hasnât seen strong adoption, and we can easily see why in terms of the previous criteria for how people and standards interact. What we really need is not just LOD but âŠ
- #41Â LOUD. Linked Open Usable Data. Standards allow for data to be consistent, but for usable applications to be built, the data also needs to both be usable and explicitly be concerned with that application usability.
- #42Â 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 LOD publishing, any recommendations about usability need to take into account the consumer. * Usability is thus dependent on, and determined by, the Audience
- #45Â 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.
- #46 To reapply the priority of constituencies in the context of LOUD âŠ
- #47Â But this is another correlated trade-off. In Linked Data, the API is directly tied to the model, and therefore there is a relationship between the usability of the API and the completeness or semantic correctness of the model.
- #49Â Bibframe 1.0 was terrible. It was complex without actually addressing the issues, worse than Simple Dublin Core, which at least has enough to get /something/ done with. Then you have frameworks further up the usability scale like Web Annotations and EDM, and a little more complete, but by no means everything you want to say. The IIIF Presentation API is, demonstrably, about as usable as a linked data API can get ... but we're constantly fighting to stay at high usability by resisting requests to add arbitrary features. Then comes the slippery slope that schema.org is further down ... still usable for now, but they're constantly adding to it ... and not in a sustainable or directed fashion ... until you hit rock bottom with CIDOC CRM and the meta-meta-meta statements available via CRMInf.
- #50Â The zone to be in is where the area under the point is maximized. So if the line is the likely possible values, anywhere in this target zone is the optimal area for a semantic API.
- #51Â Part of the good practices or design considerations though, is that if you only need half of the completeness, you should not be punished in terms of usability to the half that you donât need. You should be able to get close to the maximum usability for the particular use caseâs completeness requirements.
- #54 We think that we have the right people, with the right commitment to participation, and have learnt from the open but formal processes of previous work to have a good chance of dramatically improving the way that museum metadata is published. Okay, so to summarize what we have learnt, and thus what we hope to apply in Linked Art âŠ
- #55Â Standards are made by people for people, and require a commitment to engage with the community that constitutes the audience. That community must feel welcome, and have the ability to participate meaningfully, not just in a community group walled garden or in meaningless voting procedures. The organization that defines the specification doesnât need to be a globally recognized standards body, it just needs to speak for and work on behalf of the community.
- #56Â Standards need have enough functionality to be useful, but not so much as to be incomprehensible. Similarly, they need to be be complete enough to fulfil the use cases, but no so complete as to become unusable. They need to balance the ease of implementation by publishers and consumers.
- #57Â There may or may not be a spoon, but there certainly is no magic bullet. There is no one correct answer that magically solves all standards problems. The right answer for one community, specification or set of use cases might be completely wrong for another. Iâm afraid I donât have a short, pithy checklist of actions to take a photo of and apply at home The only way to know that youâre on the right path is to be keep focused on the task, be open to meaningful participation, remain active (or at least attentive), and be flexible in the face of changing requirements and environment.
- #58Â Most importantly, the process needs to actively create opportunities for meaningful participation by the people that the standard is intended to serve. Without engaging with the audience, not only is it impossible to know if the standard is successful, I believe a stronger assertion, that it is impossible for the standard to be successful.
- #61Â Scope creep drags up the functionality and down in comprehension.
- #64Â Bibframe 1.0 was terrible. It was complex without actually addressing the issues, worse than Simple Dublin Core, which at least has enough to get /something/ done with. Then you have frameworks further up the usability scale like Web Annotations and EDM, and a little more complete, but by no means everything you want to say. The IIIF Presentation API is, demonstrably, about as usable as a linked data API can get ... but we're constantly fighting to stay at high usability by resisting requests to add features. Then comes the slippery slope that schema.org is further down ... still usable for now, but they're constantly adding to it ... and not in a sustainable or directed fashion ... until you hit rock bottom with CIDOC CRM and the meta-meta-meta statements available via CRMInf.