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?
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 --
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?
What are the Applications?
• Searching structured data and metadata
• Searching full-text
• Distributed searching
Who are we?
What are our competencies?
• Developers
– protocol implementors
– application developers
• Users
• Competing interests
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
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
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
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
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
What is the problem?