- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Thu, 1 Nov 2012 20:00:24 +0100
- 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 ;-) Antoine
Received on Thursday, 1 November 2012 19:00:59 UTC