Weibel Lines

Metadata: Semantics; Structure; Syntax

Peter Murray, aka the Disruptive Library Technology Jester posted an encapsulated history of the origins of the Dublin Core, and observed that he still is

trying to reconcile what differences exist between RDF and the DCAM based on these postings and comments from Stu’s blog.

I'm glad that people are engaged in trying to sort this out, even as I'm unhappy that its still unclear at this late date.  That it still IS unclear is incontrovertible (look at the caliber of people trying!).  I'm not very confident at this point that I can wash away the confusion, but it does seem potentially useful to reprise a part of my metadata talk that I used to give a lot.

Sharing metadata requires agreements on three topics:

1. Semantics: what is the meaning we are trying to convey in metadata assertions?  Meaning, of course, resides in the minds of people, not machines.  The focus of the Dublin Core effort has been to promote those shared meanings... and make them sharable.  The semantics bit is about agreeing about elements: author, publisher, date, etc.
2. Syntax: how do you take a set of metadata assertions and pack them so that one machine can send them to another, where they can be unpacked and parsed by machine logic or displayed and read by a person  with high probability that the meaning of the assertions travel unchanged from one mind to another. RDF documents refer to  serialization... the order of bits in a stream... actually putting the stuff 'on the wire.' (The careful readers and jaded among you may wonder why i changed the order of exposition  from the title of this post.  Best for last? no... hardest.)
3. Structure: You can't do syntax reliably unless you have unambiguous structure.  The sorts of things you have to specify in a well-structured metadata assertion (not an exhaustive list):

• The boundaries of a set of assertions (what constitutes a record)
• Cardinality - Can an element be repeated, and if so, is there a limit on the number?
• How is a name structured? What is the delimiter separating elements of a compound name (Prince and Bono excepted, most names are compound structures, many with surprising and confounding complexity).
• How is nesting managed?
• How are dates encoded? YYYY-MM-DD? DD-MM-YYYY? MM-DD-YYYY?
• How does one identify an encoding scheme that specifies the above question?
• How does one identify a value encoding scheme (rg. LSCH, MeSH, Dewey) from which metadata values can be chosen?  Are such schemes required or optional?
• Are metadata values specified by reference (URI) or by value (literal strings)?

Most of these issues are not addressed in RDF. The can be, of course... but without agreements about how to do so, people tend to do them this way and that, leaving us without the ability to share data effectively.  This is where the Dublin Core Abstract Model (DCAM) comes in, as it specifies how to structure these sorts of things in a way that makes the data sharable.

Is it perfect and generalizable?  No... its authors, in comments on my posts, have made evident that they make no such claim. Is it the best that is available for descriptive metadata?  I assert that it is, and that efforts to work towards an Uber-Metadata-Model should start with this effort and simplify or complexify as is necessary and sufficient to assure that metadata  can be shared across communities.

One last point.  DCAM is articulated in the vernacular of RDF, but the structure that it creates is independent of RDF.  If RDF passes into the graveyard  of once-or-never-mighty technologies, the abstractions it (DCAM) declares survive quite nicely.  Syntax independence: a goal we strove for from day 1 of the first DC metadata workshop.  It is a worthy metadata engineering principle.

To sum up: Defining semantics is a political process of reaching consensus.  Syntax is arranging the bits reliably so they travel comfortably between computers (RDF is a fine way to do this, but by no means the only way), and structure is the specification of the details necessary to layout and declare metadata assertions so they can be embedded unambiguously in a syntax.  A data model is the specification of this structure. 
-----
I was influenced to include semicolons in the title of this post by an article in today's NYTs, forwarded to me by Marguerite.  I LIKE semicolons, even if they are stodgy.
-----
Wary Ibises (or something like them) in Barwon Heads, Australia

A Glimir of the Future

I spoke at VALA 2008, Australia’s biennial library conference, this past week. My participation was spurred initially by a request to deliver a paper on behalf of OCLC's Robin Murray, who could not attend. Soon after I agreed, the organizers invited me to stand in for a keynote speaker who had to cancel due to a family emergency. My first ever double-substitution conference.

The topic of the conference (Libraries: Changing Spaces, Virtual Places) gave me a perfect opportunity to combine two areas of interest – social networking and canonical identifiers – to present a case for how library systems might bring their assets into sharper Web focus.

