SEMLIB & OAC

[Christian Morbidoni]

Hi everybody,

my name is Christian Morbidoni and I'm leading the development of an
annotation system in the context of the SEMLIB EU project.
It will be basically a porting of SwickyNotes (swickynotes.org), which
currently is a desktop application, to a web based system.
We are in early development phase and we are considering using the OAC
ontology to represent annotations. We will store annotation natively
in RDF and OAC model is conceptually very similar to the one (home
brewed) we are using in SwickyNotes, so it seems to fit perfectly :-)

However, in our system annotations will be made of triples themselves,
meaning that the "body" will possibly contain RDF statements
representing typed relations among "targets" (e.g. A "cites" B, A "is
similar to" C, A "depicts" D and so on). In such a scenario, in other
words, annotators collaboratively build RDF graphs that can be then
explored and queried. As this case seems not to be directly addressed
in the OAC docs, I'm wondering if someone already thought about it and/
or have recommendations or comments.

I guess it can be done in two ways: using a reified node as body of an
annotation or, in turn, with named graphs (the second one being my
choice).
I'm attaching an example of how my annotations would look like in Trig
format.

best regards,

Christian

P.S. if someone is interested in more details about SEMLIB please just
mail me.


:Defult-Graph {
ex:ANNOTATION-1 a oac:Annotation ;
rdfs:label "My beautiful annotation";
dcterms:created "2010-01-27 10:30:56";
dcterms:modified "2010-01-27 10:30:56";
dcterms:creator ex:Christian ;
oac:hasBody ex:ANN-BODY-1 ;
oac:hasTarget ex:TARGET-1 ;
oac:hasTarget ex:TARGET-2 .
oac:hasTarget ex:TARGET-3 ;

ex:ANN-BODY-1 a oac:body ;
rdfs:comment "Il testo della mia bella annotazione è questo: bla
bla" ;
semlib:statements ex:Graph-1 .

ex:Graph-1 {
ex:TARGET-1 ex:similar-to ex:TARGET-2 .
ex:TARGET-2 ex:cites ex:TARGET-3 .
}

[Karin Verspoor]

Hi Christian,

For now, a short reply, but this fits in with our use case. Attached please find a paper that describes some preliminary proposals along these lines; we'll be presenting this a conference this summer (the BioOntologies SIG at ISMB). It still needs to be formalized and connected formally to the OAC, but it can serve as a starting point for discussion.

Karin

[Robert Sanderson]

This issue came up strongly at the OAC Workshop in March, and is very
definitely on our radar.

Some of our current thinking on it:

* If the Body's statements are merged into the Annotation graph, then
the creator of the Annotation becomes the creator of those statements.
This may not be correct!

* As the Body can be of any format and type, a machine-readable Body
is perfectly reasonable. And can be inlined within the Annotation
document using the Content in RDF approach, as per the data model.

We hope to have at least some recommendations on this topic for the
Beta version of the specification, due when the selected experiments
from the current RFP start.

Hope that helps!

Rob

> --
> Karin Verspoor, PhD
> Research Assistant Professor
> Center for Computational Pharmacology, University of Colorado Denver
> 12801 E 17th Ave, MS 8303, Aurora, CO 80045 USA
> karin.v...@ucdenver.edu / tel: (720) 279-4875 / campus: 4-3758
> http://compbio.ucdenver.edu/Hunter_lab/Verspoor
>
>
>
>
>
>
>
>
>
>

[Christian Morbidoni]

On May 24, 2011, at 9:54 PM, Robert Sanderson wrote:

> This issue came up strongly at the OAC Workshop in March, and is very
> definitely on our radar.
>
> Some of our current thinking on it:
>
> * If the Body's statements are merged into the Annotation graph, then
> the creator of the Annotation becomes the creator of those statements.
> This may not be correct!

I think I didn't get this point. By "merged into the Annotation graph" you mean expressed using reification?
In this case I do not agree...the reification does not imply the statement itself...but, again ... I don't get the point exactly :-)

>
> * As the Body can be of any format and type, a machine-readable Body
> is perfectly reasonable. And can be inlined within the Annotation
> document using the Content in RDF approach, as per the data model.

You mean RDF/XML into RDF? well...I didn't think about it...
However, for storing annotations into a triplestore, the named graphs approach seems better: I can flexibly query the triples contained in annotations. This might be useful as we are going to have "collections" of annotations that users of the system should be able to create...as "personal views" on the annotations store.
On the other hand, Content in RDF could be a nice way to return annotations (along with contained triples) in RDF/XML by an API call.

>
> We hope to have at least some recommendations on this topic for the
> Beta version of the specification, due when the selected experiments
> from the current RFP start.

It is definitely closed right? :-)

[Vladimir Alexiev]

Hi Christian, I watched your SEMLIB video, very nice!

- Totally agree that expressing all annotation data in triples is better than as a string in any encoding.

- In the above why use a non-standard relation semlib:statements ex:Graph-1? Why not simply:

  ex:ANN-BODY-1 {

    ex:TARGET-1 ex:similar-to ex:TARGET-2 . 
    ex:TARGET-2 ex:cites ex:TARGET-3 .  

  }

- In ResearchSpace our current model is to use reification, since it gives us the flexibility to annotate a property-instance with or without talking about its object.

PS: I hope we'll get to work together. We're partners in that Marie Curie ITN  proposal.

[Christian Morbidoni]

Hi Vladimir,

On Wed, Feb 8, 2012 at 2:14 PM, Vladimir Alexiev <vlad...@sirma.bg> wrote:
> Hi Christian, I watched your SEMLIB video, very nice!

Thank you :-) I don't know exactly what video you refer to. May be it
was an old one.
I posted some videos recently that reflects more the current state of
development:
http://www.youtube.com/watch?v=gVA_v152Qn0,
http://www.youtube.com/watch?v=z1hXr5K3kTM and
http://www.youtube.com/watch?v=Q5KTzEcRrPs.
I should update them and perhaps write some comment...making
screencast is so time consuming :-)

Feedback is VERY welcome.

One thing we are doing now is building more user friendly GUI. The
idea is to have quick and simple ways to create triples behind the
scene without involving the user in "manually" creating them.

> - Totally agree that expressing all annotation data in triples is better
> than as a string in any encoding.
> - In the above why use a non-standard relation semlib:statements ex:Graph-1?
> Why not simply:
>
>   ex:ANN-BODY-1 {
>     ex:TARGET-1 ex:similar-to ex:TARGET-2 .
>     ex:TARGET-2 ex:cites ex:TARGET-3 .
>   }
>

Agree, and in fact we changed a bit our data model. We are now using
the aos:hasBody property to directly connect the annotation with its
graph, eliminating the useless "step".

> - In ResearchSpace our current model is to use reification, since it gives
> us the flexibility to annotate a property-instance with or without talking
> about its object

Reification is a valid option, we were using it in a previous project
(swickynotes.org).
I decided to go for named graphs in SemLib as I think it is more easy
to query annotations and "slicing" the overall graph.
It saves triples also, reification is more expensive...isn't it?

>
> PS: I hope we'll get to work together. We're partners in that Marie Curie
> ITN  proposal.

Well...crossed-fingers :-)

best,

Christian