RE: quick review of the PRISM spec

Hi Aaron,

Thanks for the comments. A couple of quick responses...

> I think Dan, Tim, I and a bunch of other people would be glad 
> if you got
> these URI schemes out of the spec.

Yes, that was the gist of a comment from John Cowan as well,
so I will change those around to standard URI references.

> > But a lightweight procedure for registering URI schemes 
> would be nice.
> 
> No, it wouldn't creating new, unnecessary URI schemes is 
> generally a bad
> idea. They can almost always be fitted into some sort of 
> existing scheme
> just fine, whether it's by a URL, or, if you're desperate, 
> some sort of URN.

Starting from your opening premise - that the new URI schemes
were unnecessary - of course they would look like a bad idea. 
But there just may be other points of view that should not be
dismissed out of hand.
However, this is not the place or time for this discussion,
so I'll drop it.

> >> * xmlns:prism="http://prismstandard.org/namespaces/1.0/basic/"
> >> I recommend "...basic#" rather than "...basic/", because 
> "...basic/"
> >> necessarily
> >> denotes an HTTP resource, i.e. a sort of generic document
> >> (i.e. a thing
> >> that responds to GET requests), but RDF properties and classes
> >> might turn out to be disjoint from HTTP resources.
> >> "...basic#foo" isn't
> >> constrained the way "...basic/foo" is. (@@does this make any sense?
> >> Ask TimBL about it if you get a chance.)
> > Yes, it does make some sense. But basic#foo is constrained in
> > other ways. You have to fetch all of basic and then dig through
> > it for #foo. The PRISM namespaces are small enough that would not
> > be a big filesize problem (unlike the LCSH case), but the only
> > format that has fragment identifiers defined for it right now
> > is HTML. So, one way or the other we are implicitly saying something
> > about the resource - that it is an HTTP resource or that the thing
> > is a part of an HTML file. Both suck, but I think the HTTP
> > thing sucks less. I am open to argument on this issue, however.
> 
> Actually, that's not true. XPointer is in Last Call:
> 
> http://www.w3.org/TR/xptr
> 

Yes, I know, although I don't know how long it will take to get
the patent situation resolved. Nevertheless, I should 'fess up
that my argument about HTML will not be true for long.

But rather than digress, the real question here is whether to
use '/' or '#' as the last character in a namespace URI. The
PRISM URIs currently use '/', which I generally prefer to '#'
because it is the server's job to deliver the part, instead
of making the client dig through potentially arbitrary formats
in files of arbitrary size. I find this a very pragmatic
argument, and consequently one that holds a lot of weight for me.

> However, I do think it would be rather useful to get 
> something at those
> namespace URIs. RDDL will do just fine, and it has fragment 
> identifiers
> defined (both by XPointer and by HTML!).

Yeah, that would be a good thing to do. I suspect that I won't
get to it before the spec goes out on April 9, but after that
I see no problems.

> A typo:
> > which then contains one of RDF's collection constructs, 
> such as dc:Seq.
> 
> I think you mean rdf:Seq.

Whoops. Thanks for catching that.

> I'd also appreciate seeing RSS in the "Relationship to Other 
> Specs" section.

Yes, good suggestion. I can do that. Got a good, short, synopsis
of RSS you want me to base that on?

> It looks pretty good, although it might be useful to break 
> the normative and
> non-normative parts into two separate documents to make it shorter.

Yeah, it is longer than I would prefer. But without the intro,
the spec just seems too bare for people in the target market -
implementers of publishing systems and policy. 

Best regards,
Ron

Received on Tuesday, 13 March 2001 09:59:10 UTC