[openbiblio-dev] literals and ows:sameAs

[William Waites]

* [2011-02-08 19:07:43 +0100] Tatiana de la O <tatiana.delao at okfn.org> écrit:

] <http://bnb.bibliographica.org/entry/GB5006595>
] <http://purl.org/dc/terms/contributor>
] <http://bibliographica.org/entity/cc173131fa0d998642762e937b81e7a8> .
] 
] 
] instead of
] 
] <http://bnb.bibliographica.org/entry/GB5006595>
] <http://purl.org/dc/terms/contributor> _:b2007454 .
] 
] _:b2007454 <http://www.w3.org/2002/07/owl#sameAs>
] <http://bibliographica.org/entity/cc173131fa0d998642762e937b81e7a8> .

Hi Tatiana,

So this is not an accident but it is causing some problems
-- particularly the timeouts for some authors and publishers
because you have to turn on same-as processing to get an
answer.

Why is it done like this? The first reason was to change
as little about the BL data as possible. It actually 
doesn't have identifiers for anything at all... So put
an identifier for the record itself, to root it, and 
then put in sameAs hooks for the other types of entities
that we might want to talk about.

The second reason will take some working through to
get right. Suppose we were to materialise all those 
authors and publishers and put their data in their 
own graphs. Consider the author's name. It is now 
present both in the graph for the record for their books
and in their own graph. Now someone notices a typeo
and fixes it -- we have to fix it in several places. If
it isn't fixed but the BL gives us new, corrected, data,
we have to fix it in several places. If it is fixed and
we get a new version of unfixed data from the BL we 
have to not change it and perhaps even re-correct the
new BL data. So we have a synchronisation problem.

If we were to move the author's details out of the
record itself and into their own graph we would not 
have them straightforwardly to display on the record 
page. We'd have to implement something that would pull
the graph for the record and each of the authors and
the publisher before displaying it, and smoosh them
together for display. And we have to be careful about
editing to make sure changes are saved to the right 
graph. This was implemented using ore:Aggregation in
the older, javascript-based iteration of Bibliographica
and might well be the way to go -- provided we are
careful of synchronisation...

Would love to hear other ideas about how to handle
this.

Cheers,
-w
-- 
William Waites                <mailto:ww at styx.org>
http://river.styx.org/ww/        <sip:ww at styx.org>
F4B3 39BF E775 CF42 0BAB  3DF0 BE40 A6DF B06F FD45