- From: Kai Eckert <eckert@bib.uni-mannheim.de>
- Date: Tue, 13 Jul 2010 10:31:01 +0200
- To: public-xg-lld <public-xg-lld@w3.org>
Hi Antoine, Alexander, Emmanuelle and I are currently working on the template. So I summarize our findings and try to bring them in line with your suggestions: > Re. feedback on the content of the template, my most important comment > concerns the use of the "dimensions" at [3] in the sections of the use > case template [1]. > My first understanding of the "library linked data dimension" section, > based on the "dimensions" of the Prov XG [4] initially there [5], is > that this section would be rather technical, implementation-driven. In > fact, to me the examples for filling the "library linked data dimension" > section should come from the "topics" that we assembled over the past > weeks (now at [6]). [4] is really closer from [6] than it is from [3]. You are right. I also tend to use the topics list (maybe a somewhat cleaned/shortened version) as dimensions (and maybe just call it topics ;-)). Or we use both. But as I said on the phone conference, I don't think that the dimensions/topics are THAT important. For me there are two reasons for them: They can help *use case providers* to think about the broad field of library topics and to find interesting use cases related to these topics. And they can help *us* after the gathering of use cases to organize the use cases and maybe to identify topics/dimensions with missing use cases. For the former, we have to be careful that we do not restrict the use case providers with too narrow topics, so I assume that we need either an open list or at least a "misc." topic. For the latter, we can always extend, reorganize or refine the list afterwards, as this only affects our own organization of the use cases. So I suggest to provide a link to the dimensions/topics in the template and encourage the providers to think about them and choose one or more of them to characterize their use case but in the same time also allow them to suggest a new topic or just let the field empty if they feel not comfortable with it. > Now, I think the point on which we fundamentally agree (and which may > explain the above disagreement ;-) ) is that *the "use case dimensions" > at [3] should stimulate something that comes before what the "linked > data topics" at [6] would stimulate*. > The more I look at it, the more I wonder why the Prov XG had put their > "provenance dimensions" before their "goal" and "use case scenario". I > can see a logic here, but it's one of someone with a quite clear view on > the domain's technical points--the Prov XG provided the UCs > themselves--not necessarily the one of a true application owner (i.e., > "business"-oriented). That is indeed the case, but I would not overestimate the actual position of the section within the template. I think (I was not involved in the template development of prov-xg), it could be due to such a simple reason as just to have it on top of each use case so that you can easily classify a use case when you look at it. > > I would thus suggest to have the following order: > 1. Name; 2. Owner; 3. Background and Current Practice; 4. Goal; 5. Use > Case Scenario [suggesting the use case dimensions at [3]); 6. Problems > and Limitations; 7. Library Linked Data Dimensions (pointing to the > topics at [6]; 8 Unanticipated Uses (optional); 9 Existing Work (optional) > Currently we have the following (without dimensions and topics): 1. Name, 2. Owner, 3. Background and Current Practice, 4. Goal, 5. Use Case Scenario, 6. Existing Work (Optional), 7. Related Vocabularies (Optional), 8. Problems and Limitations, 9. Related Use Cases and Unanticipated Uses (optional), 10. References (Optional) The rationale is, that we expect some use cases (like around VIAF, our current example), that are already more or less implemented and so the existing work is very important for the description. But we still want to separate it from the actual use case, so we need the own section. The same holds for the vocabularies, of course we are interested in vocabularies in use or existing vocabularies that could be used in the described use case. The Problems and Limitations section is then open for all kind of problems, depending on the contents of the previous sections. From general problems arrising from the use case itself, over technical issues with existing implementations to problems or weaknesses of the vocabularies involved. The Related Use Cases and Unanticipated Uses is also used to help us organize the use cases and also to stimulate further use cases from the unanticipated uses. > This could have the benefit of illustrating the natural complementarity > between "problems and limitations" and "LLD dimensions". For many of the > Prov XG's use cases, I feel that it is the informal gathering of > problems that leads to the more formal identifications of the dimensions. You are right, I just checked that in the prov-xg wiki. They *first* had a set of use cases, *then* they created the list of dimensions and included the dimensions section in the template. > Would people around here agree? I would agree to put it at the end, but after the related use cases and unanticipated use cases. I would explain to the providers that they *can* relate their use case to an existing topic *and/or* an existing dimension, but they don't have to. They also can suggest other topics and dimensions, if they want. At the same time, I would put a link to them in the introduction, to help people think about possible use cases, but also emphasize that they should not restrict themselves to this list. The actual organization of the use cases and the relation to the topics and dimensions, alternatively the extraction of them out of the provided use cases is the job of our xg members, when they curate the use cases. > But as said it is indeed much less important, and I realize I've already > written one page on the order of the sections of the template alone so > I'll stop here :-) And now I added even more text, sorry :-) I think we will be ready with a new template *and* two or three examples how they could be filled in with actual content until the end of the week. I suggest that we wait for that and then reopen the discussion again. But I think we are now converging towards a really acceptable solution, so hopefully there will be not much more to discuss. :-) Regards, Kai > [1] http://www.w3.org/2005/Incubator/lld/wiki/UCTemplate1 > [2] http://www.w3.org/2005/Incubator/lld/wiki/UCRationale > [3] http://www.w3.org/2005/Incubator/lld/wiki/Dimensions > [4] http://www.w3.org/2005/Incubator/prov/wiki/Provenance_Dimensions > [5] > http://www.w3.org/2005/Incubator/lld/wiki/index.php?title=UCTemplate1&oldid=86#Linked_Data_Dimensions > > [6] http://www.w3.org/2005/Incubator/lld/wiki/Topics3 > > -- Kai Eckert Universitätsbibliothek Mannheim Fachreferat Mathematik, Informatik, Wirtschaftsinformatik Schloss Ostfluegel 68131 Mannheim Tel. 0621/181-2946 Fax 0621/181-2918
Received on Tuesday, 13 July 2010 08:31:36 UTC