RE: Annotations and the Graph

Regarding utility of annotations without bodies – A number of bodiless annotation use cases were put forth by readers of scholarly publications, both humanists and scientists, who said they often did not want to stop in their reading to have to articulate the details or their thought about a passage they wanted to annotate. Nor did they want to pause and choose from a menu to describe their motivation or the relationship of their thought to the passage. It was sufficient to simply call attention to the passage – i.e., make a SpecificResource – and then move on. The claim is that it would be intuitively obvious (to the original reader and often to their colleagues working in the same domain) what the implicit body was and why the SpecificResource had been created  when attention was called to the annotation target passage subsequently, but it would be too disruptive to their reading flow to pause and be explicit when the annotation is created. This mode of annotating without a body while reading is traditional of course – consider how many books in the library have underlining or other cryptic marks around text (in spite of the best efforts of generations of librarians to prevent this behavior), and I do think we need to support it.  And we have to be able to provide provenance and context for the creation of a SpecificResource. 

 

I also anticipate that a majority of bodied annotations will not have motivations or roles – again this is partly due to users not being willing to stop and describe their motivation or the role of their bodies / targets – but that some will have one or the other and some will have both. 

 

So, we do have a broad range of use cases to support, from bodiless annotations with and without motivation to multi-body / multi-target annotations with and without motivation and/or roles.  Like Rob I personally think that this is best done and most flexibly done through the use of a wholly new oa:Annotation class that is not a subclass of rdfs:Statement,  rather than through trying to map our classes as  subclasses defined for RDF reification. When we've tried to use RDF reification instead, which has been suggested a couple of times previously, it seems both less flexible and more limiting in terms of use cases supported, and it also seems likely to have perception problems with some developers.  It gets us right back into the issue that some developers have with an overtly RDF solution. I presume json-ld can support RDF reification, but I've not seen examples, and I don't know how developers who shy away from explicit RDF constructs would respond. (I recall seeing something about reification in early json-ld discussions to do with @graph and the named graph concept, but I don't know to what extent they considered json-ld for serializing rdf reification, how easy it is to do, how exotic / non-intuitive it might look to developers who shy away from RDF.)

 

So, I would need to see more concrete examples of how RDF reification could be used in lieu of the separate oa:Annotation class to support our full range of use cases and what reification graphs might look liked serialized in json-ld before I could consider endorsing the idea.  

 

-Tim Cole

 

 

From: Randall Leeds [mailto:randall@bleeds.info] 
Sent: Tuesday, October 27, 2015 6:56 PM
To: Robert Sanderson <azaroth42@gmail.com>
Cc: Web Annotation <public-annotation@w3.org>
Subject: Re: Annotations and the Graph

 

On Tue, Oct 27, 2015 at 4:41 PM Robert Sanderson <azaroth42@gmail.com <mailto:azaroth42@gmail.com> > wrote:

 

Hi Randall, Jacob,

 

There are three issues with the proposal that I can see.

 

One concern about the proposal is that rdf:Statement reifies a single triple, and an Annotation has significantly more flexibility.  For example, there may be no body to an Annotation, which would result in a statement with no subject.  Or for multiple bodies or multiple targets, there would be multiple subjects or objects respectively.  That's not the intent of rdf:Statement and related predicates, and I would be hard pressed to argue that it was kosher to subclass it.

 

I did suggest that Annotation could actually 1 or more rdfs:Statement associated with it, rather than being an rdfs:Statement itself, but I was trying to squeeze it into a shape that would be backward compatible with many existing annotations, to make it more palatable.

 

I'm still not sure I'm convinced that an annotation without a body is a useful thing. I know we debated it and decided to include it. I can't remember why. It would seem to me any such annotation could have a stub body. Or, more likely, that there is no annotation, there is only the production of a SpecificResource.

You could say that bookmarking is an annotation with the bookmarking motivation that has no body. Or you could just say that you have a bookmark (the body) and it refers to the target. Whether you even need an annotation as a separate resource here is questionable to me.

 

 

Secondly, motivation and predicate are not really the same thing, as has become clearer with the adoption of the role proposal to allow motivations to be associated per body.  For example, if you had a single Annotation with a motivation of bookmarking, and a body with a role of describing, plus a second body with a role of tagging, the use of rdf:predicate seems very difficult to work with.

 

 

It seems easier to me, though difficult to put them all into a single annotation. Again, though, here I am confused about what the model is attempting to do. It seems like it's trying to double as a simple container when really the user could create a container and give it provenance and have it contain all the annotations, one which describes and another which tags. Or maybe you have a resource "Bookmark" which can have properties for tags and descriptions, and the predicate relates the bookmark and the annotation.

Why should we avoid instantiating a Bookmark and instead create an Annotation that refers to some tags, some text, and some link, and complicates the relationship between them?

 

And finally ... we already have rdf:Statement (and the recommendations against its use) and named graphs. If an Annotation were restricted to just a single statement, I'm not sure that we would need a new specification :)

 

Thanks for making my point for me.

SpecificResource and the selector vocabulary is great and I don't see anything that exists quite like that.

But we have mechanisms to distribute statements with attribution. I don't understand what the model adds to that other than, it seems, a way to obfuscate the semantics and avoid actually creating triples that relate the body and target.

In a sense, it seems to me like the purpose of much of the model is to escape from having to model that which we want to model.