Re: Connecting multiple fragment selectors with individual bodies

Dear Lutz,
in order to collect use cases challenging the single body restriction,
would it be possible for you to send a concrete example (maybe in n3) of
how you are currently modeling the annotation?

At first glance it seems the way you use of oax: hasSemanticTag is very far
from what the relationship has been created for. But again, I'd rather see
a concrete example before digging into it.

Also, when you refer to multiple targets, are these considered as a whole
(ALL), as alternative (ANY) or it does not matter?

Best regards,
Paolo

On Thu, Aug 9, 2012 at 10:18 AM, Lutz Suhrbier <l.suhrbier@bgbm.org> wrote:

> 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.
>
> Lutz
>
>
>
>
>
>> 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
>>>
>>>
>>>
>>>
>
>