Re: Update: OAC Annotation model

15 views
Skip to first unread message

Bernhard Haslhofer

unread,
Jan 18, 2010, 8:12:44 AM1/18/10
to Antoine Isaac, oac-d...@googlegroups.com
Hi Antoine,

thanks for your feedback. I am forwarding your mail (and my comments) also to the OAC discussion group in order to share these thoughts...and maybe kick off some discussions in our hyperactive group :-)

On Jan 15, 2010, at 9:31 AM, Antoine Isaac wrote:

> Hi Bernhard (cc Herbert, in case he'd be interested)
>
> Thanks for the OAC pointer [1]. That's really interesting!
>
> I should not comment on it, because I have many other things to do (and in fact I couldn't post anything on the hyperactive google group, as I can't possibly handle the answers that would be given to my questions there ;-)
>
> But if you go for using the OAC in EConnect, here are the comments that popped out in my mind, in a rather raw form.
>

At the moment we are using the LEMO model for Annotations in Europeana, which works fine for the moment, but has some limitations...like the dc:format issue or the fact that annotations with complex content (e.g., a word document annotating a video region) can only be modeled by introducing a LEMO extension (annotation profile).

If we implement the OAC model in the Europeana Annotation component we could also bridge the structural and conceptual gaps to the EDM, because an OAC Annotation can be regarded as a specialization of an ore:Aggregation.

So your comments are extremely valuable, thx.


> - is the use of URNs strongly recommended for text annotations? As said, it's not resolvable. Plus, URNs are not as lightweight to handle as HTTP URIs, aren't they?


Agree. From a linked data perspective having URIs for the source resources definitely makes sense. In my opinion we should apply HTTP URIs wherever possible. We can always keep URNs as secondary identifiers, if they are available. This makes it easier to link annotations and constituents with each other...

>
> - is there a strong motivation for having oac:Transcription in the model? I get the use case, but I'm wondering whether this really fits the core of annotation functions. If OAC includes many more like this, it may become difficult to understand!

As far as I remember from our meeting in October this reflects the idea of Resource Maps in OAI-ORE, so these are the pointers to the various serializations of an annotation. In Linked Data you wouldn't explicitly include such pointers in the data model but leave it to the transport protocol to return the pointers to the requested serialization (usually via HTTP 303). So I agree that we should rethink that...

I think it makes sense to define the OAC model on an abstract level without implementation details. A concrete linked data / RDF implementation would then do pretty well without the oac:Transcription property.

>
> - I find the handling of segments a bit cumbersome. In fact I'd say that in case of annotating the fragment, the "target" should rather be the fragment, and the "context" the whole document. First, intuitively the "document" fits more the idea of "context" for the fragment, and thus for the annotation on it. Second, if we use the hasTarget property to refer to the "object of the annotation" (the object of the "implicit P1" in the OAC graphs) in one scenario, I'd expect to use the same property for other cases, even if the "object of the annotation" is a fragment.

That's of course a matter of interpretation. In Annotea the context is defined as "The context within the resource named in 'annotates' to which the Annotation most directly applies." So from this perspective, if we try to "reuse" the notions used in Annotea, having an oac:Context makes sense.

But you're right, for people who are not aware of Annotea, this might be confusing. I'll put it on the "open issues" list...

>
> I know this may raise problems for query/retrieving scenarios: in order to find annotations "on" a document, you'd have to query for both oac:hasTarget and oac:hasTargetContext (and make a union of the results for each property). But well, I still find the proposed solution slightly counter-intuitive.

hmm..why? If you know the URI of the annotated document you could issue a SPARQL (or whatever) query on the triple pattern (?x oac:hasTarget <http://bla/mydoc>) and get the identifiers of all annotations on this document. This presumes that the object of the oac:hasTarget property is a URI without any fragment identification information.


>
> Note that this comment is in a way valid for your own LEMO model. Even though the naming there make things easier to swallow there: your (and Annotea's) "annotates" could still be said to be hold for a more general resource that carries the direct target of annotation, while I'd expect "hasTarget" to be the most precise information.


yes. I agree...we must re-think the naming again and provide precise definitions...


Thanks again,

Bernhard

>
> I'm never afraid of issuing stupid comments, so feel free to forward that to any discussion group you see fit. Which I already started to do by ccing Herbert, in fact ;-)
>
> Cheers,
>
> Antoine
>
> [1] http://www.openannotation.org/documents/OAC-Model_UseCases-alpha.pdf
>
>

______________________________________________________
Research Group Multimedia Information Systems
Department of Distributed and Multimedia Systems
Faculty of Computer Science
University of Vienna

Postal Address: Liebiggasse 4/3-4, 1010 Vienna, Austria
Phone: +43 1 42 77 39635 Fax: +43 1 4277 39649
E-Mail: bernhard....@univie.ac.at
WWW: http://www.cs.univie.ac.at/bernhard.haslhofer

Robert Sanderson

unread,
Jan 18, 2010, 10:44:36 AM1/18/10
to oac-d...@googlegroups.com
Hi Antoine, Bernhard.

Great to get some discussion going on the list :)

My responses inlined below (some bits cut for length).

On Mon, Jan 18, 2010 at 6:12 AM, Bernhard Haslhofer
<bernhard....@univie.ac.at> wrote:
> thanks for your feedback. I am forwarding your mail (and my comments) also to the OAC discussion group in order to share these thoughts...and maybe kick off some discussions in our hyperactive group :-)

[snip]


>
> If we implement the OAC model in the Europeana Annotation component we could also bridge the structural and conceptual gaps to the EDM, because an OAC Annotation can be regarded as a specialization of an ore:Aggregation.


This is something which we reconsidered after the meeting in Berkeley.
The problem is that the two models don't converge when it comes to
proxies. There can only be one proxy per tuple of (aggregation,
aggregated resource), which would map to (annotation, target/content)
... and we definitely want to allow for more than one target segment
with the same base URI.
This also goes towards Antoine's comments below about Context being
the target, not the parent resource -- if the context were the target,
we would have more of an alignment with ORE ... but that has problems
as well (see below).


> So your comments are extremely valuable, thx.

Very much so!

>> - is the use of URNs strongly recommended for text annotations? As said, it's not resolvable. Plus, URNs are not as lightweight to handle as HTTP URIs, aren't they?
>
> Agree. From a linked data perspective having URIs for the source resources definitely makes sense. In my opinion we should apply HTTP URIs wherever possible. We can always keep URNs as secondary identifiers, if they are available. This makes it easier to link annotations and constituents with each other...

Agreed as well! We would recommend always using HTTP URIs, especially
as there are many many services out there that will give you one for
some text (twitter for short comments, google docs, scribd, blogs, etc
etc). However to not cover this in the model at all would be shooting
ourselves in the foot as 99% of existing annotation clients do not
treat the content as a resource in its own right. There needs to be a
clear migration path towards the "correct" behaviour for them to
follow, and URNs are a great deal better (IMO) than blank nodes as
they allow for deduplication.


>> - is there a strong motivation for having oac:Transcription in the model? I get the use case, but I'm wondering whether this really fits the core of annotation functions. If OAC includes many more like this, it may become difficult to understand!
>
> As far as I remember from our meeting in October this reflects the idea of Resource Maps in OAI-ORE, so these are the pointers to the various serializations of an annotation. In Linked Data you wouldn't explicitly include such pointers in the data model but leave it to the transport protocol to return the pointers to the requested serialization (usually via HTTP 303). So I agree that we should rethink that...
>
> I think it makes sense to define the OAC model on an abstract level without implementation details. A concrete linked data / RDF implementation would then do pretty well without the oac:Transcription property.

There are two main reasons for including the Resource
Map/Transcription in the data model:

1. If it's not there, you can't have metadata about it. We very much
want to know who created the transcription, when and what usage rights
it has.

2. The links in the transcription to other transcriptions are great
for discovery. Especially if they're not available via 303 for
various reasons -- for example there might be multiple serializations
all with the same mimetype, such as the various ways of formulating
rdf/xml or rdf in json.


>> - I find the handling of segments a bit cumbersome. In fact I'd say that in case of annotating the fragment, the "target" should rather be the fragment, and the "context" the whole document. First, intuitively the "document" fits more the idea of "context" for the fragment, and thus for the annotation on it. Second, if we use the hasTarget property to refer to the "object of the annotation" (the object of the "implicit P1" in the OAC graphs) in one scenario, I'd expect to use the same property for other cases, even if the "object of the annotation" is a fragment.
>
> That's of course a matter of interpretation. In Annotea the context is defined as "The context within the resource named in 'annotates' to which the Annotation most directly applies." So from this perspective, if we try to "reuse" the notions used in Annotea, having an oac:Context makes sense.
>
> But you're right, for people who are not aware of Annotea, this might be confusing. I'll put it on the "open issues" list...

We tried both ways and while we weren't completely happy with either,
we thought that the current method was preferable.

Reasons:

* For simple cases, the current model still holds true, as the target
can be a Media Fragment URI.
* If the context node is the target, then it must always be the
target, even when there isn't a segment. Otherwise you can't tell if
you're annotating the context resource, or if you're annotating the
resource linked from the context.
* It's very unlikely that the context will be an information resource.
Note the distinction between Context and SegmentDescription, for
example. This seems more wrong from a Linked Data perspective.
* The current model follows the Annotea model which people are familiar with.
* Renaming it to something less vague would be perfectly fine by me!

If the W3C Media Fragment people had been open to our by reference
segment description approach (which is basically to put the URI of the
segment description in the #fragment part of the URI), then this would
be a non-issue.

Hope that helps :)

Rob

Antoine Isaac

unread,
Jan 18, 2010, 4:28:28 PM1/18/10
to Bernhard Haslhofer, oac-d...@googlegroups.com
Hi Bernhard,

OK, I'll drop one clarification. I think I'm either happy or re-assured by the rest ;-)


