From: Matt G. <go...@na...> - 2009-05-22 01:25:54
|
I've been working on a natural history themed wiki for my area and have recently decided to extend its content to cover the region. http://www.sitkanature.org/wiki/ I'm pretty much figuring things out as I go, but I have found semantic mediawiki and semantic forms extensions to be very helpful for what I am doing. One thing that seems like a good idea to do at this point is rethink my properties and their names a little bit. I've learned a bit through the experience of using what I came up with initially, and I have some ideas for improving it, but I would welcome any suggestions and/or links concerning standard property names for this sort of thing, if they exist. I figure the easier it is to integrate the information I collect into the greater knowledge base of information on the internet, the better (as long as it's not too painful for me to implement). In any case, it seems prudent to make any significant changes now, before I get too far along in entering in the data/information I have. Thanks, Matt Goff |
From: Dan B. <dan...@gm...> - 2009-05-25 13:02:04
|
2009/5/22 Matt Goff <go...@na...>: > > I've been working on a natural history themed wiki for my area and have > recently decided to extend its content to cover the region. > http://www.sitkanature.org/wiki/ > > I'm pretty much figuring things out as I go, but I have found semantic > mediawiki and semantic forms extensions to be very helpful for what I am > doing. > > One thing that seems like a good idea to do at this point is rethink my > properties and their names a little bit. I've learned a bit through the > experience of using what I came up with initially, and I have some ideas > for improving it, but I would welcome any suggestions and/or links > concerning standard property names for this sort of thing, if they exist. Unfortunately I don't know of anything like this around at the moment (other than a bunch of informal conventions that you will pick up reading various documents). Semantic Forms imposes a set of conventions which are useful, so I would recommend reading the documentation for that. I've been meaning to write a 'data modelling howto' for ages now, shamefully I haven't even started. I would suggest that you write one document briefly summarising the data that you have and how you intend to map it onto SMW (category names, property names, pages and queries). This is the first step in any basic 'data modelling' or 'requirements analysis' strategy. Post that summary back to the list, and I'm guessing people will pipe up with some suggestions about the sorts of names or conventions that they would use. The next most important thing to do is think about how you expect your site to be used, and to check if you design will support that usage. Also you should look at a selection of the sites listed at http://smw.referata.org and see how things are done there. > I figure the easier it is to integrate the information I collect into the > greater knowledge base of information on the internet, the better (as long > as it's not too painful for me to implement). In any case, it seems > prudent to make any significant changes now, before I get too far along in > entering in the data/information I have. > > Thanks, > > Matt Goff > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: Yaron K. <ya...@gm...> - 2009-05-25 18:39:56
|
Just a small correction - that URL should be smw.referata.com, or, more specifically, http://smw.referata.com/wiki/Special:BrowseData/Sites. -Yaron On Mon, May 25, 2009 at 8:33 AM, Dan Bolser <dan...@gm...> wrote: > 2009/5/22 Matt Goff <go...@na...>: > > > > I've been working on a natural history themed wiki for my area and have > > recently decided to extend its content to cover the region. > > http://www.sitkanature.org/wiki/ > > > > I'm pretty much figuring things out as I go, but I have found semantic > > mediawiki and semantic forms extensions to be very helpful for what I am > > doing. > > > > One thing that seems like a good idea to do at this point is rethink my > > properties and their names a little bit. I've learned a bit through the > > experience of using what I came up with initially, and I have some ideas > > for improving it, but I would welcome any suggestions and/or links > > concerning standard property names for this sort of thing, if they exist. > > Unfortunately I don't know of anything like this around at the moment > (other than a bunch of informal conventions that you will pick up > reading various documents). Semantic Forms imposes a set of > conventions which are useful, so I would recommend reading the > documentation for that. I've been meaning to write a 'data modelling > howto' for ages now, shamefully I haven't even started. > > I would suggest that you write one document briefly summarising the > data that you have and how you intend to map it onto SMW (category > names, property names, pages and queries). This is the first step in > any basic 'data modelling' or 'requirements analysis' strategy. > > Post that summary back to the list, and I'm guessing people will pipe > up with some suggestions about the sorts of names or conventions that > they would use. > > The next most important thing to do is think about how you expect your > site to be used, and to check if you design will support that usage. > Also you should look at a selection of the sites listed at > http://smw.referata.org and see how things are done there. > > > > > I figure the easier it is to integrate the information I collect into > the > > greater knowledge base of information on the internet, the better (as > long > > as it's not too painful for me to implement). In any case, it seems > > prudent to make any significant changes now, before I get too far along > in > > entering in the data/information I have. > > > > Thanks, > > > > Matt Goff > > > > > ------------------------------------------------------------------------------ > > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > > is a gathering of tech-side developers & brand creativity professionals. > Meet > > the minds behind Google Creative Lab, Visual Complexity, Processing, & > > iPhoneDevCamp asthey present alongside digital heavyweights like > Barbarian > > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > > _______________________________________________ > > Semediawiki-user mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: Matt G. <go...@na...> - 2009-05-26 05:58:42
|
Thanks for the suggestions. Here's what I have so far, in terms of the types of things I would like to have included and what I would like to do with it. The primary data-storing pages can be broadly grouped into three types: Species Location Habitat Within Species I plan to store information about occurrence (spatial and seasonal), physical characteristics/morphology, ecology, phenology, and taxonomy. The actual mix of things will vary somewhat depending on the main grouping (i.e., vascular plants, birds, lichens, etc.) Within locations I would include a description of the location as well as some way of locating it (lat/long, perhaps; or maybe a link to a shape file/map). Each location will also be contained within more inclusive locations. I'll do this both for political boundaries (town-related areas) and geographic areas of varying scales. Individual locations will also have species lists, and ideally a given location would inherit all the species given for any location contained within it (though I do not know how easy this will be to implement). Habitat pages I've not worked on or thought about too much yet, so I'm not quite sure what I would include here, but I do know that I would like to include species lists and some indication of species abudance within the habitat. One of the big questions I have is how much to reuse the same property across groups of species. For example, if I have a property called "GrowthForm is", for birds I might have values like "Shorebird", "Raptor", "Gull", "Waterfowl", etc. For lichens I would have values like "Crustose", "Foliose", or "Squamulose", while for vascular plants I would have "Graminoid", "Herb", "Tree", or "Shrub". In some ways it seems sensible to just use the same property for all the species, but in other ways maybe it makes more sense to have "Bird Growth Form is", "Plant Growth Form is" and "Lichen Growth Form is". I guess the tradeoff is between a single property with a great many allowable values or several properties each with a limited number of allowable values. I'm not sure if it will make a difference in the end, but one of the things I would like to do is create a synoptic key based on the morphological/ecological characteristics that are recorded. I think this should be fairly easy to implement once the information is entered for all the species. I also think it could a powerful application of the SMW. Another problem I've not been able to work out is how to effectively save spatial/seasonal/species information both as a regional summary and for subareas within the region covered by my wiki. This is most applicable to birds, where different species occur at different times of year. Ideally I would like to be able to have seasonal presence recorded for any given location and season (though in practice this will probably be limited to a dozen or so larger areas where there is enough information available). I would also like to be able to pull that information up by season, location, and/or species. For example, if I consider a couple of species, I would have the following information: Species: Dunlin Sp Su Fa W Juneau: C R U U Sitka: C - V + Ketchikan: C - R U Species: Common Murre Sp Su Fa W Juneau: F U F F Sitka: C C C C Ketchikan: C R C C (where C = Common, F= Fairly Common, U=Uncommon, R = Rare, V= Very Rare, + = Casual, and - = Not known to occur) What I would like to do is have a form where I could add multiple sections (perhaps using the chooser functionality) like as follows. On the Dunlin page: Location = Juneau Spring Abudance is = C Summer Abundance is = R Fall Abundance is = U Winter Abudance is = U Location = Sitka Spring Abudance is = C Summer Abundance is = - Fall Abundance is = V Winter Abudance is = + Location = Ketchikan Spring Abudance is = C Summer Abundance is = - Fall Abundance is = R Winter Abudance is = U With the possibility of adding more locations in the same format. However, I don't see how to implement that (and perhaps it's not possible to do within the SMW framework). So far the best I have come up with is that each location (or species, depending on how I set it up) would have a set of properties corresponding to the seasons these properties would then need to be included on each species (or location) page. So on the Dunlin page: Juneau Spring Abundance is = C Juneau Summer Abudance is = R Juneau Fall Abundance is = U Winter Abundance is = U Sitka Spring Abudance is = C Sitka Summer Abundance is = - Sitka Fall Abundance is = V etc. The problem with this is that it multiplies properties pretty quickly. Thanks, Matt Goff On Mon, 25 May 2009 04:33:21 -0800, Dan Bolser <dan...@gm...> wrote: > Unfortunately I don't know of anything like this around at the moment > (other than a bunch of informal conventions that you will pick up > reading various documents). Semantic Forms imposes a set of > conventions which are useful, so I would recommend reading the > documentation for that. I've been meaning to write a 'data modelling > howto' for ages now, shamefully I haven't even started. > > I would suggest that you write one document briefly summarising the > data that you have and how you intend to map it onto SMW (category > names, property names, pages and queries). This is the first step in > any basic 'data modelling' or 'requirements analysis' strategy. > > Post that summary back to the list, and I'm guessing people will pipe > up with some suggestions about the sorts of names or conventions that > they would use. > > The next most important thing to do is think about how you expect your > site to be used, and to check if you design will support that usage. > Also you should look at a selection of the sites listed at > http://smw.referata.org and see how things are done there. |
From: <zeh...@mo...> - 2009-05-26 07:13:13
|
Hi, did you consider multi-value properties? For me they are essential in certain cases, although they have some shortcomings within the normal SMW tools. > So on the Dunlin page: > Juneau Spring Abundance is = C > Juneau Summer Abudance is = R > Juneau Fall Abundance is = U > Winter Abundance is = U > Sitka Spring Abudance is = C > Sitka Summer Abundance is = - > Sitka Fall Abundance is = V [[Spring Abundance::C;Juneau]] [[Summer Abudance::R;Juneau]] [[Fall Abundance::U;Juneau]] [[Winter Abundance::U;?]] [[Spring Abundance::C;Sitka]] [[Summer Abudance::-;Sitka]] [[Fall Abundance::V;Sitka]] Cheers, Gu Quoting Matt Goff <go...@na...>: > > Thanks for the suggestions. Here's what I have so far, in terms of the > types of things I would like to have included and what I would like to do > with it. > > The primary data-storing pages can be broadly grouped into three types: > Species > Location > Habitat > > Within Species I plan to store information about occurrence (spatial and > seasonal), physical characteristics/morphology, ecology, phenology, and > taxonomy. The actual mix of things will vary somewhat depending on the > main grouping (i.e., vascular plants, birds, lichens, etc.) > > Within locations I would include a description of the location as well as > some way of locating it (lat/long, perhaps; or maybe a link to a shape > file/map). Each location will also be contained within more inclusive > locations. I'll do this both for political boundaries (town-related > areas) and geographic areas of varying scales. Individual locations will > also have species lists, and ideally a given location would inherit all > the species given for any location contained within it (though I do not > know how easy this will be to implement). > > Habitat pages I've not worked on or thought about too much yet, so I'm not > quite sure what I would include here, but I do know that I would like to > include species lists and some indication of species abudance within the > habitat. > > One of the big questions I have is how much to reuse the same property > across groups of species. For example, if I have a property called > "GrowthForm is", for birds I might have values like "Shorebird", "Raptor", > "Gull", "Waterfowl", etc. For lichens I would have values like > "Crustose", "Foliose", or "Squamulose", while for vascular plants I would > have "Graminoid", "Herb", "Tree", or "Shrub". In some ways it seems > sensible to just use the same property for all the species, but in other > ways maybe it makes more sense to have "Bird Growth Form is", "Plant > Growth Form is" and "Lichen Growth Form is". I guess the tradeoff is > between a single property with a great many allowable values or several > properties each with a limited number of allowable values. I'm not sure > if it will make a difference in the end, but one of the things I would > like to do is create a synoptic key based on the morphological/ecological > characteristics that are recorded. I think this should be fairly easy to > implement once the information is entered for all the species. I also > think it could a powerful application of the SMW. > > Another problem I've not been able to work out is how to effectively save > spatial/seasonal/species information both as a regional summary and for > subareas within the region covered by my wiki. This is most applicable to > birds, where different species occur at different times of year. Ideally > I would like to be able to have seasonal presence recorded for any given > location and season (though in practice this will probably be limited to a > dozen or so larger areas where there is enough information available). I > would also like to be able to pull that information up by season, > location, and/or species. > > For example, if I consider a couple of species, I would have the following > information: > > Species: Dunlin > Sp Su Fa W > Juneau: C R U U > Sitka: C - V + > Ketchikan: C - R U > > Species: Common Murre > Sp Su Fa W > Juneau: F U F F > Sitka: C C C C > Ketchikan: C R C C > > (where C = Common, F= Fairly Common, U=Uncommon, R = Rare, V= Very Rare, > + = Casual, and - = Not known to occur) > > What I would like to do is have a form where I could add multiple sections > (perhaps using the chooser functionality) like as follows. > > On the Dunlin page: > > Location = Juneau > Spring Abudance is = C > Summer Abundance is = R > Fall Abundance is = U > Winter Abudance is = U > > Location = Sitka > Spring Abudance is = C > Summer Abundance is = - > Fall Abundance is = V > Winter Abudance is = + > > Location = Ketchikan > Spring Abudance is = C > Summer Abundance is = - > Fall Abundance is = R > Winter Abudance is = U > > With the possibility of adding more locations in the same format. > However, I don't see how to implement that (and perhaps it's not possible > to do within the SMW framework). So far the best I have come up with is > that each location (or species, depending on how I set it up) would have a > set of properties corresponding to the seasons these properties would then > need to be included on each species (or location) page. > > So on the Dunlin page: > Juneau Spring Abundance is = C > Juneau Summer Abudance is = R > Juneau Fall Abundance is = U > Winter Abundance is = U > Sitka Spring Abudance is = C > Sitka Summer Abundance is = - > Sitka Fall Abundance is = V > > etc. > > The problem with this is that it multiplies properties pretty quickly. > > Thanks, > > Matt Goff > > On Mon, 25 May 2009 04:33:21 -0800, Dan Bolser <dan...@gm...> > wrote: > > > Unfortunately I don't know of anything like this around at the moment > > (other than a bunch of informal conventions that you will pick up > > reading various documents). Semantic Forms imposes a set of > > conventions which are useful, so I would recommend reading the > > documentation for that. I've been meaning to write a 'data modelling > > howto' for ages now, shamefully I haven't even started. > > > > I would suggest that you write one document briefly summarising the > > data that you have and how you intend to map it onto SMW (category > > names, property names, pages and queries). This is the first step in > > any basic 'data modelling' or 'requirements analysis' strategy. > > > > Post that summary back to the list, and I'm guessing people will pipe > > up with some suggestions about the sorts of names or conventions that > > they would use. > > > > The next most important thing to do is think about how you expect your > > site to be used, and to check if you design will support that usage. > > Also you should look at a selection of the sites listed at > > http://smw.referata.org and see how things are done there. > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: Dan B. <dan...@gm...> - 2009-05-26 14:10:12
|
2009/5/26 Matt Goff <go...@na...>: > > Thanks for the suggestions. Here's what I have so far, in terms of the > types of things I would like to have included and what I would like to do > with it. ... > One of the big questions I have is how much to reuse the same property > across groups of species. For example, if I have a property called > "GrowthForm is", for birds I might have values like "Shorebird", "Raptor", > "Gull", "Waterfowl", etc. For lichens I would have values like > "Crustose", "Foliose", or "Squamulose", while for vascular plants I would > have "Graminoid", "Herb", "Tree", or "Shrub". In some ways it seems > sensible to just use the same property for all the species, but in other > ways maybe it makes more sense to have "Bird Growth Form is", "Plant > Growth Form is" and "Lichen Growth Form is". I guess the tradeoff is > between a single property with a great many allowable values or several > properties each with a limited number of allowable values. I'm not sure > if it will make a difference in the end, but one of the things I would One specific comment comes to mind here. To model this you can use 'sub-properties': http://semantic-mediawiki.org/wiki/Property:Subproperty_of i.e. define the property "Bird Growth Form is" as a sub-property of the "Growth Form is" property. Again, I'm not sure if it will make a difference in the end, but it may help you keep things organised, and it should allow you to get all the benefits described above. I also have lots of general comments about what you wrote. I'll reply more fully later. Cheers, Dan. |
From: Dan B. <dan...@gm...> - 2009-05-28 21:12:45
|
2009/5/26 Matt Goff <go...@na...>: > > Thanks for the suggestions. Here's what I have so far, in terms of the > types of things I would like to have included and what I would like to do > with it. > > The primary data-storing pages can be broadly grouped into three types: > Species > Location > Habitat According to the conventions outlined in the SF documentation: http://www.mediawiki.org/wiki/Extension:Semantic_Forms you would make a category for each of these types, and every piece of data of this type would be put in a page with the corresponding category. Roughly you can think of a category as a table and pages in the category as rows in the table. This isn't always the best way to model the data. You may need to think hard about what categories you want and what properties belong in what categories. You may want to restructure things as the site develops. > Within Species I plan to store information about occurrence (spatial and > seasonal), physical characteristics/morphology, ecology, phenology, and > taxonomy. The actual mix of things will vary somewhat depending on the > main grouping (i.e., vascular plants, birds, lichens, etc.) This is interesting, because it shows the complexity of real biological data. Basically you have objects (species) and then several different classification ontologies mapped onto those species. i.e. ontologies of body forms, ontologies of environmental terms, etc. Now SMW has specific functionality to bring in ontologies into the wiki, however, I don't really know how that works - I never used ontologies, and I'm not even sure what the best documents are to point you at. Here I would recommend you to look into that, but I can't promise anything concrete will come out of it. > Within locations I would include a description of the location as well as > some way of locating it (lat/long, perhaps; or maybe a link to a shape > file/map). Each location will also be contained within more inclusive > locations. I'll do this both for political boundaries (town-related > areas) and geographic areas of varying scales. Individual locations will > also have species lists, and ideally a given location would inherit all > the species given for any location contained within it (though I do not > know how easy this will be to implement). Here again I would define an ontology of locations. People tend to do this simply as pages in the wiki. i.e. Title: London Text: London is a city located in [[Located in::England]]. Title: England Text: England is a country located in [[Located in::Europe]]. Title: Europe Text: Europe is a continent located in the [[Located in::World]]. etc. This is much more straight forward than trying to do something fancy with geographic information systems (coordinates and boundaries). You can then write queries that return all the cities in Europe, for example... hmm... http://semantic-mediawiki.org/wiki/Help:Selecting_pages http://semantic-mediawiki.org/wiki/Help:Inferencing I'm not sure how to write this query just now. > Habitat pages I've not worked on or thought about too much yet, so I'm not > quite sure what I would include here, but I do know that I would like to > include species lists and some indication of species abudance within the > habitat. Thinking about this from a database perspective, I would say that you have pages for species, pages for habitats (based on some community ontology of habitats if possible) and then you have data about species in habitats, so you need pages for that data too. i.e: Title: Species X in Habitat Y Text: Species [[species::X]] is found [[abundance::rarely]] in [[habitat::Y]]. The alternative is N-ary properties, but I'm not an expert on those. I have set up a wiki to play with some of these options here: http://prodstat.referata.com/wiki/Main_Page http://prodstat.referata.com/wiki/DataPoint:0210:0044:031:2007 I quite like the text I managed to generate on the 'DataPoint' pages (like the one above, which is an equivalent of the page "Species X in Habitat Y"), however, I'm not sure if you should use that site as a guideline! > Another problem I've not been able to work out is how to effectively save > spatial/seasonal/species information both as a regional summary and for > subareas within the region covered by my wiki. This is most applicable to > birds, where different species occur at different times of year. Ideally > I would like to be able to have seasonal presence recorded for any given > location and season (though in practice this will probably be limited to a > dozen or so larger areas where there is enough information available). I > would also like to be able to pull that information up by season, > location, and/or species. As above, there are options about how to model data that belongs to specific combinations of 'objects' in your wiki. I wonder if the ontology support of the wiki can help with this... not sure, but I know this is a problem in ontology design when objects can be combinations of terms in branches of the ontology. > For example, if I consider a couple of species, I would have the following > information: > > Species: Dunlin > Sp Su Fa W > Juneau: C R U U > Sitka: C - V + > Ketchikan: C - R U > > Species: Common Murre > Sp Su Fa W > Juneau: F U F F > Sitka: C C C C > Ketchikan: C R C C > > (where C = Common, F= Fairly Common, U=Uncommon, R = Rare, V= Very Rare, > + = Casual, and - = Not known to occur) > > What I would like to do is have a form where I could add multiple sections > (perhaps using the chooser functionality) like as follows. > > On the Dunlin page: > > Location = Juneau > Spring Abudance is = C > Summer Abundance is = R > Fall Abundance is = U > Winter Abudance is = U > > Location = Sitka > Spring Abudance is = C > Summer Abundance is = - > Fall Abundance is = V > Winter Abudance is = + > > Location = Ketchikan > Spring Abudance is = C > Summer Abundance is = - > Fall Abundance is = R > Winter Abudance is = U > > With the possibility of adding more locations in the same format. > However, I don't see how to implement that (and perhaps it's not possible > to do within the SMW framework). So far the best I have come up with is > that each location (or species, depending on how I set it up) would have a > set of properties corresponding to the seasons these properties would then > need to be included on each species (or location) page. > > So on the Dunlin page: > Juneau Spring Abundance is = C > Juneau Summer Abudance is = R > Juneau Fall Abundance is = U > Winter Abundance is = U > Sitka Spring Abudance is = C > Sitka Summer Abundance is = - > Sitka Fall Abundance is = V > > etc. > > The problem with this is that it multiplies properties pretty quickly. > > Thanks, > > Matt Goff That's all I can think of for the time being. Let us know how you get on! Good luck! Dan. > On Mon, 25 May 2009 04:33:21 -0800, Dan Bolser <dan...@gm...> > wrote: > >> Unfortunately I don't know of anything like this around at the moment >> (other than a bunch of informal conventions that you will pick up >> reading various documents). Semantic Forms imposes a set of >> conventions which are useful, so I would recommend reading the >> documentation for that. I've been meaning to write a 'data modelling >> howto' for ages now, shamefully I haven't even started. >> >> I would suggest that you write one document briefly summarising the >> data that you have and how you intend to map it onto SMW (category >> names, property names, pages and queries). This is the first step in >> any basic 'data modelling' or 'requirements analysis' strategy. >> >> Post that summary back to the list, and I'm guessing people will pipe >> up with some suggestions about the sorts of names or conventions that >> they would use. >> >> The next most important thing to do is think about how you expect your >> site to be used, and to check if you design will support that usage. >> Also you should look at a selection of the sites listed at >> http://smw.referata.org and see how things are done there. > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |