1 / 11

Is there a Problem?

This article explores the challenges faced by the Z39.50 protocol in terms of being perceived as non-web-friendly, difficult to implement, and lacking clear documentation. It also addresses the need to separate application specifications from transfer syntax and proposes potential solutions such as revising the standard, improving documentation, creating better tools for developers, and integrating Z39.50 into mainstream products.

Télécharger la présentation

Is there a Problem?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Is there a Problem? • Is there a problem? • Are we happy with the status quo? • Should we prepare to fold our tents and wait for the next great thing?

  2. Who are our users/ customers/communities? • Who is our market? Who do we want to serve? Who wants us to serve them? • Libraries • Archives • Museums • Online information companies • Corporate information centers • Scientific communities • Distributed learning environments -- builders and/or tool providers • People who must distribute data for free -- govt?

  3. Who are we not trying to serve? • Are what we providing not a good fit for others? • People whose business is in the interface may not be interested in an open IR protocol. • Web search engines? Maybe their business model is changing?

  4. What are the Applications? • Searching structured data and metadata • Searching full-text • Distributed searching

  5. Who are we?What are our competencies? • Developers • protocol implementors • application developers • Users • Competing interests

  6. What is the problem? • Not web-friendly, not perceived as web friendly • Not friendly, period. • We are wedded to a single protocol and expect that all people’s implementations will interoperate. • What is not the problem -- weaknesses in the standard…but there is a problem with way it is perceived and how it is implemented. • People do not want to run anything except an http server. • Content of the standards? Are the functions of the standard needed? Re-evaluate the functions? • Interoperability problems

  7. What is the problem? • Tying the protocol to bits on the wire. • Implementation approach of TCI/BER is not acceptable to some developers • The way the standard is written and difficult to understand. Documentation problem. • The lack of APIs since many application developers don’t want to worry about the underlying protocols. • It is misrepresented, misunderstood, etc. • Technical elegance over simple solutions • BER is pretty opaque -- lack of tools

  8. Two classes of problems that can be solved by... 1. The standard needs to be revised to make it clearer. • Clear communication for utility of Z39.50 in people’s application -- semantic model • Making the standard clearer • Communicating to others the utility of the standard. 2. The standard is hard to implement. • Creating better tools for application developers (but also need for clear documentation for understanding the concepts/model of Z39.50). • Technical changes to the standard. • Separating abstract syntax and semantics from transfer mechanisms

  9. How do we broaden usage?Solving the problems • By whom? • For whom? • How can we make it easier for application developers who don’t want to worry about network protocols? • Let’s do a Java Bean for Z39.50. • Getting Z39.50 into mainstream products

  10. Addressing the Problems/Solutions • Get people together to move forward on the separation of application specifications (ASN.1semantics) from transfer syntax (E.g., implementing the XER encoding of ) • Try to test these things out. • Could be multiple approaches (XER, XP, SOAP, RFC 822

  11. What is the problem?

More Related