Re: Class of an annotation body

Hi Ray,

I think annotating the resource with tags that make assertions about its
content is probably the better way to go. Realistically though we'll likely
have to accept that there will be a (possibly large) contingent of
developers who will be typing resources in exactly the manner you've used
in your example. Probably the best thing for us would be to remain agnostic
as we can't really mandate what consumers do with annotations once they've
consumed them. This kind of thing will have to be purview of individual
communities to discuss and adopt best practices for.

If that isn't ultimately satisfactory, then we might recommend that using
additional annotations to tag the body resource with information about its
content is a better practice than asserting multiple types but, this kind
of thing will ultimately be unenforceable. If we take this route, then we
might strongly argue that adding types that make assertions about a body's
content in addition to typing information about its format/form confuses
the semantics of the annotation body because the message (content) and
messenger (carrier format) get conflated. This is an age old problem in
libraries where it has eroded the utility of terms like *genre* to the
point of complete ambiguity with regards to a resource's topicality (e.g.,
fantasy), carrier type (e.g., book), and content type (e.g., poem).

Regards,

Jacob


_____________________________________________________
Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
The Graduate School of Library and Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164
jjett2@illinois.edu

On Mon, Mar 9, 2015 at 4:33 PM, Denenberg, Ray <rden@loc.gov> wrote:

