Exploiting the value of Dublin Core through pragmatic development
Download as PPTX, PDF2 likes1,116 views
The document discusses applying agile software development practices to information modeling and application profile development. It focuses on three areas: 1) using application profiles to combine metadata elements for specific uses, 2) learning from iterative software practices like continuous testing and collaboration, and 3) the importance of working openly with users and communities. The talk promotes applying techniques like minimum viable products, iterative design, and open participation to help application profiles better meet user needs.
Exploiting the value of Dublin Core through pragmatic development
- 1. Paul Walk Head of Technology Strategy and Planning, EDINA [email protected] @paulwalk Exploiting the value of Dublin Core through pragmatic development
- 3. which are you? • an information scientist/researcher • an information professional or practitioner • a software or systems developer
- 4. which are you? • an information scientist/researcher • an information professional or practitioner • a software or systems developer
- 5. Eric Miller introduced some broad themes in his keynote last year at this conference I’m going to really narrow the focus…
- 6. 1. application profiles 2. learning from software development practice 3. working openly
- 8. application profiles “Application profiles consist of data elements drawn from one or more namespace schemas combined together by implementors and optimised for a particular local application.” Heery & Patel: Application Profiles: Mixing and Matching Metadata Schemas
- 9. range of application profile types
- 10. • a small application profile using properties from 4 namespaces: • 11 properties from Dublin Core (dc and dcterms) • 2 properties from NISO Open Access Metadata and Indicators • 8 from a new namespace - ‘rioxxterms’ • constraints imposed through several controlled vocabularies • it has one purpose: to provide a mechanism to help institutional repositories in the UK comply with the RCUK policy on open access. • it is not designed to provide general interoperability!! http://www.rioxx.net
- 11. the focus of today’s talk
- 14. most software is not designed as infrastructure
- 19. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. http://agilemanifesto.org
- 20. applying this to application-profile development • Individuals and interactions over processes and tools • doing what works - and what makes sense to the user • Working software over comprehensive documentation • an application profile is fundamentally a set of documentation! • Customer collaboration over contract negotiation • working as closely with users as possible • Responding to change over following a plan • iterative - short development cycles punctuated by review
- 21. transferable Agile techniques • iterative design and development with users • high-bandwidth interaction with users • short iterations or ‘sprints’ • documentation can be made this way just as with code • MVP • ‘pave the cowpaths’ • continuous testing during development (and after!) • testing aids development and understanding
- 22. iterative design and development with users
- 23. it’s not a marathon!
- 24. Minimum Viable Product (MVP) • start with the simplest thing that could possibly work • only revise an application profile in response to real changing requirements • ‘interoperability’ is not the goal of a focussed application profile
- 26. continuous testing • extremely important • should be mechanistic, or semi-automated, wherever possible • so that it actually gets done! • should deliver immediate and useful feedback • not just the usual XML schema validation - this is often important, but it is not enough
- 28. continuous testing (RIOXX) - reporting
- 30. encouraging (& avoiding barriers to) participation
- 31. working in the open - explaining decisions
- 32. conclusion: we need to work together. look around you - this is the community to make it happen!
- 33. DCMI’s next anniversary (21) is another important birthday in some places… Saúde!
- 34. Paul Walk Head of Technology Strategy and Planning, EDINA [email protected] @paulwalk thanks for listening! (Obrigado pela atenção)
- 35. Credits • All images are my own except for: • Sprinters: • https://upload.wikimedia.org/wikipedia/commons/b/be/ • Caipirinha: • https://upload.wikimedia.org/wikipedia/commons/9/92/ • Pave the cowpaths: • www.flickr.com/photos/wetwebwork/2847766967/ • Software developers: • https://commons.wikimedia.org/wiki/File:Hackathon_TLV_2013_-_(31).jpg • Dodo: • https://commons.wikimedia.org/wiki/File:Dodo_(15574061408).jpg • Kanban: • https://flic.kr/p/gKbsnf
Editor's Notes
- #2: thank you Eric, and my thanks to the University, and to DCMI, for the opportunity to speak - it’s a privilege. And thanks also to the translators who will be working hard! I am going to try to speak more slowly than normal for the sake of our brilliant translators, so if I speed up, you need to tell me. Like this :-) take the photo.
- #3: Stu Weibel started a tradition of taking a photo like this - continued by others including Eric Miller last year I think.
- #4: show of hands… you can answer ‘yes’ to more than one of these! the DCMI community has a history of combining these different groups make the point about the various communities in DC - the combination of professional and technical is better than the sum of the parts
- #5: I have more of a background in the last of these three. I used to be a software developer, and now I guess I might be called a professional technologist. Over the years, I have become involved with standards development mainly because I wanted software to work better. That’s my perspective on this - I think in terms of working software.
- #7: and talk about these 3 things
- #8: I want to talk a little about application profiles - and approaches to developing them. Application profiles should be at the heart of how Dublin Core is implemented
- #9: Application profiles are where the theory meets the practice. The development of an AP can be quite different to the development of a standard, mainly because of its scale, but also because it can involve a different range of people
- #10: application profiles exist on a continuum - from quite generalised through to more specific (explain the diagram)
- #11: I’m going to use the development of an application profile called RIOXX to illustrate some of the ideas I’m presenting today RIOXX is a classic application profile in that it adds constraints to existing terms and adds new ones as necessary
- #12: I want to focus on one end of this continuum - the application profile which is developed to work in some quite specific use-case
- #13: These are different things, usually done by different people. These two groups need to understand each other. Problem is, they work in different ways.
- #14: and you don’t want infrastructure to be changing all the time. That’s kind of the point. DC is embedded in all kinds of domains, software and hardware. development cycles are long
- #15: the development cycles for a lot of software are getting much shorter (explain idea of sprints and the Kanban in the background image)
- #16: We have a saying in English: “as dead as a Dodo” :-) the poor Dodo looks really sad in this photo… change - evolution - is intrinsic to most successful software
- #17: the challenge is to align how each does change-management. (explain how this is about aligning expectations - Agile development is about embracing change for example,
- #18: my recommendation: involve software developers in the development of the AP and learn from how they work
- #19: now we’ll take a look at some things which have emerged from software development over recent years and consider how we might apply these to application profile development
- #20: ‘Agile’ has become an overloaded term, but it’s important to remember that it started somewhere with some principles: Agile Manifesto couches itself in a series of ‘preferences’ - the phrases in bold towards the left worth noting this is now 14 years old!
- #21: be Agile. Agile development is not a good fit necessarily for standards development, but it has something to offer the development of application profiles, especially if they are very focussed and tightly coupled to a specific problem
- #22: Agile techniques - transferrable to AP development we’ll briefly examine each of these
- #23: the images are of work and experimentation by colleagues at UKOLN in 2010 - work led by Dr Emma Tonkin whom some of you will know Borrowed a rapid prototyping method from software development - often utilising paper and post-it notes - allows users and domain experts (who might not well-versed in information modelling) to participate effectively and comfortably. F2F is important!
- #24: The development of an information standard is a Marathon The development of an AP should be done in a series of short iterations - or sprints. the convention in Agile software development is for sprints lasting 2 weeks - our experience with RIOXX was that 4-6 weeks was more appropriate
- #25: interoperability is aspirational - it’s an appropriate concern for a standard like DC, and even for a broader domain application profile, but not for a focussed AP like RIOXX I maintained a determination throughout the development of RIOXX that we would not add anything simply because it might aid general interoperability.
- #26: If users have already started to go in a certain direction, recognise this and adapt accordingly. Running code is really important.
- #27: the subject of testing, and how we can apply it to AP development is worth a whole session on its own.
- #28: using the example of RIOXX this is testing sample data from all known RIOXX implementations on a regular basis - and it’s completely automated doing this openly on the web creates incentives for people to fix things!!
- #29: a detailed report is generated for each of the systems tested this shows both the system developers and the end-users exactly which aspects of the AP have been invalidated even shows them the raw data where these issues have occured
- #30: a few words about this.
- #31: This blog post, announcing the results of one of the sprints, has 45 comments, from a range of information professionals, software developers, domain experts and end-users. A mailing list tends to attract a community - and communities can be exclusive. RIOXX does not have a community - it just has people with vested interests and comments to make
- #32: an important aspect of working openly is explaining the rationale behind decisions - here we described all the options for the representation of a particular property, and explained why we chose the one we did. This allows us to get real engagement with users as well as developers (tell the story of the argument on skype and the open discussion here)
- #35: I’d be very interested to know what you think of this, and any questions you might have. Let’s show appreciation to the translators too.