Re: New Draft comments: textual bodies

I'm personally okay with what Jacco suggests, the most notable change is
explicitly allowing blank nodes.

It also works nicely with the JSON-LD serialization:

{
  "@id" : "Anno1",
  "target" : {"@id" : "Target1"},
  "body" : {"chars" : "content1"}
}

Would the format argument help if it had a real world use case, notably
that systems will assuredly put in both HTML and plain text into the body
string in annotations, and a client would not know which without the
dc:format property, and thus not know how to render the string?

Rob


On Sun, Jan 6, 2013 at 2:36 PM, Jacco van Ossenbruggen <
Jacco.van.Ossenbruggen@cwi.nl> wrote:

>
> On Jan 6, 2013, at 10:00 PM, Bob Morris <morris.bob@gmail.com> wrote:
>
> > If I am not mistaken, OWL DL, at least, requires
>
> Ah... OWL DL.  I  already suspected there were other arguments than those
> listed in the current spec :-)
>
> To be frank, these limitations of OWL DL and the mess with dc:creator
> ranges _would_ be arguments that would convince me.
>
> So what about the following line of reasoning:
>
> 1. Acknowledge that both approaches have there merits (remove the current
> arguments that suggest one would be better than the other)
> 2. Mention that allowing both on the same property could be confusing, and
> that in standards such as OWL DL, properties with both literal and object
> ranges are highly undesirable
> 3. That for simplicity sake we thus allow only object bodies
> 4  allowing bnode objects for those who do not need bodies with identity
> (see Antoine's arguments)
> 4. Give an example that is really only one extra triple, not the four
> extra triples I count in the current spec:
>
> <Anno1> a oa:Annotation ;
>     oa:hasTarget <Target1> ;
>     oa:hasBody [ cnt:chars "content1" ] .
>
> Would that be something?
>
> Jacco
>