>
> Google doesn't badge itself as a 'registry' - a term which
> would, I assume, leave most real end-users scratching their
> heads?  Now, depending on who the end-users of this
> 'registry' are intended to be, this may not matter - since
> the intended users may understand completely what a registry
> is in this context?  Though, even from my perspective, I'm
> confused about why this is called a registry rather than a
> search engine?
> The point is that the simplicity of Google is not just in the
> way the interface is presented (the HTML, etc.) - the whole
> concept is very simple and intuitive.  Even people who are
> new to the Web very quickly understand what it is that Google
> does for them.

Since the prototype interfaces are for "insiders", we've not worried about
how to brand them to the larger user community right now; we're trying to
find what works.  We do have a lot of confusion over the terms and something
may be better.  But since the people funding the work call it a registry, we
use that name for now.

I'm not convinced that calling it a search engine will help; people may say
"I use Google, why a should I use different search engine"  A non techie
name may help (does everyone remember how to expand the Yahoo acronym or
what Google used to be called?)

>
> As an aside, I wonder if we have similar problems with the
> word 'repository'?  We all use the word repository in a
> semi-technical sense amoungst ourselves - though, as I hinted
> in my response to Debbie, we can still argue about whether a
> 'repository of metadata records' is really just a
> 'catalogue'?!  But somehow that term also leaks out into our
> conversations with end-users.  So we go and talk to our
> academics or computing service staff about setting up a
> 'institutional repository' when the words they really want to
> hear are 'content management system' or even just 'database'.
>  Again, I wonder if some of them leave scratching their heads
> and wondering what on earth we're on about.  I assume that
> this was the thrust behind the recent request for
> clarification about the various different names for
> repository-like objects that we now use?  But anyway, I digress...

I agree -- in setting requirements for ADL, no one can agree on what in
means to have a repository of learning content.

>
> On a related note, Google doesn't give me links labelled
> 'metadata'!  And it doesn't give me many obvious links to
> XML.  And why should it, since, with the exception of RSS,
> there is no useful use that I can make of XML links in my
> browser.  By and large, links to XML are for machines, and
> should therefore be encoded in appropriate (invisible) ways
> (as per the recent discussion about using the XHTML <link> tag).

We have requests to display the metadata.
Users say they just can not pick the content they want by looking at a short
summary description or the values of a couple of keywords, and they don't
want the entire description shown on the results page.  We can't rely on
users building complex queries.  On the web you can get to the content from
the link and make decisions about it being useful or not.  For the learning
content, given security, rights, etc., you may not be able to get to it, and
have to rely on some kind of metadata to make decisions.

I can change the link label to "content description" or something else.
Things like XML are for exploration to see what people want to see, and to
help in current debugging.

> This is why we want repositories to support search protocols
> like SRW of course... because then, our server-based LMS
> (Blackboard, WebCT or
> whatever) can do the search on our behalf, bringing back the
> object into the LMS, where it can be dealt with appropriately.
>
> The alternative model is to move the LMS onto the desktop
> where it can be closely integrated alongside the end-user's
> browser.  That way, when I discover a learning object using
> Google, your 'registry' Web interface or some other Web-based
> search tool, I can make use of it directly on my desktop,
> within my personal LMS.  The desktop LMS would handle my
> interaction with the learning object - but the tracking
> information and so on would be stored server-side.  Exactly
> how our desktop-based email clients use the IMAP protocol.
> OK, a Web-based email client is useful occasionally - but not
> many people would want to use one all the time!?

This is why the registry has to support multiple interfaces; web,
search/access protocols.  We have to enable various uses outside of the
registry.  In ADL we also have other business drivers, including overall
enterprise content management in distributed repositories and finding
authoritative content in certain situations.

>
> But part of the problem is not just that end-uers want things
> to look like Google... they want them to *be* Google!
> Because that is where the end-user is doing much of their
> current resource discovery work - we can't always expect them
> to come to us (even if what we offer them looks superficially
> like Google)?

But since Google doesn't find what we need, we have to provide something
that (1) does, and (2) is easy to use.  So the Google metaphor is helpful
until someone comes up with a better one.

        - Dan