Print

Print


Thanks, got it. I think this came up a while back, maybe here, and the 
other question is: what is the relationship between the monograph and 
the series and what data belongs to the monograph and what to the 
series? The monograph *is* volume 2357 and 2357 is part of the series.  
So you might see the volume number as a datum of the instance, not of 
the series:

<instanceA> a bf:instance
   bf:enumeration "2357"
   bf:isPartOf <seriesA>

or

<instanceA> a bf:instance
   bf:enumeration "2357"
   bf:isPartOf <volumeA>

<volumeA> a bf:seriesLevel
   bf:enumeration "30"
   bf:isPartOf <seriesB>

In this way, the instance identifier is the identifier for the member of 
the series, rather than it having an identifier of its own. I'm not sure 
that works in practice. And no matter what, series and serials are complex.

kc


On 6/3/16 12:47 PM, Folsom, Steven wrote:
> Maybe this?
>
>
> <SeriesA> a ex:Series ; ##[BIBFRAME currently doesn’t have a Series 
> class.]
>
>    bf:hasPart <SomeVolumeA> ;
>
>    rdfs:label “International archives of photogrammetry and remote 
> sensing” .
>
>
> <SomeVolumeA> a ex:Volume ##[BIBFRAME currently doesn’t have a Volume 
> class.]
>
>    bf:seriesEnumeration “30” ;
>
>    bf:hasPart <SomePart1> .
>
>
> <SomePartA> a ex:SeriesPart  ; ##[BIBFRAME currently doesn’t have a 
> SeriesPart class.]
>
>    bf:seriesEnumeration “3” ;
>
>    bf:instance <SomeInstance> .
>
>
> <SeriesB> a ex:Series ;
>
>    bf:hasPart <SomeVolumeB> ;
>
>    rdfs:label “SPIE Proceedings Series” .
>
>
> <SomeVolumeB> a ex:Volume ;
>
>    bf:seriesEnumeration “2357” ;
>
>    bf:instance <SomeInstance> .
>
>
> The instance in the above example could have two separate literal 
> values in the bf:seriesStatement if representing the information 
> exactly as it appears on the resource is really a use case a library 
> wants to support. There may be (likely) an existing ontology that 
> represents series parts as things rather than literals. At a glance in 
> LOV, there didn’t seem to be one that used a simple hasPart and 
> generic Volume/Issue/Part class pattern. Everything I saw defined (IMO 
> unnecessarily) specialized properties or classes, like hasSeriesVolume 
> or SerialVolume. The pattern proposed above keeps it simple and lets 
> you say the same thing.
>
>
> I might go so far as to say bf:seriesEnumeration should be replaced by 
> a general bf:enumeration, so things not a “series” can be 
> enumerated. LOC might also consider removing bf:hasSubSeries. 
> bf:hasSeries/bf:series are enough. For example:
>
>
> <SeriesA> bf:seriesOf <SeriesB> .
>
>
> Says the same thing as…
>
>
> <SeriesA> bf:hasSubSeries <SeriesB> .
>
>
>
>
>
>
> From: Bibliographic Framework Transition Initiative Forum 
> <[log in to unmask] <mailto:[log in to unmask]>> on 
> behalf of Karen Coyle <[log in to unmask] <mailto:[log in to unmask]>>
> Reply-To: Bibliographic Framework Transition Initiative Forum 
> <[log in to unmask] <mailto:[log in to unmask]>>
> Date: Friday, June 3, 2016 at 2:27 PM
> To: "[log in to unmask] <mailto:[log in to unmask]>" 
> <[log in to unmask] <mailto:[log in to unmask]>>
> Subject: Re: [BIBFRAME] Series in BIBFRAME 2.0
>
>
>
> On 6/2/16 3:41 AM, Folsom, Steven wrote:
>> +1.
>>
>> I'd only add that the volumes and parts should be things too (rather 
>> than be represented as data properties).
>
> Can you give any examples of how you see these done? (It doesn't have 
> to be formal or correctly coded... I'm just not sure what you mean.) 
> Thanks, kc
>
>>
>> If BIBFRAME is to be used outside of library catalogs (say, a Digital 
>> Repository with an Open Access Journal) we'd need to represent the 
>> volume/issue/parts/articles as things.
>>
>> On Jun 2, 2016, at 3:32 AM, Shlomo Sanders 
>> <[log in to unmask]> wrote:
>>
>>> +1
>>>
>>> Thanks,
>>>
>>> Shlomo Sanders
>>>
>>> CTO
>>>
>>> Ex Libris a ProQuest company
>>>
>>> *From:*Bibliographic Framework Transition Initiative Forum 
>>> [mailto:[log in to unmask]] *On Behalf Of *Nicolas Prongu?
>>> *Sent:* Thursday, June 02, 2016 10:23
>>> *To:* [log in to unmask] <mailto:[log in to unmask]>
>>> *Subject:* Re: [BIBFRAME] Series in BIBFRAME 2.0
>>>
>>> Hi,
>>>
>>> Like Jörg, I find it terrible to develop a new standard and to stay, 
>>> in spite of everything, restricted by an existing one (and RDA is 
>>> not the most innovative standard!).
>>>
>>> My proposal would be to keep *both* points of view in the same 
>>> description:
>>>    1. Representing the exact information as it appears on the 
>>> resource (human-readable and RDA compatible), in one triple
>>>
>>>    2. Representing the links (the "real" and "machine-readable" 
>>> information), in a subgraph - Adrian Pohl proposal
>>>
>>>
>>> This would for instance result in such a description:
>>>
>>> <Instance>
>>>
>>> bf:seriesStatement “International archives of photogrammetry and 
>>> remote sensing, 0256-1840 = Internationales Archiv der 
>>> Photogrammetrie und Fernerkundung ; v. 30, pt. 3 = Bd. 30, Teil 3”;
>>>
>>> bf:seriesStatement “SPIE proceedings series, 0277-786X; v. 2357”;
>>>
>>>             lv:inSeries [
>>>
>>> a lv:SeriesRelation ;
>>>                         lv:series 
>>> <http://ld.zdb-services.de/resource/1110794-7> ;
>>>                         prism:volume "30";
>>>                         prism:part "3"] ;
>>>
>>>             lv:inSeries [
>>>                         a lv:SeriesRelation ;
>>>                         lv:series 
>>> <http://ld.zdb-services.de/resource/2082308-3> ;
>>>                         prism:volume "2357" ] .
>>>
>>> We could also include the "seriesStatement" in the 
>>> lv:inSeries-subgraph... Drawback: the statement is also in a blank 
>>> node. Advantage: it is linked to the machine-readable information.
>>>
>>> Best regards
>>>
>>> Nicolas Prongué
>>>
>>> Haute école de gestion de Genève
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Date: Wed, 1 Jun 2016 08:29:49 +0000
>>> From: [log in to unmask] <mailto:[log in to unmask]>
>>> Subject: Re: [BIBFRAME] Series in BIBFRAME 2.0
>>> To: [log in to unmask] <mailto:[log in to unmask]>
>>>
>>> Jörg,
>>>
>>> I think that would require a greater willingness to diverge from RDA 
>>> where transcription and the importance of statements come from, 
>>> arguably more than from MARC. E.g. rule 2.12.1.1:
>>>
>>> “A series statement▼is a statement identifying a series to which a 
>>> resource belongs and the numbering of the resource within the series.”
>>>
>>> 2.12.9.3 mandates the use of wordy numbering too. The examples given:
>>>
>>> ·no. 8
>>>
>>> ·v. 12
>>>
>>> ·4
>>>
>>> ·63-2
>>>
>>> ·tome 3, partie 2
>>>
>>> ·v. 12, part 3, fasc. 1–2
>>>
>>> MARC was designed to deal with RDA’s predecessor which worked on 
>>> similar lines and if Bibframe needs to deal with RDA, it’s going to 
>>> have to record statements and wordiness too. Perhaps it’s RDA that 
>>> needs the sternest stare.
>>>
>>> Thanks,
>>>
>>>
>>> Tom
>>>
>>> ---
>>>
>>> Thomas Meehan
>>>
>>> Head of Cataloguing and Metadata
>>>
>>> University College London
>>>
>>> *From:*Bibliographic Framework Transition Initiative Forum 
>>> [mailto:[log in to unmask]] *On Behalf Of 
>>> *[log in to unmask] <mailto:[log in to unmask]>
>>> *Sent:* 31 May 2016 16:46
>>> *To:* [log in to unmask] <mailto:[log in to unmask]>
>>> *Subject:* Re: [BIBFRAME] Series in BIBFRAME 2.0
>>>
>>> The example shows that Bibframe is not different from MARC.
>>>
>>> Data wrapped in verbose statements, with fillers like "v." or "pt.", 
>>> is not suitable for entities being linked and queried on the web. 
>>> So, there should no properties in Bibframe that contain 
>>> pre-formatted information, like the "statements" in MARC.
>>>
>>> I would rather prefer an enhanced knowledge representation like this:
>>>
>>> <journal1> a fabio:Journal;
>>>
>>>     prism:publicationName "International archives of photogrammetry 
>>> and remote sensing"@en,
>>>
>>>         "Internationales Archiv der Photogrammetrie und 
>>> Fernerkundung"@de ;
>>>
>>>     prism:issn "0256-1840";
>>>
>>>     prism:volume "30";
>>>
>>>     prism:part "3" .
>>>
>>> <journal2> a fabio:AcademicProceedings, fabio:Journal;
>>>
>>>     prism:publicationName "SPIE proceedings series";
>>>
>>>     prism:issn "0277-786X";
>>>
>>>     prism:volume "2357" .
>>>
>>> <instance> frbr:partOf <journal1>, <journal2> .
>>>
>>> Then, it is up to the interpreting program to print a formatted 
>>> "series statements" for the librarian, by calling it "Series", by 
>>> adding fillers etc.
>>>
>>> Just my 2 cents.
>>>
>>> Best regards,
>>>
>>> Jörg
>>>
>>> On Tue, May 31, 2016 at 4:55 PM, Joseph Kiegel <[log in to unmask] 
>>> <mailto:[log in to unmask]>> wrote:
>>>
>>>     The treatment of series information in BIBFRAME 2.0 is a
>>>     significant improvement over 1.0.  It provides for transcription
>>>     of series and subseries in a straightforward way.
>>>
>>>     However, one problem remains:  how to handle multiple series and
>>>     to keep associated series statements and enumerations together. 
>>>     For example, take these series, which appear on a book:
>>>
>>>     International archives of photogrammetry and remote sensing,
>>>     0256-1840 ; v. 30, pt. 3 = Internationales Archiv der
>>>     Photogrammetrie und Fernerkundung ; Bd. 30, Teil 3
>>>
>>>     SPIE proceedings series, 0277-786X ; v. 2357
>>>
>>>     In 2.0, this becomes:
>>>
>>>     < Instance> bf:seriesStatement “International archives of
>>>     photogrammetry and remote sensing, 0256-1840 = Internationales
>>>     Archiv der Photogrammetrie und Fernerkundung” ;
>>>
>>>     bf:seriesStatement “SPIE proceedings series, 0277-786X” ;
>>>
>>>     bf:seriesEnumeration “v. 30, pt. 3 = Bd. 30, Teil 3”  ;
>>>
>>>     bf:seriesEnumeration “v. 2357” .
>>>
>>>     Unfortunately, there is no way to associate each of the
>>>     bf:seriesEnumeration properties with its corresponding
>>>     bf:seriesStatement in a way that machines understand.
>>>
>>>     A possible solution is to introduce, for example, a class Series
>>>     and a property bf:series, which would be used with Work or
>>>     Instance and expect Series.  The existing properties
>>>     bf:seriesStatement, bf:seriesEnumeration, bf:subseriesStatement,
>>>     and bf:subseriesEnumeration would be used with Series and expect
>>>     Literal.
>>>
>>>     The example would look like this:
>>>
>>>     < Instance> bf:series [ a bf:Series ;
>>>
>>>     bf:seriesStatement “International archives of photogrammetry and
>>>     remote sensing, 0256-1840 = Internationales Archiv der
>>>     Photogrammetrie und Fernerkundung”  ;
>>>
>>>     bf:seriesEnumeration “v. 30, pt. 3 = Bd. 30, Teil 3” ] ;
>>>
>>>     bf:series [ a bf:Series ;
>>>
>>>     bf:seriesStatement “SPIE proceedings series, 0277-786X” ;
>>>
>>>     bf:seriesEnumeration “v. 2357” ] .
>>>
>>>     Multiple subseries would be handled in the same way, with
>>>     bf:subseriesStatement and bf:subseriesEnumeration used in place
>>>     of bf:seriesStatement and bf:seriesEnumeration.
>>>
>
> -- 
> 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