Re: Connecting multiple fragment selectors with individual bodies

Hello again,

as now some time has gone by, I was able to ingest the discussions (in 
particular "hasContext", "selection filtering" and "textual node 
example" of the last couple of weeks, and think about their 
applicability to my use case. Summarising, I can identify two promising 
alternatives:

1) Using CompositeAnnotation
The advantage is, that it clearly composes what I want to compose, a set 
of sub annotations under the ceiling of one annotation.
Disadvantage: A lot of oa:annotations will have to be created in the 
model, which are some kind of "unwanted" and waisting somewhat the model.

2) A combination of multiple bodies and the hasContext property
If I understood right, hasContext is thought to be used in any Specific 
Resource. Thus, I could create a Specific Body Resource and use the 
hasContext property to assign that body to a Specific Target Resource 
(Saying, the body makes only sense if regarded within the scope of the 
given target resource). The ladder may include source and fragment 
selector selecting the XML-Document as source and an XPath for selecting 
XML elements within the source. Finally the content of my Specific Body 
Resource holds - besides the hasContext statement - the annotated value 
and comment related to the selected XML element.

If, furthermore oa:annotation may incorporate multiple bodies, I could 
create one Specific Body as described above, and connect them with the 
dedicated Specific Target Resource. I think, that would perfectly match 
my requirements and would also avoid to create a bunch of unnessary 
oa:annotation instances within the model:-)

What I did not really get from the discussions, if hasContext's use in 
SpecificResource is intended as an addition or an alternative to the 
other concepts (e.g. Selector) within a Specific Resource. If it is 
thought as an addition, hasContext could also be used within the 
Specific Target resource, to relate a specific body resource with that 
specific target including fragment selector. That would also be an 
adequate solution to my use case too!

Looking forward regarding the first release of an OA standard, I would 
very appreciate to see both concept in that upcoming release, because I 
think they are easy to understand and could perfectly solve any problems 
I had with my use case and OA.

best
Lutz







>
>
> On Tue, Aug 14, 2012 at 9:52 AM, Lutz Suhrbier <l.suhrbier@bgbm.org 
> <mailto:l.suhrbier@bgbm.org>> wrote:
>
>     sorry, but could you please give a hint where I could find some
>     more background information regarding all these concepts you are
>     discussing ?
>
>
> Grouping annotations has been discussed here and there, but never in 
> much detail.  Mostly because it hasn't been considered within our 
> remit to talk about how annotations are used, rather than how they're 
> specified.
>
>     What I understand, is that CompositeAnnotation and AnnotationSet
>     are concepts to relate multiple annotations, and that these
>     concepts are much more suitable than hasSemanticTag to link
>     together the annotation elements defined for my use case.
>
>
> Yes, exactly :)
>
>     But, what is bothering me is that I have to create a lot of
>     unnecessary annotation instances in the model. Moreover, most of
>     these instances will not represent annotations themselves, but
>     only dependencies (or may be better said attributes) of
>     annotations. Also, these attributes will never be intended to
>     become independent "annotations".
>
>
> The issue is one of definition of what an Annotation is. Annotations 
> in the OA model as it stands can only have one body, although can have 
> multiple targets.  So in the model, you just can't do what you want to 
> do directly.
>
>     What about my proposal to allow targets or at least target
>     specifiers having a hasBody property ?
>
>
> Unfortunately, due to the open world model for RDF, it would mean that 
> all of the bodies across multiple annotations would be inherited.  
> Every triple has to be true in all contexts, not just the current 
> document or in our case Annotation.
>
> This makes RDF rather verbose as it solves these issues by simply 
> adding in more nodes.
>
> Rob