Re: [CODE4LIB] Implemented Microdata (or RDFa Lite) and Schema.org?

2013-01-15 Thread William Sexton
Jason - We implemented RFDa Lite in our digital collections application last 
year. In fact, we used your article in the C4L journal as a basis for the 
project. You can see the results in the HTML source for our collection portal 
pages and individual item pages. Here are a few example URL's:

http://library.duke.edu/digitalcollections/gedney/
http://library.duke.edu/digitalcollections/adaccess_W0355/
http://library.duke.edu/digitalcollections/behindtheveil_albany_ga_and_environs/

We started out with Microdata, and focused on connecting items to their parent 
collections, and to the library units where they're held. Later we switched to 
RDFa for more precision in representing custom metadata properties, though most 
of what we're doing now is still from the schema.org ontology. We pulled up 
short of mapping all of our Dublin Core refinements into the framework, but the 
hooks are there for it. 

We also started using sitemaps and managing them with Google's webmaster tools, 
with an eye toward using the Google Site Search platform. We're watching 
analytics to help inform our decisions, but the most ambitious outlook is 
first, to use Google as the first-choice discovery platform for 
library-generated content, and second, to expand the use of Site Search to as 
much of the library web site as possible.

Hope this helps; we'll email you privately with a little more info.

Will



On Jan 12, 2013, at 12:18 PM, Jason Ronallo wrote:

 Last year at the C4L conference, I gave a talk on HTML5 Microdata and
 Schema.org [1]. At the time I had trouble finding many libraries or other
 cultural heritage organizations that had implemented anything.
 
 Now there are big examples like OCLC, but anyone else done anything with
 this? Have you implemented Microdata (or RDFa Lite) and Schema.org since
 then? Or have you come across other libraries or cultural heritage
 organizations that have?
 
 While there are some datasets [2] out there now where I might be able to
 discover this information, I haven't had the chance to look there yet.
 
 Thank you for any examples or leads.
 
 Jason
 
 
 [1] http://code4lib.org/conference/2012/ronallo
 I also published an article in the C4L Journal:
 http://journal.code4lib.org/articles/6400
 
 [2] http://webdatacommons.org/#results-2012-1


Re: [CODE4LIB] PHP vs. Python [was: Re: Django]

2010-10-29 Thread William Sexton
I use Python and Django extensively, and think they're both great. That said, 
also great is the very funny keynote by former flickr engineer Cal Henderson at 
DjangoCon 2008, titled Why I Hate Django, which is on YouTube:

http://www.youtube.com/watch?v=i6Fr65PFqfk

When he showed the slide I had to admit that the statement

-.join(array) 

is kind of a goofy way to do that, though maybe not unforgivable. Whenever I 
use join() now I chuckle a little in my mind.

It's good to step back and re-evaluate your favorite tools from time-to-time. 
If nothing else, the ability to analyze a platform for its suitability to a 
need is key.

Will


On Oct 28, 2010, at 9:38 AM, Thomas Bennett wrote:

 Having used Zope (python based) as our WEB server of choice since 1998 I am 
 urged to express my opinion that if you do choose to use python in your 
 projects then use a service designed for python use such as Zope, Django, et 
 al.  Zope is normally run in front of Apache as a virtual host.
 
 If you are going to use python then Zope is an excellent choice for 
 interacting with databases and using python to massage/manipulate results if 
 you need complex results from the database data.  I like that you can write 
 sql queries  just like you might use on the command line and save it as an 
 individual object for use by any number of other objects.
 
 What may be a simple example to some is a tutorial quiz I wrote for the WEB.  
 There are categories and each category has any number of questions along with 
 the answers in the database.  In the management portion, the administrator 
 can 
 choose which categories are active and how many questions out of the total 
 available to pull from each category individually.  When the quiz page is 
 generated the correct number of questions are pulled randomly from the total 
 active questions for each category, some questions can be set as inactive.
 
 There are database connectors for PostgreSQL, MySQL, Oracle, odbc, and 
 others so you can choose any popular db or write your own connector.  And 
 there are python libraries written for these databases which prove very 
 useful.
 
 The main thing I like about python is that the syntax pretty much forces your 
 code to be readable by others because indention is part of the syntax rather 
 than semicolons, parens, etc.
 
 I don't know PHP in detail but am learning more quickly because the 
 University 
 is forcing all departments to move to Drupal and we will be running our 
 site 
 on Drupal within a year probably although some administrative tasks will 
 still 
 be running on our Zope server.
 
 Thomas
 
 ps: remember my point is that IF you choose to use python this supports its 
 use with databases and scripting.
 
 
 
 
 
 On Wednesday 27 October 2010 20:49:06 you wrote:
 Olá, como vai?
 
 Luciano Ramalho luci...@ramalho.org wrote:
 Actually, Python is a general purpose programming language. It was not
 created specifically for server side scripting like PHP was. But it is
 very suitable to that task.
 
 I'm not sure talking about what something used to be is as interesting
 as talking about what it is. Both Pyhton and PHP can share whatever
 moniker we choose (scripting-language, programming language,
 real-time, half-time, bytecoded, virtual, etc.).
 
 Not seen any scientific packages, but I've seen a few ray-tracers,
 although they're all demo apps and fun toys (although I think that
 applies to Python, too).
 
 No, that does not apply to Python. Python is widely used for hardcore
 scientific computing.
 
 I was referring to the ray-tracing part.
 
 It is also the most important scripting language in large scale CGI
 settings
 
 Yes, Python is widely used for scripting up interfaces into other more
 complex systems. But rarely is the core of the thing written entirely
 in Python.
 
 Maybe your Google-foo is weak. :)
 
 Or maybe he's just realizing that outside of server side web
 scripting, PHP is just not so widely used.
 
 Absolutely, and fair enough.
 
 Having used both languages, I discovered that Python is easier for
 most tasks, and one reason is that the libraries that come with Python
 are extremely robust, well tested and consistent.
 
 Hmm. PHP is extremely robust and well-tested, but yes, it's not all
 that consistent, especially not before version 5.2+. However, things
 have moved on, and with release 6 around the corner things will be
 tighter still. Just like the first versions of Python were
 interesting, so was PHP's, but where the biggest problem with the
 evolution of PHP was the very fact that it was the most popular
 language for rapid web development by far.
 
 PHP is very
 practical for server-side web scripting, but it's libraries are
 unfortunately full of gotchas, traps and unexpected behaviour.
 
 There's gotchas in every language, even Python.
 
 A key reason for that is the fact that Python has always had an
 exception-handling mechanism while PHP has grown something like that
 only a few