[Rets-dev] Comments on RQL, SQL, XPath and Joins, Why not RDF/OWL?

Matt Lavallee matt at pmptechnology.com
Wed Jul 11 11:03:30 CDT 2007


I’m hesitant to even reply because this list tends to keep a high signal:noise
ratio, but here goes:

 

1.       One of the longstanding goals of RETS is that the transmissions be
human-readable.  Most of the value of a hierarchical element graph is its
(human-friendly) presentation.  Moreover, increased verbosity means increased
overhead.  Given that the most aggressive adopters are large MLSes and
aggregators, bloating the format (for the sake of an arbitrary standard) goes
straight to the wallet.

2.       Your query returns 2 elements out of the graph, when most consumers are
going to want dozens of elements with the graph intact.  As I said in the
original reply, you have to construct the graph in SPARQL for each query, and
that’s about the most pessimum approach I can imagine for our data set.

3.       As for Microsoft’s take on RDF/OWL:
http://msdn2.microsoft.com/en-us/xml/bb291067.aspx
“RDF / OWL - We recognize that these technologies are important in certain
domains such as life sciences and national security, but so far we have not
gotten enough customer demand to justify supporting them in the core XML
libraries.”

 

It’s great that you’ve gotten involved and join the conversation here, but given
the universe-wide support for XML Web Services, SQL, and XPath, I’d be
hard-pressed to consider alternatives.

 

-Matt

 

 

From: Jeryl Cook [mailto:twoencore at hotmail.com] 
Sent: Wednesday, July 11, 2007 10:25 AM
To: Matt Lavallee; jbrush at ronintech.org; 'E-mail Rets-Dev'
Subject: RE: [Rets-dev] Comments on RQL, SQL, XPath and Joins, Why not RDF/OWL?

 


>>excessively verbose syntax, it provides no direction to structuring our data
and is only arguably useful in meta-meta-data scenarios.  Consider this example:
<http://www.daml.org/cgi-bin/hyperdaml?http://www.daml.org/2001/10/html/airport-
ont#Airport>
http://www.daml.org/cgi-bin/hyperdaml?http://www.daml.org/2001/10/html/airport-o
nt#Airport>>
RDF/XML is not meant for "you"(human beings) to interpret it is for
machines..trying to figure out a "sense of hierarchy" will drive anyone mad.  
in the link u have about the subject "Airport" , your not suppose to print a
document out like this and read through it...you missing the point.

>>SPARQL is equally overburdened with complex syntax due to the URI-based
nomenclature of RDF>>
URIs are complicated?
this query which finds the minimum price of every propertyListing in the
underlying default graph:

  PREFIX ex: <http://rets.org/>
  SELECT ?propertyListing ?minprice
  WHERE {
    ?propertyListing a ex:propertyListing ; ex:price ?minprice .
    OPTIONAL { 
      ?propertyListing ex:price ?otherprice . 
      FILTER( ?otherprice < ?minprice ) .
    } .
    FILTER ( !bound(?otherprice) ) .
  }

not that complicated to me..

Look, didn't mean to start a flame war here :), i only stumbled on RETs , trying
to develop a site for my brother who is a relestate agent/investor....& i just
happen to be a software engineer for a company that specializes in building
"Knowledge Management" systems.... i saw a connection between semantic
technology and what RETs does for the relestate industry..and put my 2 cents out
there..

as far as being mainstream, many companies are building on this semantic
technology in great numbers..Oracle, Microsoft  is using RDF/OWL, and lets not
forget RSS feeds(RDF..) ..there are a good number of software & web clients that
allows people to browse via web and visually RDF documents(could easily be
property listings)..

i think u all are doing a great job(i say it again), just throwing some ideas
out there for ya, I've been just an outside looking and reading the messages..
..i am in total agreement u shouldn't implement everything that comers out of
W3, after while building solutions based on bleeding edge,you can easily get
hurt!..but its worth another serious look.  I wish i could make it to Chicago,
but ill be in Aruba :).


Jeryl Cook

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070711/448998fb/attachment.html


More information about the Rets-dev mailing list