Print

Print




On 7/31/15 3:19 PM, Joseph Kiegel wrote:
[log in to unmask]" type="cite">

We considered the option of including the link to the related series work inside the bf:seriesStatement property.  However, this changes the relationship from one between an Instance and its related series, to a relationship between a series statement and its series work.  We thought we needed to retain the relationship between an Instance and its related series. 


Isn't the series statement just the display form of the relationship between the two bibliographic entities? Should it really be a thing in itself?

This is where I think we get hung up in trying to convert from a text-based form of cataloging to a thing and link-based form. What used to be a textual statement as a primary way of recording information becomes simply the display form of actual things and links. You don't need to do both, and it wouldn't make sense really to do both -- it would be inefficient and also prone to error.

kc

[log in to unmask]" type="cite">

 

Joe

 

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Tuesday, July 28, 2015 7:10 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Proposal for treatment of series in BIBFRAME

 

 

On 7/27/15 7:39 PM, Stephen Hearn wrote:

 

On Mon, Jul 27, 2015 at 12:47 PM, Karen Coyle <[log in to unmask]> wrote:

<snip.

In fact, what FRBR provides is not a record model but a model of collocation based on bibliographic relationships that can be used in a computerized catalog, something that we were not able to achieve with flat records stored in database management systems. I think this is the key take-away from FRBR and linked data, which is that linking provides a richer form of collocation than we had in the physical catalog, and some of the practices in that catalog were kludges to create some crude collocation through alphabetical order.

 

What I'm stuck on is how to describe the relationship between a numbered series item and its series.  The number belongs to the item, not to the series.  To say that "item x / is a member of series / series x ; no. 3" the way one would with bf:series for an unnumbered series makes no sense, since "series x; no. 3" is not a series--taken as a whole, it's an alternate designation specific to the item.  So the relationship looks more to me like a relationship to an enumeration system.  It could also be modeled along the lines of relator terms/codes,another piece of data which belongs to the resource's description, not the referenced entity.  In MARC we put the relator term after its name--700 1 $a Smith, John $e editor--like we do with series numbers, but as data it specifies the relationship type--Resource X / has editor / Smith, John.  Series number could be treated as bf:numberedSeriesNumber, similar to bf:relator but with a more open vocabulary--Resource X / is no. 3 in / series x.


In RDF, you don't "modify" by adding on to a string. You create graphs of related information, and everything is done with triples.

Relators in RDF won't be added on to the end of string. We had a long discussion here about relators and how they would be handled, but there's no "adding a subfield to a string" in RDF. The problem regarding relators, however, similar to the series problem, in that there is information that is logically a link to an entity (a person, or a series), and information that is specific to the instance being described, such as the role of the person or the enumerated position of the instance within the series.

Putting the series question into words, instanceX is a member of seriesY AND instanceX has sequence designation or number "N" within seriesY. In design terms, the series is identified with  URI and therefore is a linking data element. The series number or sequence is a string.

In pseudo-code: [*warning, possibly bad code ahead; corrections welcome]

instanceX bf:seriesStatement [
  seriesID <seriesY> ;
  enumeration "N" ] .

In triples:

instanceX inSeries _:b7 .
_:b7 seriesID <seriesY> .
_:b7 enumeration "N" .

This looks like what Joe and Theo came up with, with the difference that the series in this case is a link to a graph of information that has the data about the series which they include directly in their series statement. In their case, however, the series information is repeated in each series statement, which not only isn't necessary, it might not be a good idea. However, the three triples above are a bit deceptive because the series information is linked with a URI and therefore the triples of seriesY logically exist as part of the same graph:

<instanceX> ex:inSeries _:b7 .
_:b7 ex:seriesID <seriesY> .
_:b7 ex:enumeration "N" .
<seriesY> a bf:Series .
<seriesY> bf:mainTitle “American university studies” .
<seriesY> bf:publisher <publisher7> .
<publisher7> a bf:Agent .
<publisher7> a bf:CorporateBody .
<publisher7> ex:prefName "American University" .

In other words, the existence of an identifier in the object position (the right hand side) of a triple means that all of the triples with that same identifier in the subject position (the left hand side) are also part of the same graph. We tend to show incomplete graphs because they are more concise, but conceptually graphs are complete. The advantage of this approach is that you can include all of the information about seriesY in any graph simply by referring to seriesY as the object of any triple.

If any of the information here isn't available to your system, then you don't have a complete graph, but, as we do with library databases today, it is only sensible that all currently linked triples will be made available to the library application through some method (copying, caching, etc.). So it's best to think about all identified entities as being at least virtually local graphs, and that all information is complete.

kc



 

Stephen



kc



 

Stephen

 

  

 

On Fri, Jul 24, 2015 at 3:29 AM, Bernhard Eversberg <[log in to unmask]> wrote:

 24.07.2015 03:25,  Karen Coyle:


One thing I think that we have failed to do (as a profession) is to
bridge the gap between the intent of the cataloging rules and the actual
functioning of the technology that will manage the data that is created
in the cataloging workflow.


That's not exactly a new observation.
As I recall, back in 1984, there was an extended thread in AUTOCAT on
the subject of the OPAC interface, and the complete lack of guidelines
for its search and display features. The subject headline was "Face the
Interface". Subsequently, years later, Martha Yee (on behalf of IFLA)
published a study on OPAC design guidelines.
All of that was of no effect, and now RDA (cherished "New International
Standard") does even less to support standardization of search and
display and navigation features. So you can rightly call it a failure
of our profession, and not a small one.
Well, here's a challenge for the up and coming Generation BIBFRAME!

B.Eversberg



 

--

Stephen Hearn, Metadata Strategist

Data Management & Access, University Libraries

University of Minnesota

160 Wilson Library

309 19th Avenue South

Minneapolis, MN 55455

Fx: 612-625-3428

ORCID:  0000-0002-3590-1242

 

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600



 

--

Stephen Hearn, Metadata Strategist

Data Management & Access, University Libraries

University of Minnesota

160 Wilson Library

309 19th Avenue South

Minneapolis, MN 55455

Ph: 612-625-2328

Fx: 612-625-3428

ORCID:  0000-0002-3590-1242



-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600