The metadata of the LACITO Archive are now coded in OLAC

[Steven Bird]

Michel Jacobson writes:
> We are pleased to announce that all metadata of the LACITO Archive are now
> coded in both Dublin Core and OLAC formats.

The LACITO records are now harvested by the OLAC prototype service
provider, developed by Eva Banik.  A query for "lacito" in the OLAC search
form will return all the records.

> Remark:  In formatting our metadata in OLAC, we felt the need for a
> convention allowing us to specify the software tools which we provide for
> processing certain resources. In particular, we provide specialized
> stylesheets, etc., for processing our XML documents. A possible solution
> would be to link the XML resource to a software resource via the <Relation>
> element. The current definition of this element would require us to code
> the OAI identifier of the software resource as its content, e.g.:
> <Relation>oai:lacito:myPgm</Relation>. However, this leaves open the
> question of how the user is to call the software tool and apply it to a
> given XML resource.

I think we shouldn't be too ambitious here, but focus on the so-called
"collocating objective" of metadata.  The OLAC system must make it easy
for users to form appropriate sets of records.  In this case, we'd want to
pull out a record for a data resource, plus records for supporting software
resources.  With this set, it should be possible to visit the archive(s) in
question and inspect the documentation to learn how exactly to apply a
given software resource to a given data resource.

I guess it is conceivable that the vocabulary for Relation could be
enriched to encompass the variety of ways in which a piece of data might
require a piece of software.  Thus, instead of the simple vocabulary item
"requires" we could have complex items like "requires/browsing" to specify
that the indicated software resource is just for browsing the data, as
opposed to editing, sorting, converting or querying the data.

While there may be a case for this, I think there's a stronger case for
sorting out the vocabulary for Type.functionality, and then applying this
vocabulary to the software resources themselves.  Then a query tool would
be specified as such, and the relationship between a data resource and this
tool would be obvious.  I'm aware that this solution doesn't completely
specify the way in which a piece of data requires a tool, yet it largely
meets the need and is independently motivated.  We should at least do this
first and then re-evaluate.

Any other viewpoints?

-Steven