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

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

Indeed. A SELECT ASSERTED and SELECT INFERRED on a SPARQL implementation would be a much more elegant way of dealing with this. Otherwise each and every application that needs both would have to go through the trouble of having to query 2 rdf datasets. 
Workarounds with dual properties (re direct/non-direct) in 1 graph can indeed get very messy.

Christoffel


 

This email and its attachment(s) is confidential and intended solely for the use of the individual to whom it is addressed, and not intended to be further distributed without explicit prior approval of the sender. Any views or opinions presented are solely those of the author and do not necessarily represent those of Language & Computing, Inc. unless explicitly indicated. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited.

 

 


> -----Original Message-----
> From: public-swbp-wg-request@w3.org [mailto:public-swbp-wg-request@w3.org]
> On Behalf Of NJ Rogers, Learning and Research Technology
> Sent: vrijdag 9 december 2005 13:11
> To: Miles, AJ (Alistair); McBride, Brian; public-swbp-wg@w3.org
> Cc: public-esw-thes@w3.org
> Subject: 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)
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.371 / Virus Database: 267.13.13/195 - Release Date: 8/12/2005
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.13.13/195 - Release Date: 8/12/2005

Received on Friday, 9 December 2005 12:29:03 UTC