My interest in doing this mapping of (X)OBIS into TM (Topic Map) form is to better understand how to improve XOBIS’ representation in XML (and to improve my understanding of Topic Maps in general).

I also think it is good, once you have “finished” with something (ha-ha, we are not finished yet), to reapproach it from a different angle. So, I’m looking at what TM-XOBIS (for lack of a better label) would look like.

The first thing, for me, is to reapproach TMs.

I read a little about them way back when we were doing XOBIS. To be fair, I think I was a little unjustly put off by TMs back then by a simple, and perhaps irrelevant, part of the model. By this, I mean the word “topic.”

When I looked at TMs originally, I said, “Okay, everything is a topic, but that’s not what I’m interested in… I want to talk about authorities.” I got a little too hung up on this distinction (and will set it aside for this new exploration but before I do I want to dissect it a little).

So, what is a topic? Before looking at how the TM community is using the term, let’s just look it up in a dictionary. Dictionary.COM says:

1. The subject of a speech, essay, thesis, or discourse.
2. A subject of discussion or conversation.
3. A subdivision of a theme, thesis, or outline. See Synonyms at subject.
4. Linguistics. A word or phrase in a sentence, usually providing information from previous discourse or shared knowledge, that the rest of the sentence elaborates or comments on. Also called theme.

That’s interesting and a bit provocative. I like the idea that the pursuit (and acquisition) of knowledge is just one large conversation. One might suggest that there are not objective truths (or at not ones that we can know) but, rather, just a multitude of perspectives. If a ‘topic’ is the base ‘thing’ in Topic Maps, are the TM people saying that metadata is just one large ongoing conversation… that all we have as a ‘base’ are the topics of our discourses?

From The TAO of Topic Maps: “…the topic map standard defines subject, the term used for the real world ‘thing’ that the topic itself stands in for. We might think of a ’subject’ as corresponding to what Plato called an idea. A topic, on the other hand, is like the shadow that the idea casts on the wall of Plato’s cave: It is an object within a topic map that represents a subject.”

So there is a Platonic ideal and then something that we have as a handle for the ideal. To me, it makes more sense to say that these shadows are conceptions of the ideals. Conception, from the 1913 Websters, is “The formation in the mind of an image, idea, or notion, apprehension.” A conception (e.g., concept)… doesn’t that sound more like Plato’s shadow on the wall (given that I am not a philosopher so may be missing some subtle points)?

XOBIS, like Topic Maps, has a base element. It is the Concept element. There are ten principal elements; the other nine are instantiations of particular types of Concept(s). So why did we choose those ten? Those are the ones that stood out to us as being useful in the context in which we work (metadata for institutions of cultural knowledge).

The nine instantiated XOBIS elements are divided into two classes: substantive and notional (obviously, the substantive elements are ‘handles’ for things that can be held by a library or museum and the notional elements are the shadows on the wall that have a reason for being distinguished from the other more generic shadows). Making this distinction between topic and concept, though, allows us to make another additional distinction.

These shadows, that are our handles, can be used by us in particular ways. For instance, a concept may be used as the subject (or topic) of a particular work (this is a relationship between a work and concept). If everything is a topic from the start, how does one make the distinction that the topic is being used in a topical way? A ‘topical way,’ that is, in a different sense than the idea that everything is a topic in one large ongoing conversation. Is this ‘topic’ different from a ‘topic’ being used in a categorical way? XOBIS says there is a difference.

Yes, this is quibbling and it shouldn’t have stopped me from looking at TMs. Yes, I still think Concept makes a better base object than Topic, but where do I go from there? To get around this, I’m thinking I should be thinking about all TM topics as concepts. I’ve been told it doesn’t really matter what this base element is in TMs. The important part is that there is a base element. So, in my mind, I’m going to start working with “Concept Maps” and see where it goes.

The first screen we saw was a screen of buttons with things like: Object, Event, Exhibition, etc. One could create a record for each of these by clicking on it (you then get a detailed editor for that type of record). There were about ten or twelve of these record types (I didn’t actually count them) and though they didn’t completely map to XOBIS’ ten principle elements there were some interesting overlaps. For instance, Object and Event would correspond to XOBIS principle elements, but Exhibition would be a type of Event in XOBIS.

