From jacobson at IDF.EXT.JUSSIEU.FR  Wed Sep 19 09:02:26 2001
From: jacobson at IDF.EXT.JUSSIEU.FR (Michel Jacobson)
Date: Wed, 19 Sep 2001 11:02:26 +0200
Subject: The metadata of the LACITO Archive are now coded in OLAC
Message-ID: <WED.19.SEP.2001.110226.0200.OLACIMPLEMENTERS@LISTSERV.LINGUISTLIST.ORG>

Greetings,

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

These metadata can be accessed using the OAI protocol:
· directly, via the URL
http://lacito.archivage.vjf.cnrs.fr/servlet/metadata (e.g. by entering the
request: http://lacito.archivage.vjf.cnrs.fr/servlet/metadata?verb=Identify).
· via Hussein Suleman's OAI repository explorer
(http://oai.dlib.vt.edu/~oai/cgi-bin/Explorer/oai1.1/testoai). 
· (Coming soon) via the OLAC Service Provider at
http://www.language-archives.org 
· by consulting the archives on our site: http://lacito.archivage.vjf.cnrs.fr 

The OAI service provider is implemented in XSLT. The source code
(stylesheet) may be found at:
http://lacito.archivage.vjf.cnrs.fr/archives/styles/oai.xsl

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. A non elegant solution might be to create an OAI
identifier for each way the software in question can be called. Some
extension of the semantics of the Relation element or of the controlled
vocabulary of its attribute may be desirable for this purpose.


From sb at UNAGI.CIS.UPENN.EDU  Wed Sep 19 10:46:18 2001
From: sb at UNAGI.CIS.UPENN.EDU (Steven Bird)
Date: Wed, 19 Sep 2001 06:46:18 EDT
Subject: The metadata of the LACITO Archive are now coded in OLAC
In-Reply-To: Your mail dated Wednesday 19 September, 2001.
Message-ID: <WED.19.SEP.2001.064618.EDT.SB@LDC.UPENN.EDU>

Michel,

Great, thanks.  I'll chase up the harvesting from our end.

-Steven


From sb at UNAGI.CIS.UPENN.EDU  Thu Sep 20 17:08:47 2001
From: sb at UNAGI.CIS.UPENN.EDU (Steven Bird)
Date: Thu, 20 Sep 2001 13:08:47 EDT
Subject: The metadata of the LACITO Archive are now coded in OLAC
In-Reply-To: Your mail dated Wednesday 19 September, 2001.
Message-ID: <THU.20.SEP.2001.130847.EDT.SB@LDC.UPENN.EDU>

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


From jcgood at SOCRATES.BERKELEY.EDU  Tue Sep 25 02:41:08 2001
From: jcgood at SOCRATES.BERKELEY.EDU (Jeff Good)
Date: Mon, 24 Sep 2001 19:41:08 -0700
Subject: CBOLD now OLAC compliant
Message-ID: <MON.24.SEP.2001.194108.0700.OLACIMPLEMENTERS@LISTSERV.LINGUISTLIST.ORG>

Hello,

The CBOLD data provider is now both OAI 1.1 and OLAC compliant. The
address of the provider is:

http://linguistics.berkeley.edu/cgi-bin/CBOLD/OAI/1.1/cbold_data_prov.cgi

Jeff Good
CBOLD


From jacobson at IDF.EXT.JUSSIEU.FR  Wed Sep 19 09:02:26 2001
From: jacobson at IDF.EXT.JUSSIEU.FR (Michel Jacobson)
Date: Wed, 19 Sep 2001 11:02:26 +0200
Subject: The metadata of the LACITO Archive are now coded in OLAC
Message-ID: <WED.19.SEP.2001.110226.0200.OLACIMPLEMENTERS@LISTSERV.LINGUISTLIST.ORG>

Greetings,

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

These metadata can be accessed using the OAI protocol:
? directly, via the URL
http://lacito.archivage.vjf.cnrs.fr/servlet/metadata (e.g. by entering the
request: http://lacito.archivage.vjf.cnrs.fr/servlet/metadata?verb=Identify).
? via Hussein Suleman's OAI repository explorer
(http://oai.dlib.vt.edu/~oai/cgi-bin/Explorer/oai1.1/testoai). 
? (Coming soon) via the OLAC Service Provider at
http://www.language-archives.org 
? by consulting the archives on our site: http://lacito.archivage.vjf.cnrs.fr 

The OAI service provider is implemented in XSLT. The source code
(stylesheet) may be found at:
http://lacito.archivage.vjf.cnrs.fr/archives/styles/oai.xsl

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. A non elegant solution might be to create an OAI
identifier for each way the software in question can be called. Some
extension of the semantics of the Relation element or of the controlled
vocabulary of its attribute may be desirable for this purpose.


From sb at UNAGI.CIS.UPENN.EDU  Wed Sep 19 10:46:18 2001
From: sb at UNAGI.CIS.UPENN.EDU (Steven Bird)
Date: Wed, 19 Sep 2001 06:46:18 EDT
Subject: The metadata of the LACITO Archive are now coded in OLAC
In-Reply-To: Your mail dated Wednesday 19 September, 2001.
Message-ID: <WED.19.SEP.2001.064618.EDT.SB@LDC.UPENN.EDU>

Michel,

Great, thanks.  I'll chase up the harvesting from our end.

-Steven


From sb at UNAGI.CIS.UPENN.EDU  Thu Sep 20 17:08:47 2001
From: sb at UNAGI.CIS.UPENN.EDU (Steven Bird)
Date: Thu, 20 Sep 2001 13:08:47 EDT
Subject: The metadata of the LACITO Archive are now coded in OLAC
In-Reply-To: Your mail dated Wednesday 19 September, 2001.
Message-ID: <THU.20.SEP.2001.130847.EDT.SB@LDC.UPENN.EDU>

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


From jcgood at SOCRATES.BERKELEY.EDU  Tue Sep 25 02:41:08 2001
From: jcgood at SOCRATES.BERKELEY.EDU (Jeff Good)
Date: Mon, 24 Sep 2001 19:41:08 -0700
Subject: CBOLD now OLAC compliant
Message-ID: <MON.24.SEP.2001.194108.0700.OLACIMPLEMENTERS@LISTSERV.LINGUISTLIST.ORG>

Hello,

The CBOLD data provider is now both OAI 1.1 and OLAC compliant. The
address of the provider is:

http://linguistics.berkeley.edu/cgi-bin/CBOLD/OAI/1.1/cbold_data_prov.cgi

Jeff Good
CBOLD