Re: Use case template

Hi Kai,

Thanks for the link and for the clarification on your approach!
Indeed I agree that "beautification" of the template can happen once we've tested it further with first UCs.

Antoine


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

Received on Tuesday, 13 July 2010 14:59:22 UTC