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

RE: true/false in RDF?

From: Joshua Allen <joshuaa@microsoft.com>
Date: Wed, 16 Mar 2005 13:06:54 -0800
Message-ID: <0E36FD96D96FCA4AA8E8F2D199320E5204883A46@RED-MSG-43.redmond.corp.microsoft.com>
To: "Seth Russell" <russell.seth@gmail.com>, <semantic-web@w3.org>

> Imho, there is no such thing as "semantic meaning".  There is only
> semantic meaning to some agent(s).    It is just as easy to make some
> agent respond to
> 
>     "<http://foobar/page.html>  <urn:myterms:isCached>   true"
> 
> as it is to the URI form or the typed literal form.   The "right way"
> is the fastest way that gets lots of different developers using the
> same form.

OK, this is worth chewing on.  I completely agree that symbols derive
their meaning from the way that they're used, so technically the URI
form of "true" doesn't have any more semantics than the untyped literal
form.  However, that doesn't mean that the URI form isn't *better*.

Look at it this way; if URIs were no better than untyped literals, than
we might as well just say:

<http://foobar/page.html> "is cached" "true"

Heck, we need not even use URIs for subjects -- just let each client
decide how to interpret the subject.

Using the URI in my example is better because you know it's being used
as an English *word*, with a definition at wordnet.  That's as much as
you need to know, and no more.  With a raw untyped literal, it could be
a word, a list of words, a jpeg, or whatever.  You don't know without
extra out of band info.  In addition, you can make assertions about the
object -- since it's a URI, it can be used as a subject as well.  If you
want to find triples which use the same object value, you can -- if it
were literal, the value of equality comparison is more dubious.  And
finally, it's just more consistent.  It's a simple s,p,o triple using
URIs.  What could be simpler?
Received on Wednesday, 16 March 2005 21:07:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:45 UTC