Re: function library summary and issues

On 2010-11-28, at 17:56, Andy Seaborne wrote:
> On 28/11/10 16:30, Steve Harris wrote:
>> On 2010-11-28, at 15:34, Andy Seaborne wrote:
>>> 
>>> On 28/11/10 15:14, Steve Harris wrote:
>>>>>>  If we require it, it seems natural to me to have:
>>>>>> 
>>>>>>    CONCAT("a"@en, "b"@en) ->   "ab"@en
>>>>>>    CONCAT("a"@en, "b"@fr) ->   "ab"  (or error)
>>>>>>    CONCAT("a"@en, "b") ->   "ab"  (or error)
>>>> There are legitimate cases where you might have some literals without tags, and some with, and want to concatenate them, without having loads of logic.
>>> 
>>> (just sorting out the small details)
>>> 
>>> This can be achieved by using STR:
>>> 
>>> CONCAT(STR("a"@en), STR("b"@fr)) ->   "ab"
>>> 
>>> Is that too much logic?
>> 
>> That's not what I was thinking of as logic, but then you can't preserve the lang tag, if one applies. Might not matter though.
>> 
>> I was thinking of cases like:
>> 
>> <distilation>  a :Process ;
>>               :name "Distillation", "Дестилация"@ru ;
>>               :produces "C2H5OH" .
>> 
>> SELECT (CONCAT(?name, " ->  ", ?produces))
>> WHERE {
>>   ?process a :Process ;
>>            :name ?name ;
>>            :produces ?produces .
>>    FILTER(lang(?name) = "ru" || lang(?name) = "")
>>    FILTER(lang(?produces) = "ru" || lang(?produces) = "")
>> }
>> 
>> If we preserve lang tags then you'll get:
>> 
>> "Дестилация ->  C2H5OH"@ru
>> "Distillation ->  C2H5OH"
>> 
>> With STR() you'd lose the lang tag.
> 
> I came up with:
> 
> STRDT(CONCAT(?name, " ->  ", ?produces), lang(?name))

In this case, I'd want more like:

IF(lang(?name) && lang(?process) && lang(?name) = lang(?process), lang(?name), IF(lang(?name) && !lang(?process), lang(?name), IF(!lang(?name) && lang(?process), lang(?process), "")))

(modulo typos) which is doable, but a bit of an eyeful. Without knowing the exact process in question you don't know if ?name, or ?produces is going to have the lang tag(s).

> in other words, produce a string without lang tag and separate out the decision of which language to use rather than have a fixed policy in CONCAT.  You can even have a mixture of language tags (@en and @en-uk and @en-UK) abd decide somehow..

Yeah, it's the somehow. There are certainly going to be very complex situations where you would have to do the processing in the application logic realistically, but preserving lang tags where appropriate seems like it would be helpful.

> Seeing that example, I think I prefer this approach - do the least in CONCAT and leave the rest to the query logic.
> 
>> This might be nonsense scientifically speaking, the example I'm most familiar with is from signal processing, but it's hard to explain without a lot of context. I hope it makes the point though.
> 
> To summarise: We have the following possibilities:
> 
> 0/ Do/Don't specific the use of CONCAT in the case of lang tags.
> 
> Different lang tags (two or more distinct lang tags in a the CONCAT arg list):
> 
> 1/ -> error
> 2/ -> simple literal
> 
> Mixture of simple literals and one distinct lang tag
> 3/ -> error
> 4/ -> simple literal
> 5/ -> literal with that lang tag

I prefer 2 & 5, on balance. Stripping lag tags is easy, reconstructing them, no so much.

- Steve

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Sunday, 28 November 2010 18:30:46 UTC