On 8/23/15 10:14 AM, Thomas Berger wrote:
> In the example
>
> bf:contributor [
>    a bf:Contributor ;
>    bf:role [
>      a bf:Role ;
>      rdfs:label “creator” ;
>      bf:identifiedBy<http://id.loc.gov/vocabulary/relators/cre>
>    ] ;
>    bf: agent [...] .
>
> my naive understanding would be that bf:identifiedBy for the bf:role
> provides a concept URI in the sense of owl:sameAs and therefore the
> contraction
>
> bf:contributor [
>    a bf:Contributor ;
>    bf:role<http://id.loc.gov/vocabulary/relators/cre>  ;
>    bf:agent [...];
>
> should also be a valid way to express the same relation.
> (<http://id.loc.gov/vocabulary/relators/cre>  directly being of class
> bf:Role would be implied then, determining a suitable label would
> be left to applications, I can't see any problems in that)

This seems to me to be an implementation issue, and it would probably be 
preferable if BF allowed for more than one implementation choice. There 
is no reason why some implementations should not include these triples 
in their graphs:

bf:contributor [
   a bf:Contributor ;
   bf:role<http://id.loc.gov/vocabulary/relators/ill>  ;
   bf:agent<http://id.loc.gov/authorities/names/1234>  ].

<http://id.loc.gov/vocabulary/relators/ill>
   skos:prefLabel "[email protected]" ;
   a<http://www.loc.gov/mads/rdf/v1#Topic/>  .

<http://id.loc.gov/authorities/names/1234>
   a<http://www.loc.gov/mads/rdf/v1#Authority/>  ;
   skos:prefLabel "John Smith" .

In conversations I have had with folks developing RDF-based 
applications, inclusion of third-party authority data in their graphs is 
being built into the data ingest process. It also could be the result of 
caching.

Admittedly, it's still unclear to me if BIBFRAME is being developed as 
an exchange format or as some kind of data storage design.

kc

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