[...]


>> - I find the handling of segments a bit cumbersome. In fact I'd say that in case of annotating the fragment, the "target" should rather be the fragment, and the "context" the whole document. First, intuitively the "document" fits more the idea of "context" for the fragment, and thus for the annotation on it. Second, if we use the hasTarget property to refer to the "object of the annotation" (the object of the "implicit P1" in the OAC graphs) in one scenario, I'd expect to use the same property for other cases, even if the "object of the annotation" is a fragment.
>
> That's of course a matter of interpretation. In Annotea the context is defined as "The context within the resource named in 'annotates' to which the Annotation most directly applies." So from this perspective, if we try to "reuse" the notions used in Annotea, having an oac:Context makes sense.
>
> But you're right, for people who are not aware of Annotea, this might be confusing. I'll put it on the "open issues" list...
>
>> I know this may raise problems for query/retrieving scenarios: in order to find annotations "on" a document, you'd have to query for both oac:hasTarget and oac:hasTargetContext (and make a union of the results for each property). But well, I still find the proposed solution slightly counter-intuitive.
>
> hmm..why? If you know the URI of the annotated document you could issue a SPARQL (or whatever) query on the triple pattern (?x oac:hasTarget <http://bla/mydoc>) and get the identifiers of all annotations on this document. This presumes that the object of the oac:hasTarget property is a URI without any fragment identification information.


The current solution is indeed good at query time for this scenario: if you want to find all annotations "on a document" (ie, also on its segements), you just have one pattern to query for.
But if you want to know precisely the "item" being annotated, then you have to query for both hasTarget and hasTargetContext triple patterns (to find the cases where annotations are on segments).
So from a functional perspective both solutions have their pros and cons.

Since I found the naming in your solution less intuitive, I prefer mine ;-) . But as you say, if that's the common practice in the field, then it's perfectly understandable to priviledge this over personal taste, and go for the good documentation :-)

