It was Antoni Mylka who said at the right time 22.11.2008 01:33 the following words:
2008/11/21 Robert Jaeschke <>:
Hash: SHA1

Hi Leo,

Leo Sauermann schrieb:
For bibtex, we need a bibtex vocabulary.

afaik the bibsonomy people have solved this.
I wouldn't call it "solved", we just use SWRC
<>. It has some limitations (e.g., it does not
 allow to encode the order of authors) and missing fields (e.g., annote, key,
crossref, isbn, doi, ...) and it is not clear how to create proper URIs. For an
example output see <>. To connect it to the
tagging data we use BuRST as proposed by Peta Mika
<> - see an example here:

what vocabulary should we use for bibsonomy?
If you're fine with the restrictions of SWRC and only need the BibTeX part, use
it. If you also want to represent the post part (tags, user, date, etc.), use BuRST.

from the data side I say:
start with the publications and tags.
thats it, once this works perfectly, we release it and see if anyone
else needs the bookmarks and programs the rest.

Uploaded a first preliminary version of the new bibsonomy crawler to:

Just import it into the same workspace as the aperture trunk and try
runnin the ExampleBibsonomyCrawler class. Before we merge it with the
trunk though:

1. swrc doesn't contain properties for many important bits of
information (e.g. the bibtex key), we'll have to make some extensions
2. swrc contains classes like Person and Organization,the current code
uses nco:Contacts for Persons and doesn't create proper instances of
nco:OrganizationContact, and places plain strings instead - it can't
be left like this.
3. I couldn't find a proper definition of the burst ontology, used NAO
for tags instead
4. burst uses rdf:Seq's for authors and editors - I used rdf:List (for
the time being)
5. there is no way to detect modified entries, the hash is a part of
the URI, so a new uri = a new resource.

Incorporating SWRC in the bibsonomy crawler is important for a number of reasons
- validation won't work (OWL, collections)
- the Person and Organization classes will overlap with NCO
- BURST will overlap with NAO

I.e. the SWRC/BURST simply doesn't fit within the rest of the
framework. An application that can do things like "show me all
occurences of this person", will have to search for all nco:Contacts
AND swrc:Persons. When we wrote NIE, the goal was to avoid situations
like this. Whether or not this is a problem - let the users speak.

Gunnar, you've opened this issue, what do you think?
I propose to switch to NCO / NAO,
for the reasons you said.

Commit the code to aperture-contrib, then its easier to test-drive it?


DI Leo Sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:

Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313