[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: data smushing

• From: David Megginson <david@m...>
• To: xml-dev@l..., www-rdf-interest@w...
• Date: Tue, 02 Jan 2001 10:22:10 -0500 (EST)

Jason Diamond writes:

 > This is similar to the [base URI] property in the Infoset. I think it's an
 > excellent idea. Couldn't the source also be used to accomplish #2, though?
 > If the statement is identical except for the source, couldn't you assume
 > it's redundant?

My #2 was detecting statements that use different identifiers for the
same entity; there is no reliable way to know whether

  <rdf:Description rdf:about="http://foo.com/xxx">
   <dc:title>Joe Smith</dc:title>
  </rdf:Description>

and

  <rdf:Description rdf:about="http://bar.com/yyy">
   <dc:title>Joe Smith</dc:title>
  </rdf:Description>
   
represent the same entity or not.  Even with the same identifier,
though, it's hard to be certain whether properties from different
sources should be treated in the aggregate; imagine that hack.com
contains

  <foo:Collection rdf:about="http://foo.com/davidscollection">
   <foo:item>wooden soprano recorder</foo:item>
  </foo:Collection>

and foobar.com contains

  <foo:Collection rdf:about="http://foo.com/davidscollection">
   <foo:item>wooden soprano recorder</foo:item>
  </foo:Collection>

Does the collection have one or two wooden soprano recorders?  How can
you be sure?

In the real world, databases for movies, books, music, etc. tend to
contain a lot of duplicate entries for authors, etc., and it's hard to
prune them automatically (I once found over 20 entities for the
Beatles in a single database).  We'll face the same problem with RDF.

The only thing for sure is that software vendors who claim that their
software can solve this problem are either ignorant or dishonest --
nothing works but human eyeballs.


All the best,


David

-- 
David Megginson                 david@m...
           http://www.megginson.com/

• Follow-Ups:
  • RE: data smushing
    • From: Dan Brickley <Daniel.Brickley@b...>

• References:
  • RE: data smushing
    • From: Jason Diamond <jason@i...>

• Prev by Date: Re: Plan B+1 = Plan C+1
• Next by Date: RE: data smushing
• Previous by thread: RE: data smushing
• Next by thread: RE: data smushing
• Index(es):
  • Date
  • Thread