Print

Print



On 8/26/15 8:44 AM, Steven Folsom wrote:
>
> Re:Roles, I’m a little confused about semantics of the role proposal, which may be related to Karen’s observation about bf:Instance data and bf:Agent data. Using the example in the proposal:
>
> bf:contributor  [a bf:Contributor ;
> 	bf:role <some role resource> ;
> 	bf:agent <some agent resource> ].
>
>
> I read this to mean some work (not represented in the example) has some bnode bf:Contributor. That bf:Contributor has a role. That bf:Contributor has a related agent. Is the bf:Contributor really more of a Contribution, like a PROV Activity (http://www.w3.org/TR/prov-o/)? If so, the proposal makes semantic sense, and I would just recommend naming bf:Contributor to bf:Contribution or just using PROV activity.

I, too, am puzzled about the semantics of this. To me it says:

<some resource> <has a contributor> x
x is a Contributor
x has role <role>
x has agent <agent>

x obviously doesn't *have* an agent in the way that it has a role -- 
<agent> is the identifier for x. But I don't see how x can *be* both x 
AND some agent. In this example "x" represents the contributor, and 
<agent> also represents the contributor. Or, if you look at it in terms 
of what entity is being described, it comes down to "x has agent <x>" 
because they are talking about the same thing. (This seems to call for 
"owl:sameAs".)

I think this is one of the tricky aspects of using blank nodes. It isn't 
that they represent a blank -- they represent a specific thing that, at 
that moment in time, has no name. But it's still a thing. It's not, as 
it has been called here, a data structure. So the bnode x is a real 
thing, and if it is the same thing as <agent> then, as you say below, 
the most sensible way to portray this in RDF is:

<some work> <some role/relator> <some agent resource> .

or

<some bib entity> bf:contributor  [a bf:Contributor ;
	bf:role <some role resource> ;
	owl:sameAs <some agent resource> ].


kc

>
> If the bf:Contributor is a bf:Agent then there are some issues. The bnode bf:Contributor (again, if it is a bf:Agent) is the *same as* the <some agent resource>; the <some agent resource> isn’t the *agent of* the bnode bf:Contributor. Also, if the bnode were ever replaced by a URI for the Agent, all other roles the Agent ever performed in other works would automatically be now associated with this work.
>
> If a bf:Contributor is a bf:Agent it would make more sense just to say:
>
> <some work> <some role/relator> <some agent resource> .
>
> (Note, the <some role/relator> property would have to have the range of an Agent. We would have to careful to not use properties that have domains of a work with a range of authority with bf:Contributors if they are agents.)
>
> The Agent in turn could be described by an authority:
>
> <some work> <some role/relator> <some agent resource> .
>
> <some agent resource> <bf:identifiedBy> <some authority> .
>
>
>
> Re: the Identifiers proposal, Karen has said this before, but we shouldn’t conflate the role of URIs with string identifiers. When I read the Authorities proposal, I interpret bf:identifiedBy as having the semantics:
>
> <some thing> <is identified through an authority> <some authority resource> .
>
> **But** the identifier proposal says the bf:identifiedBy property is for an identifier string. That’s very different. I would recommend we be able to say the following through different properties:
>
> <some bf:Resource> <is described by an authority> <some authority resource> .
> <some authority resource> <is identified by an identifier> <some string identifier> .
>
>
> Thank you for your consideration,
> Steven
>
> ————
> Steven Folsom
> Metadata Strategist and Standards Advocate
> Cornell University Library
>
>
>
>
>
>
>
> On 8/25/15, 5:58 PM, "Bibliographic Framework Transition Initiative Forum on behalf of Thomas Berger" <[log in to unmask] on behalf of [log in to unmask]> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Am 25.08.2015 um 19:58 schrieb Karen Coyle:
>>
>>>> bf:contributor [
>>>>     a bf:Contributor ;
>>>>     bf:role<http://id.loc.gov/vocabulary/relators/ill>  ;
>>>>     bf:role<http://id.loc.gov/vocabulary/relators/aut>  ;
>>>>     bf:agent<http://id.loc.gov/authorities/names/1234>  ;
>>>>     bf:agent<http://d-nb.info/gnd/9876>  ].
>>>>
>>>> (MARC semantics: two different roles for one bibliographic
>>>> identity accounted for in different authority files)
>>> Wouldn't it be preferable that any equivalence between agent identifie
>> rs
>>> be declared outside of the instance data for a bibliographic resource?
>>> Logically, the information that they are equivalent is not related to
>> a
>>> particular bibliographic resource, but is a fact related to the agents
>>> themselves. It should hold true for all instances.
>> Well, I wouldn't expect that one cataloging agency would tie its
>> activities to more than one authority control environment. And if,
>> it probably would encapsulate that into some local construction
>> detailing on the exact findings of the agency:
>>
>> bf:contributor [
>>    a bf:Contributor ;
>>    bf:agent<http://example.com/authorities/xyz> ]
>>
>> <http://example.com/authorities/xyz> [
>>   a schema:Person ;
>>   a bf:Agent ;
>>   rdfs:label "John Doe (1900-1983)" ;
>>   skos:exactMatch <http://id.loc.gov/authorities/names/1234> ;
>>   schema:sameAs <http://d-nb.info/gnd/9876> ;
>>   owl:differentFrom <http://www.wikidata.org/entity/abc>
>> ].
>>
>> But for some bibliographic aggregator who does not want to presuppose
>> the authority control ecosystem potential consumers of its data would
>> prefer I can imagine descriptions where alternative(!) identifications
>> for the bf:contributor are supplied. I mean, there certainly must have
>> been a use case when MARC's 7XX $0 was introduced as repeatable?
>>
>> I'd consider this "instancial" evidence of possible identity, declaring
>> equivalence in the context of a bf:Agent would be a stronger statement.
>>
>> BTW: Different authority control systems use rather different
>> vocabularies to establish cross border identification of their
>> resources (there seems to be a general tendency to avoid owl:sameAs,
>> though). Given the fact that even for simple agents like persons
>> the entities not always are in 1:1 correspondance (e.g. LCAuth focussing
>> on bibliographic identities, and ULAN very much on real persons),
>> could or should there be a bf:identicalTo property declaring equivalence
>> in a Bibframe sense? Or would identity rather be something to be
>> defined by the application, e.g. data created in the context of a
>> manuscript and letters application would probably not distinguish
>> between Ruth Rendell and Barbara Vine and thus would use "regular"
>> authority control with a deviant notion of equivalence ;)
>>
>>
>>> (This brings up the question of usage of VIAF identifiers in the place
>>> of specific authority control identifiers, but that's another topic.)
>> Maybe not at all. Certainly VIAF is lacking some features we are
>> accustomed to find in more traditional authority control systems,
>> but if some people successfully start to use VIAF in lieu of
>> ordinary authority control, then my expectation on Bibframe would be
>> that VIAF based authority control should not work differently from
>> ordinary ones. So "VIAF" could serve as kind of litmus test for
>> Bibframe concepts ans properties - if they rely on "traditional"
>> features not present in VIAF they are lacking universality (in the
>> universe Bibframe is concerned with) and should be considered optional
>> at most.
>>
>> viele Gruesse
>> Thomas Berger
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iJwEAQECAAYFAlXc5QMACgkQYhMlmJ6W47NXIQP+OQoHIL6caieYMysDVvGrilf5
>> jHAo//n7tbH2T16iR5aoy8C4WO8rtJFgFvLPfJH22P5b2QhAA3oeHctqAMi/P8gk
>> 5X48gAwqYrQffDw6glSD+XL6a59p0JIUQFWW4lFpEq8Y+dLp3Jz9Kq4VCkDMDsul
>> Jht1oMxqC+v+azrB9Hs=
>> =Kcxq
>> -----END PGP SIGNATURE-----

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