Best practice for typing annotations

14 views
Skip to first unread message

Alexander Dutton

unread,
Jan 5, 2012, 5:02:35 AM1/5/12
to oac-d...@googlegroups.com, pelagios...@googlegroups.com
Dear OAC community members,

I'm working on an aspect of the Pelagios Project[1], which is using OAC
annotations for linking things of antiquarian interest (e.g. places and
people) to ancient places described by Pleiades[2]. In our usage, the
object oac:annotates the Pleiades place.

I recently asked on the Pelagios mailing list[3] whether the project had
best practice for expressing some classification of the annotation being
made. For the purposes of Pelagios we'd probably want to express the
following:

* find locations
* current � � or former, in CRM style � location
* was born at
* describes / is about

First off, is this an abuse of OAC? If it isn't, what metadata should be
attached to the annotation to encode this information?

My suggestion was to use a dcterms:conformsTo property, with the object
being drawn from a controlled vocabulary defined by the Pelagios
community. That said, I'm not sure whether this qualifies as a sensible
use of dcterms:conformsTo. See the pelagios-project thread for a smidge
more detail.

Kind regards,

Alex

NB. I've copied in the Pelagios mailing list so they'll be aware that
there's a discussion on oac-discuss that they may wish to follow. Feel
free not to cross-post in reply.

[1] http://pelagios-project.blogspot.com/
[2] http://pleiades.stoa.org/
[3]
http://groups.google.com/group/pelagios-project/browse_thread/thread/99685c3873d66ceb

--
Alexander Dutton
Developer, InfoDev; Metamorphoses Project Officer
Oxford University Computing Services

Bruce D'Arcus

unread,
Jan 5, 2012, 4:05:45 PM1/5/12
to oac-d...@googlegroups.com
On Thu, Jan 5, 2012 at 5:02 AM, Alexander Dutton
<alexande...@oucs.ox.ac.uk> wrote:
> Dear OAC community members,
>
> I'm working on an aspect of the Pelagios Project[1], which is using OAC
> annotations for linking things of antiquarian interest (e.g. places and
> people) to ancient places described by Pleiades[2]. In our usage, the object
> oac:annotates the Pleiades place.

I'm confused on what you're really trying to do. Can you expand on the
above a bit? What's "the object" for example?

Bruce

> I recently asked on the Pelagios mailing list[3] whether the project had
> best practice for expressing some classification of the annotation being
> made. For the purposes of Pelagios we'd probably want to express the
> following:
>
> * find locations

> * current — … or former, in CRM style — location

Rob Sanderson

unread,
Jan 5, 2012, 4:41:15 PM1/5/12
to oac-d...@googlegroups.com, oac-d...@googlegroups.com, pelagios...@googlegroups.com
Dear all,

For annotations intended for machine consumption, it is recommended to include the particular triple in the body serialized into some convenient format, rather than to subclass the annotation.
This is described in the last but one section of the Beta documentation.

The reason, as per the discussion on the Pelagios list, is the duplication of every relationship that you want to express as a subclass of annotation. Obviously this isn't desirable! We did have the concept of OAC:predicate to make the relationship explicit, but this was considered strange and doesn't scale to other machine readable formats.

So for A wasBornAt B, you would have:

X a Annotation
X hasBody y
X hasTarget B

y a ContentAsText, oac:Body
y chars "A wasBornAt B"
y dc:format "text/turtle"

B a pelagios:Place
A a pelagios:Person

Or something like that :)

Hope that helps

Rob

Sent from my iPad

On Jan 5, 2012, at 11:02 PM, Alexander Dutton <alexande...@oucs.ox.ac.uk> wrote:

> Dear OAC community members,
>
> I'm working on an aspect of the Pelagios Project[1], which is using OAC annotations for linking things of antiquarian interest (e.g. places and people) to ancient places described by Pleiades[2]. In our usage, the object oac:annotates the Pleiades place.
>
> I recently asked on the Pelagios mailing list[3] whether the project had best practice for expressing some classification of the annotation being made. For the purposes of Pelagios we'd probably want to express the following:
>
> * find locations

> * current — … or former, in CRM style — location

Alexander Dutton

unread,
Jan 16, 2012, 11:56:13 AM1/16/12
to oac-d...@googlegroups.com
Sorry for taking so long to get round to responding…

On 05/01/12 21:05, Bruce D'Arcus wrote:
> On Thu, Jan 5, 2012 at 5:02 AM, Alexander Dutton
<alexande...@oucs.ox.ac.uk> wrote:
>> I'm working on an aspect of the Pelagios Project[1], which is using
>> OAC annotations for linking things of antiquarian interest (e.g.
>> places and people) to ancient places described by Pleiades[2]. In
>> our usage, the object oac:annotates the Pleiades place.
>
> I'm confused on what you're really trying to do. Can you expand on
> the above a bit? What's "the object" for example?

Sorry, 'the object' is either a physical object¹, a person, or a place.
In retrospect I realise that there wasn't really any sane interpretation
of that part of what I said.

There's an example at <http://fpaste.org/4YcS/>, which is missing the
bit that would extend the annotation to mean "found at". I was thinking
something along the lines of dcterms:conformsTo might work, but I'm not
certain.

