- From: gsergiu via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Jan 2016 21:51:52 +0000
- To: public-annotation@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… Br, Sergiu 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 (#137) @gsergiu<https://github.com/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...) — Reply to this email directly or view it on GitHub<https://github.com/w3c/web-annotation/issues/137#issuecomment-172872489>. -- GitHub Notification of comment by gsergiu Please view or discuss this issue at https://github.com/w3c/web-annotation/issues/137#issuecomment-173372369 using your GitHub account
Received on Wednesday, 20 January 2016 21:51:55 UTC