Re: Problems with the new beta spec

I think I agree with Sebastian that some concrete examples would do.
It does not have to be real, like the annotated resources actually
existing, just that it's understandable.


In the W3C Provenance working group, we just published the drafts
http://www.w3.org/TR/prov-o/ and  many of the examples are real-world
concrete. For instance:

:bar_chart
   a prov:Entity ;
   prov:wasGeneratedBy :illustrating .

:illustrating a prov:Activity .

or

:filling-petrol
   a prov:Activity;
   prov:wasInformedBy :low-fuel-flashing;
   prov:qualifiedCommunication [
      a prov:Communication;
      prov:activity :low-fuel-flashing;
      rdfs:comment "Don't like flashing warning lights";
   ];
.


A Primer would also be a good place for examples - but I feel the Open
Annotation specification is currently pretty good and don't really
need a primer perhaps to be able to show examples of the Extensions
and Core together.



Making such examples, and making them concise enough to get the right
point across, do require a lot of time, but also challenges the model
and forces you to think twice, for instance "Hey, should we really use
two targets here?".

I agree that for now we should build the cookbook examples, and then
possibly try to rework some of them into the specification at a later
stage, rather than filling the specification now with examples that
would be too verbose or confusing.



On Thu, May 10, 2012 at 12:28 AM, Robert Sanderson <azaroth42@gmail.com> wrote:
> Sebastian, Paolo,
>
> One of the reasons for having a very abstract set of examples was to
> not require the specification to be updated every time a new example
> was created.  I do strongly believe that this is important to
> maintain, as should the work become a W3C recommendation at some point
> (which is not at all certain, but certainly hoped for!) then we would
> no longer have the ease of access we do now to update it.
>
> One solution would be to have a static link for each section to a
> table of contents document for examples.  Then the ToC document could
> be updated without touching the main specification.
>
> However, I think it would be nice to have the W3C folk on the list
> weigh in on this particular issue as they must face it for every new
> specification, and we should do whatever they recommend.
>
> I have posted two sets of slides online:
>
> http://www.slideshare.net/azaroth42/open-annotation-overview
> http://www.slideshare.net/azaroth42/open-annotation-niso-digital-bookmarking
>
> Which each walk through the model with a specific example.  Is this
> the sort of thing that you were looking for, Sebastian?  (I am not
> proposing using either of these directly)
>
>
>>>>> 2. Can there be more than one body per annotation?  Why do you need the
>>>>> Annotation node then? You would have to create an extra URI without a
>>>>> reason.
>
> One additional note beyond Paolo's explanation: we see an Annotation
> as a sort of reification of the relationship between body and target.
> It is not exactly this, as there may be no body, and there may be
> multiple targets for a single annotation.  But the creator of the
> relationship/annotation can be different from either the creator of
> the body resource or any of the target resources, and thus it deserves
> its own URI.
> For example I can create an annotation that links a youtube video
> (that I didn't create) to an image (which I also didn't create).  This
> is the case in the second slideset above.
>
> It also follows practically all existing work on annotation; to not
> have an identifier for the annotation itself would require a lot of
> explanation :)
>
>
>>>>> 3. The arguments against URI Fragments are very confusing, and I am not
>>>>> sure what is meant exactly.  e.g.
>
>>> Querying with SPARQL  is more or less the only use case, where URIs using
>>> fragments are not ideal. I wonder why you would not recommend them, however.
>>> They are useful for many other use cases. Is SPARQL the main reason for the
>>> open annotation movement?
>
> The other major consideration is the global uniqueness of identifiers,
> and what it means to attach properties to them.
>
> For example, if we used Fragment URIs to express a rectangular area of
> an image, and then associated more information with that Fragment URI,
> then everyone who subsequently used that same Fragment URI would gain
> that additional information in their annotations.  This could be very
> strange, especially for annotation-specific information such as
> styling hints.
>
> Secondly, we need to have methods beyond fragments to identify
> arbitrary segments of any resource type.  For example, in the
> Extensions document we define two text Selectors and an area Selector
> that uses SVG.  Given that we need Selectors anyway, it was more
> efficient to recommend always using them, thus reducing the problem of
> choice (fragment vs selector) for how to do things and many checks in
> consuming application code as to which choice was made.
>
> Finally, as Paolo said, we are working on updating the spec for the
> licence to follow the W3C community group requirements, but thanks
> indeed for pointing it out -- the CC licence was a hold-over from the
> OAC template that we started from rather than put there intentionally.
>
> I hope that helps,
>
> Rob
>



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Thursday, 10 May 2012 10:36:12 UTC