Kind regards,

Alex

¹ Specifically, often a
<http://erlangen-crm.org/docs/120111/classes/E22ManMadeObject___-1854906473.html>

Bruce D'Arcus

unread,
Jan 16, 2012, 12:06:18 PM1/16/12
to oac-d...@googlegroups.com
On Mon, Jan 16, 2012 at 11:56 AM, Alexander Dutton

<alexande...@oucs.ox.ac.uk> wrote:
>
> Sorry for taking so long to get round to responding…
>
> On 05/01/12 21:05, Bruce D'Arcus wrote:
> > On Thu, Jan 5, 2012 at 5:02 AM, Alexander Dutton
> <alexande...@oucs.ox.ac.uk> wrote:
> >> I'm working on an aspect of the Pelagios Project[1], which is using
> >> OAC annotations for linking things of antiquarian interest (e.g.
> >> places and people) to ancient places described by Pleiades[2]. In
> >> our usage, the object oac:annotates the Pleiades place.
> >
> > I'm confused on what you're really trying to do. Can you expand on
> > the above a bit? What's "the object" for example?
>
> Sorry, 'the object' is either a physical object¹, a person, or a place.
> In retrospect I realise that there wasn't really any sane interpretation
> of that part of what I said.

I'm not an expert on this spec, but this interpretation seems all wrong to me.

An annotation target (what I mean by "the object") is some document
fragment, selected by some person; it's not some physical object. So a
person annotates the fragment.

Is the oac:Annotation class not defined such?

Bruce

Robert Sanderson

unread,
Jan 16, 2012, 1:30:14 PM1/16/12
to oac-d...@googlegroups.com
Yes, the interpretation comes to: A real world object is somehow
"about" another real world object. While this might be true (a book
might be about a concept), it seems very odd to say that a statue is
about the place where it was discovered.

Thus we strongly recommend for any assertion that is more explicit
than "there is a relationship between these two resources" that the
information be included in the Body, rather than forcing the semantics
of the annotation.

Rob

Christian Morbidoni

unread,
Jan 17, 2012, 3:33:33 AM1/17/12
to oac-d...@googlegroups.com
Hi all,

I agree with the approach of explicitly encoding in the body the
semantics of the relations that an annotation establishes among
objects.
If it could be of help, the way I did it in SemLib project, is using a
named graph as a body of an annotation, which can contain a set of
arbitrary triples. I think that this approach is useful if you plan to
store annotations in a triplestore and then you want to query the
graph that results from merging an arbitrary set of annotations.

best,

Christian

Alexander Dutton

unread,
Jan 17, 2012, 4:55:41 AM1/17/12
to oac-d...@googlegroups.com
On 16/01/12 18:30, Robert Sanderson wrote:
> Yes, the interpretation comes to: A real world object is somehow
> "about" another real world object. While this might be true (a book
> might be about a concept), [�]

In this case you'd be relying on the ambiguity of 'book' to mean both
the physical object and the information it carries. In analogy to what
you say below, it would also most likely be odd to say that
'book-the-physical-object' is 'about' a concept.

> [�] it seems very odd to say that a statue is about the place where it
> was discovered.

I do agree.

> Thus we strongly recommend for any assertion that is more explicit
> than "there is a relationship between these two resources" that the
> information be included in the Body, rather than forcing the
> semantics of the annotation.

Makes sense. I think that it follows that � and correct me if I'm wrong
� the only legitimate use of the OAC to model these relationships would
be to say something along the lines of:

<#assertion> a ex:SomethingRelatesToSomethingElseAssertion ;
ex:firstSomething <#statue> ;
ex:secondSomething <#place> .

<#statue> ex:relatesTo <#place> .

<#annotation> a oac:Annotation ;
oac:hasTarget <#statue>, <#place> ;
oac:hasBody <#assertion> .

Kind regards,

Alex

Christian Morbidoni

unread,
Jan 17, 2012, 5:12:51 AM1/17/12
to oac-d...@googlegroups.com
On Tue, Jan 17, 2012 at 10:55 AM, Alexander Dutton
<alexande...@oucs.ox.ac.uk> wrote:
> On 16/01/12 18:30, Robert Sanderson wrote:
>> Yes, the interpretation comes to: A real world object is somehow
>> "about" another real world object. While this might be true (a book
>> might be about a concept), […]

>
> In this case you'd be relying on the ambiguity of 'book' to mean both
> the physical object and the information it carries. In analogy to what
> you say below, it would also most likely be odd to say that
> 'book-the-physical-object' is 'about' a concept.
>
>> […] it seems very odd to say that a statue is about the place where it

>> was discovered.
>
> I do agree.
>
>> Thus we strongly recommend for any assertion that is more explicit
>> than "there is a relationship between these two resources" that the
>> information be included in the Body, rather than forcing the
>> semantics of the annotation.
>
> Makes sense. I think that it follows that — and correct me if I'm wrong
> — the only legitimate use of the OAC to model these relationships would