We were told that, while the system had predefined databases tables for the specified components of a record, the label used in the display was completely configurable (this was true at the editor level; I don’t think it was true at the button screen level). I see no reason why the same couldn’t be done for XOBIS. An editor might say Exhibition, but when it stores the record an Event record with relationships to the types of things that an Exhibition type of Event might have would be stored. There didn’t look like much in the system that couldn’t be handled this way.

One neat thing about the system was it seems to allow a much richer range of possible connections between these record types (than most library systems). We were unable to find the relationship page, though, so I couldn’t see how much information was stored about the relationship itself. Also, the administrative information that was stored about an object did seem a little brief. It looked like only one set of rights management info could be recorded, but what if an object or reproduction may be used one way for photocopying and another for display on the Web?

Overall, I was impressed with the system. I’m not sure it would work for a library (authority control was there, but it seemed a little limited — you either had to import records (which, for us, would mean a split with the catalog) or connect to particular types of external resources (that was my understanding at least)), but it looked like it was exactly what they needed at the museum. One person at the meeting talked about how they had been using an offline system so being able to move online was a great advantage. I’m surprised the art students haven’t requested an online system long ago.

One thing I didn’t like about the system, though, was that to get a web interface or XML out, one basically has to do a system dump (or snapshot). There is no live interaction with the database outside of the staff editor. This makes working with the database a little tricker if you want it to share info with others, but at least system does output XML (using XSLT to generate the web view). It would be even better if it put out VRA, but there are things in the system that would need a higher level wrapping schema too (and writing the XSLT to get VRA shouldn’t be too difficult).

The meeting was an interesting one. They expressed interest in the work that we were doing so hopefully we will be able to have some more meetings and share some ideas. I’d definitely be interested in seeing more of the system at work once they bring it up and are using it in production. It would also be interesting to hear about their experiences migrating from what they have to this new system.

The best presentation of the conference (that I saw) was Bill Moen’s (during the MODS, MARC, and Metadata Interoperability session). For those that didn’t attend, Claire Stewart has summarized the main points of Moen’s presentation on the LITA weblog. She did a remarkable job (she must be a fast typist)… it is well worth the read.

Moen suggests that libraries do not play a central role in the metadata world. We do have a priviledged role, since we have been doing it for such a long time, but we need to play well with others. Now that unalog is going to have the ability to perform batch updates on its folksonomy tags (this is coming, but not quite here yet… Dan is working on it), I’m starting to wonder what I will do about my “cataloging” and “metadata” tags (should one be a variant of the other?)

I’ve argued, in the past, that metadata is just a renaming of (a small part of) what catalogers have been doing for a long time. If metadata and cataloging are the same thing, which term should we use? Using metadata is more ‘hip’ (and more savvy politically… e.g., we should be reaching out to them), but I don’t like that it doesn’t recognize our experience with the issues involved.

Perhaps this shouldn’t be necessary. We should make the concessions. We should build bridges rather than worry about who gets credit for the accomplishments (assuming anyone would care… we do play a supporting role after all).

The presentation also made me think about a “switchboard schema” that would allow us to move between the other various schemas. OCLC, Moen said, might be using MARC or MARCXML as the transition format (I know there is something up on their site, but I haven’t looked at it yet). I’m curious, now, about XOBIS’ potential to serve in that capacity (just for us… I have no illusions about world domination (well, okay, I have small ones)).

After all, we keep saying it is a ‘high fidelity’ schema. There would need to be a XOBIS database, though, since some of the mapping data would be in XOBIS content (not just in the schema). I still need to finish the beta version of the schema and get the current bibliographic references converted into XOBIS, and stored in eXist, before I start to think about this though.

