- From: LeVan,Ralph <levan@oclc.org>
- Date: Wed, 24 Apr 2002 09:45:02 -0400
- To: "'Mike Taylor'" <mike@tecc.co.uk>
- Cc: barbara.shuh@nlc-bnc.ca, azaroth@liverpool.ac.uk, Theo.vanVeen@kb.nl, Kevin.Gladwell@bl.uk, www-zig@w3.org
> -----Original Message----- > From: Mike Taylor [mailto:mike@tecc.co.uk] > Sent: Wednesday, April 24, 2002 6:24 AM > > But doesn't this point up a fundamental shortcoming in CQL as > currently conceived, namely, that it's not benefitted from the lessons > of the attribute architecture in terms of refining an access point > from one set with qualifiers from another? That's the thing that > makes interoperability between cross-domain and bibliographic servers > and clients possible in the AA world -- surely CQL doesn't want to > discard that? I think we have a fundamental difference in our understanding of the lessons to be learned from attribute architectures. Claim #1. Users think about indexes and databases think about indexes. So why are we putting attribute combinations on the wire? Claim #2. Supporting arbitrary attribute combinations from clients does not improve interoperability. That's why we're busy creating profiles now. Those claims are why I wanted to use indexes in SRW. Now, I think AttributeSets are a great invention. While the W3C is busy trying to create the semantic web, we have done the real work that helps a client (or client developer) make the mapping between the client/user's view of an index and the databases view of an index. Without AttributeSets, we wouldn't be able to explain the difference between a DC.Creator and a Bib-1.Author. But, we don't need to put those attributes on the wire. And if we do put the attributes on the wire, then we have to be prepared for attributes that we didn't expect. I don't want to do that any more. Ralph
Received on Wednesday, 24 April 2002 09:45:04 UTC