Re: Class of an annotation body

I would go for multiple bodies (which are all about the target), AND a
graph body (named graph / retrievable RDF resource) that ties them
together semantically.


I am not sure what <http://bd.example.com/wtp/> is meant to be in your
example - let's assume it is "White-throated Sparrow" as a collection,
class, species. You can further detail the below to include some
identifier/bnode of the actual observed bird individual - but then you
have to think about what happens if there is a photo of three birds of
the same species (Specific Resources to the rescue!)


You don't have any resource for the 'observation' in here - so I'll
introduce that and type it as bd:Description - we'll say a
bd:Description is a kind of description of a particular observation
(thus you can link say the particular song with the particular photo).
bd:Observation might work better.



e.g.

GET http://bd.example.com/wtp/anno1

200 OK
Content-Type: text/turtle; charset=utf8

<http://bd.example.com/wtp/anno1>     a      oa:Annotation ;

     oa:hasTarget        <http://bd.example.com/wtp/>
     oa:hasBody       <http://bd.example.com/wtp/anno1/observation>,
                             <http://bd.example.com/wtp/anno1/call.mp3>,
                             <http://bd.example.com/wtp/anno1/song.mp3>,
                             <http://bd.example.com/wtp/anno1/photo.jpeg> .

<http://bd.example.com/wtp/anno1/call.mp3> a dctypes:Sound .
<http://bd.example.com/wtp/anno1/song.mp3> a dctypes:Sound .
<http://bd.example.com/wtp/anno1/photo.jpeg> a dctypes:Image .
<http://bd.example.com/wtp/anno1/observation> a bd:Description .


GET http://bd.example.com/wtp/anno1/description

200 OK
Content-Type: text/turtle; charset=utf8


<http://bd.example.com/wtp/anno1/description> a bd:Description ;
  bd:call <http://bd.example.com/wtp/anno1/call.mp3> ;
  bd:song <http://bd.example.com/wtp/anno1/song.mp3> ;
  bd:photo <http://bd.example.com/wtp/anno1/photo.jpeg> ;
  foaf:primaryTopic <http://bd.example.com/wtp/> .


How you structure anno1/description is up to you, of course, but I
would try to avoid duplicating annotation-stuff in there - still
<http://bd.example.com/wtp/> should be mentioned somehow, as our
annotation claims that the observation is somewhat about wtp.




On 9 March 2015 at 21:33, 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
>
>



-- 
Stian Soiland-Reyes, eScience Lab
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/    http://orcid.org/0000-0001-9842-9718

Received on Tuesday, 10 March 2015 14:34:46 UTC