Re: Motivations

Hi Ray, all,

Another option that was discussed, and I think bears some relevance here,
is to include an actual relationship that is being asserted by the
annotation between the bodies and targets.

The distinction I'm trying to make here is between:

The body is a Review.    (body rdf:type xxx:Review)
The body reviews the Target.   (body xxx:reviews target)

The second could be modeled as a property of the annotation:

_:x a oa:Annotation ;
  oa:hasBody <body> ;
  oa:hasTarget <target> ;
  oa:hasRelationship xxx:reviews .


The discussion on this second option in the CG went along these lines, and
others please correct or extend:

* The exact relationship between all bodies and all targets may not be the
same.  For example a single annotation with two Tags and one full text
comment has multiple motivations (in CG speak), or different relationships
between bodies and target. Multiple relationships could be listed, but the
semantics start to become very fuzzy -- listing the motivations for
creating the annotation seemed cleaner.

* If we want to explicitly model this (the role of each body) we would
potentially need further nodes[1], but easier would be to just assert that
the <body> xxx:reviews <target> as its own triple.  However, as its own
triple it can be lost in the mass of other triples -- it's in no way tied
to the annotation any more.

* An option would be to have a property of the Annotation record the
predicate that should be asserted between bodies and targets.  We did not
find any significant precedent, outside of rdfs/owl, where the object of a
triple was a predicate and did not want to forge new ground here.

* An Annotation with this predicate reference looks a lot like a reified
triple, where the body is the subject, the predicate is the predicate, and
the target is the object.  We wanted to avoid that, as there's already
reification of triples (which no one to my knowledge actually uses) and
named graphs that would fill the same space.

So ... the motivation solution isn't ideal, but it does cover the majority
of situations to a reasonable degree.


[1] The further nodes option would be to always require a SpecificResource
for the body and associate the role with that.

_:x a oa:Annotation ;
  oa:hasBody <spbody> ;
  oa:hasTarget <target> .

<spbody> a oa:SpecificResource ;
  oa:hasRole oa:reviewRole ;
  oa:hasSource <body> .

And we're even further away from the ease of associating a simple string
with a web resource.

Rob


On Mon, Feb 2, 2015 at 12:13 PM, Denenberg, Ray <rden@loc.gov> wrote:

> ­­
>
> *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*
>
>
>
>
>
>
>
>
>



-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305

Received on Monday, 2 February 2015 20:51:49 UTC