This page is to document the set of design principles and requirements regarding ways of accessing OpenGuides data in a global context - ie without needing to know which guide it should go in. This is more details of what is discussed in #64.

What are the goals?

  • search for a place globally - automatically be redirected to the appropriate guide
  • Editing/browsing interface
  • Global API interfaces

How should they be implemented?

  • running a completely separately codebase to integrate requests and searches and distribute them to guides using an open API
  • cache results?
  • Dedicated OpenGuides server possibility - Dom has hardware to be set up
  • Integration into (redesign/replace this website)

What is required of the OpenGuides codebase?

  • Standard styles as a base
  • Expose what area they think they cover in a machine readable format

What challenges need to be met?

  • How do we cope with coverage where there is no existing guide?
    • Single global guide that can have data siphoned off it if someone wants to create a more specific guide?
  • Existing global special purpose guides? (eg
  • Vaguely consistent, but adaptable branding/styling so that people don't get completely confused
  • Defining scope of a guide?
    • cotswolds and oxford OGs don't overlap, but touch. If you did a bbox for both, they would overlap though
Last modified 15 years ago Last modified on Dec 4, 2006, 4:46:20 PM