RE: skos:ConceptScheme suggestion; separating style and meaning

Hi Ian,

Interesting stuff! 

> Now I could just declare, for instance:
> 
> skos:broader rdfs:subPropertyOf rdfs:subClassOf .
> 
> and rely on the reasoner to allow me to descend a hierarchy by only
> querying against rdfs:subClassOf. This has two problems, 
> though: first,
> the semantics of 'broader' may not, in fact, be subsumed by
> 'subClassOf', and second it's infeasible to do this for an interactive
> GUI tool, given the size of my concept hierarchies and the fact that
> they're typically stored in a database.

I've often wondered if it would be right to declare ...

rdfs:subClassOf rdfs:subPropertyOf skos:broader .

... ?  This question also relates to the earlier discussion about a
'denotes' property, and bears on the relationship between OWL semantics and
SKOS semantics.   
 
> 
> So what I actually do is to document, in an RDF meta-properties file,
> which property names are used in a given concept scheme for narrowing,
> broadening, equivalence and instantiating a concept.  I also 
> denote the
> topmost concept in the hierarchy. Since this latter feature is one of
> the properties of skos:ConceptScheme, I was wondering whether it might
> also be useful to include the characteristic concept relations as
> standard part of the concept scheme description in SKOS.

This sounds interesting, but I'm not sure exactly what you mean, could
expand this part for me?  What do you mean by 'equivalence' and
'instantiating'?  Could you post a snippet of a meta-properties file? 

SKOS Core does have a 'skos:hasTopConcept' property, which is there to allow
you to indicate the topmost (i.e. broadest) concepts for a given concept
scheme.     

But there is a deeper issue, which is that semantics and presentation are a
little confounded in SKOS Core.  I.e. Although skos:broader or any
sub-property thereof is usually displayed hierarchically, not everyone will
want to display skos:broader this way.  And often RDF properties other than
skos:broader are best displayed hierarchically, but those properties should
not be subsumed under skos:broader because the semantics are inappropriate.


Essentially I'm talking about separation of style and content (or in this
case style and meaning).  I don't think an author of a concept scheme should
specify which properties must be displayed as a tree, because users of the
scheme should be able to view (i.e. style) a concept scheme in different
ways.  

However, applications such as yours do need a way of specifying which
properties should be used by the application to generate a tree
representation.

Just a thought, one solution would be to define some RDF properties whose
semantic content is nothing, but whose default display is as tree generating
properties.  E.g. you could define tree:parent and tree:child as RDF
properties, then within your application declare that (skos:broader
style:displayAs tree:parent) and (rdfs:subClassOf style:displayAs
tree:parent).

If skos:broader were used as a generic tree property (i.e. you used it as
the super-property of all props you want displayed hierarchically), then
it's semantic content would become almost nothing, because of the many
meanings people have for trees.  
 
Cheers,

Al.



 

 


> 
> This is just a suggestion. If it's inappropriate for the goals (or
> timescales) of SKOS I won't be offended :-)
> 
> Regards,
> Ian
> 
> _____________________________________________________________________
> Ian Dickinson   HP Labs, Bristol, UK      mailto:ian.dickinson@hp.com
> net www.hpl.hp.com/personal/Ian_Dickinson       ph +44 (117) 312 8796
>

Received on Tuesday, 11 January 2005 14:02:27 UTC