RE: [SKOS, SPARQL, ALL] Closure and SPARQL

Hi all,

> I earlier suggested that SPARQL does not have to support transitive
> closure because the graph can do it.  There can be an 
> inferencing graph
> which computes the transitive closure of skos:narrower.  If you query
> that graph you query the transitive closure relationship.  If 
> you query
> the ground graph you get the direct, well at least directly asserted,
> relationship.  The question arises, whether there is a need to
> distinguish between the direct relationship and the closure
> relationship.  Are these different properties.  Should we define
> skos:inNarrowerClosure (or something more appealingly named).

Just a quick comment on this design pattern:

>From [1] section 'General Issues > Transitive relations - parts and direct parts.' ...

'In many applications, what is needed is not a list of all parts but rather a list of the next level breakdown of parts, the "direct parts" of a given entity. It is therfore often useful to use the property hierarchy to define a subproperty of hasPart that is not transitive and links each subpart just to the next level. For these examples we shall call this subproperty hasPart_directly. Note of course that the mere idea of a "direct" part is subjective, one may invent intermediate direct parts depending on numerous factors, or eliminate them.'

There is an overhead wrt to the 'direct subproperty' pattern for transitive properties, that arises when you wish to make refinements of these properties. E.g. let's say I start with skos:narrower. Because skos:narrower is transitive, I also declare a subproperty of skos:narrower, called skos:narrower_direct. Now, let's say a third party needs a property that is a refinement of skos:narrower, so they invent a property eg:narrowerSubstance, and declare it as a sub-property of skos:narrower. To get the direct behaviour, they also have to define a property eg:narrowerSubstance_direct and declare that as a subproperty of skos:narrower_direct. You end up with a property tree that looks like:

Image: http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/scratchpad/directly.png

I don't think this is so complex as to be unworkable, but it is a bit cumbersome, and it does feel like a workaround.  I'd certainly appreciate a best practice note on how to handle this properly, e.g. via different sparql endpoints, if that is the best way?
      
Cheers,

Al.

[1] http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/index.html

Received on Friday, 9 December 2005 11:32:35 UTC