Re: [office-metadata] grouping use cases

[Patrick Durusau <patrick@durusau.net>]

Bruce,

Looks like a good start.

Politically speaking, I would not mind having use case categories that 
overlap to some degree. For example, medical professionals think of 
their metadata needs as being different from those of the legal 
profession. (Apologies to John Madden! It was the only example that came 
to mind. John has a very sophisticated view of metadata but that has not 
been my experience with all users.)

Yes, we need to categorize the use cases so that we aren't running all 
over creation to assemble the requirements but it isn't that big of a 
document at present and I rather doubt it is going to more than double 
in size.

I would rather have requirements trackable back to "my" usecase from the 
perspective of different users, so that they know their concerns have 
been taken into account, than to really boil it down for the committee. 
We are by and large accustomed to extracting that sort of information 
and probably need to do the heavy lifting as required.

Note I am not disagreeing with your approach but merely cautioning that 
we need to remember that a use cases document is not simply technical 
input into a process but a political document to get buyin from users 
who may not be at ease with spotting the similarities between their 
needs and the needs of others.

Hope you are having a great day!

Patrick

Bruce D'Arcus wrote:

> One of the things we talked about earlier was grouping or categorizing 
> use cases. I think it's actually in our charter that the use case 
> document be so structured. But more importantly, I'd like us to start 
> thinking about how we'd do that so we can more efficiently move 
> towards concrete proposals. Looking at the breadth of use cases we 
> have, I could see us getting bogged down if we're not careful.
>
> So here's my suggestions for broad categories:
>
> 1)  enhanced content
>
> This involves examples like tagging and such, where a user might add a 
> layer of metadata on top of simple blocks or spans of content.
>
> 2)  custom solutions
>
> This involves extensible outboard/non-content metadata, for use in 
> processing. Often (as with citations) there will be a field in the 
> content file, with separate custom metadata which is used to generate 
> the field presentation content.
>
> I'm probably missing some, but it seems to me these two kinds of use 
> cases are different enough that it would be good to distinguish them. 
> The first involves adding metadata to content, while the second 
> involves using metadata to generate content (as well as potentially to 
> do other things).
>
> Thoughts?
>
> Bruce
>
>
>
>

-- 
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work!