W3C home > Mailing lists > Public > public-xg-lld@w3.org > July 2010

Re: Use case template

From: Kai Eckert <eckert@bib.uni-mannheim.de>
Date: Tue, 13 Jul 2010 10:31:01 +0200
Message-ID: <4C3C2445.50104@bib.uni-mannheim.de>
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. :-)



> [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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:54 UTC