W3C home > Mailing lists > Public > www-rdf-interest@w3.org > March 2001

RE: quick review of the PRISM spec

From: Ron Daniel <rdaniel@interwoven.com>
Date: Fri, 9 Mar 2001 18:47:01 -0800
To: "'Dan Connolly'" <connolly@w3.org>, <spec-comments@prismstandard.org>
Cc: <www-rdf-interest@w3.org>
Message-ID: <000801c0a90c$62bbf240$e814000a@interwoven.com>
Hi Dan,

Thanks for starting things off. Couple of questions...

> Overall, good stuff! My comments are all nits...

Glad to hear it.

> * <dc:creator>Abraham Lincoln</dc:creator>
> beware: persons versus names of persons
> also: <prism:rightsAgent>Phantasy Photos, 
> Philadelphia</prism:rightsAgent>
> also: [[
> Many elements, such as dc:subject, may take a string as a 
> value, or may use
> a URI for identifying an
> element in a controlled vocabulary of subject description 
> codes. The URI may
> be a simple reference, or
> may provide an inline description of the controlled vocabulary term.
> Implementations MUST be capable of
> handling all three of those cases reliably.
> ]]

This may be too cryptic for me. Or it may be that I understand
you perfectly, and just think that you are striving for a level
of precision that is inappropriate for PRISM's intended use.

Are you requesting that things like
  <creator>Abraham Lincoln</creator>
be changed to something else? If so, what?  Also, please keep in
mind a few things:
0) PRISM is not intended to build knowledgebases that allow rigorous
   logical deductions. It is intended to help publishers find
   and reuse materials faster, easier, cheaper, and to make more
   money reusing the stuff. Any further purpose to which the
   data can be put is gravy. So, simple implementations will
   take string representations of the names of things and
   dump them into columns for text searches to find. That is the
   world in which PRISM must live, and work.
1) Cataloging errors occur. The frequency of cataloging errors
   increases rapidly as the definitions become arcane and the
   distinctions become subtle.

> * <dc:coverage rdf:resource="iso3166-2:gr" />
> er... the iso3166-2 URI scheme is new to me; are you registering
> it?

Nope, that would be for ISO to register.

> * <dc:identifier rdf:resource="wanderlust:2357845" />
> whoa! don't give folks the impression they can create their own
> URI schemes just like that.

I am happy to change this to something else. But a lightweight
procedure for registering URI schemes would be nice.

> * 4.3 PRISM MIME Type
> The Internet Media Type (aka MIME type) for PRISM descriptions is 6
> "application/prism+rdf+xml".
> er... isn't the convention */xml+*? I should double-check the 
> recent RFC...

>From http://www.ietf.org/rfc/rfc3023.txt :

8.18 Application/rdf+xml

   Content-type: application/rdf+xml

   <?xml version="1.0" ?>

   RDF documents identified using this MIME type are XML documents whose
   content describes metadata, as defined by [RDF].  As a format based
   on XML, RDF documents SHOULD use the '+xml' suffix convention in
   their MIME content-type identifier.  However, no content type has yet
   been registered for RDF and so this media type should not be used
   until such registration has been completed.

Since an RDF media type makes about as much sense as an XML
media type (in the PRISM WG's HO), we extended the +xml convention.

> * 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.

> * 4.8.2 Constraint 2: rdf:aboutEachPrefix disallowed
> probably wise.
> * "XML DTDs cannot describe such a flexible content model, so 
> no DTD is
> provided in this specification 11 ."
> I bet you can describe it with an XML Schema; I've got some 
> stuff you might
> want to start from.
> Ah... you're already on to this: "11 A validation tool based 
> on XML Schemas
> is being developed.".

Yes, but if you can provide some help that would be great. The
story I have gotten is that we can use the xsi:type attribute
to distinguish between the different content models. However,
I am unwilling to require all PRISM users to correctly specify
that attribute as well. I want to look into making an XSLT
stylesheet that would detect the attributes and content being
used and insert the right value for xsi:type. Then, the Schema
validation could be run on that.

> * <dc:subject rdf:resource="NAICS:21"/>
> more unregistered URI schemes?

Yup. That one is for NAFTA's industry classification scheme
known as NAICS - North American Industrial Classification System.

> * bird's-eye
> using a single-quote in a name is likely to be problematic. 
> Don't go there.

Ahh - good point. I will change those.

> I hope to provide more details about these comments and give the PRISM
> spec another, closer, review. But that's what I found in the 
> first reading.
> I really like the liberal use of scenarios and examples; terms take on
> meaning by use, and using the terms in examples in the spec is a
> good way to get the use of the terms off the ground.

Thanks. So far I'm actually pretty happy with the way it has turned 
out. Now I have to go sell it.

Received on Friday, 9 March 2001 21:48:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:29 UTC