OCLC has been exploring an important facet of this problem (canonical manifestation identifiers), and the VALA conference afforded a timely opportunity to announce this exploration.  The tentative name for these identifiers: Global Library Manifestation Identifiers, or Glimirs for short.

The community at large is increasingly aware of the importance of canonical identifiers for FRBR entities, especially Group I entities (Works, Expressions, Manifestations, and Items).  Existing OCLC numbers approximate manifestation identifiers, but ironically, as the database grows in scope, this rough correspondence is reduced through the loading of records in various languages.  These are not duplicates, but rather alternative institutional, regional, or language representations that point to a given resource.

The need for explicit manifestation identifiers thus becomes more evident. We need identifiers that are globally scoped, business neutral, usable by all, and managed in either a centralized or federated manner.  To the extent that such identifiers are canonical – that is, become the dominant identifier for a given asset, they increase the “URI equity” for library assets and will strengthen the library presence on the Web.

Interesting and challenging issues arise in the design of such identifiers and their supporting infrastructure.  Broad adoption will require a careful balance of use-cases, business issues, and community participation in meeting the need.  All of this in an environment already crowded with myriad special purpose identifiers.  OCLC is launching a pilot to explore these issues.  An early proposal has been shared with a number of technical and policy leaders and their valuable feedback will be used to strengthen the effort and move it to the next stage.

Stay tuned.

-----
A surfer at Torquay beach on the coast south of Melbourne.

Roll over, George

Jonathan Rochkind made some thoughtfully peevish comments on my previous post on RDA and the Futures report which drove me (perish the thought) back to the document itself.

...I'm confused by your apparent sympathy with the Working Group
recommendations to suspend RDA work...

...That recommendation seems to instead be based on the fantasy that we need to spend lots of time 'testing' FRBR, at the end maybe deciding that FRBR is no good at all

I don't see this in the recommendations at all.  What i read (in recommendation 4.2.1, p 29) is a clear mandate to resolve the existing ambiguities in the FRBR model in order to:

provide a more robust framework for the creation of  the resource description and access rules that will be used in the future to support a broad range of searching options (also on page 29). 

This is essential, and should be undertaken in the light of functional pragmatism, not ideology.  And certainly I agree with Jonathan that there is little time to waste.  The Futures report does not impugn the value of FRBR, but simply recognizes that we as a community do not agree about the importance of Expressions.  If it is critical in other ways, I missed it.

There is much stronger concern expressed in the report about the uncertainties of RDA, having to do with unsubstantiated benefits, alignment with existing standards, and the business case for it (see the bottom of page 24).

The subsequent recommendation (on the next page: 3.2.1) is stated more strongly than I might have chosen.  But the heading (Suspend Work on RDA) is elaborated with untils, and makes clear that useful work has been initiated with JSC and DCMI, and should continue.

But any assertion that debates going on on the RDA list represent progress towards these goals is, in my view, whistling past the graveyard.

And as for Jonathan's generous remark:

In fact, I feel like you've expressed well the argument that I'd want
to submit as comments to the Working Group

I know that at least one of them reads my blog ;-)

-----
yes... THAT George Boole... taken in Cork, at the end of the DCC meeting on persistent identifiers in 2004

In fact, specifically, THIS George Boole: http://worldcat.org/identities/lccn-n83-144364 (thanks, Thom)

Failure Points and Manifestations

Ed Summers made several points worth amplifying in his comment to my previous post.

I do think there's enough space here for multiple players including the
Library of Congress. Indeed one could argue that designing a
bibliographic identification system with one central point of failure
is a bad idea.

The single point of failure argument is a serious issue, but not insurmountable.  We don't worry much about the Amazoogles being accessible through a single URL.  Partly this is because we know we can use other search engines, but perhaps more importantly, the economic stakes for reliability, combined with their technical wherewithal, mitigate against service failures.  It is fair to challenge whether OCLC can provide a similar level of service.  Perhaps the better question is what is an acceptable interval of service denial, and an acceptable mean time between failure?

The other part of this question is whether there is harm in multiple authoritative links?  I argue that there is harm, and in fact that this harm is partly the reason why library materials often fail to show up in the first few links on a given search.   I've written about this in a previous post, and I think it is critical that the community agree on a canonical URL for a given piece of library content.  To do otherwise... to promulgate many identifiers for a given resource, is to dilute the link currency of that resource, and render the resource less findable and less actionable:

