W3C home > Mailing lists > Public > www-rdf-interest@w3.org > August 2002

Re: Non-Text Literals

From: Geoff Chappell <geoff@sover.net>
Date: Sat, 31 Aug 2002 13:14:32 -0400
Message-ID: <062301c25111$df993990$825ec6d1@goat1>
To: Bill de hÓra <dehora@eircom.net>, <www-rdf-interest@w3.org>


----- Original Message -----
From: "Bill de hÓra" <dehora@eircom.net>
To: "'Geoff Chappell'" <geoff@sover.net>; <www-rdf-interest@w3.org>
Sent: Saturday, August 31, 2002 11:04 AM
Subject: RE: Non-Text Literals


>
>
> Geoff,
>
> > From: Geoff Chappell [mailto:geoff@sover.net]
> >
> > The problem is that referring to a web resource solely by its
> > URL (as a URI) in RDF doesn't fix its meaning.
>
> That's what we have model theoretic interpretations for. Some of this
> got thrashed out on the TAG list not so long ago. When it comes to URLs,
> the naming authority gets to fix meaning (assuming 'meaning' means what
> is denoted by a URI). Arguably, all URIs that support authoritative
> naming (such as http) have their meanings fixed by the naming authority.

AFAIK, the only way to fix the meaning of a uri in rdf is to make enough
statements about it so that you're constrained to a single valid
interpretation for the name (in the world you're talking about.) I'd
disagree that authoritative naming does provide fixed meaning _in rdf_,
despite possible intuitions to the contrary. However, I think that the fact
that the proposed datatyping schemes introduce the concept of a name
resolver to rdf might offer a way to introduce fixed-meaning-naming in
general to rdf (and so provide a definitive way of talking about web
resources with everyone agreeing that they're actually talking about the
same thing).

>
> > Applications
> > may choose to believe otherwise and assume the missing
> > knowledge that can't be specified in RDF - i.e that we really
> > mean a particular URI to be treated as a URL so it's ok for
> > an application to go and retrieve something from it.
>
> That's not missing knowledge, that's RDF not having a model for
> dereferencing URIs. I used to think this was a serious problem; now I
> think it can be dealt with in a layered design.

If not missing, certainly opaque to rdf. I guess it's just a question of
what we want defined in the system (rdf) and what we're willing to live with
as defined outside of the system. XML certainly has many uses despite the
fact that the semantics of a particular chunk of xml are almost completely
specified in the code of the producing and consuming applications.

>
>
> > I've been wondering recently if datatyping could play a role
> > here. An rdf datatype is essentially a function, the details
> > of which are unknown to rdf, that is able to fix the
> > interpretation of a name. The web through its mechanisms
> > plays a similar role of resolving names to resources. So why
> > not have a web datatype in rdf? For example:
>
> It sounds like you're talking about pluggable datatypes? I think the wg
> have/are considering this, you might want to go through rdf-core's
> archives. Though I imagine any such semantics can also be provided
> through the property's domain and range without a mechanism for
> datatyping the literals. The thing is, surely Literals are of the type
> Literal, not of type
> UnknownTypeTunnelledThroughLiteralsLetsRunAProcessToFigureOutWhatAndDoAD
> ynamicCast.
>
> > _:a rdf:lex http://www.example.org/someimage.gif
> > _:a rdf:dtype ex:HttpResource
> > ex:HttpResource rdf:type rdf:DataType
> >
> > (hopefully that approximates one of the datatype proposals
> > closely enough so that my point is clear)
>
> Nice; I'm not sure it's necessary to provide datatypes to do this, or
> even if it's a good idea. It might be, I'm just not sure.
>

Yeah, I'm not sure either. It's an appealing thought in that it doesn't
require an addition to rdf other than the datatype proposals already on the
table.


>
> Bill de hÓra
> --
> Propylon
> www.propylon.com
>

Geoff
Received on Saturday, 31 August 2002 12:44:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:55 GMT