- From: Bernard Vatant <bernard.vatant@mondeca.com>
- Date: Tue, 18 Jan 2005 15:20:20 +0100
- To: "'Thomas Baker'" <thomas.baker@bi.fhg.de>, "Miles, AJ \(Alistair\)" <A.J.Miles@rl.ac.uk>
- Cc: <public-esw-thes@w3.org>
I have unfortunately not the bandwidth to jump in the exciting concepts/term/URI/... debate, but I have two quick comments on the proposal for "concept space". 1. Good idea, because "space" looks much less constraining that "scheme". I can imagine a concept space with very few semantic relations, or even none at all, like a flat list of concepts, say for exemple a list of ISO languages like the one starting at http://psi.oasis-open.org/iso/639/#aar. Such flat lists in SKOS would be useful, but can hardly be considered as "schemes", since scheme seems to carry some notion of internal structure. 2. Not so good idea, since it is at risks to conflate with the "namespace" notion. BTW current SKOS specification seems completely agnostic about the relationship between namespace and concept space. OTOH, most Thesauri and vocabularies are defined as "unique name" spaces. That means legacy concepts will have generally been identified by a unique name *inside the concept space* before being ported to the RDF format. So an obvious migration practice will certainly be to use a single RDF namespace to somehow represent the concept space. I don't know if that should be recommended by the specification, or pointed out as a current/best/recommended practice. In any case, I don't think SKOS specification should be silent on that point, the more so if it actually shifts from "concept scheme" to "concept space". Just an idea : if indeed it's a good practice to attach a namespace to a concept space, why not add this attachment as a deicated SKOS property? It would make useless the repetitive declaration of "inScheme" properties, OTOH it does not seem to be consistent with the current cardinality of "inScheme" property ... I'm buying clarifications on that point (more beer on the table). Bernard ********************************************************************************** Bernard Vatant Senior Consultant Knowledge Engineering bernard.vatant@mondeca.com "Making Sense of Content" : http://www.mondeca.com "Everything is a Subject" : http://universimmedia.blogspot.com ********************************************************************************** > -----Message d'origine----- > De : public-esw-thes-request@w3.org > [mailto:public-esw-thes-request@w3.org]De la part de 'Thomas Baker' > Envoye : mardi 18 janvier 2005 14:23 > A : Miles, AJ (Alistair) > Cc : 'public-esw-thes@w3.org' > Objet : Re: Glossary of terms relating to thesauri and faceted > classifica tion > > > > On Tue, Jan 18, 2005 at 01:10:20PM -0000, Alistair Miles wrote: > > > I'm not so sure... The draft DCMI Abstract Model [1] defines > > > "term" to be "The generic name for a property..., vocabulary > > > encoding scheme, syntax encoding scheme, or concept taken from > > > a controlled vocabulary (concept space)". Then it defines > > > "term URI" as "The generic name for a URI reference that > > > identifies a term". In other words, it makes a distinction > > > between a modeling entity and the identifier for that modeling > > > entity. > > > > It occurs to me that 'concept space' might be a better name for what SKOS > > Core currently calls a 'concept scheme'. Any thoughts on this? > > That sounds good to me - "scheme" is at least as overloaded as > "term" and even more ambiguous. > > Tom > > -- > Dr. Thomas Baker Thomas.Baker@izb.fraunhofer.de > Institutszentrum Schloss Birlinghoven mobile +49-160-9664-2129 > Fraunhofer-Gesellschaft work +49-30-8109-9027 > 53754 Sankt Augustin, Germany fax +49-2241-144-2352 > Personal email: thbaker79@alumni.amherst.edu >
Received on Tuesday, 18 January 2005 14:20:27 UTC