W3C home > Mailing lists > Public > public-openannotation@w3.org > January 2013

Re: New Draft comments: Specific Resources

From: Robert Sanderson <azaroth42@gmail.com>
Date: Fri, 25 Jan 2013 10:41:03 -0700
Message-ID: <CABevsUEXowOgH0K140SO91H9zEBobByyn7sDEa6qyBBE5QV_rg@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-openannotation <public-openannotation@w3.org>
>> __Classes__
>> The Specific Resource class isn't *essential* as a client can always
>> check for the existence of oa:hasSource.  On the other hand, it does
>> make the annotation easier to process.  I don't see any harm in having
>> it.

> Yes, I don't see any harm either. It would be good though to reflect what
> you're telling in the first paragraph. Especially if, as I noted, some
> examples in the document (Fig. 3.2.) don't use the classes.
> The alternative is that the example use the classes.

Yes, I'll add the classes and explicitly note that they're not used directly.

>> __target1 vs source1__
>> Yes. However the dashed boundary lines would be even more important in
>> that case.  The reason that we called it target1 is that it's the same
>> resource as previously called target1, just in a different position in
>> the graph.
> Yes, I understand the concern to keep the same identifiers for the same
> resource. But here the resource is not the target anymore, so this is
> *really* confusing.

Yep, fixed.

> Note that switching to more "real" examples (as suggested hinted a couple of
> times) may alleviate this kind of issue.

We've tried to add real examples in the text, while keeping the
diagrams abstract.  The issues with real worked examples are, as far
as I can tell:
* Being specific helps someone who is already thinking about that
particular use case, but hinders people who aren't.  Hopefully the
framework will cover many situations, and hence we feel that abstract
with motivation is preferable.
* The danger, from the previous point, is that only the use case that
is used for the examples is implemented and people with other use
cases go elsewhere.
* Lots of different examples would be confusing, but using a single
example that builds up from section to section would reinforce the
above points.

Hence we feel that a more abstract specification, plus a single worked
example as a tutorial, and a cookbook in a wiki that many people can
contribute to fills all of the requirements for different audiences:

* Developers with a single issue can try to find it first in the
cookbook and just copy it
* People who just want to learn can start with the tutorial
* People who want to work with the ontology and understand how the
model works can go to the specification

To reuse a previous example, no one learns CSS from reading the specs
first. Or HTML. Or practically any such standard.  At least no one
that I know :)   The tutorial should fill this sort of information
need, but of course the spec has to come first so we know what should
go into the documentation for the worked example :)

>> __Overlap__
>> Another overlap would be for rectangular regions that could be
>> described either using the Media Fragments or using<svg:rect>.

> Fair enough; I had not asked the issue to be fixed ;-)

:)  Sorry. I have the "if exists(problem) then require(solution)" tendency!

> Would you fancy a little acknowledgement in the text?

Absolutely. Will put this in today.

Received on Friday, 25 January 2013 17:41:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:21 UTC