Re: Selection Filtering

Yes, I see the (significant) advantages of the hasContext approach,
both for intuitive-ness and ease of processing.  Perhaps we do just
need both ways.

A topic for next week's call?

Rob

On Thu, Aug 9, 2012 at 4:20 PM, Paolo Ciccarese
<paolo.ciccarese@gmail.com> wrote:
> Maybe we just need both ways?
>
> In your specific example I feel your first proposal makes more sense.
> The zip file is the resource and the XHTML files are parts of it and they
> don't seem having autonomous life.
> If they do they would probably get a URI?
>
> But for classic HTML pages where Images have a URI I would go the other way.
>
> (still brainstorming)
>
>
>
> On Thu, Aug 9, 2012 at 6:13 PM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
>>
>> Does the hasContext approach (eg climbing up rather than drilling
>> down) deal with situations when there's really embedded content, or
>> only resources that are referenced but have their own unique URIs?
>>
>> For example, the use case I have in mind is an ePub document
>> (basically a zip file that contains HTML and related content) that has
>> a URI, but the chapter xhtml files within it do not.  And similarly
>> the images referenced from those chapters don't have their own URIs,
>> they're just named bitstreams within the zip.
>>
>> I don't immediately see it, if it does.  And if not, how would we go
>> about providing a solution for the use case?
>>
>> Rob
>>
>>
>> On Thu, Aug 9, 2012 at 4:09 PM, Paolo Ciccarese
>> <paolo.ciccarese@gmail.com> wrote:
>> > I am dealing with the same use case exactly now.
>> > I like Rob's first solution but I agree the image is buried in the
>> > selector.
>> > The oa:hasSelector {FileSel1,ImgSel1,Svg1} does not communicate the
>> > message
>> > clearly.
>> >
>> > I would pick Jim's solution as it is simple and in line with the
>> > discussions
>> > we had in the last weeks. Christian Morbidoni was suggesting a similar
>> > approach in a previous email exchange:
>> >
>> > http://lists.w3.org/Archives/Public/public-openannotation/2012Jul/0038.html
>> >
>> > However, I am not sure if, with that, you can distinguish in between the
>> > fact that the image has been simply annotated within a context and the
>> > fact
>> > that the annotation makes sense only within that context. In the first
>> > case,
>> > ignoring the context is probably fine. In the second case, it is
>> > probably
>> > not. Probably adding a subproperty could be enough but I was wondering
>> > if
>> > that approach has the potential of scaling to more complex filtering
>> > criteria.
>> >
>> > Paolo
>> >
>> >
>> > On Thu, Aug 9, 2012 at 5:29 PM, James Smith <jgsmith@gmail.com> wrote:
>> >>
>> >> I've been thinking about how to bite, assuming I'm thinking about the
>> >> same
>> >> problem. I've been considering how to specify that a particular
>> >> annotation
>> >> is about a resource when that resource is considered in the context of
>> >> another resource.
>> >>
>> >> This can be done with an additional selector-like property:
>> >> oax:hasContext. This could have the same target as oa:hasTarget, so
>> >> anything
>> >> that can be a target can be a context.
>> >>
>> >> For example, if I wanted to annotate an image as it is embedded in an
>> >> html
>> >> document, I could have the following triples:
>> >>
>> >> Anno1 a oa:Annotation ;
>> >>   oa:hasTarget Spec1 .
>> >> Spec1 a oa:SpecificResource ;
>> >>   oa:hasSource IMG ;
>> >>   oax:hasContext Sel1 .
>> >> Sel1 a oa:SpecificResource ;
>> >>   oa:hasSource HTML .
>> >>
>> >> I'm not sure how to interpret the oa:hasSelector
>> >> {FileSel1,ImgSel1,Svg1}
>> >> pieces of the second example to know how to transform them into a
>> >> similar
>> >> form as above.
>> >>
>> >> I like this form because I can ignore the oax:hasContext piece and
>> >> still
>> >> have a good chance at getting the annotation in the right place. For
>> >> example, if I am annotating a video embedded on a particular page, all
>> >> I
>> >> have to add is the oax:hasContext piece to state that it is in the
>> >> context
>> >> of that resource, instead of annotating that resource and hoping I can
>> >> select the video within that resource (and hope that such a selection
>> >> doesn't have to change due to edits in the embedding document).
>> >>
>> >> -- Jim
>> >>
>> >>
>> >> On Aug 9, 2012, at 4:56 PM, Robert Sanderson <azaroth42@gmail.com>
>> >> wrote:
>> >>
>> >> > No one seems to be biting, so I'll throw out a proposal for a
>> >> > solution
>> >> > (maybe)  :)
>> >> >
>> >> > Instead of considering the annotation to be on the lowest level
>> >> > object
>> >> > and then climbing back up the hierarchy (annotate the image, in the
>> >> > html) instead we can use the regular structure of annotating the
>> >> > highest level resource and drilling down with Selectors to the most
>> >> > appropriate part (annotate the html, select the image).
>> >> >
>> >> > This would work in all of the cases described, and often with just
>> >> > FragmentSelector.
>> >> > eg:
>> >> >
>> >> > Anno1 a oa:Annotation ;
>> >> >    oa:hasTarget Spec1 .
>> >> > Spec1 a oa:SpecificResource ;
>> >> >    oa:hasSource HTML ;
>> >> >    oa:hasSelector Sel1 .
>> >> > Sel1 a oa:FragmentSelector ;     // oax:XpointerFragmentSelector ?
>> >> >    rdf:value "xpointer(/xpath/to/img[@href="Img1"])" .
>> >> >
>> >> > Anno2 a oa:Annotation ;
>> >> >    oa:hasTarget Spec2 .
>> >> > Spec2 a oa:SpecificResource ;
>> >> >    oa:hasSource ePub1 ;
>> >> >    oa:hasSelector CompSel1 .
>> >> > CompSel1 a oa:CompositeSelector ;
>> >> >    oa:hasSelector FileSel1 ;    //  select xhtml file in zip
>> >> >    oa:hasSelector ImgSel1 ;    //  select image in xhtml
>> >> >    oa:hasSelector Svg1 .         //  select SVG area of image
>> >> > (...)
>> >> >
>> >> >
>> >> > The main issue is that the URI of the component resource (eg the
>> >> > image) is not easily accessible, if it has one.  In the ePub case, it
>> >> > doesn't have its own HTTP URI, but in the regular web page it does.
>> >> >
>> >> > Thoughts?
>> >> >
>> >> > Rob
>> >> >
>> >> >
>> >> > On Wed, Aug 1, 2012 at 4:09 PM, Robert Sanderson
>> >> > <azaroth42@gmail.com>
>> >> > wrote:
>> >> >> Starting a new thread on this topic for ease of tracking :)
>> >> >>
>> >> >> In other a couple of other threads, the desire to describe an
>> >> >> annotation which targets a resource in some particular context was
>> >> >> expressed.
>> >> >> For example, to annotate an image only as it appears in a particular
>> >> >> html page.
>> >> >>
>> >> >> The base requirement seems to me to be:
>> >> >>    Annotate [part of] (resource) as it is used in (resource)
>> >> >>
>> >> >> This extends quickly to:
>> >> >>    Annotate [part of] (resource) as it is used in [part of]
>> >> >> (resource)
>> >> >> For example, annotate an image as it is used on page 4 of a PDF.
>> >> >>
>> >> >> This could mean arbitrary nesting, to allow for annotating an image
>> >> >> in
>> >> >> an html file in an ePub document.
>> >> >> The same should be applicable for bodies as well as targets, in
>> >> >> order
>> >> >> to extract contents from container resources.
>> >> >>
>> >> >> Is there a requirement for differentiating between the resource, and
>> >> >> the resource used in some container resource?
>> >> >> For example, is it important to be able to annotate an image, but
>> >> >> not
>> >> >> have the annotation appear when that image is embedded within an
>> >> >> HTML
>> >> >> page?
>> >> >> For annotating non-rendering resources (such as CSS, Javascript etc)
>> >> >> it might be important?
>> >> >>
>> >> >> Is there a requirement for sets of container resources, or is it
>> >> >> sufficient to simply create new annotations? For example, this image
>> >> >> in these 3 HTML pages.
>> >> >>
>> >> >>
>> >> >> A second application of filtering, that makes me very nervous, is:
>> >> >>    Annotate all occurrences of (selection) in (set of resources)
>> >> >>
>> >> >> For example all occurrences of the word "annotate" in any textual
>> >> >> resource, all occurrences of the top left pixel in JPEG images, all
>> >> >> occurrences of the first line of text in all copies of Shakespeare's
>> >> >> "Hamlet".
>> >> >>
>> >> >>
>> >> >> Before we start thinking about approaches and solutions, it would be
>> >> >> great to firmly scope what it is that we're trying to solve :)
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> Rob
>> >> >
>> >>
>> >>
>> >
>
>
>
>
> --
> 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.
>

Received on Thursday, 9 August 2012 22:47:12 UTC