Contributor Lists

[skornblith]

I have a couple questions regarding the use of contributor lists:

1) Should an item with authors, editors, and contributors have an
independent authorList, editorList, and contributorList? Or should all
of these be combined into one contributorList?

2) How should the editor for a BookSection in an EditedBook be
modeled? Presumably, the editor will be related to the EditedBook via
bibo:editor and also included in the editorList. Should these
relations be duplicated on the BookSection, since the book editor
presumably edited the section as well? Or is this unnecessarily
redundant?

Thanks,
Simon

[Bruce D'Arcus]

The latter.

The key is that role is modeled independently of order. We added the
authorLIst and editorList subproperties as a convenience.

If had you one author and two editors, then you could have an
editorList property on the EditedBook, and just a single dct:creator
property on the BookSection.

What are the "contributors" in your example?

Bruce

[skornblith]

A "contributor" here is a foaf:Person or foaf:Organization who isn't
related to the item by a dcterms:creator or a bibo:editor arc, e.g., a
bibo:translator or a po:participant.

If you can combine these contributors with authors and editors in a
bibo:contributorList, I guess I'm a little unclear what authorList or
editorList is supposed to make more convenient. Is the idea that:

<bibo:authorList>
<rdf:Seq><rdf:li rdf:ID="n16"/></rdf:Seq>
</bibo:authorList>

is equivalent to

<dc:creator rdf:ID="n16"/>
<bibo:contributorList>
<rdf:Seq><rdf:li rdf:ID="n16"/></rdf:Seq>
</bibo:contributorList>

If this is the case, I have some reservations to the idea generally,
but it should at least be documented somewhere.

[Bruce D'Arcus]

There were no ideal solutions to this problem, just as there isn't in SQL.

> but it should at least be documented somewhere.

Just to be clear, for translations, I'd typically expect something like:

# translated book
ex:1 a bibo:Book ;
bibo:translator contr:1
bibo:translationOf ex:2 .

# original book
ex:2 a bibo:Book ;
dct:creator contr:2 .

If there were more than one creator in the second (original) book,
then you could do:

ex:2 a bibo:Book ;
dct:creator contr:2 .
dct:creator contr:3 .
bibo:authorList ( contr:2, contr3 ) . # note am using an rdf:List here

The bibo:contributorList property is if you need to describe order of
multiple different roles for some (probably odd) reason.

This decision is really a consequence of the current state of SPARQL,
since it's an important priority to be able to query these data
relatively reliably using the standard query language. This structure
allows you, for example, to first easily grab all content authored by
some person. If, OTOH, you want the ordered authorList, you can easily
grab that.

Also, an aside: it would be really nice to see Zotero work towards
turning contributor blank nodes into URIs like:

<http://viaf.org/viaf/36978042>
<http://openlibrary.org/a/OL767948A/Lorcan_Dempsey>

... both of which are examples of linked data, where you can get RDF
(and other) representations.

I know this isn't terribly easy (you need an infrastructure to do
disambiguation across zotero), but treating all contributor data as
effectively dumb text is less-than-ideal as a longer-term prospect.

Bruce

[Frederick Giasson]

Hi!

> If this is the case, I have some reservations to the idea generally,
> but it should at least be documented somewhere

As I said, a new version of the site will appear in the coming month or
so. From there, we will start adding some examples and get the logic
behind these decisions from this group to the site

Right now, the only thing we have as "documentation" for this property
can be found on the mailing list with some search :|

Thanks!

Fred