Cheers,

Antoine

Antoine Isaac

unread,
Jan 18, 2010, 4:41:30 PM1/18/10
to oac-d...@googlegroups.com
Hi Robert,

[I'm also focusing my answers here on stuff that's still unclear to me. Thanks for your other answers!]


>
> On Mon, Jan 18, 2010 at 6:12 AM, Bernhard Haslhofer
> <bernhard....@univie.ac.at> wrote:
>> thanks for your feedback. I am forwarding your mail (and my comments) also to the OAC discussion group in order to share these thoughts...and maybe kick off some discussions in our hyperactive group :-)
> [snip]
>> If we implement the OAC model in the Europeana Annotation component we could also bridge the structural and conceptual gaps to the EDM, because an OAC Annotation can be regarded as a specialization of an ore:Aggregation.
>
>
> This is something which we reconsidered after the meeting in Berkeley.
> The problem is that the two models don't converge when it comes to
> proxies. There can only be one proxy per tuple of (aggregation,
> aggregated resource), which would map to (annotation, target/content)
> ... and we definitely want to allow for more than one target segment
> with the same base URI.


I think I don't get this. You would want to create several proxies for a given target (or context) in the context (sorry for loose wording!) of a given annotation?
What would be the relation with the URIs with segements?

[...]

>>> - is there a strong motivation for having oac:Transcription in the model? I get the use case, but I'm wondering whether this really fits the core of annotation functions. If OAC includes many more like this, it may become difficult to understand!
>> As far as I remember from our meeting in October this reflects the idea of Resource Maps in OAI-ORE, so these are the pointers to the various serializations of an annotation. In Linked Data you wouldn't explicitly include such pointers in the data model but leave it to the transport protocol to return the pointers to the requested serialization (usually via HTTP 303). So I agree that we should rethink that...
>>
>> I think it makes sense to define the OAC model on an abstract level without implementation details. A concrete linked data / RDF implementation would then do pretty well without the oac:Transcription property.
>
> There are two main reasons for including the Resource
> Map/Transcription in the data model:
>
> 1. If it's not there, you can't have metadata about it. We very much
> want to know who created the transcription, when and what usage rights
> it has.
>
> 2. The links in the transcription to other transcriptions are great
> for discovery. Especially if they're not available via 303 for
> various reasons -- for example there might be multiple serializations
> all with the same mimetype, such as the various ways of formulating
> rdf/xml or rdf in json.
>

