Category Archives: Academic Papers

Academic Papers Artwork baby names Blog blogging democracy Design ethics Facebook firefox Flickr folksonomies Google Google Docs Google Spreadsheets how-to information-architecture information-retrieval information design internet iphone journalism listserv mailing list maps mass media Online News Papers Photography plugin poll social-bookmarking social networking social software spam tagging trust Twitter Usability web-development Web2.0 webspam web standards WordPress Writing

Ontology for Radiological Terrorism Research

Academic Papers, Projects, , , ,

Domain

The ontology was created from the Radiological Terrorism Research Thesaurus, specifically constrained to the portions under the term “material sources” and “consequence management” (now called response). Other classes not found in these areas, but referenced by fields in these areas, are included, but not developed—this includes Organization, Event, Expertise, Person, and Material and their subclasses.

Background

Terrorism is an incredibly important issue, and agencies within the US and worldwide need to meet the challenge of compiling and organizing research in a number of fields in order to counter this very real threat. In addition, agencies have been criticized in the past for not sharing information, or maintaining knowledge organization systems (KOS) which are incompatible with each other. Work is often duplicated, and often vital information will be unavailable to some agencies even though it has already been archived by others.

Clearly, there is a need for a large-scale KOS that can be used to organize information efficiently and correctly, allow for complex analysis of information, and allow for easy knowledge sharing between agencies. The most flexible and powerful KOS, and therefore the most appropriate, is an ontology. Classes, subclasses and relationships are developed and then appropriate fields are created for each. This allows for faceted search and display, automated search, hierarchical organization of information, and interoperability with other systems.

Users

This is just a sample of the larger, more complete ontology. The complete ontology would be useful for virtually any person or agency dealing with anti-terrorism, counterterrorism, intelligence or consequence management. The ontology will allow risk assessment officers, for example, to see a list of every high-level material source in the United States and Canada and their coordinates. Medical first responders could use it to catalog and retrieve proper treatments for specific bioterrorism agents. And if widely-adopted, it would greatly reduce the barriers to efficient knowledge-sharing. If the Department of Energy we to license a new Uranium mine in Montana, the information would be immediate available to risk-assessment officers, instead of requiring time for the paperwork to make its way over to the Department of Homeland Security.

 

View and navigate the ontology

Notes on “Ontologies Come of Age”

Academic Papers, , , ,

Ontologies Come of Age, Deborah L. McGuinness (2002)

One thing I noticed about this reading is the ample use of examples. If you look through all of the points below “Structured Ontologies and Their Uses” you can see what I mean. I find that to be a big problem with a lot of the things I’ve read about ontologies or the semantic web—there’s a lot of terminology and very little illustration. So in that regard, this was a good reading.

On the other hand, the more I play with Protege and read about ontologies, the more it seems to me that all the information science and library science people are moving closer and closer to the way relational databases work, without actually knowing it. For example, each of the classes in an ontology could be thought of as tables. The class/subclass relationship is like a one-to-many foreign key relationship, and since you can have more than one parent for any particular class you can have many-to-one and many-to-many relationships as well. Each of the fields or “slots” is just like a field in a relational table. There are only a few ways in which ontologies and relational databases differ, and they’re only really cosmetic differences. Relational databases have no notion of inheritance, for example, so fields for a table called “Thing” are not passed down to other other tables that have “thing_id” as a foreign key. But database applications and users create views which join the tables and do something similar. Also, Protege allows you to use a class or and instance as the type for a slot, whereas in relational databases it really only makes sense to use an instance.

There must be other people who have noticed this, and since a lot of web pages have relational database back-ends I have to assume semantic web pages will as well.

Notes on “Metadata Principles and Practicalities”

Academic Papers, , ,

Metadata Principles and Practicalities, Duval, Erik, Wayne Hodgins, Stuart Sutton, Stuart L. Weibel (2002).

This was a pretty straight-forward reading. I did like the Lego metaphor for metadata, but it would be nice if it was elaborated on a little bit more. So, kids have no problem combining space ship Lego parts with medieval castle parts, but just because it is possible to do so, is it beneficial or useful in any way? I understand they are just talking about modularity as a quality at the point, but it also gives the impression that metadata schema, properly constructed, can be mixed and matched willy-nilly.

One thing I have not seen discussed very much is where the line is drawn between metadata and regular data. For example, most schema have some sort of author/creator field. I see how the author could be data describing and article, but if you look at articles in a journal or on a web page, the author is almost always presented along with the body text. A more clear example of what I’m trying to say is an article’s abstract. I’ve see some schema that have the abstract as a piece of metadata, but does that mean it is not part of the data (the article) itself? Or is it both?

It all depends on your point of view. From a database designer’s perspective, all of theses metadata fields are just data, and metadata is what describes the structure of the database—field types, lengths, foreign key relationships, etc. I’m not saying that everything should be stored in one big lump. I guess I’m just concerned that depending on the point of view, metadata could mean anything. Really, all of this is just a matter of properly separating different data elements from each other. Obviously author/creator should be a separate field from article body text. And date, titles, etc. should be separate as well. But that doesn’t really separate them from the thing itself, they are still all aspects of the thing.