Ross Singer, of Code4Lib (among other things), also had a very interesting idea about having multiple transition formats (depending on the source and target schemas). The switchboard, in this case, would negotiate the best path for a transformation. I think this would require humans to put that knowledge into the system… I can’t imagine a system that could handle that negotiation by itself (but maybe I’m not creative enough(?))

Also, somewhat related, after my XOBIS talk, I spoke with a person who characterized XOBIS in an interesting way… he described it as an island. An island on which everything is tightly integrated and logical, but still separate from the world at large. I think it is a fair characterization. It would be idea if everyone lived on this island but, as Moen said, this isn’t going to happen.

This doesn’t mean we shouldn’t develop XOBIS. If it does what it is supposed to, and does it well, it is worth the investment. We should also focus on building that bridge though.

An earlier version of the schema, though, used Name instead of Being. This, of course, spells CLOWNPOETS. We wanted so badly for that to work out, but Name just didn’t make as much sense as Being (given all our discussions at the time). So, in the end… no CLOWNPOETS.

Another fun word twist… Anagram Genius’ anagram server renders Kevin Sean Clarke (my full name) to “Snakelike craven”… Ouch, that hurts!

The paper starts off by tracing the progression of the language used to talk about these issues (from "bibliography" to "document" to "documentation" and back to "document"). What I find interesting is that it doesn't make it all the way back to bibliography. It seems no more of a stretch to say "bibliographic" when talking about an antelope than it does to say "document." I wonder, perhaps, if the term's regression stopped at document because, as Buckland says (while talking about why document was originally used), "it was felt that something more than traditional 'bibliography' was needed…"

I've always been a little uncomfortable with XOBIS' name: The XML Organic Bibliographic Information Schema because of this very issue. Is 'bibliographic' really the best word to talk about events, objects, beings, etc.? What I do like, though, is that we kept it (instead of trying to find a new term). It was a nod, I think, to recognizing that these types of issues are the issues of librarianship. Computer scientists and "knowledge managers" may reframe some of the terms, but this really is the realm of library science (not that they aren't welcome to join us here).

Buckland's paper traces many cases where people used "document" to indicate the thing that is representated by a record in an information system. In particular, he cites Suzanne Briet who says a document is "any physical of symbolic sign, preserved or recorded, intended to represent, to reconstruct, or to demonstrate a physical or conceptual phenomenon." Briet goes on to list six objects and asks if each is a document:

• Star in sky — No
• Photo of star — Yes
• Stone in river — No
• Stone in museum — Yes
• Animal in wild — No
• Animal in zoo — Yes

Buckland infers, from Briet's definition and list, four rules for determining if something is a "document":

• There is materiality
• There is intentionality
• The objects have to be processed
• The object is perceived to be a document

Now to backtrack a little into XOBIS. Why "document?" The term just seems too general to be useful. What we are really talking about are beings, objects, places, and works. In XOBIS speak, these are substantive instantiations (of a concept). They are distinguished from the notional instantiations (string, language, organization, event, and time) and the purely conceptual by their, as Buckland says, materiality (e.g., they can be collected). So, in XOBIS (and this is just a stab… expect to see comments as I change my mind or refine my thoughts):

• Star in sky — Place
  • role="authority" (if notable)
  • [grouped in its Concept if not notable]
• Photo of star (held by library) — Work
  • role="instance" or
  • role="authority instance" (if notable)
• Photo of star (held by another library) — Work
  • role="authority" (if notable)
• Small stone in river — Object
  • role="authority" (if notable)
  • [grouped in its Concept if not notable]
• Large stone in river — Place
  • role="authority" (if notable)
  • [grouped in its Concept if not notable]
• Stone in museum — Object
  • role="instance" or
  • role="authority instance" (if notable)
• Stone in another museum — Object
  • role="authority" (if notable)
• Animal in wild — Being
  • role="authority" (if notable)
  • [grouped in its Concept if not notable]
• Animal in zoo — Being
  • role="instance" or
  • role="authority instance" (if notable)
• Animal in another zoo — Being
  • role="authority" (if notable)

One difference between this list and Briet's is that XOBIS contains things that are not documents. So, while Briet's list says "No" if something is not a document (it only deals with material things that satisfy the conditions listed by Buckland), XOBIS tries to figure out where it might fit in the broader scheme. This is, of course, not a weakness of the original list… for it, these things are out of scope.

The things in this list that are not held in a library, zoo, or museum's collection are authorities (if they are notable enough to warrant a record) or are grouped into their Concept record (if they are not collected or notable enough to warrant an authority — this is the same thing as a "No" in Briet's list). A stone in a river is not notable unless it has some distinction (has something about it that would cause people to want to write about it, create art about it, talk about it, etc. — essentially, have a reason it would need to be referenced from another record). If it is notable (e.g., people will want to create Xobian relationships to it), it warrants an authority record. If the stone in the river doesn't have any particular distinction (and hasn't warranted a human assigned designation) then it is just a part of Concept: Stones (or something to that effect).

