Someone more familiar with OWL can correct me, but I think this use would be acceptable if bf:adminMetadata was defined like so:

 

bf:adminMetadata a owl:AnnotationProperty;

                # etc.

                .

 

Note that owl:AnnotationProperties “must not be used in property axioms”, which presumably includes owl:sameAs inferencing.

 

http://www.w3.org/TR/owl-ref/#Header

 

Stated a little differently, the statement may or may not have meaning outside the context (graph) in which it occurs.

 

There’s probably a better way to say that.

 

Jeff

 

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Steven Folsom
Sent: Tuesday, January 05, 2016 3:04 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Administrative Metadata proposal

 

Tim,

 

I had the same response. I want it to work, but it feels like the pattern is trying to fake a quad without naming the graph[1]. [For the record, I’m not advocating for Named Graphs.]

 

Using the Administrative Metadata proposal breaks down when you start using owl:sameAs assertions. For example…

 

<http://id.loc.gov/authorities/names/n94064763#RWO>

    a bf:Person ;

    owl:sameAs <http://viaf.org/viaf/41071008> ;

    rdfs:label "Rineer, A. Hunter (Amos Hunter),  -1985" ;

    bf:adminMetadata [

        a bf:AdminMetadata ;

        bf:changeDate "2009-09-28T18:43" 

    ] .

 

The above statement is saying <http://viaf.org/viaf/41071008> has the same administrative metadata as <http://id.loc.gov/authorities/names/n94064763#RWO> .

 

Respectfully,

Steven

 

[1] http://patterns.dataincubator.org/book/named-graphs.html 

 

 

From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of Tim Thompson <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Monday, January 4, 2016 at 8:10 PM
To: "[log in to unmask]" <[log in to unmask]>
Subject: [BIBFRAME] Administrative Metadata proposal

 

Hello, happy 2016 to all.

I've had a lingering question about the BF 2.0 Admin Metadata proposal[1]. It seems to take a step in the right direction, in that it makes admin metadata easier to isolate, but in the end I don't see how it is conceptually any different from the BF 1.0 approach.

The property bf:adminMetadata is still a property of the description of a resource, not of the resource itself, and as a wise man once wrote, "The same URI cannot identify both a document that describes the resource and the resource itself."


This becomes more apparent when the resource being described is, for example, a person, rather than an abstraction like bf:Instance.


    a bf:Person ;

    rdfs:label "Rineer, A. Hunter (Amos Hunter),  -1985" ;

    bf:adminMetadata [

        a bf:AdminMetadata ;

        bf:changeDate "2009-09-28T18:43"

    ] .


It's not the RWO that has admin metadata, but <http://id.loc.gov/authorities/names/n94064763>, the authority record that describes the real person.

 

Wouldn't it be more coherent to recommend that separate URIs be used for RWOs and the documents that describe them, as exemplified by the hash URI above?

 

Best,
Tim


[1] http://www.loc.gov/bibframe/docs/pdf/bf2-draftspecadmin-10-29-2015.pdf


--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library