We would like to extract relations of the following sort:

Author1 cites Author 2
Author1 mentions Author2
Author1 hasCoAuthor Author2
etc..

A problem might be the fact that such relations have to be derived from publications. Take the first example. It would in fact be a derivation from other relations:

Author1 isAuthorOf Document1
Document1 hasCitation Document2
Author2 isAuthorOf Document2
it then could follow that
Author1 cites Author 2

I wonder how I can find work relevant to this question. Perhaps we first need to define relations that can exist between persons and documents, and from that deduce relations between persons (the same goes for documents of course). What are the relations between authors that could interest us?  It may sound silly, perhaps it is, but I don’t know how to proceed (well we could make our own AOAA -Author Of A Author- vocab, but that again sounds silly).

It may help to streamline thoughts on how to proceed if we want our (digital) libraries to become part of the semantic web. I started a wave therefore, and posted the following message.

——

Working from the assumption that the library should become part of the semantic web, what should we do? Is the following a reasonable set of things to do?

1) Identify what we have, and give it a URI (meaning that authors, documents (objects), keywords, and concepts should get a URI

2) deposit the URI’s in a registry, with a minimal set of triples (relate URI of documents to URI of authors, etc…): what is the minimal set?

1 and 2 are data level requirements, the following are service level

3) use OAI-ORE to define compound objects

4) define owl:sameAs relations between URI’s when needed (what is the workflow here?)

5) Which vocabularies/ontologies can/should be used for which services. Do we need a service catalogue first?

what else?

——

Now, if you are interested in active participation, let me know

In October, we rounded out our TV domain by synchronizing with the excellent user-curated TV fan site TVRage.com.  Combined with earlier data loads from thetvdb.com, we now have comprehensive coverage of nearly every TV show and episode created in the United States.  It includes cast and credits, as well as links to key TV websites like tvguide.com and Hulu — nearly a million topics in all!

But the load that took us over the 10 million mark was the final load of editions from Open Library.  Compromising 650,000 authors, almost 2 million books and 2.1 million book editions,   this load pushed new boundaries in our data acquisition, curation, reconciliation and QA processes.

compiles a suite of the best software tools, services and information sources for every aspect of the Semantic Web. Finding, creating, linking and publishing information – the flexibility and richness of the Semantic Web is only a few mouse clicks away.

The W3C Technical Architecture Group proposed an operational definition to make that distinction. It goes as follows:

1. If an “http” resource responds to a GET request with a 2xx response, then the resource identified by that URI is an information resource
2. If an “http” resource responds to a GET request with a 303 (See Other) response, then the resource identified by that URI could be any resource;
3. If an “http” resource responds to a GET request with a 4xx (error) response, then the nature of the resource is unknown.

It is almost too obvious that this will never work, for a variety of practical and technical reasons. If arguments for this are needed, the reader is referred to httpRange-14, Cool URIs & FRBR or The web’s identity crisis and httpRange-14.

But there is something fundamentally wrong too with this proposal. It classifies types of resources using properties of URI’s (in the context of the way the internet works). We should not use URI’s to classify things, we should use metadata for that. Classification determines, for the purpose of the classification, what things are identical. Establishing absolute identity is just classification with extreme discrimatory power.

Following Leibniz we should say that thing x is the same as thing y (are identical) when each and every predicate that is true of x is also true of y, and vice versa. In library terms: if the metadata describing x are the same as the metadata describing y, then x and y are identical. If the metadata are coarse, many things that we see as different will still be the same according to this definition. This leads us to an operational definition of identity.

If x and y are described by the same metadata, they are the identical. If, for some reason, we see a significant or relevant difference between x and y, we should add new metadata-elements that express this.

The above mentioned solution to the httpRange problem clearly violates this principle.

But classification using metadata (predicates) on the internet is not without its problems. I will mention three:

1. It is hard to find all relevant metadata for a given thing, so a complete comparison is often not possible. Identity, in practice, has to be concluded using incomplete evidence.
2. Not all metadata seem to be used to express identity. Some metadata relate things without defining their identity, but just relate things. That document x is a commentary on document y and not on document z does not allow us to conclude that y and z are different. Or does it? In any case, the question is which metadata elements define identity? To say that all metadata do seems too easy an answer.
3. On the internet, what has received a name (is called x), may change over time. So what is described may not be fixed.

Problem 3 seems to be the most fundamental. Things need to be named, singled out if you want, before they can be described. (Yes, we need some intuition about what things are. The internet supports this intuition by the way it is organized. At any given moment in time one URI/URL produces an identifiable thing.)

So how can things be named that can change all the time. Here the recent memento proposal comes in handy. It offers a (partial) technical solution to the problem of web archiving by introducing a system that allows us to identify representations of resources at particular times (and relate these timed traces to the current URI). Conceptually the memento proposal allows to see all that happens on the internet as events and offers a system to identify (name) those events.

