Subdividing large aggregations

18 views

Skip to first unread message

Neubert Joachim

unread,

Sep 20, 2010, 5:08:03 AM9/20/10

to oai...@googlegroups.com

Hi,

In the work with 20th Century Press Archives (http://zbw.eu/beta/p20), a question arose about the best way to deal with large aggregations.

The Archive is largely build on nested ORE aggregations - a collection consists of folders, which in turn contain documents, which consist of pages, which have image files in different resolutions. Our problem occurs on the folder level: The biographical collection has currently 5400 folders, and the company collection will grow up to 13,000. This is not only a problem for an RDFa application (where no user ever wants to see such a monster page). It's also nasty for crawlers (a single added or updated folder enforces the change of the modified date of all upper levels, and thus the parsing of all children of these levels to check *which one* had changed).

There is no "logical" intermediate level to divide this aggregations (nationality of a person or location of a company come with its own set of issues). So, my soltuion for this was to build an artificial intermediary level, conveniently hashed by initials.

<person> ore:aggregates <person/a>, <person/b> .

<person/a> ore:aggregates <person/4711>, <person/4712> ;

ore:isAggregatedBy <person> .

<person/4711> ore:isAggregatedBy <person> .

<person/4712> ore:isAggregatedBy <person> .

On the HTML level just the same: A folder page for an individual person, say "Adler, Alfred", has no back link to the "Person A" page, but only directly to the "Biographical Archives" page.

Of cause, the "missing" inverse relations can be infered:

<person/4711> ore:isAggregatedBy <person/a> .

<person/4712> ore:isAggregatedBy <person/a> .

<person> ore:aggregates <person/4711>, <person/4712> .

But this comes on the cost of the users who want to deal with the consequences.

I now wonder what you think of this approach - specifically, is it compliant with the ORE model and the ideas behind it? Hints to other approaches to deal with this problem in the context of ORE are also highly appreciated. (Hi Rob, Clare, Richard, did you further evaluate a "paging mechanism for resource maps", as mentioned in http://portal.acm.org/citation.cfm?id=1555400.1555503)