RE: skos:ConceptScheme suggestion; separating style and meaning

Hi Al,
> 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.   
Is there a SKOS semantics? I kind of got the idea, perhaps quite
wrongly, that SKOS was aiming to create a vocabulary matching some
commonly held, intuitive, notions of KS modelling without getting too
hung up on semantics. If you want semantic rigour, don't you just use
OWL?

> 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? 
Sure.  Using N3 (because I find it a darn sight easier to edit the
source code :-)

# Tasks tool
:tasksTool a :KMAToolConfig
  ; :title "Tasks"
  ; :locationX "650"^^xsd:int
  ; :locationY "100"^^xsd:int
  ; :width "300"^^xsd:int
  ; :height "400"^^xsd:int
  ; :taxonomy :tasksTaxonomy
  ; :renderingRule
  		[   :ifResourceClass skos:Concept
  		  ; :image "images/concept-folder.jpg"^^xsd:string
  		]
  ; :renderingRule
  		[   :ifResourceClass kma:Task
  		  ; :image "images/task.jpg"^^xsd:string
  		]
  ; :renderer :standardRenderer
  ; :showInstances "true"^^xsd:boolean
  .

# Tasks taxonomy
:tasksTaxonomy
  a :TaxonomySource
  ; rdfs:comment "The user's personal task taxonomy"
  ; :rootResource kma:AllTasks
  ; :rootLabel "My tasks"
  ; :isEditable "true"^^xsd:boolean
  ; :broadeningProperty
          [ a :PropertyReference
            ; :propertyName skos:broader
          ]
  ; :narrowingProperty
          [ a :PropertyReference
            ; :propertyName skos:broader
            ; :useInverseProperty "true"^^xsd:boolean
          ]
  ; :equivalenceProperty
          [ a :PropertyReference
            ; :propertyName owl:sameAs
          ]
  ; :instanceProperty
          [ a :PropertyReference
            ; :propertyName skos:subject
            ; :useInverseProperty "true"^^xsd:boolean
          ]
  ; :modelID localJoseki:kmaStore
  .
 
> 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.     
Yes. I have rootResource as my property, but I could, and probably will,
change this to skos:hasTopConcept.

> 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.
Yes, I think this is quite right. There *are* two distinct, but
overlapping, sets of needs.  Display a data source that has some
hierarchical structure in a hierarchy is clearly one need.  But the
concept of broader and narrower (and isPartOf and part) are important
semantic constructs necessary for a variety of reasoning tasks,
irrespective of the presentation. skos:broader and skos:narrower, and
other such, serve both needs.

Note that there is a wrinkle that appears in the above N3.  The
'narrowing property' describes how to get the narrower concepts than a
given concept. SKOS has skos:narrower for this purpose, but my tasks
dataset only stores 'T1 skos:broader T2', and not 'T2 skos:narrower T1'.
Assuming an appropriate inference engine, this wouldn't matter. But,
seeing that a UI typically won't rely on a reasoner (for reasons
previously described), it's important for the taxonomy to describe
itself in operational terms. So the "narrowing property" is described as

  ; :narrowingProperty
          [ a :PropertyReference
            ; :propertyName skos:broader
            ; :useInverseProperty "true"^^xsd:boolean
          ]

which is how you would query for it in the DB.  So this seems to be a
case where the content description and the presentation can't easily be
completely separated.

> 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. 
Agreed. 
 
> 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).
Yes, I like this.  Following this through, there's probably a whole set
of generic properties and classes that can be used to characterise a
data source for the purposes of rendering or displaying it.  Respecting
the current zeitgeist, this would presumably be DOPS (description of a
presentation scheme) or DOUI (description of a UI) or something similar.

> 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.  
Agreed.

Regards,
Ian

Received on Tuesday, 11 January 2005 14:34:15 UTC