> be to say something along the lines of:
>
> <#assertion> a ex:SomethingRelatesToSomethingElseAssertion ;
>  ex:firstSomething <#statue> ;
>  ex:secondSomething <#place> .
>
> <#statue> ex:relatesTo <#place> .
>
> <#annotation> a oac:Annotation ;
>  oac:hasTarget <#statue>, <#place> ;
>  oac:hasBody <#assertion> .

This is very close to a rdf reification as far as I understand.
This is correct i think, but what if an annotation contains multiple
statements? e.g. is says that

<#statue> ex:relatesTo <#place>
<#statue> dc:creator <#person>
<#statue> foaf:name <#statue-name>

It would result in a lot of triples. Furthermore I think it things get
complicated when it comes to query the statements inside the
annotation bodies...as it needs ad-hoc logic.
As I said in the previous mail one could consider using named graphs instead.

<#annotation> oac:hasBody <#graph>

<#graph> {
<#statue> ex:relatesTo <#place>
<#statue> dc:creator <#person>
<#statue> foaf:name <#statue-name>
}

Of course it has drawbacks to...
for example it would not be possible to serialize an annotation AND
its body into a single n3 document. one should use TriG, or simply
serve the two pieces with to APIs...

I run into the same problem and went for named graphs.

Hope this helps...

best,

Christian


>
> Kind regards,
>
> Alex

Brian Hoffman

unread,
Jan 17, 2012, 9:32:43 AM1/17/12
to oac-d...@googlegroups.com, oac-d...@googlegroups.com
Thanks Alex,

I was out of the office yesterday for holiday. Maybe we should just have our regular meeting on Thursday so I can try it again today. Also, I can see about getting Alex access to my machine. It should be possible.

Brian

Robert Sanderson

unread,
Jan 17, 2012, 11:30:09 AM1/17/12
to oac-d...@googlegroups.com
On Tue, Jan 17, 2012 at 2:55 AM, Alexander Dutton
<alexande...@oucs.ox.ac.uk> wrote:
> On 16/01/12 18:30, Robert Sanderson wrote:
>> Yes, the interpretation comes to: A real world object is somehow
>> "about" another real world object. While this might be true (a book
>> might be about a concept), […]

>
> In this case you'd be relying on the ambiguity of 'book' to mean both
> the physical object and the information it carries. In analogy to what
> you say below, it would also most likely be odd to say that
> 'book-the-physical-object' is 'about' a concept.

Yes, my apologies! I didn't mean to say that you should use books
(real world objects) as Bodies, just that there are real world objects
which are "about" other resources that have URI identifiers, to
contrast with the example given of a statue and a place.

Are there use cases that are obviously annotations where the Body is
*not* a document? Or more explicitly, a resource which is able to be
dereferenced and provide 1 or more representations, or one such
representation embedded within the Annotation graph? It's always
possible to reference a description of a non-information resource,
rather than the non-information resource itself, but is this
sufficient?


> Makes sense. I think that it follows that — and correct me if I'm wrong
> — the only legitimate use of the OAC to model these relationships would


> be to say something along the lines of:

(below)

This would allow the assertion to be directly within the Annotation
graph, and is maybe an example of a case where the Body is not a
Document (in this case it's an assertion). Is this an important use
case for you?

The reasons that we suggested including the statement as a serialized
literal, rather than within the Annotation graph are:

* You can make multiple assertions in one body
* Easier provenance tracking (it's a document, not an ephemeral non-info res)
* Doesn't assume RDF as the only way to make assertions
* Allows mixing serializations (body as JSON-LD, annotation as RDF/XML)
+ Which allows future named graph specs to be used directly
* Coherent with other recommendations:
+ take a ContentAsText Body and give it an HTTP URI if you see it
+ embedding data in ContentAsText with a mimetype provided
+ DataAnnotation means "please process the body further"
+ Ability to assert metadata about the Body (author,
last-modified, format etc)


> <#assertion> a ex:SomethingRelatesToSomethingElseAssertion ;
>  ex:firstSomething <#statue> ;
>  ex:secondSomething <#place> .
>
> <#statue> ex:relatesTo <#place> .
>
> <#annotation> a oac:Annotation ;
>  oac:hasTarget <#statue>, <#place> ;
>  oac:hasBody <#assertion> .

Hope that helps explain some of the thinking at least :)

Rob

Vladimir Alexiev

unread,
Jan 23, 2012, 3:22:50 PM1/23/12
to oac-d...@googlegroups.com, pelagios...@googlegroups.com
Hi Alex!
Why not use CRM relations for this? It seems to me that CRM has enough stuff for this particular use case.

Vladimir Alexiev

unread,
Feb 8, 2012, 3:56:11 AM2/8/12
to oac-d...@googlegroups.com, pelagios...@googlegroups.com

y chars "A wasBornAt B"; dc:format "text/turtle".

Hi Rob! 
I think it's a very bad idea to represent RDF as anything else but RDF triples. 
If you encode the RDF, that defeats semantic repository indexes and query optimizations.
You wouldn't store encoded relational data in a single RDBMS field, so why would you do it for RDF?
See my top-level posting for more details.

Reply all
Reply to author
Forward
0 new messages