- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Tue, 12 Feb 2013 19:08:32 +0100
- To: <public-openannotation@w3.org>
Hi Rob, The arguments for provenance mentioned in the other mails sound more important to me than what the Content in RDF really is. We'd rather focus on *our* requirements and views on what is needed/feasible. We have to be realistic, and I'll be blunt, really sorry (or maybe I'm plainly wrong--perhaps you can ask at the W3C workshop you're attending; in fact I'd be quite happy to be proven wrong here). This Content in RDF document is a working draft by a working group for which the charter does not explicitly state they have to produce such a spec. Nothing has happened on it since quite a while (see the mailing list mentioned in the call for comment), and we're more or or less the only ones to use it besides the creators (who all come from the same team). Furthermore I've not yet seen the RDF group addressing it, while this would seem a convenient forum for this. Antoine > Hi Antoine and all, > > It would be good to know what the Content in RDF folk think, but the > issue for me is consistency both internally and with the web. > > The question seems to be, does the ContentAsText node a correspond to > a representation or to a resource. If it's a representation, then you > would have multiple ContentAsTexts, one for each language. If it's a > (negotiable) resource, then you would have one ContentAsText node, > with the various options for language based content negotiation. > > Given the inclusion of characterEncoding as a property of > ContentAsText, and the existence of ContentAsXML and ContentAsBase64, > it seems more closely associated with a particular representation. > > This would mean each language would have its own node, with its own > explicit metadata (dc:language). It would also have its own media > type (dc:format), which we can't use use datatypes for as they're not > URIs. Creator, Creation date, and other provenance information are > also important. Also, resources might have multiple languages (english > and arabic used in the same comment for example) which would not be > possible (in my understanding) with language tags. So, like the > general literal body question, it seems that there's a possible > shortcut via language tagged literals, but it doesn't cover all of the > use cases. > > Thus a oa:Choice of multiple nodes, seems more appropriate than > language tagged rdf literals, such as: > > _:body1 a cnt:ContentAsText ; > cnt:chars "english"@en ; > cnt:chars "french"@fr ; > cnt:chars "german"@de ; > ... > > > Rob > > On Tue, Feb 12, 2013 at 9:28 AM, Antoine Isaac<aisaac@few.vu.nl> wrote: >> Hi Paolo, >> >> OK, this quite clarifies it then: how much is your option 2) compatible with >> the idea of text body in CNT with dc:language? >> >> And further: what would this would say about the potential awkwardness of >> the idea of text body in CNT with dc:language in the first place? >> Because option 2) does look like a very natural alternative for handling >> translations in RDF... >> >> Antoine >> >> >> >>> Hi Antoine, >>> sorry, I have not been clear on that point. >>> >>> <comment-in-english> for me could mean a text body in CNT with >>> dc:language. >>> As specified in the specs in >>> http://www.openannotation.org/spec/core/core.html#BodyEmbed >>> >>> Paolo >>> >>> On Tue, Feb 12, 2013 at 9:18 AM, Antoine Isaac<aisaac@few.vu.nl >>> <mailto:aisaac@few.vu.nl>> wrote: >>> >>> Hi Paolo, >>> >>> >>> Additional use cases? Thoughts? >>> >>> >>> >>> There was also the option of using a custom attribute (e.g. >>> dc:language) on a body-as-resource to indicate this language. This solution >>> (which I didn't like) was addressing a different problem (the one of >>> representing language of a text body represented as a CNT resource). But if >>> people want to use it then there might be a dependency with the options you >>> raise below. >>> >>> In fact your option 1 would need some of this: right now nothing says >>> you<comment-in-english> is in English, actually. So either the "label" of >>> <comment-in-english> has to be tagged as "en", or you have to use a >>> dedicated property (e.g. dc:language) to create a new statement with >>> <comment-in-english> as subject. >>> >>> Cheers, >>> >>> Antoine >>> >>> >>> >>> >>> >>> Dear all, >>> now that the new draft of the specs has been published, I would >>> like to discuss further some aspects that have been dropped along the way. >>> One of them is languages and translations. >>> >>> This is my scenario: I have a textual content written in one >>> language. As curator, I pick an important sentence within that text and I >>> provide, through annotation, the translations in different languages of that >>> particular passage. And it could be even a little more complicated and we >>> might need to keep track of multiple translations for each language >>> performed at different moments in time or by different agents in different >>> moments in time. >>> >>> Does any other member have use cases about translations? >>> >>> A couple of solutions have been discussed in previous emails >>> exchanges [1][2][3]: >>> >>> 1) Translations "by oa:Choice". This seems well representing those >>> cases in which we are modeling an actual choice. >>> >>> _:x a oa:Annotation ; >>> oa:hasBody<choice1> ; >>> oa:hasTarget<ny-times-article> . >>> >>> <choice1> a oa:Choice ; >>> oa:default<comment-in-french> ; >>> oa:item<comment-in-english> ; >>> oa:item<comment-in-spanish> . >>> >>> However, it does not seem fitting the above use case where all the >>> translations are meant to be provided at the same time. >>> So I wonder what you think about: >>> >>> _:x a oa:Annotation ; >>> oa:motivatedBy blah:translating >>> oa:hasBody<comment-in-english> ; >>> oa:hasBody<comment-in-spanish> . >>> oa:hasTarget<ny-times-article> . >>> >>> 2) Translate "by multilingual body": >>> >>> _:x a oa:Annotation ; >>> oa:hasBody<multilingualcomment> ; >>> oa:hasTarget<ny-times-article> . >>> >>> <multilingualcomment> rdfs:label "comment-in-french"@fr ; >>> rdfs:label "comment-in-english"@en ; >>> rdfs:label "comment-in-spanish"@es . >>> >>> This could look more explicit, however it introduces a new kind of >>> Body. >>> >>> Additional use cases? Thoughts? >>> >>> Best, >>> Paolo >>> >>> [1] >>> http://lists.w3.org/Archives/__Public/public-openannotation/__2012Oct/0004.html >>> <http://lists.w3.org/Archives/Public/public-openannotation/2012Oct/0004.html> >>> [2] >>> http://lists.w3.org/Archives/__Public/public-openannotation/__2012Nov/0001.html >>> <http://lists.w3.org/Archives/Public/public-openannotation/2012Nov/0001.html> >>> [3] >>> http://lists.w3.org/Archives/__Public/public-openannotation/__2012Nov/0006.html >>> <http://lists.w3.org/Archives/Public/public-openannotation/2012Nov/0006.html> >>> >>> >>> -- >>> Dr. Paolo Ciccarese >>> http://www.paolociccarese.__info/ >>> <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<tel:%2B1-857-366-1524> (mobile) +1-617-768-8744 >>> <tel:%2B1-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. >> >> >>
Received on Tuesday, 12 February 2013 18:53:36 UTC