Print

Print



On 7/31/15 3:19 PM, Joseph Kiegel wrote:
>
> 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

> 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]
>     <mailto:[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]
>             <mailto:[log in to unmask]>> wrote:
>
>                  24.07.2015 03 <tel:24.07.2015%2003>: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
>
>             Ph: 612-625-2328 <tel:612-625-2328>
>
>             Fx:Â 612-625-3428 <tel:612-625-3428>
>
>             ORCID: Â 0000-0002-3590-1242
>
>         -- 
>
>         Karen Coyle
>
>         [log in to unmask]  <mailto:[log in to unmask]>  http://kcoyle.net
>
>         m:+1-510-435-8234  <tel:%2B1-510-435-8234>
>
>         skype: kcoylenet/+1-510-984-3600  <tel:%2B1-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]  <mailto:[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