In fact I was not really questioning the relevance of transcriptions per se. Just wondering why the construct is coined in an model for annotation, while it seems interesting in other contexts!

Best,

Antoine

Robert Sanderson

unread,
Jan 19, 2010, 10:15:35 AM1/19/10
to oac-d...@googlegroups.com
On Mon, Jan 18, 2010 at 2:41 PM, Antoine Isaac <ais...@few.vu.nl> wrote:

>>> If we implement the OAC model in the Europeana Annotation component we
>>> could also bridge the structural and conceptual gaps to the EDM, because an
>>> OAC Annotation can be regarded as a specialization of an ore:Aggregation.
>>
>> This is something which we reconsidered after the meeting in Berkeley.
>>  The problem is that the two models don't converge when it comes to
>> proxies.  There can only be one proxy per tuple of (aggregation,
>> aggregated resource), which would map to (annotation, target/content)
>> ... and we definitely want to allow for more than one target segment
>> with the same base URI.
>
> I think I don't get this. You would want to create several proxies for a
> given target (or context) in the context (sorry for loose wording!) of a
> given annotation?
> What would be the relation with the URIs with segements?

I wasn't very clear, sorry!

The scenario that causes the problem is when there are multiple
targets, all being complex segments of the same resource. For
example, 3 SVG boundaries on an image:

Annotation oac:hasTarget Image
Annotation oac:hasContent Text

Annotation oac:hasTargetContext Ctxt1
Annotation oac:hasTargetContext Ctxt2
Annotation oac:hasTargetContext Ctxt3

Ctxt1 oac:hasSegmentDescription SVG1
Ctxt2 oac:hasSegmentDescription SVG2
Ctxt3 oac:hasSegmentDescription SVG3

An ORE proxy would be between the Annotation and Image, whereas we
would want there to be three proxies, one per Context node.

This is one of the drawbacks of the context/segment description approach!

>> There are two main reasons for including the Resource
>> Map/Transcription in the data model:
>> 1.  If it's not there, you can't have metadata about it.

>> 2.  The links in the transcription to other transcriptions are great
>> for discovery.

> In fact I was not really questioning the relevance of transcriptions per se.


> Just wondering why the construct is coined in an model for annotation, while
> it seems interesting in other contexts!

