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]> on behalf of Karen Coyle <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Friday, June 3, 2016 at 2:27 PM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: [BIBFRAME] Series in BIBFRAME 2.0

On 6/2/16 3:41 AM, Folsom, Steven wrote:

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

+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

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

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]
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]
Subject: Re: [BIBFRAME] Series in BIBFRAME 2.0
To: [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]
Sent: 31 May 2016 16:46
To: [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]> 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