Re: Problems with the new beta spec

Hi Stian,
the plan is to collect the examples in the Cookbook - on the wiki - and
splitting them into those that can be encoded with the current specs and
those that cannot be. The latter are the new use cases that can be used to
challenge the model.

However, we understand some concrete example would help clarifying the
specs. There are several ways of doing that, Rob and I are trying to find a
good solution that would not imply changing the spec document often.

Best,
Paolo

On Thu, May 10, 2012 at 6:35 AM, Stian Soiland-Reyes <
soiland-reyes@cs.manchester.ac.uk> wrote:

> 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
>



-- 
Dr. Paolo Ciccarese
http://www.paolociccarese.info/
Biomedical Informatics Research & Development
Instructor of Neurology at Harvard Medical School
Assistant in Neuroscience at Mass General Hospital
+1-857-366-1524 (mobile)   +1-617-768-8744 (office)

CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s),
may contain information that is considered
to be sensitive or confidential and may not be forwarded or disclosed to
any other party without the permission of the sender.
If you have received this message in error, please notify the sender
immediately.