Re: Motivations

No, I think you are right. The primary issue with motivation is that it
defines the role of the body within the annotation. I think we want to
reserve type to represent something structurally specific to the
annotation, e.g., highlights. In the highlighting use case I might have a
"Highlighting" motivation but, we could just as easily consider that all
highlight annotations do not have bodies but do have CSS instructions. This
is a case where we can get some significant mileage out of sub-typing
oa:Annotation with an oa:Highlight (or somesuch...there might be other
"bodiless" use cases. As once we see either the sub-type or the motivation
then our software can make some assumptions, e.g., do not expect oa:body,
do expect oa:style; if this is not the case then not a valid annotation.
You can't realize that type of validity checking with motivations, and in
fact with the glaring exception of highlighting (and maybe one other
thing...) motivations don't help use validate.

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, Feb 2, 2015 at 2:36 PM, Bill Kasdorf <bkasdorf@apexcovantage.com>
wrote:

>  Just to make sure I'm understanding . . .
>
>
>
> When I said I thought it was important to keep "type" and "motivation"
> separate, it was because I think there is a very high value to "type," and
> that needs to accommodate very flexible--often user- or
> community-specific--terms. Thus as I mentioned on an earlier call, I don't
> think we should try to define what "types" there are, we should just make
> sure there is a means to designate a type.
>
>
>
> That seems different from where we're going with motivations, correct? Two
> different things, and we need both.
>
>
>
> And that's why I was advocating verbs for motivations, and nouns for types.
>
>
>
> Or am I misunderstanding?
>
>
>
> *From:* Denenberg, Ray [mailto:rden@loc.gov]
> *Sent:* Monday, February 02, 2015 3:13 PM
> *To:* 'Web Annotation'
> *Subject:* RE: Motivations
>
>
>
> ­­
>
> *From: Benjamin Young [mailto:bigbluehat@hypothes.is]
> <[mailto:bigbluehat@hypothes.is]>*
>
>
>
> > If we choose to change "describing" to "description" then we should
> change
>
> > "hasMotivation" also, so that the whole is more legible.
>
>
>
> *(As Rob notes, it's actually "motivatedBy".)  I would like to change it
> to "asserting".  I think of an annotation as asserting a relationship
> between the body and target.  Thus, if A is a review of B, then the
> annotation:*
>
> ·         *has target B,*
>
> ·         *has body A,*
>
> ·         *is asserting that  the body is a review of the target.  I.e.
> it is “asserting (a) review”*
>
>
>
>
>
> > "annotation is a description" reads nicely...but then looks like
> sub-classing.
>
>
>
> *I'm trying to find a middle ground here, where we can talk about type
> without it needing to be rdf:type.*
>
>
>
>
>
> > Ray's original motivation was improving our cosmetics:
>
>
>
> *I lied.*
>
>
>
> *Well not really lied, but perhaps we could  see this as a change where
> the world at large would view it as cosmetic while my constituency would
> see it as something more substantive. *
>
>
>
>
>
> *I want to also point out, although  the motivations listed in the model
> are expressible in the gerund for (and perhaps all could be expressed in
> infinitive form)   there are going to be annotation “types” that cannot be
> expressed in either of those forms.  I have already submitted “cover art”
> as an annotation type.  How would you express the motivation there?
> “Coverarting”?  “Table of contents” is going to be an annotation type in
> BIBFRAME (which I’ll explain in a separate post) and that’s another
> example.  HeldItem might be another annotation type. *
>
>
>
>
>
> *In responds to Rob’s questions:*
>
>
>
> > * Is the objection to the use of skos:Concepts, rather than classes?
>
> *No, no objection from me, to the model prescribing this approach.  We
> have already left the door open for other namespaces to use subclassing
> instead (or in addition) and that’s good enough for me.*
>
>
>
>
>
> > * If not, is the objection to the definition of motivation for creating
> the
>
> > annotation?
>
>
>
> *The closest thing I see (in the model) to a definition is “the reasons
> why the Annotation was created”  and I have no objection to that
> definition.*
>
>
>
>
>
> > * If not, given that these are instances, is there significant
> improvement in
>
> > understanding by renaming them?
>
> *No, to say that there would be a significant improvement in understanding
> would be a stretch. I am saying that the suggested change would allow those
> of us who like to think in terms of annotation types to do so, without
> forcing the concept on those who don’t. *
>
>
>
> *Thanks.  *
>
>
>
> *Ray*
>
>
>
>
>
>
>
>
>