Re: Annotations and the Graph

I realize I sent this without finishing with a concrete proposal, so here
it is, with maximal backward compatibility (though I would consider more
aggressive changes, too).

Make oa:Annotation a subclass of rdfs:Statement. Without loss of
generality, make oa:hasTarget and oa:hasBody sub-properties of rdfs:subject
and rdfs:object. Rename the motivations so that they clearly describe the
relationships between subject and object.

If we would like to maintain some of the same multiplicity behavior, make
it clear than any number of subjects and objects can be related by one
predicate (or maybe more, but that seems dubiously useful).

On Tue, Oct 27, 2015 at 1:11 PM Randall Leeds <randall@bleeds.info> wrote:

> My attraction to annotation is the promise of containers for referencing
> and relating content.
>
> The SpecificResource and its associated Selector classes accomplish the
> task of fixing references to content (not just URLs).
>
> Motivations accomplish the relating. The roles proposal expresses a desire
> to do so even more granularly.
>
> Motivations (and roles) makes the relation between body and target into an
> object related to the annotation (or body). This succeeds in avoiding
> publishing statements that explicitly involve the body and target as
> subject and object of a statement, but leaves the relation between the body
> and target to inference.
>
> Possibly one of the most important semantic statements the annotation
> could convey is not even in the graph!
>
> That is all fine and well motivated (ha!), but there already exists the
> RDF Schema reification vocabulary for conveying triples that are, for
> whatever reason, kept initially out of the graph.
>
> Consider a typical annotation use case, using rdfs:Statement,
> oa:SpecificResource and schema:Comment:
> http://json-ld.org/playground/#/gist/0185862e6812fd5a908e
>
> Here, the only Web Annotation Data Model classes I've used are
> SpecificResource and TextQuoteSelector. I chose "target" and "body" for
> mapping context terms to highlight the similarity to our typical examples.
>
> None of this is to argue that the Web Annotations Data Model needs to
> constrain its vocabulary more. It's perfectly fine and great to instantiate
> new vocabulary terms that are identical or similar to terms in existing
> vocabularies like schema.org and fix them within a W3C spec.
>
> For the extremely commonplace usage of annotation as targeted commenting,
> putting <article, comment, body> into the graph would seem to be the
> simplest thing.
>
> I would like to avoid querying for comments on this article PLUS
> annotations with the commenting motivation that have this article as their
> target or the source of their specific target. Wow, that second part seems
> needlessly complex compared to the first, doesn't it?
>
> To remedy this, we could be more careful in defining our motivation terms
> as rdf:Property instances that are meant to relate the bodies and targets
> directly. The annotation is either a sub-class of rdfs:Statement or perhaps
> it's a resource with a collection of one or more rdfs:Statement.
>
> I could ingest annotations and reify the new triples they describe. I
> could keep independent datasets, quads, named graphs, etc according to the
> the non-Statement metadata the Annotation bears in order to keep
> collections separate and non-conflicting, if I care to. Then I could make
> straightforward queries.
>
> Right now we can't do this because "oa:commenting" is not "oa:isCommentOn"
> and we don't reify <body, motivation, target> at all. We are really unclear
> about what the relationship is between bodies and targets, even in the role
> proposal.
>
> We are describing the annotation rather than using the annotation as a
> vehicle to describe the world with attribution.
>