Re: Annotation body a transcription of the target

Comments inline...


On Fri, Oct 18, 2013 at 6:56 AM, Robert Casties <casties@mpiwg-berlin.mpg.de
> wrote:

> Hi Rob,
> I confess I'm still struggling in the big world of RDF so I didn't
> really understand all your comments. See my struggles below :-)
>

No worries :)



> > If you're going in the route of a transcription being a resource with a
> > label and no content, then it would be good to tag it as an
> oa:SemanticTag.
>
> Is that just about the use of rdfs:label for the text instead of cnt:chars?
>

Yes. The semantic difference is that rdfs:label is the name, title or
similar human readable label for a resource. Which implies that there is a
"thing" for the label to describe.

On the other hand, the cnt:chars property is simply the character string
which is a representation (in the web architecture sense) of the resource
that has the property. This still implies a "thing", of course, but in the
case of transcription, it makes more sense (at least to me!) that it would
be content rather than the name of something.

In the case of transcribing a place name (or other name of something) it
might make some sense to use rdfs:label ... as the transcribed text *is* a
label for the physical place.  But then it's not a transcription of some
writing, it's the name of a physical place.  Conversely, it would be very
strange (again, to me) to say that the name of a line of text is the
content of the line.  I would expect that the *name* of a line of text
would be something like "Line 12", and that line would have some content
which would be the transcription.

Or did I misunderstand Rainers comment? I understood his proposition to be:
> _:body1 a cnt:ContentAsText, pelagios:Toponym ;
>   rdfs:label "Placename" .
>

Which doesn't work because ContentAsText requires the cnt:chars property.
 And if it isn't ContentAsText, and it's not a dereferencable resource that
contains content, then it should be a SemanticTag.


>  And Robert, the above route would be in the opposite direction to Shared

> > Canvas making them incompatible. Shared Canvas (and the IIIF Metadata API
> > that provides explicit recommendations on how to use the ontology in
> > practice) treats transcriptions as just a regular body, with a motivation
> > of sc:painting (for painting some content, of any format, on to the
> Canvas
> > that represents the page).
>
> I was just looking at the SC spec and didn't find any examples for
> transcriptions (on http://www.shared-canvas.org/datamodel/spec/ links to
> the cookbok pages were broken and the examples page mostly empty).
>

Yes, we're reorganizing to bring the IIIF Image API and the Shared Canvas
documentation together in a single space at the moment (hopefully in the
next couple of weeks).  Long long overdue, of course.



> The IIIF-Metadata specs are much more detailed but the format is
> JSON-LD. Isn't the example in Section 5.6.1 of
> <http://www.shared-canvas.org/datamodel/iiif/metadata-api.html>:
>
> {
>   "@context":"http://www.shared-canvas.org/ns/context.json",
>   "@id":"http://www.example.org/iiif/book1/annotation/anno1".json,
>   "@type":"oa:Annotation",
>   "motivation":"sc:painting",
>   "resource":{
> "@id":"http://www.example.org/iiif/book1/res/tei.xml#xpointer(//line[1])"
>     "@type":"dctypes:Text",
>     "format":"text/xml"
>   }
> "on":"
> http://www.example.org/iiif/book1/canvas/p1.json#xywh=100,100,500,300"
> }
>
> much like the one above if "resource" is the Body and "on" is the Target?
>

(Also compare the embedded cnt:chars example at
http://www.shared-canvas.org/datamodel/iiif/metadata-api.html#AdvEmbedded )

The JSON-LD context for IIIF is different to the default context for Open
Annotation, and you are correct that "on" is the target, and "resource" is
the body.  The reason for this is that we felt it easier to understand for
people unfamiliar with RDF and Open Annotation but only looking at the
JSON.  This came from a discussion at iAnnotate with Nick, Randall and
Blaine.  As we had to make a new context anyway for the Shared Canvas
specific predicates, we thought we'd follow that approach.

The difference is that the tei.xml document would need to be retrieved and
the xpointer to find line[1] resolved.  That would then give you the
content to display.  So that's in line with the use of cnt:chars, which is
simply a W3C method to embed the content (aka representation) of a resource
within the RDF graph.


> > So if Shared Canvas compatibility is important, it would be good to align
> > now rather than later :)
>
> I think it may be a good idea so I would like to discuss it now. If it
> proves to be impractical or unneccesary we should just leave it be.
>

I would propose to discuss it on either the IIIF or Pelagios lists, rather
than the overall Open Annotation list ... unless there are other people
here who think it would be beneficial for the community group in general?

Thanks Robert! :)

Rob