Public Comment

[comment-form@oasis-open.org]

Comment from: mail@makxdekkers.com

The following is the response of the DCMI Directorate in the public 
review of the document: 

Search Service Interoperability
Working Draft 01, 17 November 2003
Document identifier: wd-egov-searchservice-01
Location: http://www.oasis-open.org/egov/docs/
Editor: Eliot Christian, U.S. Geological Survey <echristi@usgs.gov>

-------------------------------------------------------------------- 

The basis for the document seems to be that a "search service" is 
the single way that Governments can create interoperability between 
government organisations and with external users of government 
information ("Governments must offer to intermediaries an 
information search interface").

However, the document does not make clear the difference between (to 
paraphrase): "search services/interfaces" as "database or Web 
applications designed to help people find information" as opposed to 
"search services/interfaces" as "specifications for structured 
messages passed by protocols". It therefore does not make clear that 
"search services" (in meaning #1) would need to run special software 
to support the "search services" of ISO 23950 (meaning #2).

The underlying model -- not explicitly stated -- seems to be that 
search systems are implemented (only) through real-time, on-line 
connections between Clients and Servers. Although this approach has 
been proven to work in one-to-one communications, the document does 
not acknowledge that there are known problems with searching across 
multiple sites, as would be required for multiple government 
organisations providing different (and possibly overlapping) parts of 
the information that is being sought.  (For example: multi-site 
search mechanisms are only as strong as their weakest link, so 
sophisticated error handling is needed, and searches can result in 
incomplete or confusing results, for example when update frequencies 
are not coordinated or when servers are temporarily unavailable.)

The document need not (and probably should not) discuss such
technical problems in detail.  However, it should at a minimum
distinguish search services in general from client-server-based
search services in particular and explain that such services
presuppose an installed base of special software on both the client 
and server sides for handling queries in real time.

In this context, the document should at least acknowledge "metadata 
harvesting" as an alternative and widely implemented approach to 
implementing interoperable search over distributed bodies of data.  
Ideally, the document would explain that an emerging practice of 
"institutional repositories" uses the Open Archives Initiative 
Protocol for Metadata Harvesting to compile centralised indexes for 
searching by harvesting metadata records from multiple servers that 
do not themselves need to support "search services" (in meaning #2) 
with special software.  Ideally, the document would also acknowledge 
that this approach addresses some of the problems with multi-site
searching mentioned above.

Taking a broader view of the requirements for searching and 
interoperability would provide a context for correcting the 
document's depiction of Dublin Core.  In the current draft, Dublin 
Core is described only as a set of tags for "embedded metadata", 
while the Open Archives Initiative is mentioned only as something 
which uses "this style of metadata". This seems doubly misleading 
because Dublin Core metadata may not just be embedded in Web 
documents, but is more often stored separately from the data itself, 
while the OAI Protocol is in fact not designed to do anything with 
embedded metadata at all. On the contrary, the OAI approach is 
based on the harvesting and merging of metadata records -- an 
approach which has, in turn, underscored the need for standards for 
describing resources.

Dublin Core, then, could be better characterized not as a "profile" 
of "meta element names" for use in "embedded metadata", but as a 
standardised set of semantics intended for merging into search 
services (in meaning #1) such as those provided for institutional 
repositories -- or at any rate in the context of "Metadata for 
Digital Objects" as opposed to just "Metadata within Digital 
Documents".

The section on Service Registries (Section 1.4.5), finally, could 
perhaps mention registry-building efforts within the Dublin Core 
community to help communities of practice converge on interoperable 
semantics.

Kind regards, Makx Dekkers.

--------------------------------------------------------------------
Makx Dekkers                                    mail@makxdekkers.com
Managing Director                    Dublin Core Metadata Initiative