W3C home > Mailing lists > Public > public-openannotation@w3.org > January 2013

Re: Plain textual bodies - summary of arguments and possible solutions

From: Robert Sanderson <azaroth42@gmail.com>
Date: Thu, 17 Jan 2013 09:22:35 -0700
Message-ID: <CABevsUEVO3FB5PDEjnQtxHi1WBP=9HHf_9BQRrFpA0s6FngixQ@mail.gmail.com>
To: Bob Morris <morris.bob@gmail.com>
Cc: Paolo Ciccarese <paolo.ciccarese@gmail.com>, Bernhard Haslhofer <bernhard.haslhofer@cornell.edu>, public-openannotation@w3.org
Two issues extracted from the page deserve to be discussed further on
the list, as they are necessary regardless of whether a literal body
is possible or not.

1.  "What will happen in multilingual environments? CNT has no
recommended patterns for describing the language of its ContentAsText

This is a great observation.  I can see two possibilities:

* Use of dc:language as a property with the label as the value.  This
would follow from the view that language is metadata about the
resource, similar to author, creation time, etc.

    _b1 a cnt:ContentAsText ;
        cnt:chars "Hello!" ;
        dc:language "en" .
    {"chars" : "Hello!", "lang" : "en"}

* Or using the language tag on the literal object of cnt:chars.  This
would be, perhaps, the more RDF centric approach, but in my experience
makes implementation harder in some development libraries compared to
just adding a triple.  Interestingly the Turtle syntax is shorter than
a triple, but the JSON-LD syntax is longer!

    _b1 a cnt:ContentAsText ;
        cnt:chars "Hello!"@en .
    {"chars" : "Hello!", "@language" : "en"}

And the second question I think is clearer:

2. It is unclear how to make annotation with (XML) typed literals.

As previously, no one expressed a real use case for this requirement,
but it may come up and it would be good to have the answer clear from
the specification in that case.

There are several options:

1.  Use ContentAsText, with a dc:format of "text/xml".
2.  Use the cnt:ContentAsXML class
3.  Use a typed literal as above.

My own preference for 1 is to use dc:language for consistency with
dc:format, and I have no significant preference between options 1 and
2 for the second.


On Thu, Jan 17, 2013 at 8:08 AM, Bob Morris <morris.bob@gmail.com> wrote:
> Bernhard has produced an excellent  page on the issue wiki
> http://www.w3.org/community/openannotation/wiki/Textual_Bodies. I
> would urge that any discussions continue there. The "history" tab on
> that page makes it easy to find out what is evolving, and the  "watch"
> tab provides email notifications of changes.
> Bob Morris
> On Thu, Jan 17, 2013 at 7:54 AM, Paolo Ciccarese
> <paolo.ciccarese@gmail.com> wrote:
>> Thank you Bernhard!
>> Whatever approach we will all decide for, it is good to keep track of all
>> these aspects for future reference.
>> best,
>> Paolo
>> On Wed, Jan 16, 2013 at 11:51 PM, Bernhard Haslhofer
>> <bernhard.haslhofer@cornell.edu> wrote:
>>> 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
>> --
>> Dr. Paolo Ciccarese
>> http://www.paolociccarese.info/
>> Biomedical Informatics Research & Development
>> Instructor of Neurology at Harvard Medical School
>> Assistant in Neuroscience at Mass General Hospital
>> +1-857-366-1524 (mobile)   +1-617-768-8744 (office)
>> CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s),
>> may contain information that is considered
>> to be sensitive or confidential and may not be forwarded or disclosed to any
>> other party without the permission of the sender.
>> If you have received this message in error, please notify the sender
>> immediately.
> --
> Robert A. Morris
> Emeritus Professor  of Computer Science
> UMASS-Boston
> 100 Morrissey Blvd
> Boston, MA 02125-3390
> IT Staff
> Filtered Push Project
> Harvard University Herbaria
> Harvard University
> email: morris.bob@gmail.com
> web: http://efg.cs.umb.edu/
> web: http://wiki.filteredpush.org
> http://www.cs.umb.edu/~ram
> ===
> The content of this communication is made entirely on my
> own behalf and in no way should be deemed to express
> official positions of The University of Massachusetts at Boston or
> Harvard University.
Received on Thursday, 17 January 2013 16:23:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:21 UTC