Re: Review of Cool URIs for the Semantic Web

Hi Harry!

thanks for the review, I changed the document accordingly.
Especially the wrong URIs in one of the illustrations needed to be fixed.

I did not include all changes, partly due to the time constraint which 
we have now.

It was Harry Halpin who said at the right time 28.03.2008 18:39 the 
following words:
> Since I think this is quite an important note, I'm going to chime in.
> While I do think there's problems with both 303s and hash URIs (Please
> read this message to www-tag [1] to see how they both kinda have issues
> from a purely Web standards viewpoint, or just read the entire paper at 
> [2]), in certain cases they are better than nothing and I think it's the
> job of this note to explain the TAG's decision, not change it :)
>
> Minor semantic clarifications:
>
> 1) I kinda think, even though I think this is wrong, that the term
> "information resource" applies to whatever might in some possible world
> (i.e. the future) be returned over the Web. But if the TAG hasn't
> noticed this then it doesn't likely matter, but just in case..
>
> " In technical literature, such as Architecture of the World Wide Veb,
> Volume One <http://www.w3.org/TR/2004/REC-webarch-20041215/> [AWWW
> <http://www.w3.org/TR/cooluris/#ref-AWWW>], the term /Information
> Resource/ is used instead of /Web document/." -> "For most purposes, in
> technical literature like the Architecture of the World Wide Veb, Volume
> One <http://www.w3.org/TR/2004/REC-webarch-20041215/> [AWWW
> <http://www.w3.org/TR/cooluris/#ref-AWWW>], the term /Information
> Resource/ can be considered synonymous with the term /Web document/."
>   
the document is targeted at "the web developer from the street" therefore we
picked "Web document"

> 2) Overall the document is excellent explanation. It would be better
> also if it served as a bit of a primer, since after I've just been
> indoctrinated into giving URIs to things by using 303s, an eager
> developer might actually want to do this. Yet the example of how to
> modify an .htaccess file so 303 and conneg can be used is  in "Best
> Practice Recipes for Publishing RDF Vocabularies" [3].
>
> Yet the only reference of this *extremely useful* cut and paste sort of
> examples - precisely the kind needed by developers wanting to deploy
> 303s and conneg - is here  "The W3C's Semantic Web Best Practices and
> Deployment Working Group has published a document that describes how to
> implement the solutions presented here on the Apache Web server. The
> Best Practice Recipes for Publishing RDF Vocabularies
> <http://www.w3.org/TR/2006/WD-swbp-vocab-pub-20060314/> [Recipes
> <http://www.w3.org/TR/cooluris/#ref-Recipes>] mostly discuss the
> publication of /RDF vocabularies/, but the ideas can also be applied to
> other kinds of small RDF datasets that are published from static files."
> So, why not just either merge the documents? Or keep the "Cool URI"
> document as an explanation, and keep technical examples in the Best
> Practice Recipe Doc?
>
> To make this document useful as a primer, you either you need to provide
> working code (like .htaccess files) for your examples inline in the
> document or *clearly* tell the readers this sort of thing is in the
> "Best Practices" document.
>
> To make your life easier, I'd just move all the rather technical details
> in Sec 4.7 to the "Best Practice Recipes" in order to keep readers in
> line. And say, "If you're going to need help implementing content
> negotation and 303 redirection, please see the working examples for
> modifying your server in Best Practice Recipes for Publishing RDF
> Vocabularies <http://www.w3.org/TR/2006/WD-swbp-vocab-pub-20060314/>."
>   
forwarded this idea to the editors of best practices
we won't change cool-uris now,
we have only "a day" left.
(this was last-call wd and we can't change the document as big as indicated)

> 3) Remove mention of XRIs:
>
> "*XRI <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri>*
> defines a scheme and resolution protocol for abstract identifiers. The
> idea is to use URIs that contain wildcards, to adapt to changes of
> organizations, servers, etc.
> Examples are |@Jones.and.Company/(+phone.number)| or
> |xri://northgate.library.example.com/(urn:isbn:0-395-36341-1)|."
>
> XRIs are patented and not clearly royalty-free and IMHO can be dangerous
> to use.  Either this should be mentioned or they should just be removed
> entirely. I'd prefer to remove them entirely, since if one can't say
> anything nice one should say nothing at all.  Or you could say "Using a
> new scheme that isn't clearly in the public domain like the patented
> technology of XRIs, could inadvertently put you in a sitution where a
> company may demand money from you!"
>   
Wikipedia says otherwise:
"The patents that enable XRI technology were licensed exclusively to a 
public non-profit organization, XDI.org <http://www.xdi.org>, a 
non-profit organization required by its charter 
<http://www.xdi.org/modules/pages/index.php?id=5> to manage XRI and XDI 
infrastructure in the public interest. When the XRI Technical Committee 
was formed at OASIS in January 2003, XDI.org contributed its patent 
license as fully documented on the XRI TC IPR page 
<http://www.oasis-open.org/committees/xri/ipr.php>. The XRI TC has 
operated since its conception under a royalty-free licensing policy as 
explicitly stated in its charter 
<http://www.oasis-open.org/committees/xri/charter.php>."

