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/>

Received on Monday, 28 January 2008 08:11:42 UTC