W3C home > Mailing lists > Public > semantic-web@w3.org > June 2005

Re: Identity of URIRefs / Resources

From: James Cerra <jfcst24_public@yahoo.com>
Date: Sat, 4 Jun 2005 19:52:21 -0700 (PDT)
Message-ID: <20050605025221.56312.qmail@web42202.mail.yahoo.com>
To: semantic-web@w3.org, reto@gmuer.ch

Reto,

Very nice and interesting CMS.  I have a simular idea; although, it isn't a
server side app.  What does WYMIWYG stand for?  What You Make Is What You Get?

> If I understand http://www.w3.org/TR/rdf-concepts/#dfn-URI-reference 
> correctly, the following graph contains two statements :
> <snip>

Yes.  Even if they were the same URIs, though, there would _still be two
statements_!  They would just be duplicates, but that is allowed in RDF's data
model.

> Does it make sense that "Two RDF URI references are equal if and only if 
> they compare as equal, character by character, as Unicode strings.", 

Yes. That is correct.

> wouldn't it cause less problems to say "Two RDF URI references are equal
> if and only if the resolve to the same URI".

The problem is that two RDF URI references don't have to "resolve" to anything!
 They could point to a resource that is not network retrievable, for example. 
For this reason, I think the tag URI scheme is a good idea for most URIs.  See
<http://taguri.org> for more info on that scheme.

> I'm asking because I'm implementing and RDF based CMS [1] where GET and
> MGET requests are answered according of the properties the requested
> resource has in the model and I have no way to find out whether the user
> requested http://gmuer.ch/%C3%BC or http://example.org/&#65533;&#65533;.

Take a look at the SPARQL protocol, which provides a standard way of using HTTP
to get RDF information.  See <http://www.w3.org/TR/rdf-sparql-protocol/> for
more information.



--
Jimmy Cerra
https://nemo.dev.java.net


		
__________________________________ 
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html 
Received on Sunday, 5 June 2005 02:52:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:05 GMT