Print

Print


On the whole I agree we need both the ability to record a series statement and to consider series as its own entity related to the thing being cataloged, I do have one comment about Eric's statement.

From a visibility use-case perspective, the current approach we're taking is to define a Series as a Collection (of Works). As Collections are a subClass of Work, Series can have members which are other Series. The relationship "memberOf" associates Works as part of a Series (Collection). The topology (as illustrative above by clicking around and following your nose) is pretty interesting and this helps raise the visibility of these resources.

This approach again assumes (like RDA) that the series relationship is work to work which is not always the case.  A particular instance of  a work may be in series while another instance of that same work is not in a series or in a different series.  Ideally I think that we would want to be able to have a Collection as a subclass of instance or even the more general Resource so we could relate at whatever level is appropriate.

Barbara

__________________________________________________
Barbara Bushman
Assistant Head
Cataloging and Metadata Management Section
National Library of Medicine
8600 Rockville Pike
Building 38, Room 1N13
Bethesda, MD 20894
301-496-7135
301-402-1211 (fax)
[log in to unmask]<mailto:[log in to unmask]>




From: Eric Miller [mailto:[log in to unmask]]
Sent: Tuesday, July 21, 2015 7:16 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Proposal for treatment of series in BIBFRAME


On Jul 21, 2015, at 11:38 AM, Karen Coyle <[log in to unmask]<mailto:[log in to unmask]>> wrote:

Joe and Theo,

This is clearly a well-thought out bit of work. I assume that the blank node solution is viable, but I wonder if you contemplated another possibility: that the series is a bibliographic entity on its own that has a relationship with monograph? This would make sense given that:
 - a series is a work in its own right
 - there can be catalog entries for the series itself
 - some series have authority records

The advantage of this solution is that it identifies a series with a persistent identifier that would allow one to link all members of the series, e.g. to show a list of monographs in the series.

The following are examples of the kind of modeling Karen is describing.  Series as a typed resource with persistent identifiers that would allow one to link all of its members (e.g. to show a list of monographs in the series).

- http://labs.libhub.org/worthingtonlib/resource/q1-0LjxD/
- http://labs.libhub.org/denverpl/resource/-xJPFP-c/
- http://labs.libhub.org/anythink/resource/_WKi-go9/

For those interested, the raw data of the first Series can be extracted from the RDFa of the page and seen here:

- http://www.w3.org/2012/pyRdfa/extract?uri=http%3A%2F%2Flabs.libhub.org%2Fworthingtonlib%2Fresource%2Fq1-0LjxD%2F&format=turtle&rdfagraph=output&vocab_expansion=false&rdfa_lite=false&embedded_rdf=true&space_preserve=true&vocab_cache=true&vocab_cache_report=false&vocab_cache_refresh=false<http://www.w3.org/2012/pyRdfa/extract?uri=http://labs.libhub.org/worthingtonlib/resource/q1-0LjxD/&format=turtle&rdfagraph=output&vocab_expansion=false&rdfa_lite=false&embedded_rdf=true&space_preserve=true&vocab_cache=true&vocab_cache_report=false&vocab_cache_refresh=false>

These Series are materialized from collections of MARC records that share MARC 830 properties. While there is certainly more testing to do, I continue to be impressed how well existing MARC records map to this paticular linked data pattern.


The disadvantage is that it has to solve these problems:
1. what to do with series that usually do not get authority control (e.g. the publishers' series)

This is not an issue of identifiers but a general one of determining when things are the same and when they're not.


(my take: treat them as entities and give them an ID)

Agreed.  And the ability to give these resources identifiers at the granularity your describing provides a basis for more collaborative, value-add curation going forward.

2. at what "level" to link a series to a bf:Instance (the bf:Work for the series?)

These questions always fall back "it depends" and benefits from concrete use cases.

The #2 question there is one that is even more complex with FRBR, but is true for all multi-entity bibliographic models, which is that bibliographic relationships need to be made between entities and it isn't always clear which entities are appropriate for the relationship. In this case, the series as a bf:Work is manifested as a group of bf:Instance's with a "partOf" relationship. There's no single publication that is the bf:Instance of the series.

From a visibility use-case perspective, the current approach we're taking is to define a Series as a Collection (of Works). As Collections are a subClass of Work, Series can have members which are other Series. The relationship "memberOf" associates Works as part of a Series (Collection). The topology (as illustrative above by clicking around and following your nose) is pretty interesting and this helps raise the visibility of these resources.

Joe and Theo's suggestion of "series" (as partOf refinement) is a further refinement of "memberOf" but that level of specificity may be less important once one treats Series as a typed resource.  That said, their document is good analysis and, as this is such a complex issue, more thought,  experimentation and exploration is certainly required.

--
Eric Miller
President, Zepheira "The Art of Data"
http://zepheira.com/ tel:+1.617.395.0229