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

Re: URIs vs. URIviews (was: Agenda for RDFCore WG Telecon 2002-02-15)

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Thu, 14 Feb 2002 20:46:15 +0000
Message-Id: <5.1.0.14.0.20020214200153.04c89b18@0-mail-1.hpl.hp.com>
To: Aaron Swartz <me@aaronsw.com>
Cc: RDF Core <w3c-rdfcore-wg@w3.org>
At 13:20 14/02/2002 -0600, Aaron Swartz wrote:
>I notice that Brian seems ready to close all the little naggling issues. I
>think this is great but I don't want to see some issues drop thru the
>cracks.

Absolutely.  Thank you Aaron.

>Particularly, I'm worried about the URI-vs-URIviews issue, which I
>thought we agreed to put on the issues list, but I don't seem to see it.

I don't remember that.  There is no such issue on the list.  My bad maybe?


>Specifically in:
>
> > 16: Issue rdfms-fragments
> >
> > Propose:
> >
> > o The WG resolves that the meaning of absolute
> >   URI's with fragment ID's is a matter of web architecture and
> >   beyond the scope of this WG and that this issue be closed.
> >
> >
> > See:
> > http://www.w3.org/2000/03/rdf-tracking/#rdfms-fragments
>
>I really can't agree with this. It's our problem that RDF uses this
>non-standard piece of Web architecture,

True.

>  and in doing so has incurred all
>sorts of problems. If we're going to be the Resource Description Framework,
>we need we're actually describing resources.

I could live with us describing parts of resources as well.

>  My ideal resolution would look
>like:
>
>  o The WG resolves that the use of absolute URIs with fragment IDs is a
>    to identify Web resources is relatively incompatible with current Web
>    architecture.
>
>  o We recommend that RDF users refrain from using '#' in their Resource
>    identifiers and namespaces. RDF developers and tool creators may present
>    a warning to the user when using resource identifiers with '#' in them.

Kinda blows rdf:ID out of the water too.


>  o We understand the need to identify portions of Web entities (data used to
>    describe a resource, such as the data returned when making an HTTP GET
>    request). We recommend that they identify such Resources using something
>    along the lines of:
>
>_:x rdf:type web:Fragment .
>_:x web:resource <http://www.w3.org/2001/tag/ilist> .
>_:x web:fragID "w3cMediaType-1" .
>_:x dc:date "2002-02-14T13:03Z" .

Cute.

Side show just for fun: not the main thrust this response:  the domain of 
rdf:type is rdf:Resource, right?  Therefore a fragment is also a 
resource.  Therefore it can be named by a URI.  What URI?  If there was a 
general way to turn a URI with fragid into a URI, we'd be fine?  The other 
format would just be syntactic shorthand.


>My goal is to:
>  a) raise awareness about the problem while
>  b) maintaining backwards-compatibility but
>  c) lay the ground work for future WGs to fix this bug

Good goals.


>[...later...]
> > (d) choose namespace names that end in non-xml-name-characters
> > such as / # ?
>
>I think perhaps we should provide some warning about using # in namespace
>names, dependent on the resolution of rdfms-fragments.

The way I've been thinking about this is that (I think) I can see
a model for URI's with frag id's that would work for RDF as is.
We've passed this issue to the TAG for consideration.  If they rule
the right way we need do nothing.  If the rule differently, then
RDF will have to change, but it should have a solid definition of
what a URI plus frag id denotes to work with.

What I'd rather avoid is making a change, then having to change
again when the TAG rules, assuming it accepts the task.

You're approach of warning "here be dragons" is interesting.

I'd like to hear from the folks with knowledge of user communities
(PRISM, DC, CC/PP, ...) their reaction to this suggestion.
>
>you're-not-getting-off-that-easy-'ly yrs,

:)

Hmm, now I've got a list of actions somewhere that need doing ...

Brian
Received on Thursday, 14 February 2002 15:47:56 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:45:11 EDT