Showing posts with label schemas. Show all posts
Showing posts with label schemas. Show all posts

Thursday, April 2, 2015

More thoughts on linked data and the future of cataloging

I really enjoyed Slistopher's fun post and article link about the venom library.  I wondered about the metadata too, and his suggestion that it could be the project for next year's class cracked me up. But on a more serious note, it prompted me to look up metadata schemas for real, organic things, and it turns out there's a ton of them, this list of schemas being, I am sure, just one of many.  And that got me to thinking about linked data and cataloging in world of linked data.

Suppose you had this book on lemurs:  Behavioral variation : case study of a Malagasy lemur. Current cataloging techniques give it a several LC subject headings (this is from WorldCat; the older record in my library's catalog uses only the first four):

Verreaux's sifaka -- Behavior.
Social behavior in animals.
Mammals -- Behavior.
Mammals -- Madagascar.
Behavior, Animal.
Lemuridae.
Social Behavior.
Mammals.
Madagascar.
Lemuren.
Verhalten.
Madagaskar.
Lemurs

In a linked data world, we would reasonably expect that the basic descriptive metadata (author, publisher, identifiers such as ISBN, etc.) would use some kind of permanent identifiers that would allow them to be meaningfully linked to related content.  But what about those subjects?

In both WorldCat and my library's catalog, the subjects are clickable links, but clicking them results in a search for that subject only within the catalog.  In a more linked environment, would siloized search still be appropriate?  Maybe the subject links could bring in lots more things that are linked to that heading using LC's linked data service (e.g. Lemuridae).  But is that enough?  Will other curators of desirable content use LCSH?  Maybe instead of, or at least in addition to, expecting outside entities to conform to library-centric aboutness terminology, cataloging records should link to data hubs appropriate to the content.  Just one example in this case is the ITIS taxonomy (e.g. Verreaux's sifaka). That would potentially link this book on the social behavior of a specific type of lemur to scientific articles, datasets, images, and perhaps even its genome.  It's not hard to imagine other elements that might link in similar ways:  Madagascar, for example, or perhaps even primate social behavior.

Do you think this kind of outside vocabulary will eventually replace LCSH or will it still be important for broad, general categories like "Social Behavior"?  Will we still need it for faceted, siloized library searches?  Will we still even have the silos?



Wednesday, March 25, 2015

A Different Kind of Schema

Tonight in class, Dr. MacCall talked about ways to automate, or partially automate, metadata entry in digital libraries. While highly sophisticated automation is beyond the scope of our class project, it's useful to be aware of the possibilities in case we need them later in our careers. Using our football image library, Dr. MacCall suggested as an example that perhaps instead of manually typing in a whole, possibly difficult-to-spell name (e.g "Baumhower") every time, the image cataloger could instead type in the player number (in this case, 73) and lookup software would provide the correct name.

Of course, it couldn't really be that simple, and the discussion quickly turned to all the ways it could go wrong (reassigned numbers, duplicate numbers, partial numbers, and so on), as well as the myriad rules for uniform numbers allowed on the field every game. I never realized that football uniform numbers were so complicated!  Furthermore, that complicated uniform number system would have to be written into the rules of the number-to-name matching software.  Thus numbering rules intended to reduce confusion on the actual football field would be re-purposed as a schema intended to reduce errors in a virtual library of football images. How wonderfully poetic to think that the rules and structure of the game itself could become an integral part of creating a football image library!

Wednesday, February 25, 2015

Superschema or Common Schema?

After reading the articles that inspired them (here and here), it was fun to compare Adam's blog post on the useful simplicity behind Dublin Core to Tonya's post on the plausibility of creating a superschema to rule them all.  Using very basic set theory to describe these approaches, it seems to me that Dublin Core takes the approach of the intersection of metadata sets, while the superschema idea consists of the union of all metadata sets.  Both ideas seem to posit a system in which all elements would be optional, using only those appropriate to the object being described.  However, Dublin Core works by providing a limited number of common elements that can describe nearly anything generically, while the superschema would work by providing an almost unlimited number of elements that could describe nearly anything specifically.  What an interesting contrast!

From a practical standpoint, DC has a lot to offer in terms of interoperability, maintainability, and the ease of building fast indexes with understandable browsing facets. The superschema idea would allow a lot of freedom, but describers would need to have a very broad knowledgebase, and even local systems based on it would be highly complex.

From the user's standpoint, what would the superschema system look like?  I suspect that it would look a lot like Google.  The search algorithm would probably need to rely on keywords, with relevancy heavily informed by the tags from the various schema (so your search for "sage in herbal remedies" wouldn't be swamped by articles published by SAGE Publishing).  While I don't know how their proprietary indexing systems work, this sounds to me an awful lot like library discovery layers, and the direction they are moving in.

To me, the good news here is that the mix-and-match can, and probably will, happen at a higher level than the metadata schema.  Individual systems could continue to use the specialty schema that work best.  Knowing other schema is still important in case of migration, but hopefully combining datasets will come to rely on something more sophisticated than the most basic of crosswalks. It will be interesting to see where it all goes!