• Machine comparisons of identifiers will fail to recognize two referents as the same resource
• Diluted identity leaves resources lower in linking algorithms and hence less findable on the open web
• Aggregation of given identifiers in social software systems will be similarly diluted

It is naive to imagine that we can obliterate all but a given canonical URL from use, or even that we should. It is useful to be able to, for example, hack a WorldCat identifier together from an ISBN in hand.  Still, when citing (on paper or on the Web) a given identifier, it should be the canonical URL, not a transactional URL or even an ISBN URL.  OCLC can go a long way towards promoting this goal by making the canonical URL -- the permalink -- a prominent part of the record in the user interface, as well as to redirect all other comparable URLs to that canonical URL so that it appears in the browser address window.

Ed goes on to say:

OCLC's vast holdings database is certainly important for resolving an identifier to the actual item. But for practical purposes of citation (identification) it's rarely necessary to talk about the item itself...normally referencing the manifestation will do fine.

I agree with this point entirely... in fact, the canonical WorldCat URL is the OCLC record number, which for practical purposes, rounds to a manifestation identifier.  It is the holding data, not the manifestation identifier, that gets you that last mile.

-----

What I believe to be Frigate birds, taken on the beach at Manzanillo, Mexico, at DC 2006

Libraries and the Soul of the Web

Tim Spalding, perhaps the most innovative of Internet library entrepreneurs, made a number of interesting points in the LibraryThing blog, Thingology, recently.  However one may feel about the details of his argument, he is partially correct that:

the failure of the LC and other libraries to get their data "out there" on the open web has hurt them... It has made them seem irrelevant, standing silent and apart from the great conversation....

I believe Tim's charge that we're responsible for our own irrelevance is true, at least in part. He is way too hard on LC, though, dumping the sins of the community all in one place. And it isn't as though nobody on the Web knows about anything going on in libraries.  But still... as a community we have been slow to get the data out there.  There are lots of reasons for this, having to do with business models, capitalization, culture, public mission, and more.  It is far too complicated to unpack in a blog post.

What Tim has achieved almost singlehandedly is to demonstrate both the power and appeal of remixing bibliographic data and people in system that is engaging, accessible, and useful.  If you're a librarian and haven't explored LibraryThing, then do so, and you'll get a glimpse of what Web 2.0 means for our community, and more importantly, to our patrons.  Keep in mind that this system became, by some measure, the 100th largest library in the US on less than a single person-year of development effort (and an enormous amount of Web 2.0 patron-contributed effort). I hope my admiration is evident. 

Tim goes on in this same post to say:

The first culprits are the online catalogs, ugly, backward things lamed with session-based URLs. If you want to link to the LC, you can't. The URL you get will only work for you, for ten minutes. Linking--the very soul of the Web--is impossible.

