On Fri, 2005-03-11 at 14:17 +0000, Miles, AJ (Alistair) wrote:
>
> One reason I favour this position is that it is consistent with the
> recommended pattern for declaring RDFS/OWL ontologies. This pattern
> follows e.g.
>
--- RDF/XML cut ---
>
> In fact, the property skos:inScheme was originally a sub-property of
> rdfs:isDefinedBy, but I changed that for what I now think were
> erroneous reasons. Whether it should go back or not is open to
> further evaluation - I would like to better understand the
> relationship between these two properties (and I have got that wrong
> in the past, probably my biggest wopper to date :).
It seems to be somewhat reasonable to relate the two properties.
> If, on the other hand, you have:
>
> --- RDF/N3 (standard namespaces)
>
> @prefix ex: <http://www.example.org/vocab#> .
>
> ex:AAT a rdfs:Class;
> rdfs:subClassOf skos:Concept
>
> ---
>
> ... it is easy (without well written documentation that requires
> careful reading) to get confused about what the hell sort of thing a
> resource of type ex:AAT is supposed to be.
Yes, I can see that. I suppose this is already a problem in DC, with
dct:DDC, dct:LCSH and dct:MESH etc. In some of those cases, the naming
is fortunate, as it has double meanings: "a LC Subject Heading" works
OK, as does "LC Subject Headings" as an entity.
> You could end up with RDF statements that render into english as
> 'resource x is of type The Art and Architecture Thesaurus'.
Yes...
> I believe that, to allow the same resource to be both a concept scheme
> and a class of concepts doesn't promote clarity. I think a lot of
> people will get very confused about why or how the two things can be
> the same thing, and that will reduce perceived usability.
Well, I'm not sure how to avoid it. Whatever you say about this being
confusing is already present in the definition: "A concept scheme is a
[conceptual work/information resource] that identifies a set of concepts
and explains their meaning and proper use."
So having to introduce another resource to stand for the set of concepts
is *also* confusing :-) But I still see your point.
>
> So anyway, I'll leave it there for now, but in summary my feeling is
> that, for the short term at least, it's best to model these two sorts
> of thing (a 'concept scheme' and a 'class of concepts') as distinct
> resources, until we have a better understanding of what sort of thing
> we want a 'concept scheme' to be. In the mean time, a formal
> relationship between the two types of entity can be expressed via an
> OWL restriction on the skos:inScheme property, as outlined in an
> earlier message.
The main problem is having an endorsed URI to use for the class of
concepts. And introducing a separate URI to stand for that class is not
something that SKOS vocabulary authors are likely to do. Imagine
ex:AAT a skos:ConceptScheme.
ex:AATTerm a rdfs:Class;
rdfs:subClassOf skos:Concept.
It does not help at all if I can define the class myself (even formally)
as DC compatibility still will suffer.
This kind of double-declaration does not seem very likely to happen...
or does it??? Maybe if a SKOS Best Practices guide recommended the
introduction of such a class of concepts in SKOS vocabularies? Or
mentioned that for maximum DC compatibility such a class is useful?
I still think it would be fair to users of SKOS to make this clear, as
dc:subject will probably be a major deployment point for SKOS concepts.
/Mikael
