[rdfweb-dev] Tests for smooshing

Libby Miller libby.miller at b...
Thu Aug 29 11:57:13 UTC 2002


hi all

I've been chatting with Damian about how to improve my smushing code
since he pointed out that my existing code was not smushing properly in
the codepiction demo:

http://swordfish.rdfweb.org/people/libby/rdfweb/paths/nt/2002-08-15-codepictdump.nt

by looking at it in his new browser.

So, I've started to rewrite my api using Dan's RubyRDF as a basis:

http://www.w3.org/2001/12/rubyrdf/intro.html

and it's pretty similar, except for the way I'm indexing the nodes in
the graph class.

Basically
- every node has an id
- indexing is done using ids, _not_ sha1 or the textual or uri values
- you do queries by internally mapping from text values to internal
identifiers
- to smush, you just change the identifiers on certain nodes, so you
don't loose any information, because you don't change the uris, even if
they're bnodes.

The problem I have now is that a post-smush query

(http://smushed.subject.node.textvalue/ ?pred ?obj)

gets me _all_ the subjects that have the same id as
http://smushed.subject.node.textvalue/, not just that particular node,
i.e. results like this

(http://smushed.subject.node.textvalue/ pred obj)
(_somebnode pred obj)
(http://blah/blah pred obj)

This seems kind of mad but it sort of makes sense to me. It's
clearly not the right answer, but in some sense the nodes with uri
values _somebnode and http://blah/blah are after smushing the same node
the same node as that with uri http://smushed.subject.node.textvalue/.

Now I don't know what to do! any ideas? Does anyone think this sounds a
bit like the tidy literals problem?

btw, the new api passes all of Damian's tests.

Libby

p.s. Damian realised this would happen as soon as I explained my
indexing plan.

On Sun, 25 Aug 2002, Damian Steer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> These two cases came up while I've been writing an rdf
> browser. Wondered what the various smooshing apps did with them.
>
> First case: adding two documents
>
> <rdf:RDF>
> <Person>
> <mbox rdf:resource="mailto:a at e..." />
> </Person>
> <Person>
> <mbox rdf:resource="mailto:b at e..." />
> </Person>
> </rdf:RDF>
>
> <rdf:RDF>
> <Person>
> <mbox rdf:resource="mailto:a at e..." />
> <mbox rdf:resource="mailto:b at e..." />
> </Person>
> <rdf:RDF>
>
> Should result in one person, but I'm not sure all smooshers will.
>
> Second case: when identifiers collide
>
> <rdf:RDF>
> <Person>
> <mbox rdf:resource="mailto:a at e..." />
> </Person>
> <Person rdf:about="http://example.com/a">
> <mbox rdf:resource="mailto:a at e..." />
> </Person>
> <rdf:RDF>
>
> Not sure what the resulting graph should be here. It's (maybe) clearer
> with:
>
> <rdf:RDF>
> <Person rdf:about="http://example.com/b">
> <mbox rdf:resource="mailto:a at e..." />
> </Person>
> <Person rdf:about="http://example.com/a">
> <mbox rdf:resource="mailto:a at e..." />
> </Person>
> </rdf:RDF>
>
> I've seen a couple of instances where Person nodes have been given
> URIs and wondered what happened to that information when smooshed.
>
> You can combine these two cases:
>
> <rdf:RDF>
> <Person rdf:about="http://example.com/b">
> <mbox rdf:resource="mailto:a at e..." />
> </Person>
> <Person rdf:about="http://example.com/a">
> <name>a</name>
> </Person>
> </rdf:RDF>
>
> <rdf:RDF>
> <Person rdf:about="http://example.com/a">
> <mbox rdf:resource="mailto:a at e..." />
> </Person>
> </rdf:RDF>
>
> With unpleasant consequences...
>
> Enjoy,
>
> Damian
>
> PS One thing I thought of for the second case is not smooshing, but
> using daml:sameIndividualAs (or somesuch)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (Darwin)
> Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard <http://www.gnupg.org/>
>
> iD8DBQE9aRL/AyLCB+mTtykRApBnAKCyrKLPqRik/IJWI8hfkdaWO0NK4wCg0LAW
> C6g1hKaYbSUkokc76rKmzaw=
> =izxy
> -----END PGP SIGNATURE-----
>
>
>
> To unsubscribe from this group, send an email to:
> rdfweb-dev-unsubscribe at egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>




More information about the foaf-dev mailing list