It may be that it is impossible to link to LC's catalog, but it just isn't an issue.  It is not the place anyone should link to.  Web blaspheme?  No.  LC is not (for most of the Web's clientèle), a lending library.  It is the source of most (and arguably the best) of the cataloging that libraries depend on.  Why not link to these records?  Several reasons, foremost of which is that while such links are suitable as citation links, they are not connected to the content itself -- that last mile problem again -- and arguably the problem at the center of the "very soul of the Web".

So, are libraries thus marooned forever in Real Life?  No.  If you want to link to library materials there is exactly one best way to do it: WorldCat.org.  By using a WorldCat identifier, you provide a persistent identifier that links not only to an authoritative citation record, but to the items themselves.  The Worldcat database is supported by the holdings data of the OCLC Cooperative, thus allowing patrons to find the library closest to them that holds the item.  There are also links to electronic content, directly accessible, even though it isn't 'held' by a library: an example. There are even links to buy items if one would prefer to own rather than borrow (and libraries get a cut!).  Check it out... buy a couple of my wife's books just to prove that it works.

If it sounds like I'm flogging my employer's product (and Marguerite's books!), I suppose I am.  But the fact of the matter is that when WorldCat.org came online last summer, the world's library content became web-addressable for the first time in a soul-of-the-Web way with persistent, globally-scoped identifiers that will work anywhere in the world that members of the collective provide services.  Even if OCLC went belly-up next year, can anyone seriously imagine that the community could afford to not sustain the WorldCat database?

Now, if only we could get the WorldCat team to stamp that permalink prominently at the top of every record.  Stay tuned.
-----
Disclaimer: The opinions in this, and all of my posts, are mine.  The are not reviewed by anyone at OCLC prior to publication.  I'm trying my best to make them the opinions of my employer.
-----
image: Winter lights in my front yard, when I was still enjoying the snow.

Library standards in the mainstream

Jon Udell's weekly podcast from February 16 features Dan Chudnov in a lengthy conversation about OpenURLs, COINS, xISBNs, FRBR, digital archiving, and other library geekery.  This is a long, but rewarding conversation that surfaces many issues of technical librarianship into one of the technical world's A-list blogs.  If you've been putting off raising your understanding of OpenURLs and related technolgies, this podcast will help contextualize contextual linking, and give you a roadmap for exploring a host of related technologies.

One of Udell's pet peeves is the difficulty of assuring the archival preservation of blogs, a medium that he, more than most, has invested in as a serious record of thought.  Conventional thinking has it that blogs are ephemeral, and who really cares if they are preserved?  I'm with Udell -- Blogs will become (are?) an important cultural and historical record -- even if they are ephemeral.  Remember the days when libraries were wringing their collective hands about preserving slow-burning acid-paper collections?  It was the so-called ephemera of earlier eras that caused the greatest concern, as these were precisely the materials that would disappear most quickly, and leave holes in the cultural record of their time.  So, today -- blogs.

Udell and Chudnov pod-pine for a business model for the preservation of blogs today.  Why not an inexpensive LOCKSS-like blog preservation service run by... who else... libraries?  Perhaps in Dan's new role in the Library of Congress he will be able to promote such a service.

-----

The canopy over the main platform of the Berlin Haupt Bahnhoff reprises the open elegance of major 2oth century European train stations in a modern facility in the heart of the city.

LOCKSS - Floating electronic librarianship to a higher level

Victoria Reich, of Stanford University, spoke about LOCKSS and CLOCKSS at OCLC this morning, following her colleague Mike Keller’s talk yesterday.   LOCKSS stands for Lots Of Copies Keeps Stuff Safe (though, it might be temporarily rewritten as Lots Of Coherent Knowledge from Stanford Speakers, given the excellent presentations we’ve enjoyed here in Dublin this week).

Many readers will have heard of these systems, especially LOCKSS, which has nearly a decade of development effort behind it.  If I were to characterize Mike Keller’s perspective as how we make libraries more Googlish, Vicky’s perspective is solidly in the realm of how to make the Web behave more like library shelves.  This may strike some as ho-hummish, but it is arguably among the most important missing links in making digital libraries solid enough to bear up as reliable stores of cultural assets.

Vicky builds her case on two core assumptions:

1. Democracies and libraries and are inextricably linked
2. Maintaining collections with design and intent distinguishes libraries from book warehouses

She amplified these assumptions by describing the attributes of print libraries that make them particularly suitable as reliable preservation systems:

• Resistance to Attack - replication of assets means they are less susceptible to:
  • Natural disasters 
  • Ideological extremists
  • Vagaries of governmental policy
• Self Healing - collaboration and resource sharing make access to print tractable (if perhaps a tad slow):
  • Interlibrary loan
  • Preservation copies

Vicky argues that the Web changed the relationship of libraries and publishers, and (at least potentially) compromised all of these attributes in one way or another, thereby weakening the link between libraries and the societies they support, and compromising the coherence of managed collections. LOCKSS is intended to help redress these issues.

She poses two key questions about electronic library data:

1. Who has custody?
2. Who gets access?

If it sounds a bit like divorce court… it IS a bit like divorce court.  The revenue stream belongs to the content owners, but the custody part resides with the people with the sensible shoes -- us. In the case of LOCKSS, this means a community governance model and library custody of data... but with constraints.  One important aspect of the model is that data previously 'purchased' remains accessible to members of the community that purchased it. That is, stuff paid for in the past, but for which current subscriptions are not in force, remains accessible.

This point is quite important, as it returns management of the collection back to the library.  Publishers may of course feel differently about this. Some endorse the model, others view their data as a time-sensitive licensed-commodity -- the electronic equivalent of taking materials off your shelf when you decide you don't want to (or can't) sustain the subscription (my metaphor, not Vicky's).

Which brings up a key issue in the LOCKSS model: Publishers must agree.  Agreement is simple to effect: slap a LOCKSS-friendly consent statement on the Web page (data ingest is by Web-crawler, so everything in this system happens pretty much automagically).  But not all publishers see through these same rose-colored glasses.  An earlier version of this post misquoted the number of titles  currently under LOCKSS management, but it is substantial and growing (thanks to Vicky for catching my error).  It will be interesting to see how it grows as a proportion of total ejournal usage .

LOCKSS also addresses the problem of format migration by supporting HTTP content negotiation. This too-little used feature of the HTTP protocol allows clients and servers to have a conversation about the  formats in which data can be provided and accepted.  LOCKSS clients use this information to do a best-match on-the-fly re-formatting of content so an obsolete format can be rendered as close as possible to the original, and without intervention by the reader. While I am skeptical as to how this holds up in a generalized way, it may the best way to address the problem, and will probably work reasonably well for common formats that can be expected to comprise the bulk of formally-published materials.

Vicky touched on a wide array of related issue that I cannot cover in one post, including CLOCKSS, a Controlled LOCKSS that differs very little in the underlying technology, but which is managed according to different policies that will be more appealing to a broad range of publishers. Another exciting prospect is the use of LOCKSS as a low-cost means of preserving semi-published, often poorly-curated content that is unencumbered by the constraints of publishing business models. And it fits particularly nicely into the role of libraries as managers of unique collections.  Blogs and institutional repositories are on their radar screen, and one can imagine other interesting possibilities. 

This is terrific work that evokes a higher professional calling than simply being handmaidens to the Amazoogles.  This is technology that is carefully thought out, low in cost, high in impact, and which can be wrapped in policies that surface the professional standards and culture of collaboration that define the library community.

-----

Image: Son, brother, wife & mother, coerced to pose in the Short North district in Columbus, around Thanksgiving, 2006

Global Scope and Global Uniqueness are Different

I have been poking around in the Life Sciences Identifier (LSID) spec in recent days, and in fact a few of the die-hard semgrail (semantic web discussion group) folks met to discuss it recently.

At one point in the spec, the authors reprise LSID functional requirements with reference to URN requirements (LSIDs are registered as a URN sub-namespace). The laundry list includes both:

• Global scope
• Global uniqueness

I stumbled at this distinction in my first reading. Global uniqueness is part of identifier canon law, but also trivial to achieve in today’s distributed networking environment. We know it is foundational, but we get it for free as part of DNS network addressing.

But what about global scope? My first reaction was to think that they had merely parroted something from the URN specs and it had no direct implications for the functionality of LSIDs. 

Further reflection occasioned an Aha! moment, however. Global scoping is not really an attribute of an identifier, but rather part of a service environment that comes into play when we deploy and propagate them.  My modest flash of insight on this is born of my thinking about identifiers having to do with WorldCat.org.  If we are as a community to increase the value of our links (that is, links to library-held materials), we need to agree on standard identifiers that are recognized and universally actionable (global scope of recognition).

The following identifiers are all valid within WorldCat:

http://www.worldcat.org/oclc/26160663&referer=brief_results

http://www.worldcat.org/search?q=083890596X&qt=owc_search

http://www.worldcat.org/search?q=083890596X

http://www.worldcat.org/oclc/26160663

Inspection tells us that 3 of the 4 are transactional identifiers and are thus less likely to be persistent. The last is an OCLC-number-based URL, which has, naturally enough, assumed the moniker of permalink in WorldCat. That’s the one to use. (It needs to be made more prominent in Worldcat.  Don’t make me click to get it… it should be in bold at the head of every record presentation)

Permalink is a good name here, but it is also misleading in that people use the term rather indiscriminately. For example, this blog entry has a permalink as well, but lets face it, its persistence extends only as far as the business case that supports it (that is, until I stop paying my annual fee to Typepad or Typepad goes out of business). In the case of a WorldCat permalink, it is a reasonable bet that they will be useful as long as there is a globally-scoped bibliographic database. 

Which brings me back to the point of this entry.  One of the virtues of having the entire Worldcat database available to the Internet Commons is that we have a stable identifier that is globally scoped and inclusive of what increasingly rounds to the world’s library assets (yes, I’m over reaching, but a bibliographic utility’s reach should exceed its grasp, or what’s a WorldCat for?)

If I use an identifier bound to a local library system or any locally-scoped system, then I’ve done little to reduce barriers to more effective global access.  A record identifier for a given asset in the UW system is probably different than that in, say, Ohiolink.  An identifier in WorldCat will identify a given asset anywhere, and may be used for direct access within locally-scoped systems as well, if the systems are designed with global scoping in mind. 

This doesn’t happen automatically, of course… system designers have to recognize and exploit the global scope of a given identifier. This is the nature of network value – the more something is used for a given network purpose, the more valuable it becomes. 

The library community benefits from a public, globally-scoped identifier such as WorldCat provides for the first time.  It should be the identifier of first choice in library systems.

-----

Image: Early morning view of the 520 bridge from the Union Bay Natural Area on Lake Washington.

Digital Repository Interoperability

Microsoft, the Mellon Foundation, the Coalition for Networked Information, the Digital Library Federation, and the Joint Information Systems Committee in the UK, jointly sponsored a meeting in April of 2006 to promote discussion and consensus on the characteristics of digital repositories that need to be standardized in order to promote desirable levels of interoperability. The list of sponsors is a strong clue to the importance of this somewhat esoteric topic. What is at stake is a common set of functionality that will support automated interchange across a wide spectrum of repositories and assuring auditable provenance for managed materials. Not a modest objective.

The final report for this meeting is available at the Mellon Foundation. It is not casual reading, intended to capture a discussion rather than characterize the state of the art, though readers may find the background materials and recommendations generally useful.

Those conversant with digital library research may be familiar with the early work of Robert Kahn and Robert Willenski on repository architectures. It is interesting to note that, a dozen years later, there still is no commonly agreed terminology, let alone a universally accepted model for this critical piece of digital library infrastructure. It is a reminder of how new our digital workspace is, and how much effort remains to achieve even a rudimentary infrastructure for supporting reliable, persistent access to electronic assets.

There is inherent tension between standardization and localized design, especially in an unstable technological environment. Builders want to build, not reconcile. The conferees at this meeting (largely implementors of early repository systems) did not even entirely agree on which aspects of functionality should be considered core for interoperability purposes (though progress was made towards this goal).

It is perhaps not astounding that understanding of repository core functionality is not so different now than in 1995. The Kahn-Willenski list included (I paraphrase) access, deposit, and tell-me-more. The 2006 meeting agreed on obtain and harvest, and talked at length about whether put should be there. The notions map roughly across the intervening years, though current understanding of the underlying details far exceeds the 1995 model.

If this sounds like scant progress for a decade, keep in mind that a great deal of experience has been garnered through the deployment of DSpace, arXiv, Fedora, ePrints aDORe and the like – serious repository applications that afford the practical experience necessary to bring together common expectations on how these technologies will work together.

The problem is broad in scope… a data model and architecture to support documents, data archives, and  formats, policies, and recombinant practices that are to a significant degree yet undeveloped.  The architecture must accommodate the functional requirements of disparate domains with entirely different business models, legal requirements, and data demands.  As the first crop of serious repository applications have matured, the field is now ready for the harder task of bringing these efforts into an interoperable framework. This meeting will have helped to focus attention and effort on this important goal and set the stage for additional progress.

-----

Image: Downtown Seattle from Elliot Bay, July, 2006

 

Tag Team Wrestling

Tim "LibraryThing" Spalding has just announced a new feature on LibraryThing, currently the most impressive instance of so-called Library 2.0 that I know of.  The new feature addresses a topic that many (including myself) have been wrestling with for a while now: the relationship of formal knowledge organization systems to folksonomies.  Tim's Mother's Day blog post speaks to the raging controversy:

Are tags better than subjects? Are subjects better than tags? Are tags just a fad? Will tags replace subjects? Are tags evil? Are subjects evil? (Believe me, the idea is out there.) Librarians have become deeply emeshed in the debate, with partisans on both sides. Until now, there hasn't been much in the way of hard data, at least for books. LibraryThing provides that.

This last is the exciting part.  LT has provided a platform to explore the behaviors of both in a coherent, data-rich system.  Researchers, start your systems!

-----
image: Carolyn Dunford, of the UW MLIS program,alerted me to a lovely wildlife preserve nearly within slingshot distance of the UW (known as the Montlake FIll).  This is a closeup of one or another species of Horsetail (Thanks to Bob O'Hara for the ID), taken at the preserve.