W3C home > Mailing lists > Public > public-swbp-wg@w3.org > December 2005

RE: [WN, SPARQL, ALL] Describe

From: McBride, Brian <brian.mcbride@hp.com>
Date: Wed, 14 Dec 2005 16:40:47 -0000
Message-ID: <DE62D3D0BDEF184FBB5089C7D387C37460D10C@sdcexc04.emea.cpqcorp.net>
To: "McBride, Brian" <brian.mcbride@hp.com>, "Jacco van Ossenbruggen" <Jacco.van.Ossenbruggen@cwi.nl>, <public-swbp-wg@w3.org>

Reading the message I just sent (after our Christmas lunch, hic :) I'm
reminded of my guidance to self, that we should couch our answers in
terms of specific requirements of the work of SWBPD, i.e. are there
specific guarantees we would like to see for DESCRIBE or Wordnet or SKOS


> -----Original Message-----
> From: public-swbp-wg-request@w3.org 
> [mailto:public-swbp-wg-request@w3.org] On Behalf Of McBride, Brian
> Sent: 14 December 2005 16:30
> To: Jacco van Ossenbruggen; public-swbp-wg@w3.org
> Subject: RE: [WN, SPARQL, ALL] Describe
> Hi Jacco,
> > McBride, Brian wrote:
> > 
> > >So a position for discussion:
> > >
> > >1. The DESCRIBE functionality would be useful for Wordnet.
> > >
> > >2. It would be useful stand alone, not as part of SPARQL.
> > >
> > >3. It would also be useful as part of SPARQL, but less so.  
> > An example
> > >might be a query that queried multiple Wordnets for
> > different languages
> > >for "chat" and returned dscriptions of each of the word senses.
> > >  
> > >
> > I had missed this mail from Brian, and the last time I had read the 
> > SPARQL draft it did not mention DESCRIBE, so I could not 
> answer Guus's 
> > question on this during the previous teleconf.  Having 
> catched up, I 
> > agree with Brian's point at
> > 1) and 2) above.
> :)
> >  My position concerning 3) would be stronger than his:  I think any 
> > useful implementation of DESCRIBE is so dependent on the vocabulary 
> > being queried, that it should NOT be part of the core of a general 
> > query language such as SPARQL (all the other functionality 
> of SPARQL 
> > can be implemented independent of the data being queried, 
> this would 
> > be the only exception) .
> Chatting with Andy Seaborne today (that is an acknowledgement 
> rather than name dropping :) he pointed out that there are 
> some vocabularies where DESCRIBE might be useful, but where 
> the resource to be described is represented is not named but 
> is represented by a b-node.  He cited FOAF as an example.  In 
> this case it is useful to be able to DESCRIBE a variable in a query.
> But I think your point here is that queriers might want some 
> guarantees about what would be returned as the result of a 
> DESCRIBE query and that such guarantees are dependent on the 
> vocabulary.  I think this is a valid point, though it is not 
> one that I feel qualified to make much in the way of 
> definitive statements of requirements.
> I suppose I am wondering whether we might deal with this but 
> allowing SPARQL to support the general vocabulary in the 
> query language and then individual vocabularies could 
> suggest/require what should be returned as the result of a 
> DESCRIBE query.  This would then make the behaviour of the 
> query server depend on particular vocabularies.  One might 
> envisage a standard for describing the the results that 
> should be returned as the result of a describe query which 
> might defined in terms of an equivalent SPARQL query, e.g. 
> for resource of type X, return the graph generated by query 
> Q.  I suspect the waters are murky when we have mixed 
> vocabularies, but might not be too bad.
> An alternative line might be that there is no guarantee about 
> what might be returned and application that does not find the 
> information it needs returned as the result of a describe 
> query must be prepared to issue further queries to get the 
> information it needs.
> > 
> > Having said this, we might want to encourage the DAWG to 
> continue work 
> > on DESCRIBE, as it would be useful for Wordnet, SKOS and 
> every other 
> > large ontology of which one might want a concise description of a 
> > single resource.  I think they will still have an interoperability 
> > issue.  I do not buy the argument that the type of functionality 
> > offered by DESCRIBE doesn't need to be interoperable.  If a machine 
> > needs to be able to do anything useful with the result, there will 
> > need to be a minimum set of assumptions the machine can 
> make about the 
> > result.  Also, one might expect that different Wordnet servers at 
> > least return the same _type_ of information for the same 
> query. So one 
> > might want to have an RDF vocabulary in which you can specify the 
> > result of DESCRIBE for a given type of resource.
> There may be a class of application where just showing the 
> user what the server chose to return is good enough or what 
> is in fact the desired behaviour.  
> There may be a class of application where the application 
> knows enough about the vocabulary to ask for stuff that is 
> missing, though in that case it could have stated explicitly 
> what it wanted in the first place.
> In that case using DESCRIBE might just be syntactic shorthand 
> for the lazy programmer, or a way of saying "tell me what you 
> know" which might be more than the application was expecting, 
> though again that could be explicitly coded in the query.
> There might be some value for DESCRIBE in handling multiple 
> versions of vocabularies, where the query to specified 
> depends on the version of the vocabulary being used.
> It could be that the Wordnet and SKOS documents can give 
> guidance on what a server should return when resources of a 
> particular type are DESCRIBED, and as I suggested above, 
> there might be a mechanism for vocabilaries to describe what 
> should be returned.
> I'm not yet clear in my own mind what I think about this 
> issue.  At the time writing it seems to me that the value of 
> DESCRIBE is when applications don't know what to expect and 
> the server gets to choose, and also as a short hand for what 
> otherwise be a tedious query to specify, but I'd like to hear 
> Jacco's and other's thoughts before continuing.
> Brian
Received on Wednesday, 14 December 2005 17:09:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:15 UTC