Re: New Draft comments: Specific Resources

Hi Rob,

OK!

On the abstractness of the examples: I can live with the choice that you've explained to me already a couple of weeks. I may ask to re-consider it as a whole, when the "Primer/tutorial" comes out and fulfills the need (or not). But it is not my point right now. It's more about not keeping to a strict approach to whatever option your generally pursue. Even if trying to be abstract in general, for some specific cases it may still be good to be flexible and not stick to abstract labels/identifiers. Which is why I'm flagging such specific cases in my reviews.

Cheers,

Antoine



>>> __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.
>
> Rob

Received on Saturday, 26 January 2013 14:04:32 UTC