Re: [Wikidata-l] OpenStreetMap + Wikidata for light houses
Tom, Split tool to the rescue ? :) Looks like the GeoNames ID is for the islet itself...so probably needs another entity for the Vinga Lighthouse itself sitting on that islet. Thad +ThadGuidry https://www.google.com/+ThadGuidry On Thu, Apr 23, 2015 at 1:02 PM, Tom Morris tfmor...@gmail.com wrote: On Thu, Apr 23, 2015 at 10:16 AM, Edward Betts edw...@4angle.com wrote: Thad Guidry thadgui...@gmail.com wrote: I helped with the Lighthouses schema in Freebase. Some of which is based on List of Lights (NGA) USA. I have DB conversion data for the PDFs...just never got around to loading them all in. Let me know if I can help. I was able to match 407 lighthouses on OSM and Wikidata: http://edwardbetts.com/osm-wikidata/2015-04-18/match_results/Lighthouses.html How can something be both a islet, a nature preserve, and a lighthouse? http://www.wikidata.org/wiki/Q3372089 Tom ___ 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] World's largest cities with a female mayor :-)
BTW, the Freebase ingestion later this summer should help fill a few of those holes in population and other statistics. We had US Census, World Bank, and UN Data as our primary data sources for any /statistics/ of a City/Town/Village. Here's Houston - https://www.freebase.com/m/03l2n#/location/statistical_region and Paris - https://www.freebase.com/m/05qtj#/location/statistical_region The cut-off in the USA is based on Census data collection years. Thad +ThadGuidry https://www.google.com/+ThadGuidry On Tue, Apr 21, 2015 at 9:56 AM, Jeremy Baron jer...@tuxmachine.com wrote: On Apr 21, 2015 10:41, Pharos pharosofalexand...@gmail.com wrote: There appear to be a number of other major cities missing, though I'm not sure what the cut-off for population is: Cities where we have articles for the mayor: Baltimore, Maryland (USA) [...] You're welcome to fix some of them. :) https://www.wikidata.org/wiki/special:diff/208946888/212095823 -Jeremy ___ 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-Freebase mappings
Nice work Haklae and team ! And thanks for making this investment and sharing it publicly. This will help everyone involved as migration progresses forward. Thanks again, Thad +ThadGuidry https://www.google.com/+ThadGuidry On Wed, Apr 8, 2015 at 8:03 AM, Kim Haklae haklae...@gmail.com wrote: Hi all, I am pleased to announce that the Freebase-Wikidata mappings are shared in public. http://github.com/Samsung/KnowledgeSharingPlatform Google is already providing the mapping relation between Freebase and Wikidata (https://developers.google.com/freebase/data), however, they might not offer a updated version. We extract a set of identical relations from both Freebase and Wikidata datasets using Wikipedia links; several algorithms are also tested to find out same entity pairs. Although this approach is limited to identifying all same entities of both datasets, it would be a useful source to understand instances of both data sources. The source code for extracting this data will also be shared soon. The data is serialised using the N-Triples format, and the following is the details of this data: - Total 4,395,258 triples (same entity pairs) - Updated: February 13, 2015 - Data Format: N-Triples RDF - License: CC0 - File size: 236 MB zip - File size: 2.5 GB (uncompressed) Feel free to ask me if you have any questions. Cheers, Haklae Kim Senior Engineer Samsung Electronics Co., Ltd. scot@samsung.com / haklae...@gmail.com -- Dr.Dr. Haklae Kim Semantic Web and Open Data Hacker Open Knowledge Foundation Korea http://thedatahub.kr http://getthedata.kr http://blogweb.co.kr Tel: +82-(0)10-3201-0714 Who's Who in the World's 27th Edition - 2010 IBC 2000 Outstanding Scientists - 2010 ___ 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] External identifiers vs. Wikidata-internal links data
Ah, as Markus mentions, since we already have https://www.wikidata.org/wiki/ Property:P214 Then the rest of the problem is just a readability issue. So there is no need for renaming property names as I suggested and suffixing with ID P214 solves the grouping problem fairly easily. And Lydia says readability in general is going to improve...just wait. So, I am looking forward to the site display improvements in the future and more use of P214. Thad +ThadGuidry https://www.google.com/+ThadGuidry On Sat, Apr 4, 2015 at 2:05 PM, Joe Filceolaire filceola...@gmail.com wrote: Best to have a statement (instance of:wikidata database index property) instead of trying to do this with the English language label as it is easier to localise statement s. On 4 Apr 2015 17:23, Helder . helder.w...@gmail.com wrote: On Sat, Apr 4, 2015 at 5:19 AM, Smolenski Nikola smole...@eunet.rs wrote: Citiranje Thad Guidry thadgui...@gmail.com: I think a simple naming convention would suffice (and clean up the existing ones): blah ID such as for example: CANTIC ID Freebase ID Munzinger IBA ID NLP ID dmoz ID Oxford Biography Index ID SELIBR ID How would you name ISBN, for example? ISBN ID? :) And how would this work with translations? Helder ___ 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 ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] External identifiers vs. Wikidata-internal links data
Re-reading... Erik, I think you mean that the display itself for instance on this page: https://www.wikidata.org/wiki/Q42 would be more useful if all Identifiers were pushed down to the bottom half or different section, for instance, and keeping descriptor properties on the upper half ? (instead of the current mixing of both within the div.wikibase-listview ? Thad +ThadGuidry https://www.google.com/+ThadGuidry ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] External identifiers vs. Wikidata-internal links data
Why do you have to get lost in them ? Most already have the phrase ID or Identifier in their naming convention. So perhaps a better approach would be to standardize the naming convention used for External Identifiers and make it a best practice and golden rule during property creation and voting. A further refinement could be to enhance the statement selector with an option for ID or WP ID or Descriptor. I think a simple naming convention would suffice (and clean up the existing ones): blah ID such as for example: CANTIC ID Freebase ID Munzinger IBA ID NLP ID dmoz ID Oxford Biography Index ID SELIBR ID etc.. Thad +ThadGuidry https://www.google.com/+ThadGuidry On Fri, Apr 3, 2015 at 8:17 PM, Denny Vrandečić vrande...@gmail.com wrote: Is there any external key which is not of data type string and vice versa? Also, no matter whether this gets done or not, please don't remove qualifiers and references from these statements (I.e. explicitly don't treat them like sitelinks) On Fri, Apr 3, 2015, 17:36 Erik Moeller e...@wikimedia.org wrote: Hi all -- Have we considered separating in some way (in the UI, and possibly the data model) properties which track identifiers in external databases vs. properties that describe the item using Wikidata-internal links? As more and more external identifiers are added, it's easy to get lost in them while looking for the right property to describe an item. We're effectively already doing this with Wikimedia identifiers by calling them sitelinks and it seems like a potential logical extension of that concept to group other kinds of external identifiers in their own section rather than having CANTIC, BIBSYS identifiers, Freebase identifiers or even DMOZ links mixed together with the primary descriptors of an author or work, for example. Thanks, Erik ___ 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 ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] OpenStreetMap + Wikidata for light houses
I helped with the Lighthouses schema in Freebase. Some of which is based on List of Lights (NGA) USA. I have DB conversion data for the PDFs...just never got around to loading them all in. Let me know if I can help. Thad +ThadGuidry https://www.google.com/+ThadGuidry On Tue, Mar 10, 2015 at 10:19 AM, Markus Bärlocher markus.baerloc...@lau-net.de wrote: It would be fine to have all this together: _OSM_ seamark:type=light* _Wikidata_ https://www.wikidata.org/wiki/Q44782 _Wikipedia_ https://de.wikipedia.org/wiki/Kategorie:Liste_(Leuchttürme) https://de.wikipedia.org/wiki/Liste_von_Leuchttürmen _Commons_ commons:Lighthouse category:Lighthouses _Example_ Wikipedia: https://de.wikipedia.org/wiki/Roter_Sand Commons: https://commons.wikimedia.org/wiki/Category:Leuchtturm_Roter_Sand Wikidata: https://www.wikidata.org/wiki/Q220034 Resonator: http://tools.wmflabs.org/reasonator/?q=Q220034 OSM-DB: https://www.openstreetmap.org/node/635484478 OpenSeaMap: http://map.openseamap.org/?zoom=13mlat=53.85557mlon=8. 08198mtext=Roter%20Sandlayers=BFTFFFTFFTT0FTFF Best regards, Markus ___ 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] OpenStreetMap + Wikidata
Think... BIGGER. Jo has the right idea... Linked Data. It sounds to me like the right way forward for domain specific interest data (like OSM) ...is, Instead of 1 source of data (Wikidata)...and throwing domain specific interest data into Wikidata (not all data needs to live inside it). Just use 1 source of data, i.e. Linked Data. Wikidata does not have to be the 1 sole source... and besides, I am sure that eventually someone could just allow federated queries / joins to Linked Data. Perhaps Wikidata can try to be and eventually help build... the 1 sole QUERY source for Linked Data. :) (Select OSM_ROADS contained_in Ardennes) Thad +ThadGuidry https://www.google.com/+ThadGuidry ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Freebase's incompatible types and Property description permissions
Back to the original discussion...and summary... Anyways, thanks to all for summing up the current state of the Properties on properties which is the 1st step for the Rules enforcement and that will offer similar capabilities that Freebase had with Incompatible Types. Also I feel more comfortable now, knowing that the Schema model on Properties is reviewed and cases of abuse are checked and automated. Thanks all for answering my questions. Thread closed. Thad +ThadGuidry https://www.google.com/+ThadGuidry ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] Derived Properties (Computed Properties) or Metaschema ?
Freebase originally had 2 modes. View and Edit. And then changed to only an Edit mode (where some properties were no longer hidden) Wikidata as far as I know only has Edit (All properties are shown in the UI) Derived properties might work, but only in a View mode. Or only if Derived properties where specially marked visually as such. There should always be an option to have the UI show all properties. Freebase's Metaschema is much like the idea of derived properties. Where some rules govern the population or assumption of a property value. Details here: https://developers.google.com/freebase/v1/search-metaschema Thad +ThadGuidry https://www.google.com/+ThadGuidry On Wed, Jan 14, 2015 at 8:37 AM, apoh...@o2.pl apoh...@o2.pl wrote: Referring to the NIST classification of semantic relations, general affiliation is a different relation than part-of. That's why conflating them is not the best idea. But this is a minor issue in that context. I am wondering if there is any list of properties for beginners, that should not be treated as a real part of the knowledge base? As I wrote earlier there are two problems with ambiguous entities: 1. indicating super-properties 2. inferences drawn with such properties I don't question the usefulness of properties such as country, i.e. searching all cities in one country or searching all bands that originated in another country. I am just concerned with the duplication and as a result coherence of the data that is in Wikidata. One of the basic principles of DB design is that data should be stored in only one place. That's why DB normal forms where developed. Even more - that's why Wikidata was extracted from individual Wikipedias in the first place! In the case of Dublin, country and Ireland. At present we have two distinct claims expressing the same fact, that one day may become incompatible. Being constructive - maybe it's the time to consider derived properties? Thus claims like Dublin country: Ireland would be visible in the UI, but would be computed based on the contents of the knowledge base. The same applies to age and many other properties, that are useful for 'beginners', but can be computed from the other properties and rules expressed in the ontology. Cheers, Aleksander ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Disambiguating property [was: Freebase like API with an OUTPUT feature}
https://www.wikidata.org/wiki/Property:P279 aka the superclass ... seems to have an equivalent property that refers to http://www.w3.org/2000/01/rdf-schema#subClassOf ??? dunno. Thad +ThadGuidry https://www.google.com/+ThadGuidry ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Mediawiki-api] Freebase like API with an OUTPUT feature ?
So Lydia, Your saying that if I see https://www.wikidata.org/wiki/Q18614948 as a property on another Property... then that is similar to the Freebase disambiguating flag ? In Freebase, we have just one flag but that is not the case here, correct ? Wikidata has (or might have) several such disambiguating flags via the property on Property ? It would be nice, from an API and developer perspective, to not have to discover all those disambiguating propertiesbut have only a master disambiguating property to work with...a single disambiguator flag, just like Freebase has is this possible, where someone can go through an mark all of them as disambiguating ? My hope is that the Wikidata query service could give me nicely formatted output for claims that only contain disambiguating property data just like the Freebase API example URL that I mentioned at the beginning of the thread. So hopefuly you guys are saying that is possible via the property on a Property. Thad +ThadGuidry https://www.google.com/+ThadGuidry ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Relating Wikidata entities to external URIs (was: Disambiguating property ...)
Thanks for explaining Markus. The advantage of avoiding equivalentProperty in favour of subPropertyOfExternalProperty (and similarly for classes) is also that our definition can be more specific than the one used for the external property/class. So we can relate our data to multiple external things, which may fit our own definition more or less tightly. Agreed. Thad +ThadGuidry https://www.google.com/+ThadGuidry ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Freebase's incompatible types and Property description permissions
Markus, Devils in the details. =) You used the English word associated. That's great. Then I would propose to expand the definition of P17 just a bit to add that. P17 Country - sovereign state of this item ... to ... sovereign state ASSOCIATED with this item Then you save the world. =) Thoughts ? Agreement ? Secondly, the Description: (Description :colon: on the Discussion page https://www.wikidata.org/wiki/Property_talk:P17) is defining a Country... not the description of the Country __Property__..which is the line just above it. How is the Description :colon: line supposed to work or be really used for ? Seems like the Description :colon: line is basically describing the Represents :colon: line lol. Very confusing. Thad +ThadGuidry https://www.google.com/+ThadGuidry ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] Freebase's incompatible types and Property description permissions
Freebase has mutexes that store incompatible type information. For instance, in Wikidata I noticed on the U2 band topic, that they have statements of: P17 Country - sovereign state of this item. P740 Location of formation - location where a group or organization was formed. In Freebase we have basically that P740, Place where musical career began.but not a Country property with that sort of definition. But having sovereign state of this item on an instance of band, seems weird, and perhaps should not be allowed , or incompatible. Unless the P17 Country property had an expanded definition of sovereign state (or originating sovereign state) of this item 1. How does Wikidata want to handle Property / Statement rule enforcement and Freebase's incompatible types ? 2. How does Wikidata want to handle locking down Property descriptions (Freebase uses Permissions and Owners), where the complete meaning of something being changed might cause severe wrongful polluted data ? Thad +ThadGuidry https://www.google.com/+ThadGuidry ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Freebase's incompatible types and Property description permissions
On Thu, Jan 8, 2015 at 12:17 PM, Federico Leva (Nemo) nemow...@gmail.com wrote: Thad Guidry, 08/01/2015 18:58: Unless the P17 Country property had an expanded definition of sovereign state (or originating sovereign state) of this item That's more like P27. Both are rather flexible though, see their talk pages. https://www.wikidata.org/wiki/Property_talk:P17 1. How does Wikidata want to handle Property / Statement rule enforcement and Freebase's incompatible types ? I'm not sure how this is an example of incompatible type, it sounds more like a type Freebase didn't have. Handling such differences is possible by tweaking property descriptions and adding constraints. P17 is already declared incompatible with instance of: human. If you make music band a subclass of human, then this statement about U2 will be reported by bots as a constraint violation. Right, Freebase would not stick a Property called Country right on an instance of a Music Band. We would put Country under the Musical Group type, and give it a better definition like The nation or territory that this item originated from. Freebase's Properties always live under a Freebase Type, like Musical Group. Which is why on Wikidata, even seeing P17 on the U2 topic page makes me wonder what kind of schema Wikidata is trying to pull off. But it appears that someone did not really read the description page of P17, like I just did, then they would see it just is not allowed like that, but instead should have used P27, but then you can't have a date of birth for a Musical Group (band), which voids using even P27 on an instance of band. I understand, there are many holes in Wikidata's schema currently. I am one of several Freebase experts coming over that can help Wikidata identify those problematic Schema. :-) 2. How does Wikidata want to handle locking down Property descriptions (Freebase uses Permissions and Owners), where the complete meaning of something being changed might cause severe wrongful polluted data ? There is no such thing in wikis. http://c2.com/cgi/wiki?WikiDesignPrinciples https://meta.wikimedia.org/wiki/The_wiki_way But Wikidata is not a wiki in the true sense, or should not be purported as one Because it is not Schema-less, but in fact, prescribes to a publicly editable and agreed upon Schema model. One thing I did notice is that the Wikidata Schema model is actually composed of both agreement on the 2 tabs of https://www.wikidata.org/wiki/Property_talk:P17 both the Property tab, AND the Discussions tabcombined...give the effective model of the Property...whereas in Freebase, we would just have the Property, where all rules and definitions about it are stored (Discussions about a Property were stored on our wiki and also our mailing list). I enjoy the Wikidata way a bit more compared to Freebase, the benefit being a primary place to see the defines of the Property as well as the Discussion and questions about it in the past. The errors are corrected after the fact; the central control system is not made of permissions, but of checks like the constraint violations bots mentioned above. What other pollutions of the data you have in mind? And that is my worry. That the Schema model is publicly editable at any time. And constraint violations are only effective against a Well Defined Property. But what if I do not Well Define that property, or worst, I completely change the meaning of that Property. Imagine if I suddenly change the meaning of one of your MySQL table columns... like, PERSON suddenly becomes FURNITURE. That can happen with Wikidata's publicly editable Schema modelif someone maliciously changes the description of that P17 Country to something very generic like a state oh really ? What kind of state ? Nations only ? Or territories considered as an organized political community under one government.? or both ? it appears that P17's Discussion clarifies this a bit, and defines it a bit more narrowly and would not allow just any territory with a political community. We have the same problem in Freebase, where if by public agreement, we change the meaning of a Property so much that it might cause erroneous data statements, then we deprecate that Property and create a new one, splitting off the various statements into their proper form and letting the Community know, and also performing the data tasks to subscribe the old data to the new Schema. The pollution of data would happen if by agreement P17's Discussion page drastically changed the intended meaning of it, then all the data that used P17 would need to be cleaned up. How does Wikidata intend to deal with those kinds of changes to Property meanings in the future ? and the data cleanup involved ? ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Freebase's incompatible types and Property description permissions
Hi Marcus! Yes, you and I are on the same page. Yes, I know about the Property-first view of WIkidata. No quibbles. But there is still an issue with Assumptions for Country P17 being used for an instance of Band...so let's clarify this... So, I guess things are fuzzy, because I do not jump to assumptions beyond the meaning of P17 as it states on its Property or Discussion page. And the difference is that you are mentally performing a few assumptions. It is hard to train a computer to read your mind and answer a question for you however. :) Its better to write those assumptions (meanings) down somewhere. Even for Freebase, we found that Properties had to be described very well for all to understand their meaning with minimal ambiguity, and I was a big proponent on Freebase to Google for better descriptions. So, question since you understand the meaning of Country on the U2 page as you state... Can you please tell me that meaning...and then let's see if we can transfer your knowledge to better improve P17 Property and its description. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Mediawiki-api] Freebase like API with an OUTPUT feature ?
Hi Lydia, It's more than that. I can get labels just fine with props=labels Ideally there were be a Number 3 a reconcile service, or an API that can be USED as a reconcile service. Given a search string of Paris, let's say... 1. Return some disambiguating properties and their labels and values. For reconciling purposes, you don't want to deal with codes like P12345 but instead a human understandable description of the property. a. Allow the output of the information returned to be expanded or reduced by some parameter values that I mentioned as OUTPUT. b. Allow the use of a (disambiguator) parameter to output only the disambiguating properties. (disambiguating properties are those that are most important when comparing A = B and given a type). In Freebase API, we had the option of this as shown here: http://freebase-search.freebaseapps.com/?query=Texasoutput=(disambiguator)limit=100scoring=entitylang=en The current disambiguator with Wikidata is actually the descriptions. Wikidata does not flag or mark properties like P856 (official site) as a disambiguating property, an important property. Freebase does however. It would be nice for Wikidata to begin work on having a disambiguating property flag (boolean Y/N) like Freebase does. The closest starting point for a Reconcile API with the current API structure that I can see is hacking a bit on this one: https://www.wikidata.org/w/api.php?action=wbgetentitiessites=enwikititles=Parislanguages=enprops=descriptions|claims Btw, that closest starting point, only outputs 1 entity for Paris in the enwiki... where's Paris, Texas ? Thad +ThadGuidry https://www.google.com/+ThadGuidry ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Mediawiki-api] Freebase like API with an OUTPUT feature ?
Yes I did try wbsearchentities, and your right, it returns more via a search operator. The problem with wbsearchentities is that it is limited and cannot additionally pipe output for the claims information (ideally important claims only, disambiguating claims/properties) Thad +ThadGuidry https://www.google.com/+ThadGuidry ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
