Thomas,

Orthogonal to the current hot issues on the list this weekend, but I wanted to pick up on your questions about granular annotation targets from several days ago that were left dangling. This is my take, with a bias towards the RDF approach to the world. 

Long story short -- to annotate individual statements within a BIBFRAME description, you need to start by giving an identifier (URI/IRI) to that BIBFRAME description as a set of RDF statements (triples). Essentially this makes the BIBFRAME description an RDF named graph.  Since named graphs can be comprised of a single triple, you could go further and give every triple within the BIBFRAME description its own URI in order to allow arbitrary annotation, but that's not very practical. For now, mechanisms to annotate a specific statement/triple within a named graph or RDF document are serialization-specific. Put in practical terms, you have to be explicit about whether you are annotating the RDF/XML serialization of the BIBFRAME description or the JSON-LD serialization of the BIBFRAME description. Both could easily have the same URI and rely on content negotiation to decide which serialization to deliver, but the Selector that allows you to specify which statement within the RDF graph is the one you mean, is different according the representation (the serialization) you get.  As part of its model of oa:SpecificResources, Open Annotation includes properties like oa:hasSource, oa:hasState, oa:hasSelector and appropriate classes to allow you to do all this. Fragment identifiers don't work, because fragment identifiers are MIME-type specific and RDF instances (BIBFRAME descriptions) can be disseminated in a variety of different MIME types (think xml, N3, turtle, JSON-LD, ...). There's been some discussion that a SPARQL-based selector could be developed which would be serialization agnostic and so might simplify some of this, but that's a bit speculative at the moment.  

All of which may be unduly esoteric, since I think you may want to clarify your use cases. The need to annotate a single statement within a BIBFRAME description, as opposed to annotating entities mentioned in the description or the description as a whole, may not come up as often as you anticipate. 

For more detailed comments, see embedded below.

Thanks,
Tim Cole
University of Illinois at UC

> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum
> [mailto:[log in to unmask]] On Behalf Of Thomas Dukleth
> Sent: Tuesday, June 25, 2013 8:27 AM
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Annotations: External and inline
> 
> How might bf:Annotation function to treat an individual occurrence of a
> particular property as the target of an annotation?
> 
> Such granular targets would often be necessary in a linked data
> environment where we hope to be readily exchanging a little bit of data
> here, there, and everywhere.  

Sometimes yes, but may need to explore and clarify the use cases. I suspect that most often the bits of data being exchanged will be about a Resource (bf:Work, bf:Instance, bf:ProviderEntity, etc.) not about a single specific  statement (RDF triple) asserting a particular property, e.g., if asserting an additional bf:subject, a bf:providerPlace, etc. you are annotating the bf:Work, bf:Instance, bf:ProviderEntity, etc. not a BIBFRAME property triple. In other cases the annotation may be about a set of triples collectively, see next comment.

> The postponed issue of provenance seems to
> require such granular annotation for provenance to be meaningful in a
> linked data environment.  If our automation systems would already be doing
> all that they should do for us, we should already have provenance for MARC
> records provided automatically without any necessary human effort at the
> individual occurrence of every field, indicator, and subfield.

Agreed. But RDF doesn't deal with records as such. The closest analog is a named graph. In RDF a graph is a set of triples -- such as you get by transforming a MARC XML record into BIBFRAME semantics using the bibframe.org/tools Transformation service. A named graph is an RDF graph that has been given a unique identifier.  

