Print

Print


Hey James,

again, why should events even be in scope of the bibliographical
domain? Secondly, MARC is not part of the Linked Data picture.

In general, I think the answer can be only as specific as: "it
depends". Mostly on usage.

If you know that a book is about "United States--History--Civil War,
1861-1865", then the only thing you can state in RDF with certainty
is:

  _:book dct:subject [ dct:title "United States--History--Civil War,
1861-1865" ] .

In other words, this book is about something with this title. I've
used blank nodes and Dublin Core properties here, but they could also
be URIs and properties from a different vocabulary.

Now maybe someone else has minted a URI for your subject concept, e.g.
DBPedia. Then you can state instead:

  _:book dct:subject <http://dbpedia.org/resource/American_Civil_War> .

If you dereference DBPedia's URI, you will find RDF types such as
dbo:Event. At this point your book is explicitly about the US Civil
War, in a distributed Linked Data context.

Notice that no BIBFRAME specific properties or classes were necessary
to state that fact.

P.S. URI itself is not "the thing", it only *identifies* "the thing".


Martynas

On Sat, Jan 23, 2016 at 5:58 PM, James Weinheimer
<[log in to unmask]> wrote:
> On 1/23/2016 2:24 AM, Martynas Jusevičius wrote:
>>
>> I encourage participants of this list to watch the following
>> presentation by Robert Sanderson before diving into philosophical
>> discussions about events in spacetime:
>> https://www.youtube.com/watch?v=2-U-Qd37WgE
>
>
> Thanks for that. Very interesting.
>
> The discussion about reuse is at: https://youtu.be/2-U-Qd37WgE?t=31m26s, and
> I agree that if you want developers to include your information (which is
> the idea of linked data), it is necessary to reuse code whenever possible.
> Otherwise, you are creating a huge additional hurdle for the developers and
> many will choose not to include your information in any tools they create.
>
> Of course, the problem with using other codes is that you end up stuck in
> certain ways if they define things differently than you do. So, that is why
> in my previous message I gave the definitions of "event" as used in other
> implementations. None of them use anything that is similar to any library
> usage. Therefore, if we are to make something that will be useful and valid
> in an "events" semantic system created by somebody else, we have to decide
> how to index our information to match others' ideas of events.
>
> If an event is seen only as a meeting of people, then in addition to the
> 111s, there will also be many, but far from all, 110s (e.g. 110     2_ |a
> Air Traffic Control Association. |b Annual Meeting |n (22nd : |d 1977 : |c
> Las Vegas, Nev.)) and even many 151/110 jurisdictional names (e.g. 110
> 10 |a United States. |b Congress |n (101st : |d 1989-1990))
>
> If an event is supposed to cover other "things that happen" caused by humans
> such as wars and battles or events caused by non-humans, the new index will
> need to include some, but not all, 150s (150 __ |a Hurricane Katrina, 2005)
> and 151s (151     __ |a United States |x History |y Civil War, 1861-1865).
>
> With subjects, there is the additional complexity that there are
> subdivisions, e.g. the subject "United States--History--Civil War,
> 1861-1865--Bibliography". Would this still be considered an event?
>
> If not, there is the URI for this subject, which includes the entire string.
> http://id.loc.gov/authorities/subjects/sh2007100437.html. Would this entire
> URI still be considered an event? If not, how would it work vis-a-vis the
> URI for "United States--History--Civil War, 1861-1865"?
>
> Many others view events as individual performances as for instance, when
> someone wants to buy or sell tickets to a musical concert. Libraries don't
> code to this level and you need to look at the entire record for individual
> performance information.
>
> No matter what, it sounds like adding "event" would mean a major change for
> our current data.
>
> James Weinheimer [log in to unmask]
> First Thus http://blog.jweinheimer.net
> First Thus Facebook Page https://www.facebook.com/FirstThus
> Personal Facebook Page https://www.facebook.com/james.weinheimer.35
> Google+ https://plus.google.com/u/0/+JamesWeinheimer
> Cooperative Cataloging Rules
> http://sites.google.com/site/opencatalogingrules/
> Cataloging Matters Podcasts
> http://blog.jweinheimer.net/cataloging-matters-podcasts
> The Library Herald http://libnews.jweinheimer.net/
>
> [delay +30 days]