- From: Bernhard Haslhofer <bernhard.haslhofer@cornell.edu>
- Date: Wed, 16 Jan 2013 23:51:55 -0500
- To: public-openannotation@w3.org
Dear all, I think the current discussion on supporting plain text (literal) bodies in the Open Annotation model is important because there are many real-world annotation use cases that attach such bodies to Web resources (e.g., Flickr). Therefore I spent some time to summarize existing pro and con arguments and came up with possible solutions (with some help from Antoine) for representing plain text (literal) bodies. Here is the Wikipage: http://www.w3.org/community/openannotation/wiki/Textual_Bodies Apologies in advance, I tried to find and cite all arguments in the spec and the previous thread as precisely as possible, but might have missed one or the other. So please fix the arguments directly in the wiki. If there are other possible solutions, please add them... It seems that there are two possible solutions at the moment: 1.) Allow Literals for oa:hasBody 2.) Introduce a shortcut property (e.g., oa:hasLiteralBody) for plain text bodies I think both solutions are feasible and meet the goal of "remaining simple enough to also allow for the most common use cases, such as attaching a piece of text to a single web resource", mentioned in the introduction. If I had to choose now, I would probably prefer the first option because I am not (yet) convinced by the counter-arguments and it avoids the introduction of another property. Also, the motivation for using OA in our context (maphub, yuma, etc.) is sharing and exchanging annotation data on the Web and not building a formal knowledge base one can use for inferencing; therefore also allowing literals as bodies could easily be handled by an additional "if body.isLiteral?" condition in any OA parser. However, I understand that inferencing and therefore consistency is rather important for some other use cases, which brings me back to the second option as a possible compromise. Best, Bernhard
Received on Thursday, 17 January 2013 04:52:26 UTC