Re: Use case template

Hi Antoine,

sure, we don't want to exclude anyone. Our discussions can not be
transferred to the list, as we discussed almost everything so far during
telephone conferences. This is the luxury of a small sub-task-group :-)

Internally, we use Google docs to work on the example use case, which
contains at the same time the template, as we think it fits best our needs.

Here is the link to this document, for everyone who is interested:
https://docs.google.com/document/edit?id=1ZBPvrneFU72gyieSHGPB6Rm0jVmjk-GdUg0nBI1iW24&hl=en&authkey=CMD1jYUL

A second use case is currently prepared by Emmanuelle and should be
available tomorrow as a first draft.

Note, that this is really *work in progress*. We try not to discuss
everything, but just provide some real-world examples that help us to
discuss the result afterwards in the whole XG.

So in this sense, I would encourage people not to discuss the template
at the current state on an abstract level, but, if they want to jump in,
give us a short example use case where the template would NOT fit. Then,
we can try to incorporate it. This is exactly the approach that we try
to follow with our current examples.

Regards,

Kai

Antoine Isaac schrieb:
> Hi Kai,
> 
> 
> 
>> Alexander, Emmanuelle and I are currently working on the template. So I
>> summarize our findings
> 
> 
> Don't hesitate to discuss all this openly on public-xg-lld! Most often
> it will be very useful if someone else can jump in on a specific point
> you're discussing. Plus, it gives everyone the comfortable feeling that
> something is happening :-)
> 
> 
>> 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
>> ;-)).
> 
> :-)
> I think whatever we opt for we need some context for disambiguation.
> Which is why in my mail I always tried to use *use case* dimensions for
> [3] and *library linked data* topics for [6]. I'm not sure this wording
> is optimal, but at least it helps me...
> 
> 
>> 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.
> 
> 
> Yes, that's also what I envision for them. Even though a UC contributor
> outside the XG may still pick some LLD dimensions from our topic list,
> or even add one. We know that there are pretty smart people out there,
> too--which is why we want them to contribute ;-)
> 
> 
>> 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.
> 
> 
> +1. Feel free to employ whatever trick--it could just be an introductory
> sentence for the section to be filled...
> 
> 
>> For the latter, we can always extend, reorganize or refine the list
>> afterwards, as this only affects our own organization of the use cases.
> 
> 
> Cf. my comment above. If we have a list of topic  UC contributors can
> use, why not offering them?
> Of course we can still change the organization afterwards. If just to
> take into account the new items which will have popped out by that time...
> 
>  
>> 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.
> 
> 
> Yes!
> 
> 
>>> 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.
> 
> 
> Yes, I see the point. That could be something that we could have *after*
> having gathered and curated the UCs.
> 
> 
>>> 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.
> 
> 
> OK. Maybe you could use the latter vocabulary re-use example as a hint
> for the "unanticipated re-use" section. I was in trouble figuring out
> what could appear there, until you pointed out the obvious here :-)
>  
> 
>> 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.
> 
> 
> I'm not really sure this will bring a lot of material, but it would be a
> pity to miss any opportunity, sure.
> 
>  
>>> 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.
> 
> 
> OK!
> 
>  
>>> 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.
> 
> 
> I agree with the idea of pointer, and to have it in the intro or as a
> separate closing section for the current "LLD topics". But for the UC
> dimensions [3] I would really put the corresponding pointer in the "use
> case scenario" section, where it can help users most.
> 
> In fact the sentence and pointer which is currently in the "LLD"section [7]
> [The current dimensions list [3] suggests various categories of needs,
> resources, systems, and assets that might be invoked in use-cases, but
> should be considered a starting place rather than exhaustive.
> ]
> could be put as such in the "use case scenario" section which has the
> current sentence:
> [The use case scenario itself, described as a story in which actors
> interact with systems, each other etc. It should show who is using
> linked data technology and for what purpose. ]
> 
> [7]
> http://www.w3.org/2005/Incubator/lld/wiki/index.php?title=UCTemplate1&oldid=229#Library_Linked_Data_Dimensions
> 
> 
> 
>>> 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. :-)
> 
> 
> Agreed! So feel free to ignore my comments on the wording and ordering
> for the coming days, even if I belive they're cheap to implement.
> Anyway, be sure I'll come back with this mail later if needed ;-)
> 
> Cheers,
> 
> Antoine
> 
>>
>>> [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 14:27:53 UTC