B Will It All Fit Together The need

B Will It All Fit Together? The need for standards and the technical challenges Brian Kelly and Paul Miller UK Web Focus Interoperability Focus UKOLN B. Kelly@ukoln. ac. uk University of Bath P. Miller@ukoln. ac. uk Bath, BA 2 7 AY http: //www. ukoln. ac. uk/ UKOLN is funded by the Library and Information Commission, the Joint Information Systems Committee (JISC) of the Higher Education Funding Councils, as well as by project funding from the JISC and the European Union. UKOLN also receives support from the University of Bath where it is based.

Contents • Introduction • Background: • The Web • Library Information • Problems • Solutions • Deployment Challenges • Conclusions 2 B

About Us UK Web Focus • Advises UK HE community on web developments • JISC-funded • Represents JISC on W 3 C Interoperability Focus • Advises on issues related to the deployment of ‘interoperable’ services across libraries, museums, archives, etc. • JISC and LIC funded • Represents community on various international metadata and standardisation initiatives 3 B

About You How many are in the following groups: “Webmasters” Library catalogue/system Managers Others What do you hope to gain from the session? …and if we use terms you don’t understand… ask! 4 B

Aims of this Session The aims of this session are: • To provide an update on web developments • To illustrate ways in which the web relates to other library–based electronic information • To outline some of the advantages of adopting a standardised solution to problems • To look at the ways in which things might move in the near future 5 B

Standardisation Community • Library groups • Cultural Heritage • Government Proprietary • De facto standards • Often initially Formal appealing (cf • Formal international/ Power. Point, PDF) national standards • May emerge as processes W 3 C standards • ISO, CEN, NISO, ECMA, • Produces W 3 C Relevant ANSI, BSI… Recommendations • Can be slow-moving Bodies • Managed approach and bureaucratic 23950 • Protocols initially IETF • Produce robust PNG developed by • Produces Internet standards W 3 C members HTML Drafts on Internet protocols • Decisions made by Java • Bottom-up approach to developments W 3 C, influenced by • Protocols developed by HTTP member & PNG interested individuals URN public HTML • "Rough consensus and working whois++ review HTTP 6 code" B

Background to the Web The web was initially very successful due to its simplicity HTML Client Netscape IE Lynx Give me foo. html from www. bath. ac. uk Here it is Server Apache IIS. . . The web is based on three key architectural components: 7 Data Format: HTML (Hyper. Text Markup Language) Addressing: URLs (Uniform Resource Locators) Transport: HTTP (Hypertext Transfer Protocol) B

Background to Library Information • Long tradition of categorising information • Card catalogue (local) • OPAC (local-ish) • Web. PAC (potentially global) • Proven track record on formalising practice • AACR (rules for cataloguing) • MARC (rules for transfer) • Z 39. 50 (linking and access) 8 P

Problems With the Web Although the web has been successful, there are problems: • Performance - the web is too slow • Resource discovery - lack of a metadata architecture • HTML’s lack of arbitrary structure • Accessibility - difficulties of accessing information by visually impaired, people using PDAs, etc. • Functionality - difficult to deploy interactive applications on the web • Addressing • etc. 9 B

Solutions (Today) HTML 4. 0 used in conjunction with CSS 2. 0 (Cascading Style Sheets) and the DOM provides an architecturally pure, yet functionally rich environment HTML 4. 0 - W 3 C-Rec • Improved forms • Hooks for stylesheets • Hooks for scripting languages • Table enhancements • Better printing Problems • Changes during CSS development • Netscape & IE incompatibilities • Continued use of browsers with known bugs 10 CSS 2. 0 - W 3 C-Rec • Support for all HTML formatting • Positioning of HTML elements • Multiple media support DOM - W 3 C-Rec • Document Object Model • Hooks for scripting languages • Permits changes to HTML & CSS properties and content B

HTML's Limitations HTML 4. 0 / CSS 2. 0 have limitations: • Difficulties in introducing new elements – Time-consuming standardisation process (<ABBREV>) – Dictated by browser vendor (<BLINK>, <MARQUEE>) • Area may be inappropriate for standarisation: – Covers specialist area (maths, music, . . . ) – Application-specific (<STUD-NUM>) • HTML is a display (output) format • HTML's lack of arbitrary structure limits functionality: – Find all memos copied to John Smith – How many unique tracks on Jackson Browne CDs 11 B

