EPrints and BIBO
Christopher Gutteridge
(10 years+) open source tool for universities and other groups to use to
archive and disseminate their research papers. (Slides, Videos, Data, ...)
It's used by many universities around the world.
We are currently in beta for version 3.2.0, which introduces RDF. We
selected BIBO as the most appropriate schema to use for the default
release, although it will be possible for sites to customise this in
small or major ways.
I was going to work through the examples on the wiki (those are missed!)
As time is short, I would appreciate some feedback from this list, as
it's far easier to make changes now, than in a couple of weeks time when
we release 3.2.0 (no fixed date yet).
Examples of where we're at so far:
The BIBO/RDF extension is running (in beta) on the following sites (all
are the same physical server):
http://cogprints.org/ - A subject based research repository
http://files.eprints.org/ - A software repository
http://eprints.ecs.soton.ac.uk/ - The research repository for our school.
I have routines which create URIs for authors, and events although these
are not first-class objects in our system, I was strongly encouraged not
to use B-Nodes.
Here's some live examples:
http://eprints.ecs.soton.ac.uk/cgi/export/234/RDFXML/ecs-eprint-234.rdf
http://eprints.ecs.soton.ac.uk/cgi/export/10432/RDFXML/ecs-eprint-10432.rdf
http://cogprints.org/cgi/export/234/RDFXML/cogprints-eprint-234.rdf
http://files.eprints.org/cgi/export/23/RDFXML/files-eprint-23.rdf
(change to RDFN3 ... .n3 for N3 version)
It is *not* practical to change the metadata in our system, people don't
want RDF enough to stomach that disruption, so we have to just map the
existing data. To see all the underlying data for an article, ask for it
as XML, eg:
http://eprints.ecs.soton.ac.uk/cgi/export/10432/XML/ecseprint-10432.xml
There's clearly much data we could expose, but are not.
For an "anonymous" author:
http://eprints.ecs.soton.ac.uk/cgi/exportresource/person/4f8ae2da470948ed854baac722bed22e
For an author identified by an ID:
http://eprints.ecs.soton.ac.uk/cgi/exportresource/person/1248
An event (conference):
http://eprints.ecs.soton.ac.uk/id/x-event/8863ac50a00d4079ba680a7fc037bb57
What I really want to do is make sure ASAP we've got the broad strokes
right. RDF needs to be useful to the people wanting to consume it. I
don't consume BIBO RDF so my experience tells me I'm certain to have
made glaring omissions.
Thanks in advance for any help,
Christopher Gutteridge
--
Christopher Gutteridge -- http://www.ecs.soton.ac.uk/people/cjg
Lead Developer, EPrints Project, http://eprints.org/
Web Projects Manager, University of Southampton,
School of Electronics and Computer Science
Christopher Gutteridge
If there's no interest in, or support for BIBO, why is it worth us
making the effort to use it? I'm not keen on forcing it on our users if
the community for it is dead.
Web Projects Manager, School of Electronics and Computer Science,
University of Southampton.
Bruce D'Arcus
<c...@ecs.soton.ac.uk> wrote:
> I am disappointed that I've not had a single response in over a week.
>
> If there's no interest in, or support for BIBO, why is it worth us making
> the effort to use it? I'm not keen on forcing it on our users if the
> community for it is dead.
Sorry about the lack of response. But don't take it personally; some
of us are just overworked and things sometimes slip through the
cracks. I'll try to post a response later today.
Thanks for your interest!
Bruce
Christopher Gutteridge
Normally I'd not be pushy, but I've got a very limited window of time to make changes in, and the examples on the wiki were what I planned to work with, and they've been offline for a month.
mkbergman
You may want to officially join this group as a member. I am seeing
that moderators need to approve your posts, so that is also adding a
bit to real-time interchange and some delays in responding to you.
On Jan 26, 10:00 am, Christopher Gutteridge <c...@ecs.soton.ac.uk>
wrote:
> Lead Developer, EPrints Project,http://eprints.org/
Chris Clarke
http://eprints.ecs.soton.ac.uk/cgi/exportresource/person/1248
--
You received this message because you are subscribed to the Google Groups "Bibliographic Ontology Specification Group" group.
To post to this group, send email to bibliographic-ontolog...@googlegroups.com.
To unsubscribe from this group, send email to bibliographic-ontology-spec...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/bibliographic-ontology-specification-group?hl=en.
Please consider the environment before printing this email.
Find out more about Talis at www.talis.com
shared innovationTM
Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited.
Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
Frederick Giasson
> I am disappointed that I've not had a single response in over a week.
>
> If there's no interest in, or support for BIBO, why is it worth us
> making the effort to use it? I'm not keen on forcing it on our users
> if the community for it is dead.
Nobody get paid for this work and all the work is done in free time. So,
sometimes everybody comments at the same time for days, and other times
it takes longer. Anyway, here are my comments:
>> http://eprints.ecs.soton.ac.uk/cgi/export/234/RDFXML/ecs-eprint-234.rdf
Good usage of authorList, and all other bibo predicates (presentedAt, etc).
The embedding of all related resources in the same RDF document is good
(and simpler for data consumers).
The use of DCTERMS is right too. However, some could argue that there
there is a duplication of "information" by using both authorList and
dct:creator. However, I don't think it is bad is we consider that
authorList state the positions of authors in the paper, and creator only
states the creators of the document.
otherwise, it seems that you took some citations and extracted the names
of the auhors. It ends up that foaf:givenname as letters such as "H",
"M", etc... since this information is not really useful, I would remove
the usage of the foaf:givenname and foaf:family_name and only use
foaf:name "C.J. Harris".
All in all, this document is pretty good to me.
Also, I would personally just use bibo:abstract (and remote
dct:description). But maybe some of your systems need dct:description
for some reasons.
One last question: about the sameAs
"http://id.ecs.soton.ac.uk/person/119" assertion, is this a URI
referring to the *same* resource? (just to make sure)
>> http://eprints.ecs.soton.ac.uk/cgi/export/10432/RDFXML/ecs-eprint-10432.rdf
>>
Same comments
>> http://cogprints.org/cgi/export/234/RDFXML/cogprints-eprint-234.rdf
Here names seems better, so it would make sense to keep
givenname/family_name
>> http://files.eprints.org/cgi/export/23/RDFXML/files-eprint-23.rdf
Empty?
>> (change to RDFN3 ... .n3 for N3 version)
Doesn't work
>> It is *not* practical to change the metadata in our system, people
>> don't want RDF enough to stomach that disruption, so we have to just
>> map the existing data. To see all the underlying data for an article,
>> ask for it as XML, eg:
>> http://eprints.ecs.soton.ac.uk/cgi/export/10432/XML/ecseprint-10432.xml
>> There's clearly much data we could expose, but are not.
>>
>> For an "anonymous" author:
>> http://eprints.ecs.soton.ac.uk/cgi/exportresource/person/4f8ae2da470948ed854baac722bed22e
>>
>>
>> For an author identified by an ID:
>> http://eprints.ecs.soton.ac.uk/cgi/exportresource/person/1248
>>
>> An event (conference):
>> http://eprints.ecs.soton.ac.uk/id/x-event/8863ac50a00d4079ba680a7fc037bb57
>>
>>
>> What I really want to do is make sure ASAP we've got the broad
>> strokes right. RDF needs to be useful to the people wanting to
>> consume it. I don't consume BIBO RDF so my experience tells me I'm
>> certain to have made glaring omissions.
To me, it is a really good first step. I see no real issues with it
as-is, information is useful and clear. RDF files are properly created
and clean.
You can check what they looks like in a generic RDF browser: (click on
the arrows to extend some descritpions of resources)
http://dataviewer.zitgist.com/?uri=http%3A//eprints.ecs.soton.ac.uk/cgi/export/234/RDFXML/ecs-eprint-234.rdf
http://dataviewer.zitgist.com/?uri=http%3A//eprints.ecs.soton.ac.uk/cgi/exportresource/event/8863ac50a00d4079ba680a7fc037bb57
http://dataviewer.zitgist.com/?uri=http%3A//cogprints.org/cgi/export/234/RDFXML/cogprints-eprint-234.rdf
Hope this helps, and send any questions on this thread!
Thanks,
Take care,
Fred
Tom Morris
this support so that your data can be consumed by more people/tools?
What has been the results of interoperability testing? Have the new
audiences that you're targeting been able to successfully consume the
data?
Tom
On Tue, Jan 26, 2010 at 10:50 AM, Christopher Gutteridge
<c...@ecs.soton.ac.uk> wrote:
Frederick Giasson
> Feedback from the spec writers is useful, but aren't you implementing
> this support so that your data can be consumed by more people/tools?
>
> What has been the results of interoperability testing? Have the new
> audiences that you're targeting been able to successfully consume the
> data?
>
The goal of his email was two folds:
(1) getting feedbacks from the community that created BIBO to make sure
it was valid, consistent and meaningful
(2) trying to reach such users / data consumers
I think the goal was not to develop this feature for specific
users/clients, but to create a new data consumption channel to their
framework. Considering this, the audience would be us (the mailing
list), our projects, and some external projects such as Zotero that
could consume that data in the future (any news about this BTW?)
Thanks!
Fred
Christopher Gutteridge
The exportresource URL is the current location of the RDF+XML version of the resource. I agree it's not pretty, but it's only the back-end. The resolvable URI's are as clean as possible, such as:
http://eprints.ecs.soton.ac.uk/id/x-person/1248 is the URI of the resource which *currently* redirects to the RDF, but could do something cleverer in a later version.
http://eprints.ecs.soton.ac.uk/id/eprint/23 will redirect (in a browser) to a webpage, but uses content-negoitiation so if the client prefers RDF+XML (or N3 etc.) it'll redirect(see other) to other URLs which host those views.
Christopher Gutteridge
Frederick Giasson wrote:
> Well, as Bruce said, this is a community of people from all fields.
> Nobody get paid for this work and all the work is done in free time.
> So, sometimes everybody comments at the same time for days, and other
> times it takes longer. Anyway, here are my comments:
I appreciate everyone giving me some time, I'm hoping that EPrints will
become a useful addition to the BIBO environment. Sorry if I was grumpy
in my earlier mail.
>>> http://eprints.ecs.soton.ac.uk/cgi/export/234/RDFXML/ecs-eprint-234.rdf
> Good usage of authorList, and all other bibo predicates (presentedAt,
> etc).
>
> The embedding of all related resources in the same RDF document is
> good (and simpler for data consumers).
>
> The use of DCTERMS is right too. However, some could argue that there
> there is a duplication of "information" by using both authorList and
> dct:creator. However, I don't think it is bad is we consider that
> authorList state the positions of authors in the paper, and creator
> only states the creators of the document.
>
> otherwise, it seems that you took some citations and extracted the
> names of the auhors. It ends up that foaf:givenname as letters such as
> "H", "M", etc... since this information is not really useful, I would
> remove the usage of the foaf:givenname and foaf:family_name and only
> use foaf:name "C.J. Harris".
An interesting point, although tricky as it depends on the data entered
into the repository (which I can't control in my own, let alone other
peoples installs of eprints, #include <rant-about-academics>).
Would it make sense to instead provide "foaf:name" and
"foaf:family_name"? (2nd is useful for sorting etc.), and only
given_name if it contains a lower-case character?
>
> All in all, this document is pretty good to me.
>
> Also, I would personally just use bibo:abstract (and remote
> dct:description). But maybe some of your systems need dct:description
> for some reasons.
Sounds OK to me, I'll do that.
>
> One last question: about the sameAs
> "http://id.ecs.soton.ac.uk/person/119" assertion, is this a URI
> referring to the *same* resource? (just to make sure)
Absolutely. That's a local addition only on eprints.ecs, and won't be in
the release. Both URIs represent the same human being, one in our
eprints software, the other in our central RDF system. We'll provide
examples to people using EPrints on how to link it into their
universities URIs, once everyone realises they want to.
>
>
> Hope this helps, and send any questions on this thread!
It really does, I have had many experiences of people telling me what I
should have done when it's too late. I'm reassured that we're heading in
the right direction.
My only other concern is that there's a hell of a lot of data in EPrints
we're not exposing via BIBO and probably could. Nobody seems deeply
concerned, at this stage, so I'll not break my back trying to understand
every predicate type.
Frederick Giasson
>> Well, as Bruce said, this is a community of people from all fields.
>> Nobody get paid for this work and all the work is done in free time.
>> So, sometimes everybody comments at the same time for days, and other
>> times it takes longer. Anyway, here are my comments:
> I appreciate everyone giving me some time, I'm hoping that EPrints
> will become a useful addition to the BIBO environment. Sorry if I was
> grumpy in my earlier mail.
>>>> http://eprints.ecs.soton.ac.uk/cgi/export/234/RDFXML/ecs-eprint-234.rdf
>>>>
>> Good usage of authorList, and all other bibo predicates (presentedAt,
>> etc).
>>
>> The embedding of all related resources in the same RDF document is
>> good (and simpler for data consumers).
>>
>> The use of DCTERMS is right too. However, some could argue that there
>> there is a duplication of "information" by using both authorList and
>> dct:creator. However, I don't think it is bad is we consider that
>> authorList state the positions of authors in the paper, and creator
>> only states the creators of the document.
>>
>> otherwise, it seems that you took some citations and extracted the
>> names of the auhors. It ends up that foaf:givenname as letters such
>> as "H", "M", etc... since this information is not really useful, I
>> would remove the usage of the foaf:givenname and foaf:family_name and
>> only use foaf:name "C.J. Harris".
> An interesting point, although tricky as it depends on the data
> entered into the repository (which I can't control in my own, let
> alone other peoples installs of eprints, #include
> <rant-about-academics>).
>
> Would it make sense to instead provide "foaf:name" and
> "foaf:family_name"? (2nd is useful for sorting etc.), and only
> given_name if it contains a lower-case character?
>> All in all, this document is pretty good to me.
>>
>> Also, I would personally just use bibo:abstract (and remote
>> dct:description). But maybe some of your systems need dct:description
>> for some reasons.
> Sounds OK to me, I'll do that.
>> One last question: about the sameAs
>> "http://id.ecs.soton.ac.uk/person/119" assertion, is this a URI
>> referring to the *same* resource? (just to make sure)
> Absolutely. That's a local addition only on eprints.ecs, and won't be
> in the release. Both URIs represent the same human being, one in our
> eprints software, the other in our central RDF system. We'll provide
> examples to people using EPrints on how to link it into their
> universities URIs, once everyone realises they want to.
>> Hope this helps, and send any questions on this thread!
> It really does, I have had many experiences of people telling me what
> I should have done when it's too late. I'm reassured that we're
> heading in the right direction.
time by adding more data, making more linkage, adding facts that you
infer (entities reconciliation, etc).
> My only other concern is that there's a hell of a lot of data in
> EPrints we're not exposing via BIBO and probably could. Nobody seems
> deeply concerned, at this stage, so I'll not break my back trying to
> understand every predicate type.
You are talking about the XML file you put in your first email? Well,
the essential is there, and to suggest new addition based on this file,
we will need some more time considering that we have to learn about the
XML schema used, etc. Maybe a good way to do this would be for you to
tell us what information you would like to see in the RDF that you have
in XML. It is hard from ur standpoint to know what data exists (if we
have a cool property only used by .5% of the records, I think it is not
a priority for inclusion). So, you (or anyone in your organization that
is familiar with the data you own) are better positioned to
suggest/include new data in the output.
Thanks!
Fred
Christopher Gutteridge
Frederick Giasson wrote:
To me, it is the right direction. From there, you could improve over time by adding more data, making more linkage, adding facts that you infer (entities reconciliation, etc).
My only other concern is that there's a hell of a lot of data in EPrints we're not exposing via BIBO and probably could. Nobody seems deeply concerned, at this stage, so I'll not break my back trying to understand every predicate type.You are talking about the XML file you put in your first email? Well, the essential is there, and to suggest new addition based on this file, we will need some more time considering that we have to learn about the XML schema used, etc. Maybe a good way to do this would be for you to tell us what information you would like to see in the RDF that you have in XML. It is hard from ur standpoint to know what data exists (if we have a cool property only used by .5% of the records, I think it is not a priority for inclusion). So, you (or anyone in your organization that is familiar with the data you own) are better positioned to suggest/include new data in the output.
The following is a list of the default record types available in a fresh-install of our software. Article is by far the most common, but I need to work out how to correctly map at least the general type of each to a Bibo type. Each has a list of required, recommended and allowed metadata fields.
Fields I think I could easily do something with;
- contributor (lists of names PLUS one of a big list of contribution-types),
- editor
- exhibitors
- producers
- conductors, lyricists, accompaniment (music)
- corporate creator (plain text, could munge into a URI)
- monograph type
'technical_report',
'project_report',
'documentation',
'manual',
'working_paper',
'discussion_paper',
'other',
- presentation type
'paper',
'lecture',
'speech',
'poster',
'keynote',
'other', - pedagogic_type
'presentation',
'activity',
'case',
'enquiry',
'problem',
'collaboration',
'communication',
- publication (eg journal name)
- volume, number
- publisher (free text, but could be munged into a local URI)
- pagerange
- pages (number)
- institution and department (for thesis etc)
- isbn
- issn
- book_title (for chapters of books)
- official_url (the publishers, usually)
- related_url (lists of url/type where type is one of publishers, authors, organisations)
- latitude & longitude (although semantics depend on use of
repository)
- mimetype of main file
- List of files
- Main file
- Content, one of:
draft
submitted
accepted
published
updated
supplemental
presentation
coverimage
metadata
other
- License, undefined + default set of:
- cc_by_nd
cc_by
cc_by_nc
cc_by_nc_nd
cc_by_nc_sa
cc_by_sa
cc_public_domain
cc_gnu_gpl
cc_gnu_lgpl