Re: true/false in RDF?

On Wed, 16 Mar 2005 13:06:54 -0800, Joshua Allen <joshuaa@microsoft.com> wrote:
> 
> > 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*.

I think there might be a red herring creeping in here. There are the
semantics of the base language(s) we're using (RDF+S+maybe OWL) and
then there are the operational semantics of the system that acts on
the data (and anything that can be inferred using the RDF etc).

I like Reto's version -

http://foobar/page.html rdf:type urn:myterms:CachedObject

- because it plays well with RDF reasoning. I think to get the
true/false you'd have to go a little further to be able to make
statements that were consistent/inconsistent with this in your model -
e.g. using OWL disjointedness.

Otherwise you have defer to other (probably) operational semantics to
determine that the URIs or literals are or aren't the same.

The end result might be the same in a specific app, but by stepping
outside of the RDF/OWL semantics you're losing the portability of the
data. Every system that uses it will also have to implement the
additional inferencing (string equality or whatever).

I might well be wrong, IANAL*, shoot me down in flames, but I think
that would be the case.

Cheers,
Danny.

* I struggle with "necessary but not sufficient" 


-- 

http://dannyayers.com

Received on Wednesday, 16 March 2005 22:01:58 UTC