W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > December 2002

Re: checked RDF semantics for XSD stuff, couldn't grok namespace entailment

From: Dan Connolly <connolly@w3.org>
Date: 16 Dec 2002 10:02:26 -0600
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: w3c-rdfcore-wg@w3.org
Message-Id: <1040054546.11337.22.camel@dirk.dm93.org>

On Mon, 2002-12-16 at 02:55, Patrick Stickler wrote:
> [Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com]
> ----- Original Message ----- 
> From: "ext Dan Connolly" <connolly@w3.org>
> To: <w3c-rdfcore-wg@w3.org>
> Sent: 14 December, 2002 01:41
> Subject: checked RDF semantics for XSD stuff, couldn't grok namespace entailment
> > | We do not make any assumptions about the relationship
> > | between the denotation of a uriref and a document or
> > | network resource which can be obtained by using that uriref
> > | in an HTTP transfer protocol.
> > 
> > Again, that overstates the case. 'We' the formal semantics
> > editor don't make any such assumption. But we the RDF
> > Core WG do expect that URIs will usually be used in RDF
> > consistently with their use in HTTP, HTML and other conventional
> > contexts. This is what the intro to the semantics says;
> > directly only briefly, but indirectly thru the concepts
> > doc more elaborately.
> I myself prefer the current wording. The question of consistency
> of interpretation between the SW and Web is anything but clear,
> so I don't find it justified or helpful (or wise) for the WG
> to expect something which is arguably uncertain and unclear.

Then perhaps you should ask to re-open issue rdfms-assertion; the WG
has decided that...

"A combination of social (e.g. legal) and technical
machinery (protocols, file formats, publication frameworks) provide
the contexts that fix the intended meanings of the vocabulary of
some piece of RDF, and which distinguish assertions from other
uses (e.g. citations, denals or illustrations)."
 -- RDF concepts draft of 7Aug
 cited from 23 Aug minutes, referenced from

> The Web is able to stumble along with ambiguity in the interpretation
> of URIs

I don't believe so.

>  whereas the SW is not. The whole open debate as to what
> e.g. http://www.w3c.org/ denotes (an organization, a web site, a
> home page, a location, etc.) should be ample motivation for us
> to steer clear of taking any stand on this issue.

I disagree.

>  It's not RDF's
> place to dictate to other Web standards, and unless the RDF Core
> WG can say clearly what the consistent use of http://www.w3c.org/
> is for both RDF and HTTP, we should not assume any relationship
> (even if we would hope and expect there might be).
> > | It has been argued that urirefs in the form of HTTP URIs
> > | should be required to denote the document that results from
> > | such a retrieval.
> > 
> > I don't know why you point out that misconception;
> > the more architecturally consistent view is that
> > it denotes a thing that, when sent GET messages,
> > sends you back a document.
> Ahhh... that's refreshing, a consistent view that concedes
> that HTTP URIs actually denote locations from where things
> are obtained rather than the actual things obtained ;-)

'concede'? This has been my consistent position all along;
since long before this WG convened. (modulo quibbles
about 'location' versus 'resource')

see, for example,

  Re: A shot at rdfms-resource-semantics
  From: Dan Connolly (connolly@w3.org)
  Date: Tue, May 08 2001

> Well, if that really is the emerging concensus view, and
> folks are OK then with http://www.w3c.org/ then not denoting
> the W3C or the W3C web site or a web page,

I presume you meant http://www.w3.org/.

It denotes a generic web page; i.e. something that,
when sent a GET request, responds with a specific version.

>  but simply denoting 
> a location on the web from which things can be obtained, great. 
> I would consider that exceptional progress...
> If not, then we certainly should keep the wording above as
> it is...
> Patrick
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Monday, 16 December 2002 11:02:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:19 UTC