XML XML: • • Extensible Markup Language A lightweight SGML designed for network use Addresses HTML's lack of evolvability Arbitrary elements can be defined (<STUDENTNUMBER>, <PART-NO>, etc) • Agreement achieved quickly - XML 1. 0 became W 3 C Recommendation in Feb 1998 • Support from industry (SGML vendors, Microsoft, etc. ) • Support in Netscape 5 and IE 5 12 B

XML Deployment Ariadne issue 15 has article on "What Is XML? " Describes how XML support can be provided: • Natively by new browsers • Back end conversion of XML - HTML • Client-side conversion of XML - HTML / CSS • Java rendering of XML Examples of intermediaries 13 See http: //www. ariadne. ac. uk/issue 15/what-is/ B

Namespaces and Linking XML Namespaces What if an XML document contains a <TITLE> for the document and a <TITLE> for the name of a book? XML Namespaces enable such clashes to be resolved The naming conventions are defined at a URL XSL stylesheet language will provide extensibility and transformation facilities (e. g. create a table of contents) 14 B

Challenges facing library information Competition? Amazon. co. uk Many–MARC Integration with other scholarly resources • AHDS Gateway • SOSIG • Web of Science Alternative delivery • on–line document delivery? 15 Obfuscation ? Complication ! P

Addressing (Problems) URLs (e. g. http: //www. bristolpoly. ac. uk/depts/music/) have limitations: • Lack of long-term persistency – Organisation changes name – Department shut down or merged – Directory structure reorganised 16 • Inability to support multiple versions of resources (mirroring) ISBN/ISSN also problematic: • Not tied to the work • Nor to the item at hand P

Addressing (Solutions) DOIs (Document Object Identifiers): • Proposed by publishing industry as a solution • Aimed at supporting rights ownership • Business model needed • Do two copies of a digital object get separate DOIs? PURLs (Persistent URLs): • Provide single level of redirection 17 P

Joined–up thinking • Users can be anywhere. They need to search anywhere • Physical locations at which digital data are stored should not impinge upon access • Disciplinary boundaries should not be a barrier 18 P

Z 39. 50 • International Standard (ISO 23950) • Permits remote searching of databases • Access via Z client or over web • Relies upon ‘Profiles’ • Used outside the library 19 See http: //www. ariadne. ac. uk/issue 21/ P

Z 39. 50 Challenges • Profiles for each discipline • Defeats interoperability? • Bib– 1 bloat • Largely invisible • Seen as complicated • Seen as expensive • Seen as old–fashioned • Surely no match for XML/RDF/whatever 20 P

Z 39. 50 Futures • International Interoperability Profile • Cross–Domain Attribute Set • Attribute Architecture • Bib– 2 • XER • DNER/RDNC/NGDF/ New Library? 21 P

When to use it? • To provide remote access to a large catalogue of material (an OPAC, a museum collection management system…) • To facilitate/allow searching of your resources alongside like resources from elsewhere 22 P

P What is ‘Metadata’? – meaningless jargon – or a fashionable term for what we’ve always done – or “a means of turning data into information” – and “data about data” – and the name of a film director (‘Luc Besson’) – and the title of a book (‘The Lord of the Flies’). 23

What is ‘Metadata’? Metadata exists for almost anything; • People • Places • Objects • Concepts • Web pages • Databases. 24 P

What is ‘Metadata’? Metadata fulfils three main functions; • Description of resource content – “What is it? ” • Description of resource form – “How is it constructed? ” • Description of resource use – “Can I afford it? ”. 25 P

Introducing the Dublin Core • An attempt to improve resource discovery on the Web – now adopted more broadly • Building an interdisciplinary consensus about a core element set for resource discovery – simple and intuitive – cross–disciplinary – international – flexible. 26

Introducing the Dublin Core • • 15 elements of descriptive metadata All elements optional All elements repeatable The whole is extensible – offers a starting point for semantically richer descriptions • Interdisciplinary – libraries, museums, archives… • International – available in 20 languages, with more on the way. . . 27

Introducing the Dublin Core • • Title Creator Subject Description Publisher Contributor Date Type • • Format Identifier Source Language Relation Coverage Rights http: //purl. org/dc/ 28

Implementing the Dublin Core • Normally thought of as being HTML • Most recently possible in XML/RDF • Dublin Core ‘view’ onto richer databases • DC elements in Bib– 1 • DC elements form basis of XD attribute set • DC closely mapped to GILS See http: //purl. org/dc/ 29 See http: //www. ukoln. ac. uk/metadata/resources/dc/ datamodel/WD–dc–rdf/ P

P RDF Data Model RDF - the metadata framework Resource • Based on a formal data model (direct label graphs) • Syntax for interchange of data • Schema model page. html Cost Property Prop. Name 30 Cost Value Property page. html £ 0. 05 Prop. Obj Instance. Of Property. Type Value Valid. Until 11 -May-98 Cost £ 0. 05 Valid. Until 11 -May-98

Authentication We can’t (can we? ) just make all these resources available for free. Users need to authenticate. ATHENS / Digital Signatures … Authenticate once per site ? Authenticate once per query per site ? Complicated by Z 39. 50 searches authenticate once per Target queried ? ! Ideally, authenticate once when you log on in the morning! 31 P

Deployment How to I deploy “the new stuff” in the real world? Barriers: • • • 32 Browser x doesn’t do CSS, … Authoring tools don’t do RDF I prefer the web as it is I haven’t the time to learn anything new This Z 39. 50 thing is just too hard B

Approaches to Deployment Various interesting new technologies have been outlined How can they be deployed in our environment? Should we: • Ignore them? • Accept them fully? • Accept them partly? 33 B

Ignore New Developments We can chose to ignore new developments, and continue to use, say, HTML 3. 2: Safe option, with no new training, support or software costs Experience in effectiveness, limitations, etc. L Fails to address current performance problems L Fails to address accessibility problems L Fails to provide new functionality L Service likely to look "old-fashioned" compared with competition 34 B

Fully Accept New Developments We can chose to more wholesale to, say, HTML 4. 0 and CSS 2. 0: Can be exciting to be at leading edge Performance benefits Accessibility benefits Based on open-standards Provides motivation for users to upgrade browsers Likely to be solution at some point (cf. Gopher) L Backwards compatibility problems with old browsers L Costly to deploy new authoring news, training, . . L Likely to be bugs and incompatibilities with new tools and browsers 35 B

Implement "Safe" Solutions An alternative is to use "safe" parts of technologies which are backwards compatible and avoid major browser bugs Attractive sounding compromise position K Lose some functionality, but not all L Can be difficult or expensive to find "safe" options (does. margin-left work on IE on SGI? ) L Tools may not allow safe options to be chosen L Lack of validation tools for checking conformance with restricted set of specification Note 36 See <URL: www. webreview. com/guides/style/ insafegrid. htm> for unsafe CSS 2. 0 properties B

Decision Time What would you opt for? Stick with current technologies Cheap, default option. Continuation of performance and accessibility problems. Unlikely to be long term solution. Deploy new technologies More expensive option. Functionality, performance and accessibility benefits. Access problems for old browsers. Use "safe" new technologies May require home-grown tools and support. Avoids some of the problems of other solutions 37 B

An Alternative An alternative approach to deploying new technologies is available: • Use more intelligent server-side software • Use "proxies" to address limitations of browser technologies. The term intermediary was used in a paper [1] at the WWW 7 conference to describe this approach • Protocol solutions, such as Transparent Content Negotiation (TCN) and (CC/PP) [1] "Intermediaries: New Places For Producing and Manipulating Web Content" 38 B

Intelligent Server Software Simple model: • Server receives request for resource • Server delivers resource to client More sophisticated model: • Server receives request for resource • Server processes header information from client • Server delivers resource to client based on client information Can be implemented used server add-ons such as PHP/FI and MS Active Server Pages or by use of Content Management systems 39 B

Web Conclusions To conclude: • New web protocols are still being developed • Deployment of new technologies can be expensive or time-consuming, but is likely to be needed • Various deployment models: r. Don't implement Implement fully r. Implement via proxy Other solutions • We can't do it all ourselves • Experience in developing (wide-area) web applications will help in developing intermediaries 40 B

Non–Web Conclusions • Cross–domain interoperability is a laudable goal • Technical developments continue in a rapidly shifting environment • Libraries are not alone • To make an OPAC more widely available, look at Z 39. 50 • To raise awareness of library web pages, or to describe particular resources, look at a ‘metadata’ solution like Dublin Core • We need to move beyond ‘traditional’ users (who know where the library is and what if offers)… 41 P