Re: Annotations and the Graph

On Wed, Oct 28, 2015 at 1:20 PM, Randall Leeds <randall@bleeds.info> wrote:

> It's a little disturbing to me that you seem to be suggesting that they
> totally fall down and die in the presence of sub-classes and can't make
> useful inferences anymore. That's pretty bad.
>

It's not unusual in CS. Logic and reasoning is hard and frequently results
in unforeseen consequences.


> I understand what you're saying, insofar as rdf:Statement is the class of
> statements, triples. The first sentence makes no sense to me.
>

It's the class of triples. Statement is just the formal name of triples in
RDF.


> To your suggestion about appropriate questions, though, that is precisely
> how I arrived at this proposal. I asked myself, "Can I infer any statement
> of relation between the body and the target from this data?" I've found the
> answer to be, "No" and I'm very disappointed by that.
>

I'm not following. The answer to this is "yes". You can do this by
collapsing the predicate-node-predicate tuple into a single predicate. This
comes for free from the fact that RDF is a graph-based framework. Similarly
you can arbitrarily expand any predicate into a predicate-node-predicate
triple with arbitrary names. The web annotation model is based upon the
following expansion :_a relatedTo :_b. --> :_A an annotation; :_A hasBody
:_a; :_A hasTarget :_b. This is explained in section 1 (Introduction) of
the data model document. It should be a cinch to implement a reasoner for
this.

I think you may complain that it doesn't say *how* they relate but you can
get that from :_A motivatedBy :_M. Again, should be simple to implement a
reasoner for this.

In order to properly implement reasoners one must understand and wholly
grasp the underlying semantics of the data model.

Being graph-based, RDF is great because one can break models down to get
more detailed data and forge new relationships through expansion of
predicates. Take a Bibframe/Schema example for instance:
:_B isbn10 <1234567890>.
verses
:_B hasName :_n;
:_n a ISBN_10;
:_n hasValue <1234567890>.

The expansion is more verbose but affords a different set of utilities to
be exercised because we've abstracted the name of the thing away from it
allowing us to equate ISBN_10 and ISBN as naming the same thing and
explicitly capturing the work that the integers are doing in relation to
the thing being named.


> No such statement implied by the annotation can actually be made because
> the model doesn't specify that there is *any* relationship between the body
> and the target. That seems absurd considering that the purpose of
> annotation is so often to relate the them.
>

See Section 1 (the introduction) of the model. It's all right there in the
definition. There is even a helpful picture.


> I'm skeptical of this reasoning.
>

If this were a lab I think skepticism would be fine. The goal isn't to
determine what annotations are, it's to agree on how we represent and talk
about them. Either one believes that needs to be a collaborative process or
one doesn't. Competing standards helps no one.


> It's not a forgone conclusion that bodiless annotations are unquestionably
> needed by anyone. There may be alternative representations that they have
> not considered. That's the purpose of discussion. If we don't question one
> another we do each other a disservice.
>

I'm sorry, we already have use cases the state otherwise from communities
that have already concluded otherwise. Are we to dictate terms to them? How
can we possibly hope for any real uptake of the model?

More to the point, how does the existence of their use case injure your use
case?


> Unfortunately, no one has responded by explaining a use case where either:
>
> - The annotation is bodiless, but what's being created or consumed is not
> equally well represented as just a SpecificResource.
> - It would be unacceptable to infer any relationship between the body and
> target from an annotation resource.
>

One problem you have is that Specific Resources do not adequately capture
the role that the CSS plays in highlighting annotations; however, to me
that's an argument that CSS can be a body. I am sympathetic that
annotations should have bodies; however, you need to rethink how your
reasoner would work. As defined in the model, it is perfectly acceptable to
infer body relatedTo target. You can go a step further by interpreting the
motivations as sub-classes of the relatedTo property but that is an
idiosyncratic interpretation and your reasoner's output would be
idiosyncratic. IMO, its outside of the scope of our charter to do any
normative work along these lines.


> If my suggestions disenfranchise some community, name that community and
> show me its use case(s).
>

The thing is, this working group did not boil out of the ether. It's the
product of more than six years of effort by the principals. I'd encourage
you to do your homework. There are plenty of reports and other information
at websites like openannotation.org and the open annotation community
group.


