W3C home > Mailing lists > Public > public-annotation@w3.org > January 2016

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

From: gsergiu via GitHub <sysbot+gh@w3.org>
Date: Wed, 20 Jan 2016 21:51:52 +0000
To: public-annotation@w3.org
Message-ID: <issue_comment.created-173372369-1453326710-sysbot+gh@w3.org>
Hi Ivan,

1.      I’m claiming that at serialization time, the type should be 
written explicitly in the annotation if it is not the default one.
This will be solved by software applications, I don’t say that the 
human users should provide this information, which is “technical” by 
nature and not “functional”

2.      I don’t think that the Metadata Vocabulary for Tabular Data is
 representative for client applications, however if the claim is that 
there are some exceptional scenarios don’t need the type information 
(either because there is only one type used for each object included 
in the annotation), I can accept it. However, I would estimate that 
the share of the annotations created within this kind of scenarios 
will be le that 1%. Therefore … I have no problem if the standard says
 “SHOULD serialize the type” … instead of the MUST…

3.      I don’t find Tantek’s document to be a good example.   Why 
should we use a software application to guess types when we already 
know them (at the creation time) ?

4.      Why is the type obvious? For whom is the type obvious?

5.      “Type” is a keyword that is understood by anyone that has at 
least minimal computer science .. and not only

See https://en.wikipedia.org/wiki/Instance_%28computer_science%29

The meaning of the term "type" in computer science is rather similar 
to the meaning of the word "type" in everyday language. For example, a
 barman can ask a client what type of beverage does he or she want – 
coffee, tea or beer? A particular cup of coffee that the client 
receives is in the role of an instance, while two cups of coffee would
 form a set of two instances of coffee, determining its type at the 
same time.

6.     It is not only the servers, but also the clients. Annotations 
are serialized by clients and parsed by servers at creation time. And 
the other way around during retrieval. So there is a common interest 
to share the types between servers and clients. Therefore I do not 
support the following conclusion…

“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.”

7.      From my point of view a standard is made to reach a common 
understanding and not for diversification purposes. Therefore I do not
 support the following conclusion..

“But if this leads to a more diverse set of clients, it is worth it.”

8.     Sorry if I defend the developer’s point of view. But knowing is
 better than guessing in any situation…



From: Ivan Herman [mailto:notifications@github.com]
Sent: Dienstag, 19. Jänner 2016 15:39
To: w3c/web-annotation
Cc: Gordea Sergiu
Subject: Re: [web-annotation] Definition of specific resources: @Type 


I do not want to go into all details of your client-server 
 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. 

Reply to this email directly or view it on 

GitHub Notification of comment by gsergiu
Please view or discuss this issue at 
 using your GitHub account
Received on Wednesday, 20 January 2016 21:51:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:43 UTC