[Rets-dev] Google Base Housing vs. RETS

Thu Mar 15 08:58:44 CDT 2007

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/2008e20b/attachment.html