Re: [web-annotation] Definition of specific resources: @Type

@gsergiu,

I do not want to go into all details of your [client-server 
description](https://github.com/w3c/web-annotation/issues/137#issuecomment-172481249).
 Suffices it to say that I agree with what you describe in general, 
although I may not agree with all the details (e.g., you say "server 
must parse the annotation": I am not sure the "must" is really a must 
in all cases). But this is a detail.

My concern comes from a very different viewpoint. 

I think that, first of all, we can agree that there are and will be 
much more clients than servers. These clients may be fully automated 
programs (like the one you describe) but may also be humans: for 
example, the annotation model is referred to by such documents as the 
[Metadata Vocabulary for Tabular 
Data](http://www.w3.org/TR/tabular-metadata/), whereby the "author" of
 a dataset may want to add extra, essentially unstructured metadata in
 the form of an annotation using our model (do not be confused by a, 
alas!, different terminology: that document uses the term "annotation"
 in a very different way, but has a field for "notes" which 
corresponds to an annotation as we refer to in this WG). If there are 
(many) more clients (humans or machines) then we clearly have to 
optimize on what *clients* should do, and minimize the load on them 
even if this means a slightly more complicated processing on the 
server side. I hope we can agree on that.

So the question is: is adding a "type" to a structure (the full 
annotation, a specific resource, or whatever) such a big deal? Is it 
an acceptable requirement for the user? 

Well... the answer depends. You or I, or some others in the group who 
have gone through the blessings or the curses (depends whom you ask:-)
 of learning and being familiar with Semantic Web concepts have no 
problems with the concept of a type, and we may not consider it a 
problem to add such and information explicitly. However, we have to 
realize *and accept* that this may be an alien concept and an extra 
cognitive load for many. This includes not only the human clients, but
 also *the implementers* of the clients running as programs. “Why 
adding a type when it is obvious?” is the question they would ask. 
And, you know what? They are right in asking that. Why indeed, if a 
human, or a program, can easily deduce a type information? (The 
[Tantek’s document](https://www.w3.org/wiki/Post-type-discovery) is a 
great example: let a program discover the type instead of imposing the
 extra load of setting it on the client...)

The underlying issue is actually more general. We must realize (this 
has been an issue with the work in the group ever since it started) 
that we are shaping a JSON vocabulary that is (also) supposed to be 
used by people (humans and implementers) who are *not* Semantic Web 
people, and who may, God Forbid!, be actually very averse to the 
Semantic Web. Hence we have to think twice before pushing something 
"Semantic Webby" (and package it nicely). We have to do this while we 
*do* maintain a strict adherence to Semantic Web for those who care. 
Ie, we are trying to satisfy two sometimes very different communities 
by trying to find compromises. 

Hence the approach I am trying to defend: add a type if *and only if* 
the type cannot be deduced. Ie, when it is an essential information 
that is *absolutely necessary* for processing to properly happen. Yes,
 server implementers may be unhappy, but they can do it nevertheless. 
But if this leads to a more diverse set of clients, it is worth it.

(B.t.w., this approach is not sooo alien for Semantic Web people 
either. This is why one sets domains and ranges for properties: by 
using RDFS inferencing a SW client *can* deduce the type of the object
 or the subject, respectively, so that the client would not have to 
bother. This is the same concept, after all, but which has been often 
forgotten because RDF environment rarely implement RDFS inferencing. 
Unfortunately...)  

-- 
GitHub Notification of comment by iherman
Please view or discuss this issue at 
https://github.com/w3c/web-annotation/issues/137#issuecomment-172872489
 using your GitHub account

Received on Tuesday, 19 January 2016 14:39:25 UTC