W3C home > Mailing lists > Public > public-openannotation@w3.org > November 2012

Re: F2F Decision: Context

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Thu, 1 Nov 2012 20:00:24 +0100
Message-ID: <5092C6C8.1090708@few.vu.nl>
To: Robert Sanderson <azaroth42@gmail.com>
CC: public-openannotation <public-openannotation@w3.org>
Hi Rob,

> On Thu, Nov 1, 2012 at 3:36 AM, Antoine Isaac <aisaac@few.vu.nl <mailto:aisaac@few.vu.nl>> wrote:
>     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.
> I'm fine with hasScope. It's certainly better than context.
>     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.
> I'm not sure that I follow. With a domain of oa:SpecificResource, a reasoner would conclude that the subject of the x hasScope y triple is a SpecificResource. Which is likely part of an Annotation, but not necessarily (though would be outside our scope of work if it wasn't).

Yep. And I think you've followed!

>     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?
> That's why we need the Specific Resource. If (to cross threads) there was just a Media Fragment, then that wouldn't work as the fragment URI could be used in other annotations when the hasScope wasn't appropriate. If the Specific Resource was reused in a different annotation, it would have all of the triples including hasScope. If not all of them were true for the new annotation, then you'd need to mint a new Specific Resource, in the same way as if a State or Selector wasn't appropriate.

That makes much sense.
But I wouldn't tie it in too much to the discussion on Media Fragments. It can happen with any resource...
There should just be a note next to hasScope that this is a highly context-dependent property, and its use is likely to be counter-productive if its subject resource appears in multiple annotations.

>     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).
> But in turn wouldn't work for multiple resources as you couldn't tell which resource was the actual subject of the hasScope.

the pattern I'd propose is to have the *graph* being the subject of hasScope. As in the following

<aWrongPictureAnnotation> oa:hasBody <wrongPictureBody> .
G1 { <aWrongPictureAnnotation> oa:hasTarget <aPicture> .}

<aRightPictureAnnotation> oa:hasBody <rightPictureBody> .
G2 { <aRightPictureAnnotation> oa:hasTarget <aPicture> .}

G1 oa:hasScope <pageWithWrongPicture> .
G2 oa:hasScope <pageWithRightPicture> .

It is complex, but I'd argue it fits well the intention: it is the statement that links an annotation to a target (or a body), which is "scoped" by another resource. It's not an a specific attribute of the target (or body).

In fact (my turn to cross-thread) attaching the scope statement onto the target or body only seems like accepting the narrow corset of a simple data model like RDF without named graphs -- and I'm not the kind of guy who would do that ;-)

Received on Thursday, 1 November 2012 19:00:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:02 UTC