> That's awfully circular.
>

I'm sorry you don't like it.


> We're okay with defining a predicate that says that the annotation is
> "motivated by bookmarking" but not with defining a class "Bookmark".
>

Yes, because it isn't clear what the difference is between classes like
"Comment" and "Remark" but, it's easy to map concepts like "commenting" and
"remarking" to one another through an intermediary ontology like SKOS. We
could have a proliferation of classes that clogs up search and retrieval or
we could have something that works as an interchange format.


> That's actually totally fine with me. I don't need to define the structure
> of Bookmark, and am happy to leave that to other communities of practice.
>

That's the goal. We just need to leave them hooks. I wouldn't take the
existing list of motivations to be canonical. They're just examples.

What concerns me is that if one creates an annotation with the
> "bookmarking" motivation, one hasn't, according to our model, actually
> asserted a relationship between the Bookmark (whatever its shape and
> properties) and the resource being bookmarked. As a result, I have to query
> my bookmarks indirectly by asking for "bodies of annotations that are
> motivated by bookmarking" rather than simply asking for the subjects or
> objects of a "hasBookmark" or "isBookmarkOf" property or something similar.
>

Reread section 1, the model clearly (though verbosely) asserts 'Bookmark'
relatedTo Thing.


> This is helpful. Maybe I'm misunderstanding. I thought that a class was
> not only a dumb placeholder identity to be used in describing the domain or
> range of a predicate, but could actually require (as we do in some places
> in our model) the presence or count of certain properties. To the extent
> that we would define _any_ properties not generally included in
> rdfs:Statement but required on an oa:Annotation it would be distinct.
>

That it actually could require the presence or count of certain properties
is the best reason to create a sub-class. If it lacks those qualities, then
as a rule of thumb sub-classing is not terribly helpful because there is
little to differentiate one thing from another beyond raw values.

If my understanding of RDF is off, and there's some reason I still can't
> grasp why sub-classing is harmful, then that's totally fine for me.
>

Have you ever read Guarino, N., & Welty, C. (2000). A formal ontology of
properties. *Lecture Notes in Computer Science 1937*, pp 97-112.?


> I don't care about the specifics of the class hierarchy, only that there
> can be inference of a triple involving the body and target.
>

This can be engineered.

It's ironic to be told that I'm re-inventing the wheel when the purpose of
> the entire thread is to ask whether Annotation is merely re-inventing the
> named graph.
>

An annotation is an instance of a named graph, like all RDF graphs. Not all
named graphs are annotations.


> I don't understand why people need to agree. The dataset/graph/annotation
> provides attribution to someone's claim about the nature of the
> relationship, even if that is just the generic assertion that they are
> related at all. Others may disagree with the specific relationship, or even
> its existence, and therefore decide not to consume the annotation or
> redistribute it.
>

We need to agree how they can express these things in a way that
disagreements about particulars can happen. But also, having mechanisms by
which some level of agreement is possible, e.g., using SKOS for
motivations, is helpful for very large scale aggregation and computing.


> We do specify what kinds of annotations (actually, what kinds of
> relations) there are by way of motivations. What we fall short of doing is
> saying that these are relations in the sense of being predicates for
> triples.
>

Not all relations are best expressed by predicates. Many relations have
properties unique to themselves. The annotating relationship is one of
these. If I just have the triple :_a relatedTo :_b then I've lost who made
the assertion and when it was made (unless I'm working with quads or quints
- a possibility). Expanding the predicate into a node and a pair of
predicates allows us to represent the full breadth of the relation's
metadata. What is and isn't a relationship is a matter of context and
perspective.


> If anything, what I'm proposing might actually be most helpful to XML
> developers, as RDF-XML seems, from my reading, to be the degenerate
> serialization that, by virtue of having a single root node, doesn't have a
> clear way to describe named graphs or datasets.
>

Possibly, it's hard to say. RDF isn't designed for serialization. It's
designed for building interlinking webs of assertions (i.e., it's designed
for representing knowledge). Interpreting assertions into coherent
documents is very hard.

Regards,

Jacob