Print

Print


This thread has been very interesting, as it signals the beginning of the
"big change" we have all been anticipating with the advent of XML and how
that might make things easier for all of us using SGML to deliver content
via the web. It's here, only so far it doesn't look easier! Just kidding;
in fact it's very exciting to already be thinking about being able to serve
our EAD content in a multitude of ways.

I wanted to chime in because Alvin mentioned the solution/workaround we
indeed are using in the "Museums and the Online Archive of California"
project (see http://www.bampfa.berkeley.edu/moac/ if you want details),
which is to simply include both HREF and ENTITYREF pointers inside links so
that this way our finding aids can have maximum portability (used in union
systems like OAC which may have sophisticated SGML software, or also on
local systems which may find it easier to deal with HREFs and/or be
XML-based - as is the case with my museum and it sounds like others on this
list). As Alvin mentions this solution only need come into play when you
need both to be available.

Alvin, you also mention that HREF is not good because it does not allow you
to distinguish between types of links, or links to types of resources (is
it a hypertext link or an image placement?). In our finding aids we've been
indicating this information with the ROLE attribute available in both
DAOLOC and EXTPTR. So if the DAOLOC ROLE is set to "thumbnail" our server
knows to translate that link into an <img src=....but if it's set to
"hi-res" our sever creates a link ala <a href....likewise if an EXTPTR ROLE
is set to "image" then again we know to insert an <img src, but
ROLE="hyperlink" is an <a href, etc. Anyway, this is not the solution for
everyone, but couldn't HREF be safely used along with appropriate
attributes which spell indicated how that link should be manifested
(without the need for server-side parsing programs)? Just an thought.



Richard Rinehart
----------------
Information Systems Manager & Education Technology Specialist
Berkeley Art Museum/Pacific Film Archive
@ University of California
http://www.bampfa.berkeley.edu/
----------------
& President, Museum Computer Network, http://www.mcn.edu/




>>In the example above, we would encode the EAD link as
>><extref href="myentity.sgm"/>
>
>Michael, this has a profound impacy on how we interchange
>our finding aids and use them in union databases. If you
>are using <archref>, say, to link to another finding aid
>you cannot assume your "myentity.sgm" is a unique filename
>in a union environment simply because it's unique within
>your own repository. In our Museums in the Online Archive
>of California some of our members are using delivery software
>which does not understand the redirection employed by the
>entity mechanism. We've solved this problem by using both
>an href attribute and an entityref attribute. Our union
>server, Dynaweb, ignores the href attribute which it cannot
>use in a union environment, and uses the entity mechanism
>instead. The individual institution will use the href as
>that's all its software can understand:
>
><extref href="myentity.sgm" entityref="myentity"/>
>
>It's redundant information to be sure, but the fault is
>not with SGML or XML, rather it's in that particular
>software package. Interchange is the most fundamentally
>important aspect of EAD and it's important not to compromise
>this. I don't think everybody should use this duplicative
>method, just those few repositories which are using delivery
>software which is underpar.
>
>Href is not a good attribute. There is no indication of the
>*kind* of resource it's pointing to. If you are converting
>to html for example, in one case you would be translating
>to an <A HREF=""> tag for hyperlinks, and <IMG HREF=""> for
>images, <APPLET> for still more complex resources. You face
>the same problem in Panorama stylesheets. The conversion or
>rendering software can only guess at what it should do. If
>the software is sufficiently sophisticated, it could parse the
>filename or url and make a decision based on the file
>extension (Panorama cannot do this):
>
><extptr href="somefile.gif"/>  we can guess is an image
><extptr href="somefile.html"/> we can guess is a hyperlink
>
>But how about more complex urls, such as this one taken from
>an actual finding aid:
>
>http://webpac.library.yale.edu/webpac-bin/wgbroker?new+-access+top.Yale_Lib+
>search+open+ke+FHF5564
>
>Href has a powerful attraction in that it is so familiar
>to people used to dealing with HTML. The redirection employed
>by entities is something people are not familiar with but
>it's the *right* way to do this kind of thing in SGML and XML
>and not for pedantic reasons only.
>
>Alvin Pollock
>Lead Programmer
>Online Archive of California
>http://sunsite2.berkeley.edu/oac



Richard Rinehart
----------------
Information Systems Manager & Education Technology Specialist
Berkeley Art Museum/Pacific Film Archive
@ University of California
http://www.bampfa.berkeley.edu/
----------------
& President, Museum Computer Network, http://www.mcn.edu/