GILS Home | About | Policy | Standards | Systems | Index | Search |

DASL/GILS Alignment Workshop

There was a workshop on DASL/GILS Alignment at Microsoft in Redmond, WA on January 26-27, 1999. Attendees were: Adam Bosworth, Eliot Christian, Jim Davis, Alex Hopmann, Andrew Layman, and Archie Warnock.

Prior to the Workshop, some notes regarding the DASL RFC from a Z39.50/GILS perspective were compiled. Subsequent to the meeting, a message on the results of the Workshop was circulated to the DASL, GILS, and XER communities.

Discussions about DASL/GILS Alignment focused on the feasibility of building gateways between DASL clients and GILS servers (DASL-GILS Gateway) and between GILS clients and DASL servers (GILS-DASL Gateway). (GILS and DASL use somewhat different terminology for equivalent concepts--see DASL/HTTP and GILS/Z39.50 Terminology Cross-Reference.)

The immediate objective of the DASL-GILS Gateway is to enable access to the installed base of Z39.50 servers. The immediate objective of the GILS-DASL gateway is to expose issues of DASL expressability. The GILS-DASL gateway is not necessarily to be implemented, as there are  no operational DASL servers at this time.

The following points are based on the notes were taken by Jim Davis during the workshop:

• GILS to DASL gateway
• State table
• GILS SEARCH attributes
• GILS use attributes in DAV
• Controlled vocabulary subject terms
• Thesaurus as separate property
• Mandatory structure attributes
• Optional structure attributes
• DASL to GILS gateway
• DASL to Geospatial Data Clearinghouse
• Geospatial Data Clearinghouse Goal

GILS to DASL gateway

• INIT
  • authenticate (name + password) - Basic
  • version, capabilities - OPTIONS
  • preferred record size
  • store for use in SEARCH
• SEARCH
• PRESENT
• SCAN: not needed
• SORT: not req'd in GILS

State table

• INIT: OPTIONS (usually succeeds)
• SEARCH:
  • translate to SEARCH
    • select only the props that are in Brief element set
  • store results
  • return count of records
    • Piggyback search need not be supported
• PRESENT
  • return stored records. If client requests elements other than Brief, redo SEARCH. (server could cache results of search, so this need not be very expensive. Alternative is to select allprop in first SEARCH, but this is always expensive.)

GILS SEARCH attributes

• use == property
• structure == see below
• relation == operator
• truncation (right, left, none) == like
• position not used or rare
• completeness not used or rare

GILS use attributes in DAV

• Define a URN namespace for XML elements.
  • GILS to choose, e.g. http://www.iso.ch/BSR
• mandatory GILS Use attributes
  • title, originator, distributor, record source, date,
  • subject (controlled and uncontrolled unified) (see controlled vocab subject terms)
  • any/anywhere -> DASL contains
• available GILS use attributes (about 100)
  • probably all have straightforward mappings into DAV properties.
• Locally-defined attributes
  • servers may use URNs,
  • legacy GILS clients use URL of server + dbname + string attribute name
  • or invent umbrella URN for namespace, e.g. http://gils.net/locally-defined

Controlled vocabulary subject terms

• treat thesaurus as a separate property, use conjunction
  • thesaurus is also a surrogate for subject
  • URL namespace for thesauri desirable
• make each controlled subject a unique property
  • URL namespace for thesauri
  • legacy thesauri handled by convention
• structured literal, with element for thesaurus
• add 'thesaurus' as an attribute to literal

Thesaurus as separate property

<and>
   <eq>
      <prop><subject/></prop>
      <literal>fff</literal>
   </eq>
   <eq>
      <prop><thesaurus/></prop>
      <literal>mesh</literal>
   </eq>
</and>

Mandatory structure attributes

• Word == DAV:literal
• wordlist == use disjunction
• date == implicit in property
• Urx == implicit in property
  • but Urx in full text requires dt markup (DASL extension required.)

Optional structure attributes

• Phrase
• integer
• date-range - use disjunction
• bounding (arbitrary closed polygon)
  • implicit on property (e.g. epicenter)
  • use literal with some serialization, e.g. 128,70;129.5,71;130,82...
  • Maybe also a dt attribute

DASL to GILS gateway

• QSD Z39.50 defines Explain, but it's not widely implemented so in practice. Therefore a DASL UI client should allow human to enter properties not advertised as searchable. Besides, DASL servers (e.g. raw file systems) might not support omniscient QSD either, so the issue is the same.
• OPTIONS
• SEARCH :: SEARCH + PRESENT
  • PRESENT uses GRS
  • may have to request a larger element set in order to obtain selected property
• what URL in the href?
  • GILS localnumber is always a unique key
  • URLs could be to gateway (encoding local state)
  • The URL in href need not be an http URL anyway

DASL to Geospatial Data Clearinghouse

Geospatial Data Clearinghouse Goal

DASL clients can search Z39.50 servers

• Objective 1 - Demonstrate a DASL client searching a Geo Clearinghouse server
• Objective 2 - Suggest modifications to DASL protocol (and alternate grammar
  if basicsearch is inadequate) and generalize any special coding needed to achieve
  the first objective
• Objective 3 - Inform future version of GILS/GEO Profiles to simplify DASL
  interoperability

FAQ | Comments | Contacts | Privacy Notice | URL:/dasl/workshop.html