- From: Rob Sanderson via GitHub <sysbot+gh@w3.org>
- Date: Mon, 08 Feb 2016 16:54:18 +0000
- To: public-annotation@w3.org
Here's the number 1 reason why: RDF does not allow for both language and data type to be associated with the same literal. Thus you cannot have a string that is both text/plain and in English. This is a critical requirement that language tagged strings cannot accomplish, and thus we have to work around it by mandating a TextualBody resource with predicates (dc:format and dc:language). And the number 2 reason why: Given number 1, we could still allow language tagged strings... but that would be very confusing, especially as there would be both type (rdf:type) and @type (data type of the literal), value (rdfs:value) and @value (the value of a literal), and language (dc:language) and @language (the language tag of the literal). Also, it would be inconsistent between @type (literal) and format (resource) as to where to put the data type. Pros: * Common practice for RDF -- Isn't our primary focus. We aim for compatibility and following best practices where possible, but not at the expense of ease of understanding and implementation. * Allow multiple languages -- Is a big concern, and one that is addressed already with Choice + TextualBody with dc:language. It is explicit that it is a choice between two comparable resources, and not simply two different bodies. * Language is explicit -- I think that it is explicit already. It's associated with the resource, not the literal. In the unpublished working draft we moved away from overloading body, and explicitly added bodyText, see: http://w3c.github.io/web-annotation/model/wd2/#string-body -- GitHub Notification of comment by azaroth42 Please view or discuss this issue at https://github.com/w3c/web-annotation/issues/149#issuecomment-181462980 using your GitHub account
Received on Monday, 8 February 2016 16:54:20 UTC