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

Re: Connecting multiple fragment selectors with individual bodies

From: Lutz Suhrbier <l.suhrbier@bgbm.org>
Date: Thu, 09 Aug 2012 16:18:34 +0200
Message-ID: <5023C6BA.7020203@bgbm.org>
To: Robert Sanderson <azaroth42@gmail.com>
CC: public-openannotation@w3.org
Hi Rob,
> Hi Lutz,
> Is there a reason why you want to have all of this information as one
> annotation, rather than simply splitting it up into multiple
> annotations?  That would seem the easiest route.
Yes, because they belong together. In our use case, we have domain 
specific XML documents, which shall be annotated under some predefined 
topics, which may include multiple elements within a dedicated XML 
document. For example, a more general topic would be the correction of 
geographic locations, which may include longitude, latitude, country, 
city, region, timezone etc.. In that case, it makes no sense to have 5 
non-related annotations for that kind of annotations, because the 
annotation is only valuable, if all of the related elements can be 
expressed within a single annotation !

Any of these elements can be identified by XPath expressions related to 
the XML document. But, to each of these XPath expressions, a different 
value must be assignable since longitude value is different from 
latitude value, e.g. With the current OA version, using fragment 
selectors it is possible to create a "list" of XPath expressions, which 
permits to capture any annotated XML elements within a single 
annotation. But, due to the restriction to max. one body per annotation, 
it is not possible to relate the new (annotated)XML element values with 
their corresponding fragment selectors.

That was my problem using OA, and I think, several other applications 
dealing with annotations of XML documents will have the same problem ?

> The model only allows one Body currently for exactly this reason; that
> people would simply put all of the bodies and all of the targets in
> one big blob of uninterpretable RDF, even though some Bodies relate
> only to some of the Targets.  It also shows the danger of workarounds
> like hasSemanticTag which side step this issue.
In order to solve my dilemma, I followed your former idea splitting up 
that one annotation into multiple annotations and grouping them by using 
hasSemanticTag as a clamp (as described in my former posting)

I also thought about inventing my own referencing schema for the body, 
so that I can identify what value belongs to which fragment selector. 
But, from my perspective, that could not be regarded as OA standard 
conform implementation.

Anyway, as OA is an upcoming standard and I also guess that I am not the 
only one aiming to use OA in similar scenarios, I brought it up to the 
mailing list proposing my approach.

I still think that moving annotation bodies to target (selector) bodies 
would not prevent others from using bodies as a big RDF blob. But I 
think it would wide up use cases directly supported by the standard and 
would perfectly solve my problem.

May be, there are other or better standard conform approaches out there 
supporting my use case perfectly?

Finally, I hope any of them will melt into the final standard.


> Rob
> On Wed, Aug 8, 2012 at 7:53 AM, Lutz Suhrbier <l.suhrbier@bgbm.org> wrote:
>> Hi,
>> I am currently trying to adopt OA to an application scenario, which I
>> actually didn't found described here.
>> The plan is to annotate XML documents in a way that the annotation relates
>> one or more XML element values(let's call them subannotations), which can be
>> given a domain specific annotation type.
>> As the target selection of subannotations(XML Elements) can be realised by
>> the usage of multiple specific targets in combination with fragment
>> selectors, there is no obvious and standard conform way of assigning
>> individual annotated values(bodies) to the selected targets.
>> Currently, I implemented a workaround by applicating the oax:hasSemanticTag
>> predicate to each subannotation "pointing" at an embracing "meta"
>> annotation.
>> Even though that workaround appears to be doing its job, I am wondering
>> 1) if that is the intended way of using hasSemanticTag ?
>> 2) if there is no other standard conform method reflecting that scenario
>> which can actually reflect those requirements ?
>> With regard to a potential approach to be integrated within the standard,
>> simply allowing multiple targets and multiple bodies does not appear to
>> solve that question adequately, as the relationship between the specific
>> target and the body (subannotation) would not be reflected. As the crucial
>> point is the relationship between target and body, a target predicate like
>> "hasBody" would be a better approach, at least from my perspective. One may
>> even think about moving the "hasBody" predicate from oa:annotation to
>> oa:target, as I see no relevant application of having annotations just
>> consisting of a body without any target ?
>> Anyway, doing so should not hinder any otherwise possible logical
>> construction of annotations, or does it ? Also, it does not preclude
>> annotations having targets pointing at the same body, nor does it preclude
>> targets having multiple bodies if the discussion shows that this is somewhat
>> useful.
>> I have to mention, that this is my first project using RDF or OA, so may be
>> I am in some topic completely misleaded. But I would appreciate if my point
>> could be somehow discussed and reflected in an upcoming release of the
>> standard.
>> best regards
>> Lutz Suhrbier
Received on Thursday, 9 August 2012 14:19:07 UTC

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