- From: Thomas Baker <thomas.baker@bi.fhg.de>
- Date: Wed, 6 Oct 2004 10:26:43 +0200
- To: Bernard Vatant <bernard.vatant@mondeca.com>
- Cc: Thomas Baker <thomas.baker@izb.fraunhofer.de>, SW Best Practices <public-swbp-wg@w3.org>
On Wed, Oct 06, 2004 at 09:54:38AM +0200, Bernard Vatant wrote: > Quite late, but hopefully better than never, some (well, quite a few) in-line comments on > the Scoping Draft Thank you, Bernard. I am reworking the draft this week in preparation for putting it on a Wiki, so these comments come right under the wire. > > Section 1. Terminology > > > > I assume that we would need to agree -- at least for > > the purposes of the VM note -- on the meaning of some > > basic terms. Section 1, then, would define a list of a > > dozen or so basic terms such as "term" and "vocabulary". > > BV : Eating or own food, and to be nicely recursive, this section should be organized > following our own guidelines :) One suggestion that has been made (with which I agree) is that the terminology should follow everything else -- both in terms of process (i.e., we should do it last, after writing the rest of the note) and in terms of page sequence (i.e., readers should not necessarily have to read through definitions before getting to the main points). > > Section 4. Evolving issues > > > > On many issues we will not be able to agree, whether > > because the issues are controversial (e.g., the idea of > > "ownership" of a namespace which surfaced on this list > > in response to an earlier draft) or because they are > > the object of ongoing discussion and experimentation. > > We should try to distill these issues down to a > > "manageable" number -- a dozen or so -- and discuss > > each issue in one or two paragraphs which describe > > the issue and characterize the main viewpoints, areas > > of development, or controversies, with pointers to > > the literature. In my opinion, a "manageable" number > > is important not just to aid the reader, but also to > > allow us to divide ownership of the issues among Task > > Force members. > > BV: Maybe an extension of this section could be a wiki where those keep up being discussed > ? That sounds like a good idea. I want to make sure the more controversial (or less-baked) issues do not distract from the parts we can agree on. > > -- Namespace Document (definitive material about a Namespace) > > -- Namespace Schema (definitive material about a Namespace in a > > machine-processable schema language). > > BV: Agreement on what should or should not go there, and then on the definitions, could > take a lot of energy, so everyone involved should be ready to be consensual :)) > I think this list is a good basis. I don't think it goes too far. That is encouraging to hear. > > 4. About Section 2 - Vocabularies in the Semantic Web: Here > > is a very rough list of assumptions and principles that > > come to mind when one thinks of the Semantic Web. Does it > > seem like we need a section articulating assumptions on > > this very basic level (this depends of course on our > > target audience)? I'm thinking two or three pages - > > does that seem about right? > > BV: Do we really need that kind of prose? Depends indeed if the document is intended for > evangelization, or to provide technical clues to those already more or less convinced, > knowing the Whys and Wheres, but asking for the Hows. IMO we should rather target the > latter, but maybe I'm overly optimistic :) > In any case, the shortest the best here. I completely agree, but think we need _something_ along these lines. Two tight paragraphs with six pointers to further readings would be great. Again, this is something which, process-wise, we could fill in when the draft is further along -- not a point of departure by any means. The rest of your note gets into the meat of what sorts of assertions the note might be able to make -- great stuff, but I will work those into the draft instead of commenting here. In the meantime, just two more comments: > > -- When making assertions about terms belonging to another > > Namespace Owner, consider seeking their endorsement of > > those assertions ("assertion etiquette" or "good neighbor" > > policies). > > BV: Dream on ... Well, we are trying to work that out between DCMI and LoC regarding the use of MARC Relators as subPropertyOf dc:contributor, so there would be at least one example to point to. Maybe some members of the group can look over our shoulder as we finalize the details. We were thinking that assertions endorsed by some sort of mutual agreement would be more powerful than unilateral assertions alone. > > -- The formation of URIs. The issues here include > > "hash or slash", the implied semantics of language > > strings and of implied directory hierarchies in URIs, > > and the use of version numbers in URI strings. > > BV: Can of worms :)) Of course -- that is why I didn't even pencil it into the main section :) -- but presenting the options in a paragraph and saying it is a can of worms is perhaps better than saying nothing... Many thanks, Tom -- Dr. Thomas Baker Thomas.Baker@izb.fraunhofer.de Institutszentrum Schloss Birlinghoven mobile +49-160-9664-2129 Fraunhofer-Gesellschaft work +49-30-8109-9027 53754 Sankt Augustin, Germany fax +49-2241-144-2352 Personal email: thbaker79@alumni.amherst.edu
Received on Wednesday, 6 October 2004 08:22:40 UTC