W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > June 2007

Re: Using Labels in SPARQL

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Fri, 1 Jun 2007 18:24:55 +0100
Message-Id: <2F3B465E-1EC8-4FC1-B6A1-80C44089C5A6@cs.man.ac.uk>
Cc: public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>
To: Chris Mungall <cjm@fruitfly.org>

On 1 Jun 2007, at 16:38, Chris Mungall wrote:

>
> On Jun 1, 2007, at 3:31 AM, Bijan Parsia wrote:
>
>>
>> Looking at some of the queries in:
>> 	http://esw.w3.org/topic/HCLS/Banff2007Demo? 
>> action=AttachFile&do=get&target=Banff2007Part2.pdf
>>
>> I am reminded again of the practice of using gensyms for the URIs  
>> of terms, e.g.,:
>> 	?class rdfs:subClassOf go:GO_0008150
>
> this isn't really a gensym but never mind

Yes, sorry, I should have written "Not readable".

> - it's the stable identifier for the class, or rather a  
> bastardization of the stable identifier to make it conform to the  
> URI standard
>
>> In Swoop, we added the ability for the display (e.g., class tree,  
>> definitions) to replace URIs with the label of your (language)  
>> choice.
>
> very nice it is too - I believe you added this on my request when I  
> was playing with GO in Swoop back in the day

Not surprised :) I liked the ability to flip a switch and see  
everything in a different language.

[snip]
>> LABELS obo:myEnglishLabels FOR <http://www.geneontology.org/ 
>> formats/oboInOwl#>
>>
>> select  ?name  ?class ?definition
>> from <http://purl.org/commons/hcls/20070416>
>> where
>> {   graph <http://purl.org/commons/hcls/20070416/classrelations>
>>      {?class rdfs:subClassOf NiceNameForGO_0008150}
>>     ?class rdfs:label ?name.
>>     ?class obo:hasDefinition ?def.
>>     ?def rdfs:label ?definition
>>     filter(regex(?name,"[Dd]endrite"))
>> }
>
> wouldn't the argument have to be a literal?

No idea ;)

> E.g.
>
> LABELS obo:myLabels FOR <http://www.geneontology.org/formats/ 
> oboInOwl#>
>
> ?class rdfs:subClassOf "biological process"@en			(this is the label  
> for GO:0008150)

Oh, I see. Yes, probably. Though, perhaps we could special case  
labels designed for such things. Hmm. That sounds like it belongs in  
the tool layer.

>> I'm not sure if we'd want to let that sugar percolate into the  
>> rdfs:label queries. Then the query would look like:
>>
>> select  ?class ?definition
>> from <http://purl.org/commons/hcls/20070416>
>> where
>> {   graph <http://purl.org/commons/hcls/20070416/classrelations>
>>      {?class rdfs:subClassOf NiceNameForGO_0008150}
>>     ?class obo:hasDefinition ?def.
>>     filter(regex(?class,"[Dd]endrite"))
>> }
>> It just strikes me that all the label probing is beside the  
>> actually application logic of the query and gets in the way.
>>
>> If one want to get the uri as well, a function could do that,  
>> perhaps even in the head.
>
> I'll bet Alan has some lisp macro facility to do this already in  
> his LSW s-expression syntax sparql queries

Indeed.

> Even though I'm not keen on specifying the extra triples in the  
> query I'm not sure this warrants ad-hoc extensions to a standard.

Well, it was more of a use case. I'm thinking about syntactic sugar  
for sparql as a whole and this seems to be an important case.

> I'd rather see it part of a more general mechanism, such as a  
> function in the head. It would feel more natural to write:
>
> ?class rdfs:subClassOf hasLabel("biological process"@en)

That does seem neater. You could do the hasLabel in the filter as  
well and cover both cases:

	select  ?name  ?class labelFor(?definition)
...
	?class rdfs:subClassOf hasLabel("biological process"@en).
     	?class obo:hasDefinition ?def.
     	filter(regex(hasLabel(?class),"[Dd]endrite")

Or something like that. The tricky bit comes if you want to select a  
particular set of labels using some hypothetical future label tagging  
mechanism. Perhaps that could be handled by query macros, e.g.,

def hasLabel ?x
	?x rdf:label ?y
	return ?y

Or some such. You could define these up top and have some query in  
the body.

Cheers,
Bijan.
Received on Friday, 1 June 2007 17:24:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:48 GMT