So the internet then becomes a system of named events. We have the primitives at hand, ready to be described. We have the possibility of naming all that happens on the internet using URL’s (including parameters) and time. Having a set of events at hand, allows us to work with the pragmatic definition of identity given above: events are identical if all the metadata are the same (whereby it is always possible to split up equivalence classes by adding (or finding) extra metadata.

Formally, the internet is the set of all events , whereby an event is a tuple .

Using metadata, we can define equivalence classes on this set. Metadata are events themselves too, of course. An event is a metadata event if it contains a reference to another event That other event can be a metadata event too. So it is the content (having a URI in the content) that determines whether an event is a metadata event.

What is said about that reference could, if one so wishes, determine whether the talked about “object” is informational or non-informational. Being informational or not, is the proper subject of metadata.

The second problem needs to be solved by singling out a set of attributes that create the equivalence classes. Equivalence becomes a matter of perspective, a matter of selection of appropriate metadata events. Which ones are appropriate may depend entirely on the application one has in mind.

The first problem becomes one of finding metadata events given an event. We discussed this already (if only partially) in an earlier post called From data to metadata.

But, given a document, how can we find the metadata? The problem is that documents and metadata are often separate resources which are not necessarily bi-directionally linked. In practice, the link from a document to resources containing metadata about that document is often missing.

Let’s first change our terminology before discussing this in more detail. Following the principles and accepted terminology of the web architecture we will not use the term document, but replace it with the more general term resource. A resource refers to a variety of objects, including textual documents, audio-visual material, data sets, running code, etcetera. We will only deal with resources that have an online presence.

A resource can take two roles. It can be a metadata resource describing other data resources and a data resource itself. To safe on typing we will use the acronym MR to refer to a metadata resource and DR for a data resource. If a resource refers explicitly to another resource and gives some extra information about it, the referring source is a MR and the referred to resource a DR. Two resources can refer to each other and so be both a DR and a MR at the same time. A catalog, for example, can describe a series of art objects and it can itself be described by yet another resource, for instance one that critiques the catalog as an art object in itself. The catalog is both a data and metadata resource. Seen from a philosophical perspective it can perhaps be noted that everything refers to something else, so everything is metadata. So, being a DR or an MR are roles a resource can take.

Any MR needs a reference to a DR, while a DR does not need a reference to a MR. Without loss of generality, I think, we can assume that a MR is a set of RDF triples. All metadataformats can in principle be expressed in the RDF datamodel. What is needed to realize this transformation is that every resource is globally unique identifiable. RDF uses URI’s for this. Let’s however ignore this "problem" for  a while.

We then have the situation in which MR’s and DR’s have a URI, if the URI’s are URL’s both should lead to a representation (retrievable over HTTP) of the resources. There are only a few methods thinkable to retrieve a MR (or more) when a DR is known.

1. There is an algorithm (or convention) that derives the URI’s of a, or all, MR’s from the URI of a DR.
2. There is an algorithm (or convention) that derives the URI’s of a, or all, MR’s from the content of a DR.
3. There is at least one registry where a MR registers itself as an MR for a given DR URI.
4. The site that hosts a DR can be notified of the existence of MR’s that mention it.
5. Embed into the DR references to a MR.

Each of these options need to be detailed. Option 1 could be (partially) solved by Cool URI’s and  the finer details of the HTTP response mechanism (especially HTTP 302/303 responses) need to be explored. In option 4 one of the refback methods (HTTP) might be used, or perhaps a variation on the trackback mechanisms used in the weblog world.  But this is not the place to present those details.

What is noteworthy in all solutions is that a community effort is needed to get it done. Technical details need to be worked out, but first conventions need to be written down, workflows and responsibilities need to be written out and handed over to organisations. Registries might be needed and certain  groups have to maintain them. What is lacking therefore is a community that sets itself to these tasks.

This is tinkering.

The idea that our work should be demand-driven leads to tinkering too. We define services in collaboration with researchers and librarians and then realize that service. Serving our customers is of course our main goal, in the end, but librarians should not jump from "demand" to "demand". What is lost is a reflection on that what may connect the services thus developed, what is lost too is a critical attitude to the foundations of a library.  For example, customers tend to take many things for granted (like: libraries shuffle documents, whether online or offline, libraries offer search tools that answer questions by presenting a list of documents). A rethinking of the foundations of libraries and the resources it works with will rarely be triggered by obeying customer demands.

 Tinkering works from existing "infrastructures": takes them for granted. Not tinkering, but thinking might be instrumental in changing that infrastructure in order to deliver future services with a maximum of ease. It is not that no one thinks about such an infrastructure. OAIS reference architecture, SOA, 5S and similar undertakings show that infrastructural issues are addressed in the literature.  Also, the Linked Data Initiative has come with clear advice on how to represent metadata and how metadata can be re-used. Registries of identifiers are seen as essential in this context. The issues around Open Data and rights of (re-)use have received considerable attention too, and are an integral part of a solid infrastructure. That work could lead to the definition of an overall architecture and to the development of a flexible infrastructure on top which new services can be developed.

It would be advisable, I think, to retract from the demand oriented strategy and start working on the specification of a good and flexible infrastructure using one of the existing methodologies (a few were mentioned). I think it is an essential step that would make future developments less costly and increase the likelihood of developments to become stable and sustainable services. And we surely should not waste our time with 23 things, there is no inherent evil in that work, but it distracts us from the core issue: build an adequate infrastructure for the digital library.

We need to think more and tinker less.