[Rets-dev] Google Base Housing vs. RETS

Thu Mar 15 09:20:28 CDT 2007

agreed.  this can be good if you want free marketing and bad if you dont.

3/15/07, Stuart Schuessler <sschuessler at tds.net> wrote:
>
>  I stand corrected.  Here is the terms and conditions:
>
>
>
> Google claims no ownership or control over any Content submitted, posted
> or displayed by you on or through Google Base. You or a third party
> licensor, as appropriate, retain all patent, trademark and copyright to any
> Content you submit, post or display on or through Google Base and you are
> responsible for protecting those rights, as appropriate
>
>
>
> However there is already a problem with data being high jacked out of
> RETS.  Posting it on GoogleBase does effectively make it public domain.  If
> someone wanted to populate a site like trulia all they would need to do is
> suck the data out of Googlebase- which looking at Trulia it appears that is
> exactly what they are doing.  The statement above basically means Google is
> not going to put any copyright protections on your data.  What happens to
> the data is your problem not Google's.  By submitting it to Google it can go
> out into any number of feeds.
>
>
>
> Then there is this:
>
>
>
> By submitting, posting or displaying Content on or through Google services
> which are intended to be available to the general public, you grant Google a
> worldwide, non-exclusive, royalty-free license to reproduce, modify, adapt,
> publish, and otherwise use, with or without attribution such Content on
> Google services solely for the purpose of displaying, distributing and
> promoting Google services.
>
>
>
>
>  ------------------------------
>
> *From:* rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] *On
> Behalf Of *JP Fielding
> *Sent:* Thursday, March 15, 2007 8:59 AM
> *To:* Rets-dev at rets.org
> *Subject:* Re: [Rets-dev] Google Base Housing vs. RETS
>
>
>
> im not sure that is entirely accurate.   while its true its been posted in
> the open (which is the purpose of marketing), copyright transfer is a _very_
> rigid process.  they have been given permission to post it, so long as the
> owner allows it, but copyright transfer requires a specific legal instrument
> (not a light undertaking).  in an unclear instrument of transfer, im pretty
> sure the rights remain with the owner.  if i recall correctly, photos have
> an implied copyright, even if they dont have one attached.  the data is less
> clear.  while facts, such as data about a listing are not supposed to be
> copyrightable, it has always been acceptable to allow the copyright of
> accumulation of other works (as in a book of a collection of poems).
>
> either way, i think it might be overstating the situation to say anyone
> but the owner owns it.  either the original owner owns it, or noone does.
>
> jp
>
> On 3/15/07, *Stuart Schuessler* <sschuessler at tds.net> wrote:
>
> Another thing about GoogleBase is once it is posted it is basically public
> domain.  Basically the copyright has been removed and transferred to
> Google.  Google owns the data.
>
>
>
> Stuart
>
>
>  ------------------------------
>
> *From:* rets-dev-bounces at rets.org [mailto: rets-dev-bounces at rets.org] *On
> Behalf Of *Stuart Schuessler
> *Sent:* Thursday, March 15, 2007 9:33 AM
> *To:* dsrockets at gmail.com; Rets-dev at rets.org
> *Subject:* RE: [Rets-dev] Google Base Housing vs. RETS
>
>
>
> >> So why is RETS so complicated again?
>
> It's no more complicated than any other standard.  Given the high adoption
> rate apparently there are others that do not think it is too complicated
> either.  Any ideas to make it less complicated are always welcome.  Have you
> been to any of the meetings?
>
>
>
> >> No one explained the theory behind it
>
> There is a certain assumption that there is some understanding of Real
> Estate and hierarchical metadata structures.  The specification includes
> examples of use.  I could not find a document outlining the theory of
> GoogleBase and yet you have an understanding of it.  Googlebase has a
> description of use but no "Theory".  I would go out on a limb here and say
> RETS is better explained with more documentation than Googlebase- of coarse
> with Googlebase what is to explain.  It is an FTP push.  There is no
> identity management, no control over who gets the data, no business rules
> that allow owners of a listing to see field like expiration date, etc…  It
> is a classified ad.
>
>
>
> >> The need for the concept of a client is crazy.
>
> The core RETS specification does not require a special client.  Everything
> can be done through the browser.  In fact originally it was set up to work
> nicely with just some simple javascript if you wanted to put a user friendly
> search screen on top of it.
>
>
>
> >>just 'readable' in a pure http browser
>
> RETS 1.x is
>
>
>
> Googlebase (beta) has been out just over a year.  I like the housing
> templates:  http://base.google.com/base/help/housing.html
>
>
>
> Notice the:
> *Not Found* *Error 404*
>
> For each of the templates- again: BETA
>
>
>
> Why not just stick with FTP feeds?  It is basically the same thing except
> they are offering a push location.  Googlebase is a classified ad.  Not very
> robust.
>
>
>
> RETS 1.X offered the real estate industry something before SOAP even came
> out and certainly before GoogleBase.  Once SOAP came out and stabilized the
> RETS community started to move in that direction.  I believe the reason the
> adoption of RETS 2.0 has been slow is basically RETS 1.X is doing the
> job.  Once some of the 2.0 features have stabilized and there are a couple
> of large MLS/MLS Vendors that start using 2.0 there will be a higher
> adoption rate.  That is how the RETS 1.x got started.
>
>
>
> I am sure that if you are having a problem trying to get something
> implemented you could ask question and get help.  Do a general "this sucks"
> post on the thread really does not accomplish anything.
>
>
>
> Stuart
>
>
>
>
>
>
>  ------------------------------
>
> *From:* rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] *On
> Behalf Of *dsrockets at gmail.com
> *Sent:* Thursday, March 15, 2007 7:21 AM
> *To:* Rets-dev at rets.org
> *Subject:* Re: [Rets-dev] Google Base Housing vs. RETS
>
>
>
> haaaha.  Blast from the past!!! Seems like a good time to dig this back up
> as it got a mention on a MLS blog ++
> http://www.flexmls.com/blog/?p=23#comment-19
>
> So why is RETS so complicated again?  No one explined the theory beihind
> it, when the same things are accomplishable, as secure, with much simpler
> technology (see googlebase)?
>
> The need for the concept of a client is crazy.  It should just be easily
> defined in most programming frameworks, and just 'readable' in a pure http
> browser (pure XML with https url based auth -)
>
> In fact, is most of the core of RETS2 still not php/python friendly?  Yes,
> that is going to be fun seeing that most of the client apps out there are
> php based.
>
> I feel like I am part of the 300!
>
> On 12/21/06, *Chadwick Meyer* <chadwick at cratemedia.com> wrote:
>
> Here Here. I agree. I've always thought RETS was needlessly complicated in
> it's own obscure fashion.
>
>
>
>
>
>
>
>
>
>
>
> *Chadwick Meyer*
>
> chadwick at cratemedia.com
>
> T. 407/538.9026
>
> F. 866/534.8654
>
>
>
> *****************
>
> *Crate Media*
>
> 1087 Dees Dr .
>
> Oviedo FL 32765
>
> www.cratemedia.com
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Dec 20, 2006, at 8:56 PM, dsrockets at gmail.com wrote:
>
>
>
> been a patient observer in and out of rets for a while, thought I needed
> to put some my own experiences out on this.
>
> I dont think there is any benefit to Google even looking at RETS.  As said
> earlier, they have thier own system and it works just fine.  In fact, RETS
> should look at how Google / Trulia / Oodle handle data (or more closely
> listing) exchange a bit more closely.
>
> All of these are built on simple, yet effective transport mechanisms that
> can handle query based retrieval and updates.  We have implemented both RETS
> for pulling data and all three methods mentioned earlier for update and
> query.  The level of complexity (earlier message) seems to make it apparent
> why Google / Trulia / Oodle have all had large adoption rates.  It gets the
> job done simply and easily.  They are also built using out of the box and
> proven methods.
>
> I'd recommend the powers to be consider these approaches, if not even
> piggyback on them, as they are solid, structured, secure and more
> importantly efficient and straightforward.
>
>
>
>
>   From: dbt < retsdev at develest.com >
> Date: Dec 20, 2006 5:09 PM
> Subject: Re: [Rets-dev] Google Base Housing vs. RETS
> To: Eric Madariaga < ericm at nsoftware.com>
> Cc: David Harris < dharris at fmls.com>, E-mail Rets-Dev < rets-dev at rets.org>
>
>
> There's no reason you can't embed a RETS payload (RETSML or a JSON'ified
> COMPACT representation) in an Atom document and use an OpenSearch
> style API to retrieve a set of records with permalinks for each entry
> that you can use to retrieve/update.
>
> GET /rets/search?q=(AREA=+2000) HTTP/1.1
> Host: rets.example.com
> Accept: application/atom+xml
>
> HTTP/1.1 200 OK
> Content-Type: application/atom+xml
> <feed xmlns=" http://www.w3.org/2005/Atom">
> <link rel="self"
>     href="/rets/search?q=(AREA=+2000)" />
> <title>Search Results</title>
> <entry>
>   <link rel="alternate" type="application/rets+xml"
>         href="../properties/10029" />
>   <summary>Server-generated user-readable description, perhaps containing
>     the address or square feet or whatever</summary>
> </entry>
> </feed>
>
> GET /rets/properties/10029
> Host: rets.example.com
> Accept: application/rets+xml
>
> HTTP/1.1 200 OK
> Content-Type: application/rets+xml
> ETag: xyzzy
>
> <REPropEntry>
> ....
>
>
>
> Interestingly, and in completely unrelated news, Google themselves just
> deprecated their SOAP search API.
>
> On Wed, Dec 20, 2006 at 03:28:18PM -0500, Eric Madariaga wrote:
> >
> > Not to sound pessimistic, but good luck with that :). Google's format is
> > based on the GData specs that they have published (basically Atom/RSS
> 2.0
> > with extensions).  You would have a MUCH easier time providing a
> > transformation mechanism for MLS data.
> >
> > For example I'd love to see an RSSBus module ( www.rssbus.com) for RETS.
> > That would  enable you to push MLS data from any RETS capable server
> > directly to Google base with no additional code.
> >
> > -Eric
> >
> > -----Original Message-----
> > From: rets-dev-bounces at rets.org [mailto: rets-dev-bounces at rets.org] On
> Behalf
> > Of David Harris
> > Sent: Wednesday, December 20, 2006 3:33 PM
> > To: E-mail Rets-Dev
> > Subject: [Rets-dev] Google Base Housing vs. RETS
> >
> > Just for giggles, I looked at the Google Base Housing API metadata, and
> of
> > course, no mention of RETS. Here is the link (I hope):
> >
> > http://www.google.com/base/api/itemTypeDocs?verticalName=housing&vertica
>
> > lLocale=en_US
> >
> > Question is, do we (meaning Paul) open a line of communication with them
> to
> > hopefully have them adopt RETS? Something about keep your friends close
> and
> > your enemies closer... jk.
> >
> > David
> >
> > _______________________________________________
> > Rets-dev mailing list
> > Rets-dev at rets.org
> > http://lists.rets.org/mailman/listinfo/rets-dev
> >
> >
> > _______________________________________________
> > Rets-dev mailing list
> > Rets-dev at rets.org
> > http://lists.rets.org/mailman/listinfo/rets-dev
> >
>
> --
> David Terrell
> dbt at meat.net
> ((meatspace)) http://meat.net/
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev
>
> ---------- Forwarded message ----------
>
>
>
> _______________________________________________
>
> Rets-dev mailing list
>
> Rets-dev at rets.org
>
> http://lists.rets.org/mailman/listinfo/rets-dev
>
>
>
>
>
>
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070315/3e78971d/attachment.html