RE : RE : [ISSUE-77] [ISSUE-48] Skos subject properties are deprecated

Dear all,

(and I would like to point the SWD members to this very interesting thread, which does not appear on the SWD list any more)

The way I understand it, there are two "perspective" that are being opposed here:

1. SKOS is about KOS representation only, and it is not feasible/desirable have SKOS representing the indexing link between (possibly very numerous) resources and the concepts they are about. The functions are just different.

2. Accessing the resources that are the "extension" of a concept can be very interesting for manipulating the concepts, e.g for designing standard applications. 

I am rather in favor of the second option. As lot of SKOS applications are indeed about accessing documents via concepts, it may be helpful for SKOS to have minimal control on the "interface" between conceptual knowledge bases and documentary systems. While of course allowing the application designers to coin their own properties (subproperties of skos:subject) for this.
Note that this can be dealt without introducing the extra skos:subject property. We can write a guideline that says which property from another vocabulary should be used as a standard. dc:subject is of course a natural candidate, the problem being perhaps that it is too "subject" oriented, as was criticized in this thread

Best,

Antoine



-------- Message d'origine--------
De: public-esw-thes-request@w3.org de la part de Bernard Vatant
Date: lun. 28/01/2008 09:11
À: Aida Slavic
Cc: public-esw-thes@w3.org
Objet : Re: RE : [ISSUE-77] [ISSUE-48] Re: [Dbpedia-discussion] Skos subject     properties  are deprecated
 

Aida
>
> Bernard,
>
> > Not sure SKOS should make this distinction, and I'm not sure I make it
> > clearly myself. What is the point of organizing concepts, if not for
> > organizing resources? I would even say, pardon me it's Friday evening,
> > what is the point of defining a concept at all, if not for cataloguing
> > things?
>
> It is not normal practice that vocabularies 'declare' which of 
> millions of resources in the world are indexed by them. It is rather 
> the opposite... resource metadata declare according
> to which vocabulary standard i.e. concept (URI) the subject of the 
> resource should be understood.
Now that it's Monday morning let me clarify things:)
I agree totally with that, when saying that we need 
skos:watever-its-name property to declare those metadata. Providing this 
property in SKOS vocabulary would mean a generic way to do that, which 
does not preclude more specific indexing pointers. I also wrote that we 
do not need, and certainly should not use in general, any inverse 
property. So, indeed, the concepts and concept schemes will generally 
not be 'aware' (so to speak) of the resources indexed on it. But to help 
e.g., SPARQL queries to discover those resources, a generic indexing 
property is useful.
>
> Theoretically - if vocabulary exposed in SKOS is in some kind of
> registry we may have millions of resources from various
> collections/countries/ pointing to particular concept URI from this
> vocabulary. Which is why it makes sense that metadata of the resource
> should point to the SKOS concept - but SKOS need not point to metadata
> or resource.
OK. And you don't need that to find the millions out. See above.
>
> I thought that SKOS may be used to organize/expose concepts and not
> resources themselves. For all kind of vocabulary management reasons and
> good practice in collection management it makes more sense to have a
> vocabulary expressed in SKOS kept externally from metadata and also to
> keep metadata externally from resources.
Yes
>
> If one using Dublin Core wishes to nest SKOS description or embed all
> these in resource or keep them bundled together in the same repository -
> that is understandable, but this scenario would not be typical for
> vocabularies that function as de facto standards or are shared.
Of course. I don't see what I have written in defense of skos:subject 
going against that.
>
> I think what Leonard (and I) are maybe thinking here of the usual 
> practice in managing metadata using relational databases and keeping 
> things that needs to be managed/updated, controlled and accessed 
> separatelly as separate. I don't know enough about semantic 
> technologies to be able to see how this is no not relevant.
It is completely relevant, and this is the way I figure skos:subject is 
to be used.

Bernard

-- 

*Bernard Vatant
*Knowledge Engineering
----------------------------------------------------
*Mondeca**
*3, cité Nollez 75018 Paris France
Web:    www.mondeca.com <http://www.mondeca.com>
----------------------------------------------------
Tel:       +33 (0) 871 488 459
Mail:     bernard.vatant@mondeca.com <mailto:bernard.vatant@mondeca.com>
Blog:    Leçons de Choses <http://mondeca.wordpress.com/>