Rob, et al. -

Going back to it, the particular problem that I was having was the use of "label" for different properties, such as:

<http://example.org/1> a bf:Instance,
     bf:publication [
         a bf:Provider ;
         bf:providerDate "1966" ;
         bf:providerName [ a bf:Organization ; bf:label "Hamlyn" ] ;
         bf:providerPlace [ a bf:Place ; bf:label "London" ]
     ] .
Both place and organization name would need to be searched on the string predicated with bf:label. In order to distinguish them, it would be necessary to walk down the graph from the distinguishing property (providerName or providerPlace) to the non-distinguishing property, bf:label. Because of the intervening blank nodes, this path wasn't available, and a simple search on bf:label would bring in results from various unrelated triples. (There may be other uses of bf:label in BF - I haven't looked for them.) This is the simple query that failed for that reason:

SELECT ?subject ?label
    WHERE { ?subject bf:providerName ?bnode .
        ?bnode bf:label ?label . }

There are a few potential solutions that I can see:

1) use specific terms in the place of bf:label. This could get ugly, but bf:providerPlaceLabel would make the search possible
2) create named graphs instead of blank nodes so that the graph can be traversed using SPARQL (e.g. your bf:providerPlace would need a non-bnode URI). This may need to apply to other areas of BF that use blank nodes.

Note, however, that even if we do create a bf:agent that can link the place and the name, there will continue to be other issues having to do with the order of statements. For example, where there is more than one place of publication, AACR says "always give the first named place" -- that is, provide the same order as is found on the piece. The transcribed portion of the bibliographic record has a lot of challenges of this nature, and we may need to either give up some of the rules that govern transcription, or treat the transcribed text as a single document that maintains order, punctuation, etc.

kc


On 7/31/14, 2:29 PM, Robert Sanderson wrote:
[log in to unmask]" type="cite">

+1 to standardizing the representation of place, using identifiers. (I'm sure that's no surprise to any one)

I'm less in favor of publisherStatement to transcribe and then repeat the same information in somewhat of a jumbled fashion with repeating publishedAt/By/On.  If there's the possibility of multiples, as demonstrated, then the information shouldn't get lost as to which place is associated with which organization, IMO.

Here the structure isn't imposed just for the sake of having structure, it's to model the publication event and its participants.  The W3C PROV-O equivalent would be:

_:instance1 a bf:Instance, prov:Entity ;
    prov:wasGeneratedBy [ _:publicationEvent a prov:Activity, bf:PublicationActivity ;
        prov:used [ _:work1 a bf:Work ] ;    // maybe?
        prov:wasAssociatedWith [ _:ucp a bf:Organization ; ...] ;
        prov:wasAssociatedWith [ _:gv a bf:Organization ; ... ] ;
        prov:startedAtTime "1955" ;
    ]
]
    
    
Rob 



On Thu, Jul 31, 2014 at 2:04 PM, Ford, Kevin <[log in to unmask]> wrote:
Agreed.

The transcription element aside, which would be contained within the publisherStatement, I would expect a value vocabulary be used, and therefore an identifier be used, when recording the place of publication /as data/.  In that case, the identifier would be specific to Paris, France versus Paris, Texas.

Yours,
Kevin


> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum
> [mailto:[log in to unmask]] On Behalf Of [log in to unmask]
> Sent: Thursday, July 31, 2014 4:49 PM
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Proposal to handle "Providers" differently
>
> This seems to me to be a really excellent opportunity to take advantage of
> the opportunity presented by Linked Data. We could translate: "Paris
> [France]" to http://dbpedia.org/data/Paris or some other specific choice,  or
> "Chicago [Illinois]" to http://sws.geonames.org/4887398 or some other
> specific choice... we could use identifiers for a task for which they are very
> well suited: disambiguation.
>
> ---
> A. Soroka
> The University of Virginia Library
>
> On Jul 31, 2014, at 4:09 PM, "J. McRee Elrod" <[log in to unmask]> wrote:
>
> > Karen posted:
> >
> >> e.g. Paris : Gauthier-Villars; Chicago : University of Chicago Press, 1955.
> >
> > As I keep saying, our European and/or Asian clients would want
> > [France] after Paris, and [Illinois] after Chicago.  Our North
> > American cleints want jurisdction for some cities for which Australian
> > and DLC records lack jurisdiction.  A city known in Canberra or the
> > Beltway may not be known in Canada.  Isn't it time, since we are no
> > longer limited by what we can get on a card, to leave our Anglo silo?
> >
> > It seems to me, the move to Bibframe would be a time to standardize
> > representation of place.
> >
> > As was said in the early days of automation, "garbage in, garbage
> > out".  Isn't it time we were more consistent in what we are coding, as
> > opposed to feeding in truncated unit card type data?
> >
> > In Bibframe, the labels are sometimes longer than the data being
> > coded!
> >
> >
> >   __       __   J. McRee (Mac) Elrod ([log in to unmask])
> >  {__  |   /     Special Libraries Cataloguing   HTTP://www.slc.bc.ca/
> >  ___} |__
> \__________________________________________________________



--
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet