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 


> 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]>
>     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]
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600