What is interesting is that there is a line here that is a bit hard to discern. When does a stone that is famous, not owned or collected by anyone, and not large enough to be considered a Place become an Object? Is there even such a thing? Would a stone that is large enough to not be collected but still important enough to warrant being an authority record necessarily be a Place? [Thanks to Dick for hashing out these ideas with me before I hit the 'publish' button on this weblog] While creating XOBIS (awhile ago now), we tried to reinforce every decision or statement we made with examples. Perhaps I need to find one here.

Anyway… things (beings, places, objects, and works) that can be held in a collection may either warrant "instance" records or "authority instance" records. A stone that has been removed from a river (but that does not have any significance apart from being a part of a particular collection) would be an "instance" record. The Hope Diamond, on the other hand (a rather notorious stone), would warrant an "authority instance" role for the institution that holds it and an "authority" role for those that don't.

Likewise, a random elephant out in the wild would not warrant a record (it would be handled by its Concept authority record). An elephant that is a part of a zoo's collection, but that has no significance apart from that collection, would be a role="instance" being. An elephant that belongs to an organization but, who is notable outside of the organization's particular collection (e.g. Elsa, one of Thailand's painting elephants), would warrant an "authority instance" record. If another museum were to collect Elsa's paintings, it would need a Being record with an "authority" role so that relationships from the records for the paintings could be made.

Interestingly, all Buckland's inferences seem also to apply to XOBIS. The XOBIS elements, however, have a greater granularity than just being "documents" in an information system. They are bibliographic entities that have particular characteristics (e.g., they are one of XOBIS' ten Principal Elements — four substantial, five notional, and one conceptual). Again, this is not a weakness of the original paper, its predecessors, or the organizational schemes discussed therein; it is just a difference in scope. In defining the scope here, I can't help but ask, "Why do we need two schemes… one for authorities and one for bibliographic items?" Isn't what we are talking about the same set of things that are used (or referenced) in different ways?

Anyway, this is (as always) just a draft. I expect I've overlooked things and welcome other Xobian enthusiasts to question, doubt, and point them out (I'm working on rhymes with my four year old). I guess I should also throw in the disclaimer that these are my own opinions and may not be representative of those of any of the other XOBIS creators (e.g., all deficiencies are my own and should not be taken as representative as XOBIS as a whole). Others can speak for themselves by leaving their own comments as they see fit.

So, usually, an XML namespace is used like so:

<element_ns:first_element xmlns:element_ns="http://my.namespace.com/ns/1.0">
<element_ns:second_element>Metadata term</element_ns:second_element>
</element_ns:first_element>

What the library at DLF suggested was to use a namespace to control the metadata itself:

<element_ns:first_element xmlns:element_ns="http://my.namespace.com/ns/elements/1.0" xmlns:metadata_ns="http://my.namespace.com/ns/metadata/1.0">
<element_ns:second_element>metadata_ns:Metadata term</element_ns:second_element>
</element_ns:first_element>

