Re: Annotation Concept vs Document (was Level 1 comments)

Dear all,

On Wed, Jan 9, 2013 at 7:44 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> I really don't like that an annotation resource is in fact denoting a
> serialization.
> This puts a big burden on recognizing an annotation after it has passed a
> data conversion step, which will happen quite often in the kind of
> interoperability scenarios you're after.
>

Yes, and hence Section 3.3.2. about expressing the equivalence of
resources, including Annotations.



> There is a need for representing an annotation as a more abstract business
> object, which is "created" by people or smart agents. Of course I
> understand the need for requirements on the provenance of documents and
> data sources, but that seems quite distinct (and to me, quite less
> important).
>

But there isn't such a need for Bodies, which is where the actual content
is?  It seems inconsistent not to want an identifier for the Body, but to
want an identifier for the concept of the Annotation as well as one for the
Annotation Document.

Could you give some use cases when you would need to really distinguish the
two, that aren't covered by equivalentTo?


> I still think that respecting the one-to-one principle is important in
> these matters: attributing statements (e.g., oa:serializedBy and
> oa:hasTarget) to one URI, while they belong to different levels, can be
> very confusing in a paradigm (the Semantic Web one) that expects this kind
> of mixture not to happen.
>

I agree ... except that it happens all the time, as people take short cuts
like this in RDF when they're not considered dangerous.


Actually I'd be curious to hear about the feedback you received on ORE
> ResourceMap. I personally don't think it was technically so bad.


Neither did we, of course :)  The feedback I recall was:

* From the non LOD community, the mandatory 303 was seen as unnecessarily
complex to implement for little visible gain.
* From the LOD community, the fact that we required information be attached
to the Resource Map, which they saw as a temporary artifact only needed to
serialize the graph for a particular HTTP transaction, was seen as
unnecessarily complex.
* And of course, the never-ending HttpRange14 arguments.



> To me a good way for handling solution 1 would be for OA to just coin the
> properties serializedAt and serializedBy and *defer to other 'data
> provenance' proposals* (NGs, ResourceMaps, PROV...) for how to use them,
> i.e., on which resource exactly to attach them. Of course we could provide
> a couple of examples as guidance.
>

We could formalize Appendix A (Mapping to W3C Provenance Model) further and
introduce actual classes for the Annotating and Serializing activities,
Annotation entity as opposed to the Serialization entity, etc.  However I
am very wary of introducing multiple ways to express the same information,
and the current solution seems (to me) to be the easiest compromise.

On the other hand, so long as it was additional information, systems that
need the division could add it, and systems that don't would ignore it.  So
the Annotation would have oa:annotatedAt/By and oa:serializedAt/By for the
majority of cases, and might also have identities provided for the
additional PROV entities and activities.


On option 2 or 3: I trust that if there's one resource, then it should
> mainly denote the more abstract annotation, not the serialization. I think
> this has less pitfalls for interoperability between applications. If you're
> searching for a justification: just imagine the kind of horrible questions
> data consumers will ask about the semantics of oa:equivalent! (whether or
> not higher-level statements like oa:hasBody or oa:hasTarget statements
> should be propagated across equivalent annotations -- I believe they
> should).
>

I would have thought the other way around.  That it's easier to assert
equivalence between documents than it is between concepts.  In fact the
concept should only ever have one URI, or can be trivially owl:sameAs other
identical concepts.  The metadata about the document is what prevents us
from using owl:sameAs in the first place, rather than oa:equivalentTo.



> And we could keep the current pattern but updating the semantics of
> serializedBy to mean something like
> "this resource [which is an 'abstract' annotation]" has been serialized by
> X"
> as opposed to "this serialization was carried out by X" as I understand
> the meaning of serializedBy now.
> This property would become a kind of 'shortcut':
> anAbstractAnnotation -serializedBy-> X
> standing for the hypothetical path
> anAbstractAnnotation -hasSerialization-> anAnnotationSerialization
> -createdBy-> X
>

Yes, this is what the PROV mapping expresses.



> Side question: I'd be curious to hear whether
> oa:Annotation rdfs:subClassOf ore:Aggregation
> holds for you (for me it does!)
>

We tried that in OAC, you may not be surprised to hear.  It ... was not
well received.
See: http://www.openannotation.org/spec/alpha2/#DM_Baseline and compare to
/alpha and /beta

Rob