[SKOS] Use cases format [was Re: SKOS use cases format]

Hi,

>
> Btw I forgot to add, we should ask for mails sent to 
> public-swd-wg@w3.org to have subject line starting with something like 
> "SKOS Use Case:".

Hopefully we'll do so now ;-)

> <snip>
>
>>> 1.2. (*) Please provide below some extracts from the 
>>> vocabulary(ies). Use the layout or presentation format that you 
>>> would normally provide for the users of the vocabulary(ies). Please 
>>> ensure that the extracts you provide illustrate all of the features 
>>> of the vocabulary(ies).
>>>
>>> 1.3. Describe the structure of the vocabulary(ies). What are the 
>>> main building blocks? What types of relationship are used? If you 
>>> can, provide examples by referring to the extracts given above.
>>
>>
>> Seems to me that we could switch 1.2 and 1.3
>> To answer Daniel's concerns about requirements, we might try to be 
>> more precise here by mentioning the following points (adapted from a 
>> study that a Dutch cultural heritage insitute organized recently for 
>> vocabularies, which btw generally contains elements that validate 
>> Alistair's proposal)
>> - main building blocks: type of descriptive concepts (terms, 
>> classification items with codes, etc.), presence of non-descriptive 
>> items (qualifiers use to precise the meaning of primitive concepts)
>> - structure (what type of relationship): hierarchical (with special 
>> interpretation)? associative? management of homonymy/synonymy? Others?
>> - organization: are the vocabulary elements gathered according to 
>> certain characteristics (facets)?
>
>
> The difficulty here is not putting words in people's mouths.
>
> The problem is that words like "term" "concept" "qualifier" 
> "classification" "primitive" etc. tend to have very different 
> operational meanings for different people, even if they might appear 
> to be superficially similar. This is probably the greatest difficulty 
> of working in this particular field - the terminology is so overloaded 
> and poorly defined (ironically :).
>
> Hence when I phrased question 1.3 I tried not to suggest any 
> terminology, but rather to invite the author to explain the structure 
> of the vocabulary *in their own terms*. 

I see the point.

> This is an *enormous* reason why I want to focus on the application - 
> if we have a clear idea of what functionality we are required to 
> enable, we can focus on providing something that will enable that 
> functionality, and avoid getting caught up in arguing endlessly at 
> cross-purposes about what e.g. a "term" or a "concept" actually "is".

Agreed. Actually my main point in my 'main descriptive blocks' was to 
spot the existence of distinct descriptors/non-descriptors (sorry, my 
own words perhaps) that bear some flavor of "functionality" with them 
(can I use this item to index a document, ask a question to the system, 
or not?). Such things exists, and I'm not sure they are easy to spot 
during the writing of a small use case description.
I would be more optimistic about the distinction between the different 
flavors of relationships and facets, so I won't argue if you and/or 
someone else think they are also too dangerous things to mention.

>
>>> 1.6. If a database application is used to store and/or manage the 
>>> vocabulary, how is the database structured?
>>
>>
>> Are you sure this one is so relevant? It might go into complex 
>> features, far from the intended vocabulary model (and from 
>> contributors'technical abilities)
>
>
> Looking at the data they store (or the structure of the database they 
> use to store it) gives a very direct indication of what data SKOS will 
> be required to convey. I would suggest that this information, if the 
> author is able to provide it, will be very helpful in understanding 
> the structure of their vocabulary.
>
> We might add "... please provide some example tables of data." ?

OK, let's try it, even if I'm still not convinced that database tables will help rather than bring a burden both to the contributor and the reader. (I have a bad experience of vocabularies being stored in databases that also contain almost everything else their application have to deal with) If we are lucky the informal description, eventually completed with file samples, will be enough in most cases. 


>
>
>>>   Section 2. Vocabulary Mappings
>>>
>>> In this section we ask you to provide some information about the 
>>> mappings or links between vocabularies you would like to be able to 
>>> represent using SKOS.
>>
>>
>> Here I'm quite puzzled: I like the idea of having a part dedicated to 
>> mappings, because SKOS is likely to be also about the links between 
>> different concept schemes, but I wonder wether this part should be 
>> independant in the questionnaire. It makes the distinction 
>> application/vocabularies less pregnant. Why not putting this section 
>> as (an optional) subection of the application one?
>
>
> I don't mind where it goes, as long as it's in there somewhere.
> I made it a separate section because it's more like the vocabularies 
> section than the application section - we're asking people to present 
> and explain some mappings, which might ultimately be used in more than 
> one application.

I know indeed vocabularies with mapping information that does not seem 
to be operational in any application. They were just in for guiding 
conceptualization and kept for historical reasons.
But I'm really not sure this will happen often, and if people who have 
such "pre-existing mappings" have precise goal for them.

Perhaps we can prepare for any situation by providing a "links to other 
vocabularies" item in the vocabulary section and your complete "mapping 
subsection" in the application one. Anyway, having the difference 
between what contributors have and what they want to be able to 
represent for their application, as you say.

>
>> Just wording: wouldn't "mapping links"be more precise instead of 
>> "mapping" alone?
>
>
> :) I used "mapping" and "links" separately in case they convey 
> different things to different people.
>
> To some people, "mapping" is more suggestive of relating vocabularies 
> with overlapping scopes, whereas "linking" is more suggestive of 
> connecting vocabularies with complementary scope. Ultimately it boils 
> down to more or less the same thing, but I just wanted to make sure 
> there was some room for interpretation.

Hmm why not "alignment" or "correspondence"? Ok, let's keep it like that ;-)

Cheers,

Antoine

Received on Thursday, 23 November 2006 18:39:40 UTC