Typed annotations for place of birth, find location, etc

[Alexander Dutton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

We think we want to make annotations like <http://is.gd/j90AdA> (e.g.
TTDB¹ <http://data.clarosnet.org/doc:lgpn/person/V1-1006.html>
annotates TTDB <http://pleiades.stoa.org/places/589693>).

¹ "the thing described by"

First off, should we be annotating the place with the birth, the
person who was born there, or both?

Secondly, do we have a standard way of typing the annotation for
common cases? Something like:

<oac:Annotation rdf:about="…">
<oac:hasTarget rdf:resource="…"/>
<oac:hasBody rdf:resource="…"/>
<dcterms:conformsTo
rdf:resource="http://purl.org/NET/pelagios-annotation/birth"/>
</oac:Annotation>

Of course, once one goes further down this route you might want to
annotate it with the date of birth, its uncertainty, and so on.

There are probably other common types of annotation that might be
interesting:

* find locations
* current (… or former, in CRM style) location
* describes / is about

Any thoughts?

- --
Alexander Dutton
Metamorphoses Project Developer, Claros
Oxford University Computing Services, ℡ 01865 (6)13483
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk7iPPIACgkQS0pRIabRbjATygCfbQat/biNNHrtSvwNDB4gyFA5
ahgAn3ECuDf1xswR12Qam/e7gytj7FZp
=l48r
-----END PGP SIGNATURE-----

[Leif Isaksen]

Hi Alex

This looks good to me. In answer to your questions:

- This is very much for you to decide. The answer to it is really:
what do you think users of Claros are most likely to want to find at
the other end when searching by place? Remember that it's also fine to
have multiple annotation sets (so having both is a possibility,
especially if you're generating them automatically)

- Until now, we have only encouraged people to use sensible
rdfs:labels to make it apparent what is at the other end. As our
annotation sets begin to grow however, it will almost certainly make
sense to start typing the annotations. Do people have any thoughts
about the best way to do this? And in particular should it reflect the
type of annotation or the nature of the target (or both?) Perhaps it
would even make sense to create subproperties for oac:target, oac:body
and even oac:annotation?

eg.
anno123 a pelagios:geoannotation
anno123 pelagios:texttarget <some_target>
anno123 pelagios:geobody <some_pleiades_uri>

Will this take us down a rabbithole?

L.

[Leif Isaksen]

I think that would be a very good idea. Are there URIs that can
resolve to them or should we (or Pleiades) mint some? And are they
best applied to the annotation or target? (I suspect target?)

L.

On Fri, Dec 9, 2011 at 9:26 PM, Tom Elliott <tom.e...@nyu.edu> wrote:
> For what it's worth, the old Concordia vocabulary included "findspot",
> "origin", "where", and "observedAt" terms for location relationships. These
> strings are now in the wild in the context of machine tags on photos at
> Flickr, for which Flickr has just recently introduced some "extra love"
> autolinking behavior (blog post pending).
>
> Conocordia vocab: http://gawd.atlantides.org/terms/
> Pleiades machine tags: http://www.flickr.com/photos/tags/pleiades:* and
> http://horothesia.blogspot.com/2011/09/feeds-of-flickr-photos-depicting.html
>
> T

> --
> Tom Elliott, Ph.D.
> Associate Director for Digital Programs
> Senior Research Scholar
> Institute for the Study of the Ancient World
> New York University
>
> http://isaw.nyu.edu/people/staff/tom-elliott/
>
> Want to talk or meet? Please suggest a date and time via
> http://www.doodle.com/paregorios
>

[Sean Gillies]

Speaking of that vocab, I don't think we've mentioned that it's
employed on Flickr since November. See
http://flickr.com/photos/dandiffendale/4356577859/ and click on "Show
machine tags (2)" to see how Dan's used them. These annotations could
be extracted and pumped into Pelagios and you can tell JISC "We're
already shipping!"

The vocabulary is described at http://gawd.atlantides.org/terms/ and
URIs for terms like http://gawd.atlantides.org/terms/attestsTo
redirect to that same page. Making that page better is on our todo
list. Flickr doesn't yet subscribe to linked data, so hasn't noticed.

--
Sean Gillies

[Simon Rainer]

Hi!

As I'm not the biggest RDF-guru out there, I'm grateful for any suggestions/opionions/examples you can offer! (Quite frankly though, I'm happy as soon as the necessary data is included in the dump file(s) somehow, even if it's not ideally expressed ;-)

But just a few comments from my side, regarding typing:

< should it reflect the type of annotation or the nature of the target (or both?) Perhaps it would even make sense to create subproperties for oac:target, oac:body and even oac:annotation? >

IMO what we're trying to say is this:

1. the annotation body (Pleiades URI) annotates the annotation target (e.g. TTDB http://data.clarosnet.org/doc:lgpn/person/V1-1006.html)
2. the nature of the annotation is such that it expresses a relationship defined by a term from a controlled vocabulary, e.g. Concordia

It seems that sub-classing oac:annotation would be one natural way to do it. The question, however, is whether this wouldn't result in a potentially excessive number of possible subclasses? (E.g. one pelagios:geoannotation subclass, which expresses the fact that the annotation is a place reference; plus sub-sub-classes for each term in each vocabulary we are using?)

To be honest, Alex' example using dcterms:conformsTo strikes me as quite an elegant alternative! (At least from a technical perspective it's quite lightweight & should be easy to handle.) Anyways: I wasn't aware of this property so far. The official definition seems to be "An established standard to which the described resource conforms". To my non-Semantic-Web-trained ears that sounds slightly cryptic... Is it "clean" to use it to express what we aim for? Or should we be looking at a property that's more specific to our use case?

Cheers,
Rainer


-----Ursprüngliche Nachricht-----
Von: pelagios...@googlegroups.com [mailto:pelagios...@googlegroups.com] Im Auftrag von Leif Isaksen
Gesendet: Freitag, 09. Dezember 2011 21:19
An: pelagios...@googlegroups.com
Betreff: Re: [pelagios] Typed annotations for place of birth, find location, etc

[Bridget Almas]

Hi everyone,

I also really like the idea of using dcterms:conformsTo or something
similar. I struggled with this for the Perseus annotations, when
differentiating annotations which meant "this place is that place"
versus "this place is near that place", and in the interest of time
ended up just encoding it in a dc:title element for the annotation, but
would much prefer to have a standard way to do this, using a
uri-resolvable controlled vocabulary.

I think the alternative of subclassing oac:annotation may be somewhat
contrary to the intent of the specification.

Bridget

On 12/13/2011 10:52 AM, Simon Rainer wrote:
> Hi!
>
> As I'm not the biggest RDF-guru out there, I'm grateful for any suggestions/opionions/examples you can offer! (Quite frankly though, I'm happy as soon as the necessary data is included in the dump file(s) somehow, even if it's not ideally expressed ;-)
>
> But just a few comments from my side, regarding typing:
>
> < should it reflect the type of annotation or the nature of the target (or both?) Perhaps it would even make sense to create subproperties for oac:target, oac:body and even oac:annotation?>
>
> IMO what we're trying to say is this:
>
> 1. the annotation body (Pleiades URI) annotates the annotation target (e.g. TTDB http://data.clarosnet.org/doc:lgpn/person/V1-1006.html)
> 2. the nature of the annotation is such that it expresses a relationship defined by a term from a controlled vocabulary, e.g. Concordia
>
> It seems that sub-classing oac:annotation would be one natural way to do it. The question, however, is whether this wouldn't result in a potentially excessive number of possible subclasses? (E.g. one pelagios:geoannotation subclass, which expresses the fact that the annotation is a place reference; plus sub-sub-classes for each term in each vocabulary we are using?)
>

> To be honest, Alex' example using dcterms:conformsTo strikes me as quite an elegant alternative! (At least from a technical perspective it's quite lightweight& should be easy to handle.) Anyways: I wasn't aware of this property so far. The official definition seems to be "An established standard to which the described resource conforms". To my non-Semantic-Web-trained ears that sounds slightly cryptic... Is it "clean" to use it to express what we aim for? Or should we be looking at a property that's more specific to our use case?

[Alexander Dutton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13/12/11 20:31, Bridget Almas wrote:
> […] in the interest of time ended up just encoding it in a

> dc:title element for the annotation, but would much prefer to have
> a standard way to do this, using a uri-resolvable controlled
> vocabulary.

A controlled vocab sounds like a plan to me.

> I think the alternative of subclassing oac:annotation may be
> somewhat contrary to the intent of the specification.

I've seen this done on slides 11 and 12 of
<http://www.openannotation.org/documents/GerberHunterOAC.pdf>, where
they include two rdf:type properties (which keeps happy those
consumers that don't do inference or rdfs:subClassOf-following).

I'll post something to the oac-discuss list to ask for suggestions on
best practice (presumably either additional rdf:types,
dcterms:conformsTo, or some other property).

It also turns out that there's work afoot to reconcile OAC with the
Annotation Ontology (AO).

All the best,

Alex

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk7od+4ACgkQS0pRIabRbjCoiQCcDy6XURUOtL0mT7Izlo3yb1rq
m4gAnAsyqFdD4vedy2u/nPqu0uKJPbPY
=qtat
-----END PGP SIGNATURE-----

[Leif Isaksen]

Cheers Alex, that would be brilliant. I think wherever possible we
should follow established practice rather than cook up our own.

Let us know what the oac-discuss pundits have to say.

Cheers

L.