Re: Annotation Serializations

Another aspect is relative to the multiple tags (which looks neat in the
HTML as it is):

{
   "@type": "Tag",
   "value": [
       "web",
       "standards",
       "annotations"
    ]
}

>From an application, I would have probably serialized as:
{
   "@type": ["oa:Tag", "cnt:ContentAsText"],
   "cnt:chars": "web"
},
{
   "@type": ["oa:Tag", "cnt:ContentAsText"],
   "cnt:chars": "standards"
},
{
   "@type": ["oa:Tag", "cnt:ContentAsText"],
   "cnt:chars": "annotations"
}

However, I am assuming - if format and language are the same - the above
could be written also as:

{
   "@type": ["oa:Tag", "cnt:ContentAsText"],
   cnt:chars: [
       "web",
       "standards",
       "annotations"
    ]
}

Would this work?




On Sun, Jan 19, 2014 at 3:43 PM, Paolo Ciccarese
<paolo.ciccarese@gmail.com>wrote:

> Dear Ivan and Doug,
> I believe the HTML use case can be very useful.
>
> The proposed code brings up the use of rdf:value vs cnt:chars that is
> currently recommended in the specs.
> The use of Content in RDF  ( http://www.w3.org/TR/Content-in-RDF10/ ) has
> been discussed multiple times within the Community Group.
>
> This is how an embedded body looks like according to specs:
>
> <body1> a cnt:ContentAsText, dctypes:Text ;
>     cnt:chars "content" ;
>     dc:format "text/plain" .
>
> And this is a textual Tag:
>
> <tag1> a oa:Tag, cnt:ContentAsText ;
>     cnt:chars "tag" .
>
>
> Best,
> Paolo
>
>
>
> On Sun, Jan 19, 2014 at 3:14 PM, Doug Schepers <schepers@w3.org> wrote:
>
>> Hi, Ivan–
>>
>>
>> On 1/19/14 2:39 PM, Ivan Herman wrote:
>>
>>> Ok. I accept these as proofs that an HTML based serialization fulfill
>>> a real demand. How would we do that is something that a possible WG
>>> will have to define/show; having some ideas jotted down on the wiki
>>> will be useful.
>>>
>>
>> Done:
>>  http://www.w3.org/community/openannotation/wiki/Serializations
>>
>>
>>
>>  But I do not think we should disregard JSON either, I could see use
>>> cases for that, too. Eg, if the annotation cannot be attached to the
>>> core text (this is the way Diigo, as well as most of the ebook
>>> reading system, do it) but are rather stored outside the text (eg, on
>>> a server), then the simplicity of JSON, as well as its wide usage in
>>> different tools, becomes a big plus.
>>>
>>
>> I absolutely agree. JSON is going to be an extremely common interchange
>> and wire format.
>>
>>
>>
>>  The beauty of OA is that it defines an abstract model, and the
>>> serialization is well separated. That is a major feature to embrace
>>> and showing/documenting different serializations is a major asset..
>>>
>>
>> Agreed.
>>
>>
>>
>>  (Thanks to Doug for having started this...)
>>>
>>
>> And thank you for giving me the opportunity to make my proposal more
>> coherent, and for improving my crappy code.
>>
>> Regards-
>> -Doug Schepers
>> W3C Developer Relations Lead
>> Project Coordinator for SVG, WebApps, Touch Events, and Audio
>>
>>
>
>
> --
> 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
> Member of the MGH Biomedical Informatics Core
> +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.
>



-- 
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
Member of the MGH Biomedical Informatics Core
+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.