Place of publication...again

[Ian Corns]

All,

A good while back, I posted (http://groups.google.com/group/
bibliographic-ontology-specification-group/browse_thread/thread/
e5ebc4a47ddfb20c/bc04083fbf6832be?lnk=gst&q=place+of+publication) a
query about the place of publication. My understanding at the time was
this was the place the publisher was located, which launched a
discussion on using place on dc:publisher.

My understanding of this has recently changed and, as we avoided the
problem at the time but can't avoid it anymore as we're converting
data, I need to resurface the question for some advice.

Looking more closely at the use of this in MARC (260a$), AACR2
cataloguing rules and discussing with some cataloguers, the "place of
publication" is literally the place where the item was published as
recorded on the work. It MAY be the place where the publisher is
located (as I'd originally interpreted it)., but doesn't need to be.
So, conceptually it is related to the item itself rather than the
place where the publisher is located.

So, what we're looking for a a property/literal that is ideally
geotagged to the item. Any ideas?

Thanks in advance,
Ian

[Bruce D'Arcus]

A few random things:

First, you mentioned in that thread you'd check with Nad or Rob. Did
you? If yes, does the above reflect the outcome of that discussion?

Second, part of the problem here is that MARC (and AACR2) is a totally
flat data model; BIBO is not. So it's a bit awkward to reconcile them
at times.

From my perspective, the ideal is that we have URIs for publishers, as
well as for publisher divisions (the example Ross brought up of
"Harper Collins (New York)"), and that those descriptions include URIs
for the place.

But it will admittedly take some time and work to get there, so the
question here is, what do we we do with the data in the interim?

The easiest (and dumbest) solution is to allow a bibo:place literal on
a bibo:Document.

Zotero tends to take the approach of just dumping virtually everything
into blank nodes (which as I've said, I really wish they wouldn't do).

I don't have a strong opinion on this, but agree we need to resolve it.

Bruce

[Ian Corns]

Thanks for replying Bruce.

Yep, both Nad and Rob prompted me to re-email this query, as a result
of our internal discussions.

The challenge here is the fact we're converting a piece of existing
data, but the fact remains the origin/meaning of this data is not
necessarily the place the publisher is located (for which Ross's
example and use of publisher divisions is cool) - instead its
literally where that item was published, which may (and often does) or
may not coincide with the publisher location.

From my understanding of Nads thoughts on this, your easiest solution
"to allow a bibo:place literal on a bibo:Document" aligns to his/our
thinking. Nad is not available to after the weekend, so he may have
some input here.

I guess my final question would be - does anyone else have any input,
or should we look at including bibo:place?

[Ian Davis]

Hi Ian :),

On Fri, Oct 23, 2009 at 5:55 PM, Ian Corns <ian....@talis.com> wrote:

> I guess my final question would be - does anyone else have any input,
> or should we look at including bibo:place?

I used RDA's property placeOfPublication for semanticlibrary.org

See

http://semanticlibrary.org/items/14.rdf

Ian

[Rob Styles]

The RDA placeOfPublication property is a good option. I'd really like to see places represented as resources rather than literals to allow for disambiguation, linking to other datasets, making additional statements and multilingual labelling.

rob

--
Rob Styles
http://dynamicorange.com

[Ross Singer]

On Fri, Oct 23, 2009 at 1:51 PM, Rob Styles <mmmm...@gmail.com> wrote:
> The RDA placeOfPublication property is a good option. I'd really like to see
> places represented as resources rather than literals to allow for
> disambiguation, linking to other datasets, making additional statements and
> multilingual labelling.

+1

So, perhaps rda:placeOfPublication could provide a literal and
wgs84:location (or, probably, a less ambiguous subclass thereof) a
resource?

Unfortunately you'll most likely need both since legacy data will
probably have too much ambiguity to effectively discern a definitive
location.

-Ross.

[Rob Styles]

I don't think we can use wgs84:location (assuming you mean http://www.w3.org/2003/01/geo/wgs84_pos) as it means the location where something is. Perhaps if we introduced a publication event then that would have happened at that location, but that seems more complex than we all want right now.

rda:placeOfPublication (http://metadataregistry.org/schemaprop/show/id/89.html) doesn't specify domain or range so could be used with literals or resources I assume.

rob

[Ian Davis]

I'd just use it with both - literals where you dont know of a good resource uri

On Friday, October 23, 2009, Rob Styles <mmmm...@gmail.com> wrote:
> I don't think we can use wgs84:location (assuming you mean http://www.w3.org/2003/01/geo/wgs84_pos) as it means the location where something is. Perhaps if we introduced a publication event then that would have happened at that location, but that seems more complex than we all want right now.
>
> rda:placeOfPublication (http://metadataregistry.org/schemaprop/show/id/89.html) doesn't specify domain or range so could be used with literals or resources I assume.
>
> rob
>

> On Fri, Oct 23, 2009 at 9:31 PM, Ross Singer <rossf...@gmail.com <javascript:_e({}, 'cvml', 'rossf...@gmail.com');>> wrote:

[Ian Corns]

Just ran through this thread with Nad, and he seems happy with the result - thanks for everyones comments

Please consider the environment before printing this email.

Find out more about Talis at www.talis.com

shared innovationTM

Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited.

Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.