format in the model for Embeded Textual Body?

[iherman]

The current model says that dc:format should be added to an embedded textual body (section 3.2.4). Isn't that superfluous? The only purpose in life of that class is to include language tags, with or without language tags, with or without datatypes (actually, I am not even sure whether datatyped literals, beyond plain and language tagged literals, should be allowed).

I propose to remove that. RDF environment can deduce that information.

[azaroth42]

-1. How would you tell the difference between HTML, Markdown and plain text without either explicitly being told (as per now) or tedious and unreliable introspection on the value?

[BigBlueHat]

Agreed. 👎 to removing format from Embedded Textual Bodies.

For example, what format is the text key in this JSON?
https://hypothes.is/api/annotations/oMbOEFjrSMmRL-txMbvexg

Is it...

• text/plain
• text/html
• Markdown (which...still...needs a media type, btw...)

If you chose Markdown, you'd be correct! 😄 Or, at least that's how it will be treated by the Hypothes.is UI. Without knowing that in the package, you have to go look it up...somewhere. If you were only given that JSON document (or even if you just hit that URL), you'll be hard pressed to do that. It's in our docs...somewhere.

Having it in the package contents directly, would make it obvious, useful, and simpler to understand the JSON, despite its being more verbose.

[iherman]

True. However... what about setting some defaults? After all, a plain text will probably have the most widespread usage, ie, in the absence of it one can deduce that it is plain text.

Just for Literals in RDF. If you have a literal, and there is no datatype assigned, the serialization says that it is a 'plain literal a.k.a. xsd:string. If you want something more, you add an explicit datatype.

[BigBlueHat]

Is that not already the case?

format's a SHOULD:
http://www.w3.org/TR/annotation-model/#h4_embedded-textual-body

The content of the Body is recorded as the value of the rdf:value property, and additional properties such as dc:format and dc:language SHOULD be given if known.

And "simple literals" are strings (as defined in XMLSchema afaik):

Simple literals are syntactic sugar for abstract syntax literals with the datatype IRI http://www.w3.org/2001/XMLSchema#string.

I'm starting to wonder about the \n escaping in JSON and how that plays out here...

[azaroth42]

Defaults, especially in the open world, seem very risky. I actually think that HTML will be the most common, because most annotations will be created in HTML based environments, and people will want to add at least basic styling. It's also very non-future-proof. Even if we do ascertain correctly that text/plain is the most common type of textual annotation body today, who knows what will come in two years time.

For literals, do you mean the literal body per http://www.w3.org/TR/annotation-model/#simple-textual-body ? That already has a requirement that the literal is xsd:string in the first bullet.

[iherman]

Defaults, especially in the open world, seem very risky. I actually think that HTML will be the most common, because most annotations will be created in HTML based environments, and people will want to add at least basic styling.

That may be true.

For literals, do you mean the literal body per http://www.w3.org/TR/annotation-model/#simple-textual-body ? That already has a requirement that the literal is xsd:string in the first bullet.

Yes. Hm. The problem comes, actually, from (surprise, surprise) Tim's examples on the multiple body issue. If you look at the example on the wiki, what was a plain string (ie, a simple textual body) is turned into an Embedded Content and it then has to have (well, SHOULD have) a format which was unnecessary in the simple case (and also the language but I believe that could be dropped anyway). Ie, it makes all this multi-body problem even more complex. That is what triggered my issue...

[azaroth42]

I'm starting to wonder about the \n escaping in JSON and how that plays out here...

👍 Starting a new issue for that

[azaroth42]

Dr Dr, it hurts when I use literal bodies...
... Don't do that then 😸

But regardless, "comment" can trivially be turned into {"value": "comment"} without expressing format or language. I'm sure there'll be a lot of bodies that have neither, nor any other property or relationship. As clients find the information valuable and will make decisions based on it, it believe it should be a SHOULD. Note that any other relationship could be added to a body as well, such as creator or subject or license or whatever else. We don't mention them in the model because (a) there's too many to discuss, (b) we'd be picking sides on things outside of our scope, and (c) clients are unlikely to make rendering decisions based on them.

[iherman]

So it boils down to the fact that Tim's transcription, though correct, is a little bit too complicated (sorry Tim)? If that is simply so, fine with me.