Definitely! Do you know of an ontology (other than ORE with Resource
Maps) that defines something like this? It would be nice to have it
in a general Linked Data ontology...

Rob

Herbert Van de Sompel

unread,
Jan 19, 2010, 10:26:26 AM1/19/10
to oac-d...@googlegroups.com, Bernhard Haslhofer
On Jan 18, 2010, at 2:28 PM, Antoine Isaac wrote:
Hi Bernhard,

OK, I'll drop one clarification. I think I'm either happy or re-assured by the rest ;-)


[...]


- I find the handling of segments a bit cumbersome. In fact I'd say that in case of annotating the fragment, the "target" should rather be the fragment, and the "context" the whole document. First, intuitively the "document" fits more the idea of "context" for the fragment, and thus for the annotation on it. Second, if we use the hasTarget property to refer to the "object of the annotation" (the object of the "implicit P1" in the OAC graphs) in one scenario, I'd expect to use the same property for other cases, even if the "object of the annotation" is a fragment.
That's of course a matter of interpretation. In Annotea the context is defined as "The context within the resource named in 'annotates' to which the Annotation most directly applies." So from this perspective, if we try to "reuse" the notions used in Annotea, having an oac:Context makes sense.
But you're right, for people who are not aware of Annotea, this might be confusing. I'll put it on the "open issues" list...
I know this may raise problems for query/retrieving scenarios: in order to find annotations "on" a document, you'd have to query for both oac:hasTarget and oac:hasTargetContext (and make a union of the results for each property). But well, I still find the proposed solution slightly counter-intuitive.
hmm..why? If you know the URI of the annotated document you could issue a SPARQL (or whatever) query on the triple pattern (?x oac:hasTarget <http://bla/mydoc>) and get the identifiers of all annotations on this document. This presumes that the object of the oac:hasTarget property is a URI without any fragment identification information.


The current solution is indeed good at query time for this scenario: if you want to find all annotations "on a document" (ie, also on its segements), you just have one pattern to query for.
But if you want to know precisely the "item" being annotated, then you have to query for both hasTarget and hasTargetContext triple patterns (to find the cases where annotations are on segments). So from a functional perspective both solutions have their pros and cons.



Antoine, I think I understand your perspective. But I don't think that from the perspective of the architecture of the WWW the above is something that can be solved. The finest granularity of addressing is a URI; that is what we have. That is the one that can be used for queries, I think. 

That means that in the proposed approach, one can easily find:

(*) all annotations that apply to a resource, including those that apply to a segment thereof (because the target is the resource's URI in both cases)

(*) all annotations that apply to a segment of a resource as long a that segment can be expressed as a fragment URI, i.e. using the W3C upcoming media fragment identification approach.

In our proposed paradigm:

(*) Finding annotations that apply to a segment of a resource that is described by a segment description (that itself exists at some URI) would also work if the W3C media frag people would want to listen to our proposal to use the URI of the segment description as a fragment on the URI of the annotated resource, e.g. http://blah.org/pic1#desc=http://blah.org/pics_area

(*) Finding annotations that apply to a segment of a resource that is described by an inline segment description (i.e. the desc sits in the Annotation Transcription) would be very hard, if not impossible. The point is that one does not have URIs to work with. And URIs is what the web wants.

Cheers

Herbert


==
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library





Herbert Van de Sompel

unread,
Jan 19, 2010, 10:34:02 AM1/19/10
to oac-d...@googlegroups.com
This is one of the things IRW (http://ontologydesignpatterns.org/ont/web/irw.owl) intents to address. It  definitely is in the paper about it (http://events.linkeddata.org/ldow2009/papers/ldow2009_paper19.pdf). See irw:isAbout and ldow:asscoiatedDescription. 

Bernhard Haslhofer

unread,
Jan 19, 2010, 10:55:49 AM1/19/10
to oac-d...@googlegroups.com
[starting a new thread on the relationship between OAC and ORE]

Hi Rob,

in Berkeley we somehow agreed that we should not explicitly insist on a connection between OAI-ORE and OAC, if there is any....I still think this is a good strategy because it keeps the OAC model simple.

But in our context, especially for the EDM it makes (at least in my opinion) sense to think about such a connection. So what [thinking loudly] happens if we apply the following definitions:

oac:Annotation rdfs:subClassOf ore:Aggregation

oac:hasSource rdfs:subPropertyOf ore:aggregates

oac:hasTarget rdfs:subPropertyOF ore:aggregates

we can define oac:Context as a class specific to the OAC model only, without any link to an ORE concept...

Does this make sense or is it complete non-sense?

IMO an annotation can be regarded as a kind of aggregation...of course a very specific one which can only be processed if an application is aware of the OAC model. But if we have the connection to the ORE model, applications that know nothing about OAC but are aware of OAI-ORE can at least interpret them as aggregations...

Best,
Bernhard

______________________________________________________

Herbert van de Sompel

unread,
Jan 19, 2010, 11:08:02 AM1/19/10
to oac-d...@googlegroups.com
hi Bernhard,

I hope you don't mind I express my perspective on this too.

Early on, it had absolutely been our idea to model OAC Annotations as ORE Aggregations; I think you and I even discussed this while in The Hague at Europeana.

However, the further we got into the details of the OAC model, the less attractive the proposition felt. At the granularity that you describe below, everything feels totally fine. I would love it. The problem comes with the introduction of ORE Proxies, and OAC ContextNodes, which are a different animal (see Rob's earlier mail). The combination of both in one set-up feels very complex; the semantics become bizar to say the least. Maybe it is because we have not thought into a lot of detail about it. I think we want to get the essence of the OAC model straightened out first before we start hurting our brains with this combo.

I remain open to the idea. But I also would love OAC to remain relatively simple. Given the sometimes exotic requirements that we need to address, it already feels a tad complex to me. But still manageable as the complexity builds up nicely as the use cases get more complex. But the combo of OAC ContextNodes and ORE Proxies that would result from an "integraton" feels at this point like a rather scary proposition. But as said, maybe that will change as we start to get our heads firmly around OAC.

Would love to hear your and Antoine's perspective on the combo issue.

Cheers

Herbert
--

Antoine Isaac

unread,
Jan 19, 2010, 4:09:35 PM1/19/10
to oac-d...@googlegroups.com


Indeed (if I understand well).
If the "object" of the annotation was what you currently define the context (cf my "counter-proposal"), his problem wouldn't exist, wouldn't it?
Again the current context/target choice seems counter-intuitive to my feeble mind. Had I to map aggregations to annotations, I would have said that the aggregated resources are the content of the annotation and the precise parts of a resource that are annotated. So in your example, Text, Ctxt1, Ctxt2, Ctxt3. And not Image.

Best,

Antoine

Bernhard Haslhofer

unread,
Jan 19, 2010, 4:26:36 PM1/19/10
to oac-d...@googlegroups.com
Hi,

my position is still the same: I believe the OAC should be as simple as possible but of course provide the necessary expressiveness to fulfill common annotation use cases. Aligning it with the ORE model will introduce additional complexity and might detain people from using it. So I would keep that out of the (main part of the) spec...

I was just asking this because in the specific context of Europeana it is worthwhile to think about it. We will probably make use of the ORE model in the semantic layer and it would be an elegant integration step if we could align the models by simply defining an oac:Annotation as a subclass of ore:Aggregation. I will discuss this with Antoine when we meet again...

If this is not possible at the end we can still define a mapping between OAC and our annotation model. At the moment this is what we need to do if we need to integrate LEMO with the EDM...if this is even necessary. We can do the same for the OAC model.


Best,
Bernhard

Antoine Isaac

unread,
Jan 19, 2010, 4:38:33 PM1/19/10
to oac-d...@googlegroups.com
Antoine Isaac a �crit :


Hmm. in fact I think I still don't get it. I guess that's with the URI/segment thing; otherwise I don't see why you can't create proxies for all Image, Text, Ctxt1,2,3 in your example, if you wish so.
Unless your proposal was just to have the target as aggregated resource?

Antoine

Antoine Isaac

unread,
Jan 19, 2010, 4:44:23 PM1/19/10
to oac-d...@googlegroups.com
Herbert, Bernhard,

As written in the other mail, I'd intuitively be ok with the combination. The issue is that I may consider a different set of aggregated resources as you envision.

Otherwise I don't see the problem with the proxies. I mean, they make the situation more complex only if you want to use them, with an ORE mindset, ie a mindset ready to accept the complexity of proxies.
They would be completely transparent in a mapping from OAC to ORE, as far as I can understand, and as Bernhard has suggested.

Cheers,

Antoine

> <mailto:bernhard....@univie.ac.at>

Bernhard Haslhofer

unread,
Jan 19, 2010, 4:55:13 PM1/19/10
to oac-d...@googlegroups.com
Antoine,

I dig out some example use cases we developed a while ago for the OAC model. Maybe things become clearer when looking at some RDF instances :-) The examples and the vocab are still pre-alpha and just a quick hack...but maybe they help.


I thought about your doubts on the notion of "context" again...for people who are new to annotations this is indeed confusing. So I think we should put this on our TODO list again and think about another notion. Now, since we decouple from Annotea anyway, it is the chance to introduce better names....

Best,
Bernhard

oac-vocab.rdfs
use-cases.n3

Herbert Van de Sompel

unread,
Jan 19, 2010, 5:00:36 PM1/19/10
to oac-d...@googlegroups.com
On Jan 19, 2010, at 2:44 PM, Antoine Isaac wrote:
Herbert, Bernhard,

As written in the other mail, I'd intuitively be ok with the combination. The issue is that I may consider a different set of aggregated resources as you envision.

Otherwise I don't see the problem with the proxies. I mean, they make the situation more complex only if you want to use them, with an ORE mindset, ie a mindset ready to accept the complexity of proxies.
They would be completely transparent in a mapping from OAC to ORE, as far as I can understand, and as Bernhard has suggested.


That last statement, I definitely agree with. 

Herbert

==
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library

Robert Sanderson

unread,
Jan 19, 2010, 5:04:23 PM1/19/10
to oac-d...@googlegroups.com
I'll try and put together some diagrams based on the ones we had at
Berkeley to show the various options, and post them to the list.

Rob

Antoine Isaac

unread,
Jan 19, 2010, 5:06:45 PM1/19/10
to oac-d...@googlegroups.com
Hi Bernhard,

Thanks for the examples. Beware, there are some typos in them, though (hasSegementDescription , and a couple of columns missing in front of local names).

I think I understand the basis of OAC now, an even why it makes the choices on context/target that I find counter-intuitive.

What I'm really puzzled by is Robert's argument about proxies. I don't see why, even in the more complex UCs (such as 4 and 5 in your file), the target(s) and the target context(s) can't all be considered to be aggregated resources, and why we couldn't create proxies for them in the context of their aggregation/annotation!
But maybe it's just too late for me tonight :-/

See you,

Antoine

> ------------------------------------------------------------------------

Herbert Van de Sompel

unread,
Jan 19, 2010, 5:07:26 PM1/19/10
to oac-d...@googlegroups.com
And agreed on this one too. context is overrated (read over-abused) ;-)

herbert


Best,
Bernhard









On Jan 19, 2010, at 10:09 PM, Antoine Isaac wrote:


______________________________________________________
Research Group Multimedia Information Systems
Department of Distributed and Multimedia Systems
Faculty of Computer Science
University of Vienna

Postal Address: Liebiggasse 4/3-4, 1010 Vienna, Austria
Phone: +43 1 42 77 39635 Fax: +43 1 4277 39649
E-Mail: bernhard....@univie.ac.at
WWW: http://www.cs.univie.ac.at/bernhard.haslhofer

<oac-vocab.rdfs><use-cases.n3>

Robert Sanderson

unread,
Jan 19, 2010, 5:26:09 PM1/19/10
to oac-d...@googlegroups.com
There are two options for targets when there are segments, either the
Context node (for lack of a better name) can be the target, or the
full resource can be the target. Currently the full resource is the
target, as per the top diagram in the attached file.

If the Context node is the target, as per the lower diagram, then we
end up outside of ORE due to the following:

* The Context nodes are very unlikely to have HTTP URIs, as they won't
have representations. We could mandate that they MUST have HTTP URIs,
but that would be quite a barrier to entry.
* If they do not have HTTP URIs, then they are not valid targets for
ore:aggregates, which specifies that the object must have a "protocol
based" URI (meaning that it can be resolved).

So either we ignore the "protocol base" URI requirement of ORE, or we
require HTTP URIs for little glue objects that could almost be ORE
proxies themselves. Neither of which is an attractive option.

So, going to the status quo, we have the following:

* The target has an HTTP URI, and hence oac:hasTarget is a good
candidate for being an extension of ore:aggregates.
* The content can easily get an HTTP URI, and hence could be aggregated.

However, a restriction on Proxies is that you can only have one Proxy
per (aggregation, aggregated resource) tuple. If this were not the
case, then the Context node could be a Proxy.
Eg, if you find two proxies for the same aggregation + aggregated
resource, you can owl:sameAs them together. Obviously this is not the
case for the context nodes.

So, Proxies cannot be the same as Context nodes. But then how can we
refer to a target in the context of the annotation? We can't make the
Context nodes aggregated resources, as they are unlikely to have
protocol based URIs. We can't create multiple proxies per aggregated
resource, so we're just out of luck.

At this point we decided to get to some less brain destroying work and
say that OAC annotations were not ORE aggregations :)

Hope that's made things more clear?

Rob

context_as_target.png

Bernhard Haslhofer

unread,
Jan 20, 2010, 3:05:01 AM1/20/10
to oac-d...@googlegroups.com
Thanks for the clarifications, Rob. I just would like to repeat what we discussed in one of our previous mails:

If the OAC model inherits from the ORE model, then it is up to us to define what is inherited. We can define a subclass relationship between oac:Annotation and ore:Aggregation and subproperty relationships between oac:hasTarget and ore:aggregates...and (maybe if we rethink the notion of context) also between oac:hasTargetContext and ore:aggregates. This doesn't automatically mean that the ORE proxy finds its application in the annotation model...it can remain transparent.

So the proxy would then stay within ORE and have no semantic relationship with oac:Context.

But there is still the argument that an integration with ORE would introduce additional complexity to the OAC model.

So another possibility for the case of Europeana, would be to define a Europeana Specific Anntotation "application profile" and define the mapping there. We could, for instance, define a class

europeana:Annotation a rdfs:Class ;
rdfs:subClassOf oac:Annotation ;
rdfs:subClassOf ore:Aggregation ;
.

Best,
Bernhard

>
> So, Proxies cannot be the same as Context nodes. But then how can we
> refer to a target in the context of the annotation? We can't make the
> Context nodes aggregated resources, as they are unlikely to have
> protocol based URIs. We can't create multiple proxies per aggregated
> resource, so we're just out of luck.
>
> At this point we decided to get to some less brain destroying work and
> say that OAC annotations were not ORE aggregations :)
>
> Hope that's made things more clear?

