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

--On Friday, December 09, 2005 11:32:08 AM +0000 "Miles, AJ (Alistair)" 
<A.J.Miles@rl.ac.uk> wrote:

>
> 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.'
>
For what it is worth, when I wrote the DREFT software for SWADE I got round 
this problem programmatically (ie placed the burden of this functionality 
on to the software app). What I mean is that I switched off Sesame's 
inferencing over the transitive properties (hasPart etc.) so that I could 
merely retrieve the 'next level' of concepts around some given concept. To 
retrieve concepts from further levels away I issued iterative queries based 
on the results of the initial, 'direct' query.  It helped to do it this way 
because, as a web service, Dreft is also able to send concept result sets 
(as arrays) to clients that include a numerical indicator of "how many 
levels away" some set of concepts are (e.g. through broader/narrower 
relationships) from some starter concept. This helps with web service 
clients that want to drive browse user interfaces for example.

When I wanted to get DREFT to retrieve *all* concepts e.g. broader than a 
given concept, or a "top concept" associated with some concept (which again 
requires traversing the graph) then I used different rdf model data, 
mirroring the other but this time with inferencing switched on courtesy of 
Sesame.

I'm not saying this is the ideal solution, placing the burden on to the app 
(& having 2 separate rdf datasets to work with) is also clunky and feels 
like it doesn't leverage the semantics of a SKOS schema appropriately. 
However, these dual properties (re direct/non-direct) for SKOS feel very 
"work aroundy" too.

Nikki



> 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/direct
> ly.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
>



----------------------
NJ Rogers, Technical Researcher
(Senior Technical Developer and Coordinator of Web Futures)
Institute for Learning and Research Technology (ILRT)
Email:nikki.rogers@bristol.ac.uk
Tel: +44(0)117 9287113 (Direct)
Tel: +44(0)117 9287193 (Office)

Received on Friday, 9 December 2005 12:04:35 UTC