RE : shos:indexingRule ? Re: Side question : mapping OWL classes to SKOS concepts

Bernard, Jakob, Mark,

> Antoine's proposal makes sense of course technically speaking, and we
> have thought about this kind of solution in Mondeca. But in architecture
> terms, in the long run it does not seem a good idea to have indexing
> rules declared inside the ontology. The ontology is better off keeping
> agnostic on the way its instances will be indexed, and moreover they can
> be indexed different ways against different concept schemes. So I prefer
> the modular approach proposed in an earlier message by Jakob to have the
> indexing rules in SPARQL (or any other relevant query or rule language)
> specified outside the ontology.


I think like Mark that I can understand your sentiment, and in fact you might have (partly) misunderstood  my proposal. I said that the 'ontology' specifying the indexing rule could be specified in an RDF file/source *different from the ontology one*. This way, you could have your canonical ontology describing the core understanding of hotels and so on, plus an 'indexing ontology' that you would activate for your specific application, the same way you would load indexing rules in another rule language. I think this proposal is not fundamentally different from Jakob's one from the 'architecture'/'modularity' view. And it has the nice aspect of having the rules specified in a way homogeneeous with your ontology and SKOS concept scheme. With Jakob's solution you still have to manage the link between your classes/concepts in OWL/SKOS and your SPARQL queries, what actually you try to do in the following...


> But following up with this idea, and the other way round of Antoine's
> proposal, the concept scheme itself could integrate the declaration of 
> its indexing rules, in the form of some equivalent for machines of
> skos:scopeNote, which conveys, if you look closely, some sort of
> indexing rule for humans.
> So something like skos:indexingRule, which could contain a formal
> indexing rule in whatever syntax. I've in mind full-text indexing
> engines we are currently working with (Verity, Lucene ...) which use
> their specific rule language (boolean rules, whatever). They will not
> shift to SPARQL or OWL easily, but they will more easily willing to
> represent their taxonomies/classifications/index as SKOS concept schemes
> if we provide them with a way to wrap their own rules in some attribute
> of skos:Concept, like
>
> <skos:Concept rdf:about = ...>
>     ...
>     <skos:indexingRule>
>        [my indexing rule in whatever syntax goes here]
>     </skos:indexingRule>
>     ...
> </skos:Concept>
>
> Bottom line : SKOS is certainly the best tool at hand for costless
> migration to SW of existing technology which do not require any of the
> expressive power of OWL, and don't want to jump in it right now. With
> the above proposal, you can mix up a simple SW structure with non-SW but
> nevertheless effective and powerful indexing tools. Actually the same
> SKOS concept scheme could declare either or both SW rules, e.g. in
> SPARL, to index content with RDF metadata, and non-SW rules, to index
> classical content through full-text search.
>
> Forcing existing technologies to go through complete OWL migration
> before starting to play in SW field makes a too steep adoption curve,
> and is certainly the best way to make them fly away.

I understand your point, and think your proposal is really interesting (including the comparison with scope notes). But we should be sure that having SKOS concept schemes overburdened with rules that are specific to very specific engines will not deter your users the same way that creating auxiliary OWL knowledge sources would have done!

Best,

Antoine

PS: Jakob and Bernard, when you talk about SKOS simplicity, don't forget that SKOS specification (and therefore proper use of SKOS) sometimes rely on OWL-like features like property transitivity ('characteristic' of  [1]) and even rules that are simple but out of OWL scope ('comment' in [2])

[1] http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20051102/#broader
[2] http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20051102/#subject