______________________________________________________


Research Group Multimedia Information Systems
Department of Distributed and Multimedia Systems
Faculty of Computer Science
University of Vienna

Postal Address: Liebiggasse 4/3-4, 1010 Vienna, Austria
Phone: +43 1 42 77 39635 Fax: +43 1 4277 39649
E-Mail: bernhard....@univie.ac.at

WWW: http://www.cs.univie.ac.at/bernhard.haslhofer

Antoine Isaac

unread,
Jan 27, 2010, 1:19:30 PM1/27/10
to oac-d...@googlegroups.com
Hi,

Bernhard has a good point for linking to ORE in specific case, to avoid the problems that Rob has raised. If Europeana has a policy of creating HTTP URIs for every annotated fragment, his solution is viable, isn't it?

By the way thanks very much for the explanation, Rob. The issue of HTTP for aggregated resources made immediately sense to me. It was however much more difficult to get the one with


> However, a restriction on Proxies is that you can only have one Proxy
> per (aggregation, aggregated resource) tuple. If this were not the
> case, then the Context node could be a Proxy.

So, you wanted to treat the "context" as a proxy for the "target", in the context of a given annotation? That would have been indeed weird, if just from the perspective of my intuition (maybe wrong in the end ;-) ) on what proxies can in general stand for.

Best,

Antoine

Reply all
Reply to author
Forward
0 new messages