Also, W3C patent policy is similar.
http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing
"W3C will not approve a Recommendation if it is aware that Essential 
Claims exist which are not available on Royalty-Free terms"
I interpret this as: patents are ok, if a royalty-free license is 
granted to all implementers.
 From the wikipedia page, I see that XRIs follow a similar goal, but I 
cannot judge the actual implementation, so I will not include your 
warning in the above form.

Instead I added this to cool-uris:
"Independent of standardization body and retrievability, pending patents 
and legal issues can influence the adoption of a new URI scheme.  When 
using patented technology, implementers should verify that a 
Royalty-Free license is available."

If you dig bashing other uri schemes, read this :-)
http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html


> Minor sentence clarifications:
>
> "The notion of resource /identity/ was not so important on the
> traditional Web, a URL simply identified whatever we see when we type it
> into a browser"-> "The identity of a resource is not as important
> outside the Semantic Web, since a URL simply identified whatever
> web-page was accessed when we typed the URL into a browser."
>   
not changed, its ok as is.
> "Has the homepage an email address? And why has the homepage a homepage?
> " -> "Can a homepage itself have an e-mail address? And does it even
> make sense for a home-page to have itself as its home-page?"
>   
good! done
> Maybe add a sentence or two: "A human can easily disambiguate these sort
> of distinctions to tell apart Alice and her homepage. Yet on a Web where
> data integration is performed automatically by computer programs, the
> sort of ambiguity caused by a having a person and their homepage have
> the same identifier can not be resolved automatically and may even cause
> problems."
>   
hm, not added, too distracting from the flow at this point.
> "a different setup is needed when publishing URIs that are meant to
> identify entities." -> "but a different setup is needed when publishing
> URIs that are meant to identify entities."
>   
added the "but"
> "In those cases the RDF data is extracted from the returned HTML
> document." -> "In those cases the RDF data is extracted from the
> returned HTML or XML document, and a new URI can be given to this
> extracted data as needed."
>   
not added, if we mention the new uri, we would have to explain how to 
exactly make the new uri, for which there is no time left. (as you say, 
its quite complicated)
> This is actually quite complicated in GRDDL [4], but referencing this
> might just be too scary for most people. Luckily, implementations just
> do it.
>
> The bottom URIs in this picture seem off,
> http://www.w3.org/TR/cooluris/img20080321/303conneg.png.
> Shouldn't they be http://www.example.com/aboutalice.rdf or
> http://www.example.com/about/alice.rdf. Otherwise, are all users on the
> system like Bob also being given the same about.rdf?
>   
argh, you are right.
done.

> "When using 303 URIs for an ontology, like FOAF, the network delay can
> reduce a client's performance considerable." -> "When using 303 URIs for
> an ontology, like FOAF, network delay can reduce a client's performance
> considerably"
>   
ok

> "An ideal case are RDF Schema vocabularies and OWL ontologies, where" ->
> "The ideal case is RDF Schema vocabularies and OWL ontologies, where"
>   
used "the", but not singular.
> "of the new" -> just delete. Some rather old URI schemes, including
> URNs, don't provide a resolution service. Also, might add a sentence to
> the extent that "Using a resolution-scheme to resolve to a http URI is
> usually unnecessary, as often a stable http URI itself would accomplish
> the exact same purpose but with less overhead."
>   
not changed,
this section was discussed much before and the current version somehow 
made most people happy.
> "We see that HTTP URIs are still used to identify the location where to
> download more information." -> "In this way, HTTP URIs are still used to
> identify the location where to download more information."
>   
This was already changed due to one of Susie Stephens' comments to:
"We see that HTTP URIs are still used to identify the location where 
more information can be downloaded".

thanks again for the review,
kind regards
Leo
> Overall, great job!
>
> [1]http://lists.w3.org/Archives/Public/www-tag/2008Mar/0073.html
> [2]http://www.ibiblio.org/hhalpin/homepage/publications/indefenseofambiguity.html
> [3]http://www.w3.org/TR/swbp-vocab-pub/
> [4] http://www.w3.org/2004/01/rdxh/spec#base_misc
>   


-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann@dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________