The RDF world is still coming to grips with how to manage named graphs.  Leigh Dodds posted a nice, albeit brief discussion about this a few years ago (http://blog.ldodds.com/2009/11/05/managing-rdf-using-named-graphs/). For more current thinking about how named graphs and RDF datasets work / will work, see RDF 1.1 Concepts and Abstract Syntax Working Draft from earlier this year (and related documentation), starting with the very succinct definitions offered (http://www.w3.org/TR/rdf11-concepts/#section-dataset). A named graph can be a single triple (a single BIBFRAME property statement) or a set of triples (the set of BIBFRAME statements created by transforming a MARC XML record) or anything in between. Named graphs can overlap or can contain other named graphs, etc. The cost of course is that every named graph has to be given a name (i.e., a URI/IRI).

So if what you want to do is annotate (say with provenance information) a set of BIBFRAME statements (RDF triples) that were derived from a given MARC XML Record, you just need to make sure the set of BIBFRAME statements (as a set) has a URI/IRI, preferably resolvable to a serialization of those statements as a single RDF document in RDF/XML or some other format. Note that the URI for the BIBFRAME graph is distinct from the identifiers of the bf:Work, bf:Instance, etc. being described. (Note, there are already rules for comparing and equating named graph instances, so it is feasible to have multiple instances of the same BIBFRAME description out there on the Web.) At this point, BIBFRAME doesn't seem to say much about URIs for BIBFRAME graphs, but at some point I think this needs to be addressed. 

Aside: Which raises for me a confusion I have about the bf:derivedFromLCCN. This is included in many BIBFRAME examples as if it were a property of the bf:Instance. Of course it is not; it is a "unique number assigned to a MARC record by the Library of Congress." The MARC Record is not the bf:Instance being described and the bf:Instance is not derived from the MARC record describing the bf:Instance, so the bf:derivedFromLCCN hardly seems a valid property of a bf:Instance. Presumably, bf:derivedFromLCCN would be an appropriate property of the named graph generated from a MARC XML record.  (In the BIBFRAME Transformation Service tool the similar issue with bf:derivedFrom persists.)
 
> I can imagine that such granular annotation for BIBFRAME could function
> inline if bf:Annotation could be the property of any other BIBFRAME
> property.  Yet, how would such granular annotation work as an external
> annotation to provide a target for bf:annotates?
> 
> Do individual occurrences of a particular property have implicit
> identifiers in the context of a bf:Resource (bf:Work, bf:Instance,
> bf:Authority, or bf:Annotation)

This kind of approach never works at scale and tends to run afowl of the RDF Open World assumptions. Name the BIBFRAME description of  the bf:Resource (bf:Work, bf:Instance, bf:Authority, or bf:Annotation) and treat it for the purposes of RDF as a named graph. We currently identify catalog records with LCCNs, OCLC numbers, local identifiers, so this is doable. There are rules for determining if 2 named graphs are the same, just as a catalog record may have both a LCCN and a OCLC number. 

Once you have an identifier for the BIBFRAME description as a named graph (or even as just a Web Resource which happens to be a set of RDF triples), you have a chance of annotating a specific triple within that description, though it's not easy, see below. More importantly (I suspect) you have a way of talking about the BIBFRAME description of a resource as a whole, and potentially revising / adding to the description (i.e., revising the named graph). This is an edge use case today, but there's light at the end of the tunnel.  You also have a way  to talk about relationships between bibliographic descriptions. 

> or would it be necessary to add an
> identifier to the property for the particular occurrence of the property
> to function as a target?

Again, there's a question about whether you really want to annotate a property (e.g., bf:publication) or the object of a statement (e.g., the bf:ProviderEntity that is the publisher of the bf:Instance being described) or the statement <http://bibframe.org/resources/YCS1372171298/5439928instance14>  bf:label "Using the Open Archives...."

BIBFRAME properties all have URIs, so not a problem to target for annotation if what you want to say is something global about the semantics of a BIBFRAME property. 

The object of a property statement, e.g., the bf:Instance, bf:Work, bf:Person, etc. will often have its own URI, in which case not a problem to annotate, but keep in mind that annotations of a bf:Instance, bf:Person, etc. must be globally true, not just true within the context of a particular BIBFRAME description. Note also, that in practice we sometimes neglect to give entities a URI, e.g., the bf:ProviderEntitiy that is the object of a bf:publication predicate may end up a blank node from an RDF perspective, i.e., given a generated ID useful only within the context of the specific named graph (not globally meaningful). So if bf:providerPlace is missing and you want add it, this is a bit more cumbersome. Also, if no global identifier provided for the bf:ProviderEntity, then you can't discover bf:providerPlace by examining other descriptions that reference this same bf:ProviderEntity. Give more things identifiers, is generally a good rule.

Similar problem for statements within a BIBFRAME description -- typically no identifiers. So, ...

> How would such granular annotation function for any individual occurrence
> of any RDF property using the Open Annotation Data Model,
> http://www.openannotation.org/spec/core/ ?

There is not currently a generally accepted, widely implemented way to refer to an individual triple (property statement) within an RDF instance or named graph. You can make each individual triple its own named graph (give each triple its own URI), but this does not scale well. You can recast all of your BIBFRAME statements in the RDFS Reification Vocabulary (http://www.w3.org/TR/rdf-schema/#ch_reificationvocab), assigning each statement a URI -- same problem.

Most ways of targeting individual triples (individual statements) within an RDF document (a BIBFRAME description) are serialization specific. Fragment identifiers as such don't work across serializations in RDF because fragment identifiers are MIME-specific and RDF can be disseminated in a variety of different serializations having different MIME types (e.g., application/rdf+xml, text/n3, text/turtle, text/html or application/xhtml+xml, application/json or application/ld-json , ...).

In the Open Annotation world: Assuming that the BIBFRAME description (set of triples, RDF graph) had an identifier (was a named graph), you could in Open Annotation target a specific statement (specific triple) within that description by making the target an oa:SpecificResource with an oa:hasSource (the URI of the BIBFRAME description), an oa:hasState (specifying the serialization of the Description being annotated) and an oa:hasSelector (where the oa:Selector was specific to the MIME type of the serialization, e.g., XPointer for RDF/XML, text offsest for the text formats, etc.). This would identify the specific triple being annotated.  

Cumbersome but doable if this is a common use case. As mentioned, it might also be interested to experiment with SPARQL-based oa:Selectors.

> 
> "BIBFRAME Annotation Model - BIBFRAME Community Draft - 30 April 2013 -
> bibframe.org/documentation/annotations/ " describes some thinking by the
> early experimenters about annotation prior to annotation having been
> added
> to the vocabulary.
> 
> The addition of annotation to the vocabulary provides little additional
> information without additional notes and with code examples broken by
> some
> bug.  [Nate Trail explained to me in a simple message perhaps mistakenly
> sent offlist that if code examples have supposedly been added to
> particular parts of the vocabulary but do not resolve properly on the
> relevant vocabulary pages, then there is a bug.]
> 
> Target is described under roles, section 2.2, in BIBFRAME Annotation Model.
> 
> "Target of the Annotation: A BIBFRAME Work, Instance, or Authority".
> 
> Restricting the scope of targets for bf:Annotation to bf:Resources either
> inline or using externally using bf:annotates seems unnecessarily
> restrictive in a linked data environment.
> 
> 
> Thomas Dukleth
> Agogme
> 109 E 9th Street, 3D
> New York, NY  10003
> USA
> http://www.agogme.com
> +1 212-674-3783
> 
> 
> [..]