Re: [Wikidata-l] Wikidata Transclusions
On 14/06/12 00:39, jmccl...@hypergrove.com wrote: Transclusion is surely fundamental to wiki application design. The [[wikidata]] proposal by contrast is a client-server API, such things an artifact of the 20th century. What is the point of it here? Ultimately the problem you're grappling with is not just just about infoboxes, it's about *anything* other than article text that has multilingual requirements. For instance, the same *pie chart* is to be shared among wikipedias, the only difference being the graph's title, key and other labels... [[wikidata]] is today doing format=table, later other formats. That's alot to handle in an API. I don't think Wikidata will ever do other formats. Wikidata will only export pure data. So, it's highly advised the client-server API approach be scrapped. At a minimum, it's outdated technology, for good reasons. Instead, wikidata should *publish* infoboxes that are happily cached on wikidata servers. That's the best performance that can possibly be had. Wikidata publishing infoboxes and Wikipedias using them is again the client-server model. And if Wikidata publishes infoboxes, pie charts and the like, THAT will complicate the API, not the current approach. Not to mention that Wikipedias have and want to have different infobox designs. smime.p7s Description: S/MIME Cryptographic Signature ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
While I agree that it is desirable to support simple, preformatted Infoboxes that can, with minimal effort be re-used in a large number of language versions of Wikipedia, I strongly disagree with the demand to make this the only choice. I think the present Wikidata approach to allow local Wikipedias to customize their infoboxes by accessing wikidata properties property-by-property is the right path. The large Wikipedias with many editors have invested considerable creative energy into making quite a large number of infoboxes elaborate information containers. That includes formatting, images and hand-crafted links in both the field name and the field value side. Some values are expressed through svg graphics, other values expressed through background color coding, etc. Limiting the usability of Wikidata to plain vanilla infox boxes could cause considerable resistance in these communities. And although small Wikipedia will profit a lot from Wikidata, without the engagement of editors from the large Wikipedias into curating Wikidata content, the increased synergies will not happen. Another issue is that (I believe that) Wikidata does not have a notion of ordering properties. Correct? This is no issue for the present Wikidata approach because infoboxes remain curated in each local Wikipedia. However, in a centralized one size fits all approach, replacing existing infoboxes where information is presented in a logical order with an alphabetical property order would create huge resistance (and would be a complex issue that Wikidata would have to deal with, allowing property ordering and filtering). I believe that Wikidata correctly aims to provide a smooth transition path, where it is possible to obtain only part of an infobox from wikidata and inject wikidata content into existing infobox layouts. That said: I would encourage a third party contributor to try to create a default Wikidata infobox generator in a way (extension installable in multiple Wikipedias) that enables a wikipedia to autocreate a good looking, plain vanilla infobox with minimal effort. Gregor ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
Hoi, Technically there is nothing stopping Wikidata from hosting multiple infoboxes on the same subject. The big thing about such infoboxes is that their layout is the same for all subjects in the same category. This does not mean that every one looks the same but it does mean they follow a consistent pattern. When people talk about things like colours and stuff, it becomes highly emotional but in the final analysis at this stage it is just more bike shedding. It should be obvious that attributes like colour can be overriden.. Given that info boxes will not be supported in the near future ... The notion that people should curate the info boxes locally is something that I do not subscribe to. Not being able to agree on data and sources is the same as not being able to reach a neutral point of view. This does not mean that multiple sources may not agree but equally it does not mean that different sources cannot be maintained from within Wikidata. Finally, when Wikidata provides data and info boxes, it does not mean that any project is compelled to use it. As Wikidata matures, it will become increasingly clear that it is not the best practice. Thanks, GerardM On 14 June 2012 12:11, Gregor Hagedorn g.m.haged...@gmail.com wrote: While I agree that it is desirable to support simple, preformatted Infoboxes that can, with minimal effort be re-used in a large number of language versions of Wikipedia, I strongly disagree with the demand to make this the only choice. I think the present Wikidata approach to allow local Wikipedias to customize their infoboxes by accessing wikidata properties property-by-property is the right path. The large Wikipedias with many editors have invested considerable creative energy into making quite a large number of infoboxes elaborate information containers. That includes formatting, images and hand-crafted links in both the field name and the field value side. Some values are expressed through svg graphics, other values expressed through background color coding, etc. Limiting the usability of Wikidata to plain vanilla infox boxes could cause considerable resistance in these communities. And although small Wikipedia will profit a lot from Wikidata, without the engagement of editors from the large Wikipedias into curating Wikidata content, the increased synergies will not happen. Another issue is that (I believe that) Wikidata does not have a notion of ordering properties. Correct? This is no issue for the present Wikidata approach because infoboxes remain curated in each local Wikipedia. However, in a centralized one size fits all approach, replacing existing infoboxes where information is presented in a logical order with an alphabetical property order would create huge resistance (and would be a complex issue that Wikidata would have to deal with, allowing property ordering and filtering). I believe that Wikidata correctly aims to provide a smooth transition path, where it is possible to obtain only part of an infobox from wikidata and inject wikidata content into existing infobox layouts. That said: I would encourage a third party contributor to try to create a default Wikidata infobox generator in a way (extension installable in multiple Wikipedias) that enables a wikipedia to autocreate a good looking, plain vanilla infobox with minimal effort. Gregor ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
On 14 June 2012 12:33, Gerard Meijssen gerard.meijs...@gmail.com wrote: Finally, when Wikidata provides data and info boxes, it does not mean that any project is compelled to use it. As Wikidata matures, it will become increasingly clear that it is not the best practice. that may be, but Wikidata needs a path to get there. I think the ability to integrate wikidata into existing the infobox consensus of a Wikipedia community is essential for adoption. Over time, centrally provided infoboxes with ever increasing customization functionality (order, selection, arrangement, linking properties to Wikipedia pages explaining them, etc.) are desirable and at some point the evolution of wiki data may conclude that this become the preferred method. Gregor ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
Wikidata publishing infoboxes and Wikipedias using them is again the client-server model. Not sure where this chestnut is coming from. Transclusion is as close to client-server as my cooking is to being gourmet! There's NO API. so I don't understand your commenst at all, sorry. On 13.06.2012 23:48, Nikola Smolenski wrote: On 14/06/12 00:39, jmcclure@hypergrove.comwrote: Transclusion is surely fundamental to wiki application design. The [[wikidata]] proposal by contrast is a client-server API, such things an artifact of the 20th century. What is the point of it here? Ultimately the problem you're grappling with is not just just about infoboxes, it's about *anything* other than article text that has multilingual requirements. For instance, the same *pie chart* is to be shared among wikipedias, the only difference being the graph's title, key and other labels... [[wikidata]] is today doing format=table, later other formats. That's alot to handle in an API. I don't think Wikidata will ever do other formats. Wikidata will only export pure data. So, it's highly advised the client-server API approach be scrapped. At a minimum, it's outdated technology, for good reasons. Instead, wikidata should *publish* infoboxes that are happily cached on wikidata servers. That's the best performance that can possibly be had. Wikidata publishing infoboxes and Wikipedias using them is again the client-server model. And if Wikidata publishes infoboxes, pie charts and the like, THAT will complicate the API, not the current approach. Not to mention that Wikipedias have and want to have different infobox designs. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
I strongly disagree with the demand to make this the only choice.
-
Gregor, I'm a bit confused -- are you talking about the transclusion
design approach in this statement? because, if so, I'd think there'd be
a number of infobox styles that can be selected by an author on the
wikidata platform when 'building' the infobox page. The author can
transclude any number/any specific infobox(es) on their wikipedia page,
eg
{{wikidata:en:Infobox:Some topic/some custom imfobox}}
On
14.06.2012 03:11, Gregor Hagedorn wrote:
While I agree that it is
desirable to support simple, preformatted
Infoboxes that can, with
minimal effort be re-used in a large number
of language versions of
Wikipedia, I strongly disagree with the demand
to make this the only
choice.
I think the present Wikidata approach to allow local
Wikipedias to
customize their infoboxes by accessing wikidata
properties
property-by-property is the right path.
The large
Wikipedias with many editors have invested considerable
creative
energy into making quite a large number of infoboxes
elaborate
information containers. That includes formatting, images and
hand-crafted links in both the field name and the field value
side. Some values are expressed through svg graphics, other values
expressed through background color coding, etc.
Limiting the
usability of Wikidata to plain vanilla infox boxes could
cause
considerable resistance in these communities. And although small
Wikipedia will profit a lot from Wikidata, without the engagement of
editors from the large Wikipedias into curating Wikidata content, the
increased synergies will not happen.
Another issue is that (I
believe that) Wikidata does not have a notion
of ordering properties.
Correct? This is no issue for the present
Wikidata approach because
infoboxes remain curated in each local
Wikipedia. However, in a
centralized one size fits all approach,
replacing existing infoboxes
where information is presented in a
logical order with an alphabetical
property order would create huge
resistance (and would be a complex
issue that Wikidata would have to
deal with, allowing property
ordering and filtering).
I believe that Wikidata correctly aims to
provide a smooth transition
path, where it is possible to obtain only
part of an infobox from
wikidata and inject wikidata content into
existing infobox layouts.
That said: I would encourage a third
party contributor to try to
create a default Wikidata infobox
generator in a way (extension
installable in multiple Wikipedias) that
enables a wikipedia to
autocreate a good looking, plain vanilla
infobox with minimal effort.
Gregor
___
Wikidata-l mailing
list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
Gregor, I'm a bit confused -- are you talking about the transclusion design
approach in this statement?
Yes, in the sense that it demands to be the only access to wiki data
content in a Wikipedia.
because, if so, I'd think there'd be a number of
infobox styles that can be selected by an author on the wikidata platform
when 'building' the infobox page. The author can transclude any number/any
specific infobox(es) on their wikipedia page, eg
{{wikidata:en:Infobox:Some topic/some custom imfobox}}
As I say, I look forward to see an infobox builder being developed,
but this is a serious challenge.
See, e.g. http://en.wikipedia.org/wiki/Tiger and take a look at the
hierarchical arrangement of properties, formatting of them, linking of
them (Headings link to concept explanations on the same-language
Wikipedia, with the link being different than the display text, Early
Pleistocene – Recent may be a time range, but the value is Early
Pleistocene and the link is Pleistocene; similarly each taxonomic
author - here only ony present, Linnaeus - should link on en.wikipedia
to en.wikipedia and de.wikipedia to de.wikipedia), expressing some
information with graphics, see Endangered (IUCN 3.1)[1], properties or
property values containing footnotes, the fact that a subspecies is
extinct being abbreviated with a symbol (†P. t. virgata) etc. Note
that the latter case is actually a nesting: it is a list of
subspecies, with each subspecies having multiple properties like
Scientific Name, Wikipedia Page name, extinction status - I am not
sure Wikidata plans to model such data in Phase 2 already.
My bottomline: Keep the wikidata project manageable and doable with
the available resources. Offer a method for Wikipedians to pick up
Wikidata content within the existing template infrastrukture.
But, desirable: ask a white paper which additional work would be
required to create centralized, plain vanilla infobox rendering as
well.
Would you be willing to create such a whitepaper? How much of the
above-shown Tiger example can be created centrally with a limited set
of facilities? How feature rich must the customization become?
Or are you proposing to simply use the existing template programming
with the only the difference that wikidata is the only mediawiki where
the properties can be accessed within templates? Much of my argument
assumes that you are looking for a non-template based infobox
renderer, I may be wrong there.
Gregor
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
Gregor says
Or are you proposing to simply use the existing
template programming
with the only the difference that wikidata is the
only mediawiki where
the properties can be accessed within templates?
Much of my argument
assumes that you are looking for a non-template
based infobox
renderer, I may be wrong there.
I am proposing that, from
the perspective of the Tiger article author, I would log on to wikidata
and create a page called Infobox:Tiger using a Semantic Form named
Taxobox whose fields track to the args for the Taxobox template. On
the form, one would select whether a genus, familia, ordo, ... regnum is
represented by the page... assume genus was selected,
so.
{{Taxobox
| status = EN (DUBLIN CORE PROPERTY: LANGUAGE)
|
fossil_range = Early [[Pleistocene]] - Recent (DUBLIN CORE: COVERAGE)
|
status_system = iucn3.1 (DUBLIN CORE: FORMAT)
| trend = down (DUBLIN
CORE: FORMAT)
| status_ref =ref name=IUCN/ (DUBLIN CORE: IDENTIFIER)
|
image = Tiger in Ranthambhore.jpg (EMBEDDED {{IMAGE}} TEMPLATE CALL)
|
image_caption = A [[Bengal tiger]] (''P. tigris tigris'') in India's
[[Ranthambhore National Park]]. (PART OF {{IMAGE}} TEMPLATE CALL)
|
image_width = (PART OF {{IMAGE}} TEMPLATE CALL)
| regnum = [[Animal]]ia
(UNNECESSARY - LOOK IT UP VIA #ASK)
| phylum = [[Chordate|Chordata]]
(UNNECESSARY - LOOK IT UP VIA #ASK))
| classis = [[Mammal]]ia
(UNNECESSARY - LOOK IT UP VIA #ASK))
| ordo = [[Carnivora]] (UNNECESSARY
- LOOK IT UP VIA #ASK))
| familia = [[Felidae]] (UNNECESSARY - LOOK IT
UP VIA #ASK))
| genus = ''[[Panthera]]'' (DUBLIN CORE PROPERTY:
RELATION)
| species = 'P. tigris' (DUBLIN CORE PROPERTY:
TITLE)
| binomial = ''Panthera tigris'' (EMBEDDED {{BINOMIAL}} TEMPLATE
CALL)
| binomial_authority = ([[Carl Linnaeus|Linnaeus]], 1758) (PART OF
EMBEDDED {{BINOMIAL}} TEMPLATE CALL)
| synonyms = (DUBLIN CORE PROPERTY:
TITLE)
center'Felis tigris' small[[Carl
Linnaeus|Linnaeus]], 1758/smallref name=Linn1758 / br
/
'Tigris striatus' small[[Nikolai Severtzov|Severtzov]],
1858/smallbr /
'Tigris regalis' small[[John Edward
Gray|Gray]], 1867/center
| range_map = Tiger_map.jpg (EMBEDDED
{{IMAGE}} TEMPLATE CALL)
| range_map_width = (PART OF EMBEDDED {{IMAGE}}
TEMPLATE CALL)
| range_map_caption = Tiger's historic range in ca. 1850
(pale yellow) and range in 2006 (in green).ref name=dinerstein07 /
|
subdivision_ranks = [[Subspecies]]
| subdivision = (UNNECESSARY - LOOK
IT UP VIA #ASK)
''[[Bengal tiger|P. t. tigris]]''br/
''[[Indochinese
tiger|P. t. corbetti]]''br /
''[[Malayan tiger|P. t. jacksoni]]''br
/
''[[Sumatran tiger|P. t. sumatrae]]''br /
''[[Siberian tiger|P. t.
altaica]]''br /
''[[South China tiger|P. t. amoyensis]]''br
/
†''[[Caspian tiger|P. t. virgata]]''br /
†''[[Bali tiger|P. t.
balica]]''br /
†''[[Javan tiger|P. t. sondaica]]''
}}
One could
create [[en:Infobox:Tiger]] and [[de:Infobox:Tiger]] to handle language
differences. Alternatively there'd be only [[Infobox:Tiger]] that has
language-qualified string properties, e.g, Title^en contains english
title for the page vs Title^de that contains the German title, with the
#ask pulling the correct one given the wiki's language eg
|?Title^{{CONTENTLANG}}
For links, use the same magic word eg
|genus={{CONTENTLANG}}:Panthera
To be a bit fancier:
|genus={{#ifexist:{{CONTENTLANG}}:Panthera|{{CONTENTLANG}}:Panthera|en:Panthera}}
Now, the above is a traditional non-topicmap treatment without
provenance. Let's add provenance first:
|genus={{Dublin
Core|value=Panthera|creator={{USERNAME}}|date={{TODAY}}|language=}}
Now lets add the topicmap orientation
|genus={{Topic|name=Panthera|creator={{USERNAME}}|date={{TODAY}}|language=}}
So there's certainly alternatives to look at. The basic theme though
is NOT to create a specialized factbox editor but rather is to use
Semantic Forms to capture the values of template args - values that can
be links, text, or template calls. And you're right, Gregor, the primary
way to access wikidata's triples for purposes of regular template
programming is to logon to wikidata. imho, that establishes wikidata as
a black-box, with no additional mechanisms/extensions loaded onto any
'transcluding' wikipedia, which I think is the ideal posture for
integrating wikidata resources into the wikipedias.
re: the
whitepaper. Sure I'd be happy to put together a real demo. But as a
strugglin' contractor doing opensource dev since 1998, it'd be nice
if.
Gotta run - john
On 14.06.2012 09:29, Gregor Hagedorn
wrote:
Gregor, I'm a bit confused -- are you talking about the
transclusion design approach in this statement?
Yes, in the sense that
it demands to be the only access to wiki data
content in a Wikipedia.
because, if so, I'd think there'd be a number of infobox styles that
can be selected by an author on the wikidata platform when 'building'
the infobox page. The author can transclude any number/any specific
infobox(es) on their wikipedia page, eg {{wikidata:en:Infobox:Some
Re: [Wikidata-l] Wikidata Transclusions
Hi John, On Thu, Jun 14, 2012 at 12:39 AM, jmccl...@hypergrove.com wrote: I base my belief that [[wikitopics]] is operationally faster on a basic difference between the two designs, as I think the wikipedias will operate faster if they merely transclude infoboxes of their choice, at their own speed, from the wikidata central repository. Transclusion is surely fundamental to wiki application design. The [[wikidata]] proposal by contrast is a client-server API, such things an artifact of the 20th century. What is the point of it here? Ultimately the problem you're grappling with is not just just about infoboxes, it's about *anything* other than article text that has multilingual requirements. For instance, the same *pie chart* is to be shared among wikipedias, the only difference being the graph's title, key and other labels... [[wikidata]] is today doing format=table, later other formats. That's alot to handle in an API. Other can probably comment more on the rest of your email but here's one thing: It will very very likely not be the same pie chart. The Wikipedias have quite different demands as to what they want to show and what is important to them. So, it's highly advised the client-server API approach be scrapped. At a minimum, it's outdated technology, for good reasons. Instead, wikidata should *publish* infoboxes that are happily cached on wikidata servers. That's the best performance that can possibly be had. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
I don't understand why it's so unlikely, Lydia. ANY educational article (science, math, engineering) can have graphics whose underlying data is not language-sensitve. How about timelines on a bio article -- that's anothr example. Or a map within a place article? Or financial data within a business article? I think these are more likely than the scenario that concerns you, where the *data itself* used to construct the graphic, is language- or country-sensitive. On 13.06.2012 16:03, Lydia Pintscher wrote: Hi John, On Thu, Jun 14, 2012 at 12:39 AM, jmccl...@hypergrove.com wrote: I base my belief that [[wikitopics]] is operationally faster on a basic difference between the two designs, as I think the wikipedias will operate faster if they merely transclude infoboxes of their choice, at their own speed, from the wikidata central repository. Transclusion is surely fundamental to wiki application design. The [[wikidata]] proposal by contrast is a client-server API, such things an artifact of the 20th century. What is the point of it here? Ultimately the problem you're grappling with is not just just about infoboxes, it's about *anything* other than article text that has multilingual requirements. For instance, the same *pie chart* is to be shared among wikipedias, the only difference being the graph's title, key and other labels... [[wikidata]] is today doing format=table, later other formats. That's alot to handle in an API. Other can probably comment more on the rest of your email but here's one thing: It will very very likely not be the same pie chart. The Wikipedias have quite different demands as to what they want to show and what is important to them. So, it's highly advised the client-server API approach be scrapped. At a minimum, it's outdated technology, for good reasons. Instead, wikidata should *publish* infoboxes that are happily cached on wikidata servers. That's the best performance that can possibly be had. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org [1] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [2] -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l Links: -- [1] mailto:Wikidata-l@lists.wikimedia.org [2] https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata Transclusions
On Thu, Jun 14, 2012 at 1:13 AM, jmccl...@hypergrove.com wrote: I don't understand why it's so unlikely, Lydia. ANY educational article (science, math, engineering) can have graphics whose underlying data is not language-sensitve. How about timelines on a bio article -- that's anothr example. Or a map within a place article? Or financial data within a business article? I think these are more likely than the scenario that concerns you, where the *data itself* used to construct the graphic, is language- or country-sensitive. What I am meant is that the individual Wikipedias are quite different. One Wikipedia might consider it important to show certain data in this way and another one in that way while a third might insist on not showing it at all because it is not important. Having over 280 Wikipedias agree on which and how certain data should be shown seems like a major pain on top of all we're asking for from them already for Wikidata. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
