Print

Print



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] 
> <mailto:[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 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__ld.zdb-2Dservices.de_resource_1110794-2D7&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=nOBG2_NbYDeeutfI6oVjC2-VeKxHfRfFN_eDQftfT6k&m=1W6sJa36LagxQ4eqOdvw_ZiqhtXfpxWTuDUcRqL-83A&s=NQX7p_aLd_D_UXwuwolZLQsgSjfEiaHQ4qiAVV-BCks&e=>> 
>> ;
>>                         prism:volume "30";
>>                         prism:part "3"] ;
>>
>> lv:inSeries [
>>                         a lv:SeriesRelation ;
>>                         lv:series 
>> <http://ld.zdb-services.de/resource/2082308-3 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__ld.zdb-2Dservices.de_resource_2082308-2D3&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=nOBG2_NbYDeeutfI6oVjC2-VeKxHfRfFN_eDQftfT6k&m=1W6sJa36LagxQ4eqOdvw_ZiqhtXfpxWTuDUcRqL-83A&s=vvU8Ltz4gL2zrKeIP0gYTczixgREX0omlaVbdAt1FA0&e=>> 
>> ;
>>                         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
https://listserv.loc.gov/cgi-bin/wa?A3=ind1606&L=BIBFRAME&E=8bit&P=362407&B=--------------AADCC9BE6AD170482F0CC437&T=text%2Fplain;%20charset=utf-8&header=1
listserv.loc.gov
crawl=CC-MAIN-2022-49
12789
application/http; msgtype=response
sha1:EVRZMB5K22NYIA7RBUTUVF2BA2N3TUMS
<urn:uuid:2b4ea1f2-8290-4a8c-804f-23ae4303b339>
2022-11-29T09:37:49Z
140.147.239.86
text/html
sha1:PYVHBAC4YQ75W4JMSRKQJPUGBRKYTAIW
<urn:uuid:793fdb87-3472-4ab8-8e02-545e606a32ea>
https://listserv.loc.gov/cgi-bin/wa?A3=ind1606&L=BIBFRAME&E=8bit&P=362407&B=--------------AADCC9BE6AD170482F0CC437&T=text%2Fplain;%20charset=utf-8&header=1
response
<urn:uuid:2bfe06ff-1727-41ed-bc8d-6b9283e1cb59>
isPartOf: CC-MAIN-2022-49
publisher: Common Crawl
description: Wide crawl of the web for November/December 2022
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-11
software: Apache Nutch 1.19 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.4-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/