Moreover, "Localization", even more than "inference", belongs to a given user's world view. To the highest layer between the lower end of "the data" and the higher end of "the user".
( data )-----( business, rules and other inferences )----( geo )----( localization )---> ( user ) I don't like how today I am forced to hard code language heuristics to queries that are otherwise 100% business. This is just plain wrong and there should be an alternative. Thx, A On Sun, Jan 24, 2010 at 12:18 PM, Aldo Bucchi <[email protected]> wrote: > Hi, > > This is a BIG feature request, but it is something that I use daily > via generators and I think we should bring it down into SPARQL itself > as it accounts for a very common usecase. > Of course I could try to write and push this into the next SPARQL > recommendation, but then it would eventually circle back to you guys > to see if you can implement it... So I guess the other way around > makes more sense ;) > > The basic idea: > > * There is a way to declare a global list of languages alongside a > query of arbitrary complexity > * These will be implicitly used to discern which literals to return > * The filtering is a bit more complex than a mere filter() as the list > imposes an "order of preference" amongst languages > > So a sample query may look like this: > > sparql > define lang "en-US,en,de,*" > select ?label where { ?something rdfs:label ?label } > > Implicitly, the literals ( in this case ?label ) will be matched > against the languages defined in the pragma and the match with the > highest preference will be returned ( if any ). > > This is analog to having an ordered set of UNION'ed clauses ( not easy > to accomplish as the order of evaluation is not deterministic ) or > several optionals with the following tests: > > filter( langmatches( lang(?label), 'en-US' ) ) > filter( langmatches( lang(?label), 'en' ) ) > filter( langmatches( lang(?label), 'de' ) ) > filter( langmatches( lang(?label), 'fr' ) ) > filter( langmatches( lang(?label), null ) ) > filter( 1=1 ) > > The latter ( 1=1 ) is the star (*) which matches "any" language. Even Zwagili > ;) > The keyword "none" will match literals with no lang tag ( plain literals ). > > Even for this trivial case we can see the advantage of using such > facility. Imagine what happens when there is more than one literal in > the query ( which is usually the case ). > > What do you guys think? > > Thanks! > A > > -- > Aldo Bucchi > skype:aldo.bucchi > http://www.univrz.com/ > http://aldobucchi.com/ > > PRIVILEGED AND CONFIDENTIAL INFORMATION > This message is only for the use of the individual or entity to which it is > addressed and may contain information that is privileged and confidential. If > you are not the intended recipient, please do not distribute or copy this > communication, by e-mail or otherwise. Instead, please notify us immediately > by > return e-mail. > -- Aldo Bucchi skype:aldo.bucchi http://www.univrz.com/ http://aldobucchi.com/ PRIVILEGED AND CONFIDENTIAL INFORMATION This message is only for the use of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If you are not the intended recipient, please do not distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail.
