Re: Streamlining the OA Model

Hi Bernhard,
+1 to all the things you say.
In fact, you are describing a lot of features that the NLP Interchange 
Format (NIF, http://nlp2rdf.org/news/nif-roadmap-2012-and-pointers ) has 
(will have). We really hope that NIF will converge with OA some day.

I already raised the fragment issue (although I didn't have the time to 
discuss until consensus was reached ), but find the thread here:
http://lists.w3.org/Archives/Public/public-openannotation/2012May/0002.html

In general, here is what I answer, when people (such as Nancy Ide 
recently) ask me about the relation of NIF to OA:

****************
Hi Nancy,
The Open Annotation guys should know me. I am posting on their mailing 
list now and then (e.g. yesterday) .  Open annotation is quite 
elaborate. I asked them to make an example: 
http://www.w3.org/community/openannotation/wiki/TextCommentOnWebPage
They need 15 triples and 4 generated UUID's, NIF does basically the same 
with 1 generated ID and 5 triples:

<http://www.w3.org/DesignIssues/LinkedData.html#offset_717_729>
      a str:StringInContext ;
      wa:comment <http://myannotation.org/comment/kf094erk430943k> .

<http://myannotation.org/comment/kf094erk430943k>
      rdf:type wa:Comment  ;
      wa:commentString "Good idea that Semantic Web!" ;
      wa:commentor "Bob"  .

See below for links to two references, one which I will present on the 
EKAW conference in October and another one, which is a technical report.
EKAW Short paper:
http://svn.aksw.org/papers/2012/NIF/EKAW_short_paper/public.pdf
Technical Report:
http://svn.aksw.org/papers/2012/WWW_NIF/public/string_ontology.pdf
****************

Our general guideline, when designing NIF was to be compatible and 
listen to almost everybody, especially other standards from W3C.
NIF 2.0 will (hopefully) be compatible to OpenAnnotation (your work), 
ITS-2.0, xpointer/xpath, rfc5147, Prov-AQ, LAF/GrAf, Lemon, NERD, 
(probably also Media Fragments) etc...

So Bernhard, you have probably mentioned everything that is really 
necessary for widespread adoption (the unavailability of standardized 
JSON-LD is really sad and I hope they will finish really fast). For NIF, 
we have to watch convenience of implementation, usage and scalability 
(and triple count), even if it is not as expressive sometimes. We will 
try to make it compatible with OA. Maybe, you want to adopt it some day 
as OA-Lite (less expressive, but mappable to OA-Full).

By the way, I would really like to join a telco. I have looked through 
the previous emails and couldn't find any minutes or telco time. Are 
this group's telcos public or private?
Sebastian



Am 31.07.2012 18:02, schrieb Bernhard Haslhofer:
> Hi,
>
> I spent the past couple of weeks implementing the Maphub API (http://maphub.github.com/api/) using the Open Annotation model and found that the model is expressive enough for our use cases. However, I believe that some tweaks in the OA specifications could streamline the model and make the developer's life (= the "users" of the specification) easier, both on the server- and the client-side.
>
> Here the summary my thoughts:
>
> 1.) Direct Relationship between Annotation and the Source
>
> "Give me all annotations for resource X", is probably one of the most important queries that needs to be answered. X could be an image URI, the URI of a video, whatever. Since the the Target of an annotation may be a resource with its own dereferencable URI OR a Specific Target with a UUID node, you need to consider this when formulating a query and end up with a SPARQL UNION query or some conditional node traversal code when using an RDF API.
>
> Technically, it is of course possible to do that, but given the importance of that query, I would argue that the solution is not very intuitive and maybe also not very efficient. I believe that this can easily be be fixed by introducing a direct relationship property (e.g., oa:annotates, oa:hasTargetSource) between the Annotation and the Source resource.
>
> 2.) Fragment URIs as Targets
>
> In our API (the GeoReference part) we followed the OA recommendation and used a Specific Resource and a Fragment Selector to express that a URI annotates an XY point on a raster image. We could express the same information by using W3C Media Fragments and thereby reduce the verbosity and complexity of the resulting serialization. API consumers then don't even need to know about OA-specific "Specific Resources", "Fragment Selectors", etc.
>
> The Open Annotation model currently does NOT RECOMMEND the use of fragment URIs for identifying segments of Targets or Bodies for three reasons (see 5.2.1):
>
> - "cannot query the source directly": I think this could and should be solved by considering (1.)
> - "they are not compatible with State and Style Specifiers; many annotations may have the same segment of interest, but have different States and Styles": from previous emails and discussions I understood that Styles should be directly attached to the Annotation, which also means that that they are contextualized and not an argument against fragment URIs anymore. I think that sth. similar can be done with "State" and would also result in a more consistent model and allow for fragment URIs
> - "Fragment URIs conflate the identity and the description of the segment of interest by including the description inline within the identity": I am not sure if I get the point of this argument right; however, I believe that for very practical reasons the OA model should reuse what other specifications (Web Architecture, Media Fragment RFCs) already define; this brings modularity and flexibility and avoids the risk of re-designing what others already did elsewhere.
>
> I think the benefits of reusing (Media) Fragment URIs in OA prevail the arguments of not using them and therefore I propose to RECOMMEND the use of Fragment URIs and only fall-back on OA-specific Selectors if Fragment URIs are not expressive enough.
>
> 3.) Simple Literal Body Shortcut
>
> I understand that an OA annotation is a relationship between resources (the body and the target) and that inline bodies are represented using the Content in RDF specification (see 6.1.). However, our own demonstrator and also the majority of use cases demonstrated in the OAC meeting last week showed that many annotation bodies are simply strings, which could be represented as literals.
>
> Therefore I am proposing to introduce a "shortcut" property between the Annotation and the "content" Literal (e.g., hasLiteralBody). This allows people to express simple annotations in a, in my opinion, more straightforward way and doesn't contradict the current oa:hasBody approach.
>
> 4.) Style Attached directly to the Annotation
>
> We don't express style information in our serializations because I believe that styling information and data representation should be separated. However, I understand that there are use cases that require this feature and I prefer the approach of optionally attaching style directly to the annotation over attaching it to the Specific Target.
>
> 5.) JSON (-LD) Serialization Recommendation
>
> At the moment the spec recommends that RDF/XML is used as default serialization language. We haven't implemented it yet, but I'd consider JSON (-LD) at least as alternate "default" serialization format to open the door for JS clients.
>
> Bernhard
>
> -----------------------------------------------------
> Bernhard Haslhofer
> Postdoc Associate
> Cornell Information Science
> 301 College Ave.
> Ithaca, NY 14850
> WWW: http://www.cs.cornell.edu/~bh392/
> Skype: bernhard.haslhofer
>
>
>


-- 
Dipl. Inf. Sebastian Hellmann
Department of Computer Science, University of Leipzig
Events:
   * http://sabre2012.infai.org/mlode (Leipzig, Sept. 23-24-25, 2012)
   * http://wole2012.eurecom.fr (*Deadline: July 31st 2012*)
Projects: http://nlp2rdf.org , http://dbpedia.org
Homepage: http://bis.informatik.uni-leipzig.de/SebastianHellmann
Research Group: http://aksw.org

Received on Tuesday, 31 July 2012 17:37:23 UTC