Re: F2F Decision: Context

Hi all,

Putting the satisfaction upfront: I like the proposed pattern of asIncludedIn/annotatedIn in [1]. Applying this property to a wider range of resources gives a good motivation for it (I was a bit skeptical at the F2F).

Now of course this brings the case closer to dcterms:references, as Bob puts it [2]. I'm not so convinced either by asIncludedIn or annotatedIn. Would "scope" fit better? hasScope could draw a nice parallel hasSource.


There *may* (real question here!) also be a problem with relying on "asIncludedIn predicate has a domain of SpecificResource, as otherwise it would not be specific to the annotation." [3]
With the open world assumption, you can use asIncludedIn on any resource, and a reasoner would just infer that there must be an annotation somewhere for that resource.
Also, could there be that a same resource is body or target in two annotations, one for which the asIncludedIn statement is valid and the other not?
If one wants to make it really specific to a certain annotation, then it probably needs to be *directly* related to the annotation resource (for a statement, this could be made via a named graph or reification).

Cheers,

Antoine

[1] http://lists.w3.org/Archives/Public/public-openannotation/2012Oct/0030.html
[2] http://lists.w3.org/Archives/Public/public-openannotation/2012Oct/0032.html
[3] http://lists.w3.org/Archives/Public/public-openannotation/2012Oct/0036.html


> *** Annotating a Resource in Context ***
>
> The requirement was defined in two separate parts:
>
> 1. The resource was annotated when it was part of the rendering of
> another resource
> (but does not convey any notion of invalidation of the annotation)
>
> 2. The annotation is only valid when the annotated resource is part of
> the rendering of another resource
>
>
> The group consensus was that validity of annotations should not be
> considered in scope for the current work, as it would mean allowing
> all sorts of different types of validity to be expressed, not just
> containership.  The consensus was also that "context" should be
> narrowly defined as above, to ensure that all sorts of other
> environmental factors that might occur were not included in the scope.
>   Thus the operating system of the annotator is not "context" for this
> part of the data model.
>
> Use cases discussed included:
>
> * Annotating an image in a page to say that it does not depict what
> the page describes
> * Annotating (part of) an image in a certain part of a page to say
> that it is not the correct image for that location
> (example: page with bio sketches, and one image is mistakenly used for
> multiple people)
> * Annotating a figure with a URI that is part of an academic paper,
> where the context of the particular paper is important
>
> The decision was to introduce a new predicate: oax:annotatedIn from a
> SpecificResource to any Resource (including a SpecificResource)
>
> Other options explored were:
> * Lists/chains of Selectors, however the semantics weren't clear as to
> whether it was a contextual selector or a regular use and was
> particularly challenging when the context was part of a resource
> rather than the entire resource.
> * Whether or not the context was at the SpecificResource or Annotation
> level.  If it was at the Annotation level, then a Body could not have
> a context and this was considered desirable. Also multiple targets
> would be very difficult to model.
>
>
> The name is the only contentious aspect remaining, as it implies that
> it can only be used for a target of the annotation.  We would like to
> suggest the following revision:
>
> oax:asIncludedIn  (domain oa:SpecificResource)  The object of the
> predicate is a resource in which the subject is included, and was the
> resource being viewed when the subject was used within the annotation
> which has the subject as either body or target.
>
> Other proposed names for the predicate will definitely be considered,
> but should not use "context" and should convey the notion of inclusion
> by reference (eg html) or value (eg pdf)
>
> Thanks,
>
> Rob&  Paolo
>

Received on Thursday, 1 November 2012 09:37:15 UTC