Re: Labeling ConceptSchemes: Best Practices?

Funny question!

 From my point of view, if one wants to manage a ConceptScheme like a 
Concept, (s)he will make a "hyper generic" concept at the top of the 
ConceptScheme.

What is a ConceptScheme:
1) A space constraining broader/narrower/related relations
2) Typically something managed by a coordinated team
3) As such, a "document" published with the Concepts of that team

Is it reasonable to have it in one file (one document)?
Yes if it is managed like a document (versions)
    URLs of Concept should then have the structure 
http://URL-ConceptScheme#about
No if each Concept has an independent life and should be accessible 
directly.
   A direct URL for the Concept (without the relative part #about) 
should be used.

In a sense, not having labels for ConceptScheme is a clue that they are 
not the vocabulary (the Dictionary is not the vocabulary, it is a 
document containing it).

But, for some chores, it is useful to state information at ConceptScheme 
level to be inherited by all Concept in that ConceptScheme:

1) namespace / about: many applications are using http://URL for a 
ConceptScheme and http://URL#about for the Concepts: the "about" of the 
concepts is then partially inherited from the ConceptScheme. In a way, 
the referers should do the same thing: have one place to define referred 
ConceptSchemes complete URL (e.g. an Entity) and then use only the 
&entity;#about concept to refer. Here also, the ConceptScheme defines a 
container where the Concept is an entry.

2) Icons (this is missing from SKOS standard IMHO): the ConceptScheme is 
better represented by an icon than by a lenghty name. It is nice to 
define icons at the ConceptScheme level and others at Concept level. 
Concepts without icons are then prefixed by the ConceptScheme icon.

I feel like you that making everything a document (dcterms allowed 
everywhere) may be somewhat lazy (no RDFS file to create) but may be it 
is the less bad solution to "document" SKOS Concept Scheme and others.

Those different issues have an impact on implementations and SKOS tools 
developers life when it comes to make links between different SKOS 
sources (internal and externals), all moving at their own pace

I don't think I answer every aspects of your question. This is just my 2 
cents...

Have a nice week-end,

Christophe

Le 7/08/2010 20:50, Juan Antonio Pastor Sánchez a écrit :
> Hello everyone:
>
> I doubt arises regarding labeling practices of SKOS Conceptscheme. The
> most common practice is the labeling by dc: title. From my point of
> view might have to distinguish between the description of an action by
> a metadata schema (in this case Dublin Core) and the need for
> consistent Conceptscheme from the perspective of the SKOS model.
>
> In the latter case I think would be labeled by concepts prefLabel
> schemes, altLabel, and even hiddenLabel for and applications using
> SKOS data, to query a specific KOS, using these properties.
>
> DC labels should be limited to the description of a SKOS element in
> the environment of other data sets for other applications (such as a
> digital repository).
>
> In this regard, my analysis of most of the SKOS Dataset has led me to
> the conclusion (maybe I'm wrong) that for the most common practice to
> represent a KOS, normally used only one Conceptscheme.
>
> I have the feeling that this practice creates KOS too "monolithics",
> limiting their interoperability and reusability. Perhaps this is why
> normally used dc: title instead of SKOS properties to label
> Conceptscheme.
>
> What do you think?
>
> Greetings.
>
> Juan.
>
>

Received on Saturday, 7 August 2010 21:24:15 UTC