Re: SKOS use cases format

Hi All,

Is there any way we can extract the "Type of  a word" from wordnet or some
alternatives ?

To explain - I am searching "headache" in the Knowledge Management and I
want the output to be clustered in the form of Types of Headache"

Any help ?

regards

Sabya
SSG Software Systems (P) Ltd
URL - http://www.ssgindia.com

----- Original Message ----- 
From: "Antoine Isaac" <aisaac@few.vu.nl>
To: "Alistair Miles" <a.j.miles@rl.ac.uk>
Cc: "SWD WG" <public-swd-wg@w3.org>; "SKOS" <public-esw-thes@w3.org>
Sent: Monday, November 20, 2006 3:21 PM
Subject: Re: SKOS use cases format


>
> Hi Alistair,
>
> Having read the other use case documents Guus pointed to [1], I would
> say that your proposal offers quite a nice setting. Lots of stuff there
> is indeed organized according to a general pattern including general
> introduction, scenario depiction, example, and problems in terms of
> standard being built.
> So something quite similar to your frame, and I think we could start -
> as you did for the SWED case - to gather contributions using it. But of
> course there are comments/questions I would like the WG to discuss (even
> if to discard them quickly)
>
> 1. Level of detail
> Your format seems to lead to quite elaborate descriptions, perhaps more
> than the ones in the mentioned UCR docs. I think this is not a problem,
> but I would like to have advice from people experts in that kind of
> technical document!
>
>
> 2. Independance of vocabulary section with respect to functionality
section
> I think that from our SKOS perspective it's important to emphasize on
> the vocabulary section for use case description. Even if you make the
> point in [3] that application focus is crucial, SKOS is finally about
> representing vocabularies. And I believe it's important for use case
> providers that they can express their needs with respect to this core
> aspect of their business. And therefore to do it in a section thay can
> immediately identify.
>
> This makes me ask again the question of a more fundamental distinction
> between functional requirements and representational ones. A same
> functional scenario (described in the "functionality" section) might
> apply to several vocabulary scenarios, and vice versa: a same vocabulary
> can be used in several types of application.
> I think this might confuse use case contributors: one could recognize in
> an existing use case a general application scenario he wants to specify,
> but not the vocabulary his company has to use. In such a situation,
> should the contributor "copy-paste" the functionality section? Or should
> he try to find his own word for his own scenario, even if something
> similar exists?
>
> A possible solution could be the division of use cases in two lists of:
> - "functional" cases, describing systems that exhibit specific behaviours,
> and
> - "representational" cases, presenting specific vocabularies with
> features SKOS should (or should not) enable one to represent
>
> But I'm not really sure that this is a workable solution, as the
> motivation for both aspects comes from the fact that they occur in a
> same application. So formal links between the 2 lists would be needed,
> at least. And perhaps it's the work of the editor to let the contributor
> fill in a complete use case document, and the work of the editors to
> recognize the identical contributions and deal with it. What do you
> think of that?
>
> 3. Link to ISO standards.
> Guus mentioned in [4] that we should link the use case to ISO standards.
> I think we should encourage the contributors to do so, if their case is
> already linked to it. I favor the addition of a "(non)compliance with
> existing encoding/representational standards" item in the vocabulary
> section. But I think we should mention the fact that filling this item
> is not mandatory, some vocabularies being developped outside of such
> considerations. Notice that amongst the existing standards, we could
> also mention the current version of SKOS! If a contributor already has
> insight on that this will provide with ammunition for the requirement
> list or the issues list that we've got to maintain.
>
>
> Best,
>
> Antoine
>
> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2006Nov/0028.html
>
> [2] http://lists.w3.org/Archives/Public/public-swd-wg/2006Nov/0014.html
>
> [3] http://lists.w3.org/Archives/Public/public-swd-wg/2006Nov/0023.html
>
> [4] http://lists.w3.org/Archives/Public/public-swd-wg/2006Nov/0032.html
>
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.14.9/540 - Release Date: 11/20/2006
>
>

Received on Wednesday, 22 November 2006 00:08:35 UTC