> Hi Jacob –
>
>
>
> Just to be clear, I am certainly not suggesting that the vocabulary for
> the use case I described would be created by this group, or would be part
> of the OA vocabulary. Not suggesting that we develop an ontology of body
> types, these will be extensions.
>
>
>
>    So for example, there is a “Bird Description” ontology;
> http://bd.example.com/
>
>
>
> <http://bd.example.com/wtp/anno1>     a      oa:Annotation ;
>
>      oa:hasTarget        <http://bd.example.com/wtp/>
>
>      oa:hasBody       [ a bd:Description;
>
>                                                              bd:call  [ a dctypes:Sound; ….] ;
>
>                                                              bd:song  [ a dctypes:Sound; ….] ;
>
>                                                              bd:photo [ a dctypes:Image; ….] ;
>
> etc.
>
>
>
> So, yes, as you suggest this is a best practice discussion.  Question is, is the a good practice?
>
>
>
> Ray
>
>
>
>
>
> *From:* jgjett@gmail.com [mailto:jgjett@gmail.com] *On Behalf Of *Jacob
> Jett
> *Sent:* Monday, March 09, 2015 4:58 PM
> *To:* Denenberg, Ray
> *Cc:* Web Annotation; Robert Sanderson
>
> *Subject:* Re: Class of an annotation body
>
>
>
> Hi Ray,
>
>
>
> This seems like a best practices type of discussion. You could simply make
> three different annotations with distinct motivations or make a single
> annotation with multiple bodies. If I understand correctly, it is this last
> option that is the crux of the issue.
>
>
>
> The question is whether or not we need to develop an ontology of body
> types for OA to (likely) support various search and selection features. The
> problem is that it is impossible to think of every possible scenario for
> typing resources in this manner. The solution in the past has been to leave
> this kind of functionality to various communities to build extensions to
> the base OA vocabulary for.
>
>
>
> IMO, I think this is the correct way to go. That way we are not in the odd
> position of mandating certain interpretations of resources (i.e., that an
> audio clip contains the audio of a bird call or a bird song). Knowing that
> the resource is an audio clip is just generally useful; it suggests what
> kinds of software is needed to interact with it. Naming it as a kind of
> content seems over-specified though and is the kind of information that is
> likely only going to be interesting within certain communities. Hence it
> would be best to leave this kind of ontological extension up to specific
> communities who will be more knowledgeable than us anyway. They can
> serialize the additional information with the annotation (the beauty of RDF
> and JSON-LD) and individual consumers can thereafter decide on their own
> whether or not they should exploit it.
>
>
>
> Regards,
>
>
>
> Jacob
>
>
>
>
>
> _____________________________________________________
>
> Jacob Jett
> Research Assistant
> Center for Informatics Research in Science and Scholarship
> The Graduate School of Library and Information Science
> University of Illinois at Urbana-Champaign
> 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
> (217) 244-2164
> jjett2@illinois.edu
>
>
>
> On Mon, Mar 9, 2015 at 3:16 PM, Denenberg, Ray <rden@loc.gov> wrote:
>
> Thanks Rob. I think my use case does not fit either of these two.  You
> tell me if you think it is a legitimate case; I think it is. I’m trying to
> develop it as a protocol use case but first I’ll describe it in plain
> English and if it is deemed legitimate, I’ll develop it further.
>
> Let’s say you have an Online Bird Guide -  something along the lines of
> the Cornell’s service http://www.allaboutbirds.org/guide/search but it
> relies on the contributions of bird enthusiasts/experts who photograph
> birds, record their songs and calls, and contribute the images and sound
> clips.  So, I photograph a White-throated Sparrow in my backyard, in early
> Spring, and record both its song and its call.  I contribute this
> information by annotating the service’s resource for White-throated
> Sparrow: two sound clips(song and call), an image, geographic location (DC
> area), time of day (morning), period of the year  (early Spring).  And
> note, these things – location, season, time of day – this is not
> provenance, this is descriptive information because these songs and calls
> vary by location, time of day, and season.
>
> I don’t think this fits option 1, because there you have only a single
> document, a review, and you can signify this via motivation.  In my case,
> you have multiple documents, for example, two sound clips – one for the
> song and one for the call – and you have to say which is which, and the
> only way I can think of to do that is via properties. I don’t think it fits
> option 2 either, for similar reasoning.
>
> Ray
>
>
>
>
>
> *From:* Robert Sanderson [mailto:azaroth42@gmail.com]
> *Sent:* Monday, March 09, 2015 3:46 PM
> *To:* Denenberg, Ray
> *Cc:* Web Annotation
> *Subject:* Re: Class of an annotation body
>
>
>
>
>
> Hi Ray,
>
>
>
> The issue is mostly one of provenance and graph boundaries, so falls under
> the same discussion as named graphs for bodies discussion that we had on a
> recent call.
>
>
>
> There are two main options for body resources with structure:
>
>
>
> 1.  The body is an external or embedded document containing structured
> data, or a named graph containing triples, such that the document/graph can
> be maintained and referred to separately from the annotation.  For example,
> a review in XML that had fields with number of stars, text of the review
> and so on fills the same role as a named graph containing the same
> information with triples instead of XML elements.
>
>
>
> 2.  The triples are part of the annotation graph, and thus cannot be
> referred to separately.  Consider as a parallel, the body-as-string versus
> body-as-resource distinction.  This is the body-as-string case, where there
> isn't a distinct resource to refer to... there are just triples in the
> annotation.  For example, the body could be a blank node with numberOfStars
> and rdf:value predicates.  These assertions are made by the agent that
> asserts the annotation, which may not be correct ... but also may not be a
> concern, depending on the use case.  For the general case, and hence for
> interoperability, the boundary of the body is another challenge.  The set
> of resources that are needed to make a useful body is arbitrary and use
> case dependent.  For dedicated systems this may not be an issue, but if you
> imported the annotation content into another system, it's unlikely that it
> would know which triples should be included and which not.
>
>
>
> Others please do weigh in :)
>
>
>
> Rob
>
>
>
>
>
>
>
> On Mon, Mar 9, 2015 at 12:05 PM, Denenberg, Ray <rden@loc.gov> wrote:
>
> In the OA data model, there is no general RDF Class defined for the body.
> But that doesn’t mean that the body cannot have an RDF class, for certain
> types of annotations.  For example, for  a tag, the body has class oa:Tag
> and for a semantic tag, oa:SemanticTag.   (Those are the only two I can
> think of from the model, maybe there are others I missed.)
>
> There is at least one use case that calls for a structured body and thus
> an RDF Class (Structured Review:
> http://www.w3.org/TR/dpub-annotation-uc/#comment-on-publication-title).
>  And it also seems that there is a certain amount of hand-waving that
> suggests that bodies are going to need to be structured in many cases but I
> don’t think we have had direct discussion of this.
>
> I am in the process of developing a use case along these lines and would
> like opinions on whether this approach is seen to be legitimate or frowned
> upon – annotations where the body has properties - because there was
> discussion of this in BIBFRAME and it seemed to cause controversy.
>
> Ray
>
>
>
>
>
>
>
>
>
> --
>
> Rob Sanderson
>
> Information Standards Advocate
>
> Digital Library Systems and Services
>
> Stanford, CA 94305
>
>
>