The metadata namespace would be invisible to the XML processing tools (they don’t care if a data value is using a namespace that is defined in the XML), but the programmers at this library could write code that takes into consideration that data values are tied to a particular namespace (that they are, essentially, versioned). Perhaps different actions are taken with metadata from a particular version (before the data value is returned to the user, btw, it’s namespace prefix would be stripped (via XSLT). Or, perhaps, in most cases, the namespace used could be the default namespace (so there is no prefix to append to (or strip from) the data value at all)).

For example, imagine that we have two namespaces for our metadata: http://my.namespace.com/ns/metadata/20050120 and http://my.namespace.com/ns/metadata/20050601. In version 20050120, a term might have been “Surname”; in version 20050601, that term might be changed to “Family name.” Generalized “types” of changes (the type that LC makes) might warrant their own version bumps, too, perhaps. Or, does metadata change too quickly to prevent this whole thing from being useful?

Of course, the whole thing made me think of XOBIS. In a XOBIS record, there are three parts. The first part, ControlData, is used to record information about the record itself. There is an Actions element that allows changes to the record to be recorded. If the record is edited, the date of this change is recorded in an Action element (and a descriptive note can be added to detail the change). We do not attach anything to the Principal Element of the record (the representation of the thing the record is representing) because the version of a term is about the record (not about the thing the record represents).

Keeping a record of the differences between two different versions of an XML record (via XUpdate and a native XML database) provides a real world use for these XOBIS actions. If an Action element says that a record was changed on 2005/1/23, we can use that date to retrieve the XUpdate result between that date and the current version (or between that date and the next date that it was updated (which would be another Action in the ControlData’s Actions element); either, in most cases I believe, would involve a series of XUpdates — these would be stored in the database and associated with the record). In this way, we could see the difference between a Principal Element in one version of a record vs. another.

With XOBIS, this is done explictly in the record’s ControlData section (and via XUpdate), versus associating version information with the data values themselves. Still, the whole concept of using the namespace for this purpose is interesting (and more interesting if it is the default namespace for the document. Of course, if you have multiple data values in a document that belong to different namespaces, you will have to use explicit prefixes, but still…)

Anyway, I wish I could remember which library was doing this. I’d like to visit their site and learn a little more about how they use this information in their processing.

My own post (far from thoughtful, unfortunately… hmmm, am I blog people?) commented that MARC and XML are the first layer (both are the structure in which information is passed around). Then I sort of merged the next two layers, commenting that a 245 has no real importance apart from that assigned to it by cataloging rules (e.g., the idea of title and the rules that govern recording a title both seem, to me, to be under the control of cataloging rules (both are AACR2 governed)).

Lorcan Dempsey also commented that Dublin Core focused on the middle layer (and this caused several possible third layer possibilities to pop up). The first layer, of course, is handled by XML. The whole thing made me think a bit about XOBIS.

We have assumed the encoding layer would be XML. We focused on the second layer and explicitly said, when appropriate, that a particular issue would be handled by the third layer. The interesting difference between DC and XOBIS is that DC started as a community effort… committees were set up, vested interests consulted, etc. XOBIS is just an experiment that attempts to ask and answer (or, rather, give one possible answer to) some interesting questions, but we haven’t really tried to drum up a community around it.

We have been told that we should do this, but apart from giving presentations on it we haven’t. I think, in part, this is because we are more interested in the questions than in doing the work needed to make a standard (perhaps I should just speak for myself on that though).

We have always taken the approach that we are experimenting (this gives us a bit more leeway in our approach and delivery). This is not to say that we shouldn’t tackle the nuts and bolts, but that we’ve worked from the perspective that we didn’t have limitations (so that we would not be restricted by them). In the end, though, one still has to deal with them in order to produce something useful.

Interestingly, Dick has just finished a study of the tags used by Lane Library. Now that I am no longer there, though, I find myself wondering (once again) about an XSLT stylesheet that goes from MARC to XOBIS (my earlier attempts at tranforming MARC into XOBIS were done in Java).

Lane and Dick do a lot of special things with their records (making the transformation easier). I’m now wondering about what will be involved with creating a transformation for a standard MARC record (without all of Lane’s special enhancements). Once I get a little more free time (after April 15th), I’d like to take a shot at it.