Re: Streamlining the OA Model

Hi Sebastian,

What happens when (a) someone else annotates that same section of
text, and (b) someone defines an anchor that happens to look like the
syntax?

I'm glad that it works for you, but looking more broadly at annotating
any web resource rather than just NLP I'm afraid that it doesn't work
for us.  On the other hand, the more expressive OA format does look
like it could easily be reduced to your syntax or hopefully expanded
from your syntax out to OA.

Thus a NIF<-->OA gateway doesn't seem out of the question if that's
the preferred syntax in your community.

Hope that helps,

Rob


On Tue, Jul 31, 2012 at 11:51 AM, Paolo Ciccarese
<paolo.ciccarese@gmail.com> wrote:
> Is the mechanism
> http://www.w3.org/DesignIssues/LinkedData.html#offset_717_729 really working
> in general?
>
> In my experience it does not with HTML pages in general. That would mean
> having lots of ways of composing the URIs that then need would need to be
> parsed. That is why we designed more complex selection mechanisms
> (http://www.openannotation.org/spec/core/#Selector)... and therefore more
> triples.
>
> Paolo
>
>
> On Tue, Jul 31, 2012 at 1:36 PM, Sebastian Hellmann
> <hellmann@informatik.uni-leipzig.de> wrote:
>>
>> 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 18:20:42 UTC