- From: Doug Schepers <schepers@w3.org>
- Date: Tue, 18 Aug 2015 15:22:06 -0400
- To: t-cole3@illinois.edu, 'Robert Sanderson' <azaroth42@gmail.com>
- Cc: 'Ivan Herman' <ivan@w3.org>, 'W3C Public Annotation List' <public-annotation@w3.org>
Hi, Tim–
On 8/18/15 2:59 PM, Timothy Cole wrote:
>
> [Some of this may be moot given the thread Doug started, but I wanted to
> close the loop (and had some computer issues last night).]
Yes, this topic has spawned many threads, and I'm as guilty of that as
anyone. It's making it hard to follow coherently, at least for me. :(
> Indeed, I had forgotten the non-body use of EmbeddedContent for the
> stylesheet and selector. (Would it be worthwhile creating a class and
> predicate name index for the model document?) These additional uses of
> EmbeddedContent Class do make attaching hasRole less desirable (though
> not out of the question). I also take your point that allowing hasRole
> only on the SpecificResource class simplifies the filter pattern for
> including proper default type:value via framing (so they don't have to
> be explicit in the JSON). So assuming the following patterns are what
> you have in mind, I concur:
>
> "body": {
> "role": "tagging" ,
> "source": "http://example.org/tagPlus1"
> }
>
> "body": {
> "role": "tagging" ,
> "source": { "value": "+1" }
> }
>
> Which look quite reasonable. The trade-off of not allowing hasRole on
> EmbeddedContent is that we'll need to explain / defend why the
> following, which will likely seem intuitive and natural to at least some
> JSON developers, is not considered equivalent:
>
> "body": {
> "role": "tagging" ,
> "value": "+1"
> }
Yes, thank you! This is what I've been trying to convey all along… if we
must require a more complex structure, then we need to explain why in a
way that's relevant to those JSON developers, not simply as a
justification for a technology that that is irrelevant to them.
Rob's notion of multiple-structure consistency is the best explanation
I've seen yet. But in most explanations, that's taken a backseat to all
the RDF requirements.
This is important because I expect that other implementors are likely to
extend the data model to add their own implementation-specific metadata,
and if they don't understand the structure of the data model, and why
the data model has that structure, they may produce content that breaks
that model.
On that point, maybe it might be worthwhile to include some advice in
the spec on how to extend the data model in a way that's consistent and
compatible.
> And of course regardless we will still need to explain / defend why the
> following is not considered equivalent:
>
> "body": {
> "role": "tagging" ,
> "id": "http://example.org/tagPlus1"
> }
>
> I think this can be done, but we should think about how best to do so.
I don't think it's likely that JSON folks would do that, but it's
possible, and I admit that I don't understand why that's not equivalent.
[…snipping the extra question…]
Regards–
–Doug
Received on Tuesday, 18 August 2015 19:22:10 UTC