Best practice for typing annotations
Alexander Dutton
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
<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
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
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
<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
"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
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
> Yes, the interpretation comes to: A real world object is somehow
> "about" another real world object. While this might be true (a book
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
<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
>
> 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.
>
>> 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.
>
> — 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
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
<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
>
> 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
Vladimir Alexiev
y chars "A wasBornAt B"; dc:format "text/turtle".