Cool URIs for the Semantic Web
editors notes

This page is used by Leo Sauermann as editor of the to track changes of the SWEO IG note "Cool URIs for the Semantic Web". The co-authors Richard Cyganiak and Danny Ayers also use it for comments.

Table of Contents

Handling feedback
   Feedback on version 20080321
   Feedback on version 20071217
    Issues List
     Issue #1 Thing URI, Generic Document URI, RDF+HTML Document URIs
     Issue #2 "Non-Information Resource"
     Issue #3: Graphic error?
     Issue #4: change graphics
     Issue #5: TAG has to check
     Issue #6: Give implementation examples
  Feedback before 17.12.2007 (handled)
  Notes
    Things done
    Handling of Danny Ayers' English-speaker review
    Richard's issues list

Handling feedback

Leo is reading all the feedback and marking the things to do:

• will address: The section A has typo "blah" should be replaced with "bla".
• will NOT address: Please refer to "my great idea".

• Done:  DONE, Firstname Secondname on 20.11.2007

Feedback on final note version 20080331

Feedback on version 20080321

Feedback on version 20071217

The feedback and answers indicating changes to the document by SWEO is gathered in the column "feedback by us" and then sent via e-mail back to the reported once the next version is ready. When all issues are closed, we have a new draft of the document.

Our working draft is HERE:
https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/cooluris_sweo_note.html

Issues List

Issue #1 Thing URI, Generic Document URI, RDF+HTML Document URIs

Solved in compromise: both solutions are described now.

Timbl wants to have a solution with a URI for the generic document, see

http://chatlogs.planetrdf.com/swig/2008-02-14.html#T21-11-15

Here a copy from feedback9#i1:
> ** Major technical question about the implementation of 303. I know
> that dbpedia does it the way described, but there are a lot of good
> reasons to do it by a 303 to a generic URI for the document, which
> then itself does a conneg to RDF and HTML.
>
> - It is no more round trips than the dbpedia way
> - It gives the client a URI to bookmark which is generic. This is
> important:
> - It allows the user with an RDF-capable client to bookmark the
> document, and mail it to another user (or another device) which then
> dereferences it and gets the HTML view. This use of generic resources
> is important.
> - It provides the server with the ability to add representation in new
> languages in the future.
> - It is standard conneg and so probably more supported on servers
>
> Just because client started with the URI of a thing, it doesn't mean
> that the document involved is not a first class document on the WWW.
> Best practices for this document apply. One of these is the use of
> Generic Resources. (See for example http://www.w3.org/DesignIssues/Generic.html
> and the new ontology )

You are right in your argumentation.
The problem is tough, that we still will have URIs for the various representations,
such as RDF/HTML/EN/DE, etc. In the "Content-Location" header, the http
server will return those URIs anyway.
I assume the client should bookmark the Thing-Uri, not the document
uri, or?

We will discuss this in the 20th March TAG telco?!
I hesitate though, to change the whole document now.
We have no time left.
To make everyone happy, I humbly suggest to
add your conneg-document-uri-for bookmarking solution
as another solution, after the existing ones.
Also explaining the certain problem that people
SHOULD send/bookmark/use/reference-in-triples
the thing-URI but if this is not feasible in browser
bookmarks because of redirects, it would be good to use
the generic-document-uri.

We don't know yet what is better for the semantic web, or?
lets have the reader be able to understand both sides and decide himself?
 

Pending: we wrote a mail to Stuart & TAG & SWEO & timbl about it

Notes from Telco:

Distinguishing between things and the web documents about them.
<timbl_> We have discussed ways of giving URIs to all kinds of things,
<timbl_> so that the client can find out the URIs of documents between them.
<timbl_> Note that URIs of things, say people, amd the documents abou them should not be confused: For example the person Alice is described on her homepage. Bob may not like the look of the homepage, but still like the person Alice.
<timbl_> --------------

Issue #2 "Non-Information Resource" and web document

DONE

In feedback#1, Danny Ayers wrote:
I noticed "non-information resource" used in the draft, just
rediscovered the ref. where timbl suggests it's unnecessary & maybe
misleading -
http://lists.w3.org/Archives/Public/www-tag/2007Nov/0041

In feedback#3, Andy Powell wrote:
This section appears to introduce 'Web document' as a symonym for
'information resource'? I prefer this in some ways. However, I presume
that the use of 'Web document' was rejected by previous W3C WG
discussion? Why re-introduce it here?

In feedback#3, Andy Powell wrote:
It seems to me that introducing 'web documents' and 'real-world,
non-document objects' as new terminology is ultimately more confusing
than simply using 'information resources' and 'non-information
resources'.

At the beginning of his mail, Andy preferred "web document", .... so....

In feedback#9, Tim Berners-Lee wrote:

** In general, remove the term "non-information resource" from the
entire document. Replace it with "thing". It is wrong. It is used
misleadingly to mean "A thing, which is not necessarily an information
resource".
 
** It would I think in document like this be best to stick with "web
document" instead of "information resource" too, but that is just for
readability. It is already done in places.
 
** Delete "We call all these real-world objects or (according to WWW-
Arch) non-information resources." (It is a bad term, as explained
above, and the AWWW does not use it at all).

Leo says:
The term "web document" is not common in W3Cs standardization language. Nevertheless it is understandable by the target audience, web developers. Tim Berners lee indicated positive feedback (link needed) towards the term "web document", both the SWD and TAG are critisising "web document" and required better explanations or dropping the term. As this is W3C note, we should think about dropping the term "web document".

Richard Cyganiak, Thu, 29 Nov 2007:
I'm strongly opposed to changing this terminology. "Non-information resource" is possibly the most unfortunate term ever used in discussions of web architecture, and we should quickly forget that it ever existed. ... Information resource" is an official engineering term, but inappropriate for an introductory document. The terms we currently use, "thing"/"other resource" and "web document" are appropriate, sufficiently well-explained and correct. The terminology has support from key TAG members, including Tim Berners Lee. I don't think that anything needs to be changed with regard to these terms.

Decision (accepted by Leo and Danny):

• we use "Web document" and as opposite terms "thing" and "real-world object"

Issue #3: Graphic error?

what did Christoph mean here?
He explained later that <link> should be used throughout the example.
This minor issue is closed.

Issue #4: change graphics

DONE

• DONE change uris.graffle and uris.png - replace "URL" by "URI", see feedback by Andy Powell.
• DONE TimBl in feedback#9: The diagram just before 4.2
  ** Remove "303 redirect", replace it with "content negotiation". Status code is 200.
  add the content-location reply headers to the arrows:
  Content-Location: http://www.example.com/about.rdf as label of the left arrow, remove the URI below
  and
  Content-Location: http://www.example.com/about.html as label of the right arrow, remove the URI below
  
   

Issue #5: TAG has to check

The TAG suggest to rephrase the first sentence in 3 "Uris for real-world objects" with:

"With the advent of semantic web technologies, the web is extended so that (http:?) URIs can
identify not just web documents but also "...

Suggestion: We think the current text is fine.

There is another thing in 3.1 where the TAG has to check our solution.

Issue #6: Give implementation examples

This issue will not be addressed due to time constraints of the editors and the ending of the SWEO Interest Group.

@@ Reviewers asked for example rules of thumb how to distinguish between document identifiers and concept identifiers (information and non-information resources). Write some wget examples that do that? Leo Sauermann agrees that we did not cover the crucial point yet: what is the definitive test to verify that a URI identifies a non-information resource? Range-14 says: "If an "http" resource responds to a GET request with a 303 (See Other) response, then the resource identified by that URI could be any resource;" Or is this such a problem at all? At the end the RDF:type indicates the nature of a resource. If we find a script example, I would put that into the 4.6. implementation section.

Resolved Issues

Spelling decisions:

• Web site (not website)
• email (not e-mail)
• use "representation" and "represent" instead of "description" and "describe", see its heavy use in [AWWW].
  Maybe we are biased towards "describe" because of RDF... anyway, the intended target audience is web developers, hence the language of AWWW should be used.

@@(Scope) Say that this document explains the TAG decision httpRange-14 resolution [httpRange] and does not recommend new solutions. @@

From 2.1: @@DannyAyers: ...and treat them as independent resources? @@Leo: they may be several representions of the same resource, the term "independent" may be misleading.

@@ Danny Ayers: Status will probably need editing for W3C-conformance
@@ Leo (13.3.2008) until now, nobody really complained, its ok.... if not, we get warned anyway.

@@Danny Ayers: I believe it came in a recent thread on semantic-web@w3.org that "non-information resource" wasn't defined in WebArch, though I haven't checked. If so, should be reworded. My suggestion for rewording is to delete that last sentence
@@ Leo Sauermann: there is no other term offered. Suggestion: remove "(according to WWW.Arch)" in 3

@@ Danny Ayers: It's long been possible to identify things, and RDF etc aren't strictly necessary
@@ LeoSauermann: hesitate to change the document based on this general comment.

Feedback before 17.12.2007 (handled)

• David Booth: http://lists.w3.org/Archives/Public/www-tag/2007May/0070.html
• many points
• status: not handled yet, good ideas!
• John Cowan: http://lists.w3.org/Archives/Public/www-tag/2007May/0073.html
• references to xtm-subjectidentifier and identifierRef
• status: interesting, but needs no action

• Important: From the SWD 23.10.2007: ReviewCoolURIs_SWD.htm - [public] all done, rejected, or moved to issues section in the draft

• Important: From the TAG 19.9.2007: Feedback_2007_09_19_TAG.html [public]  all done, rejected, or moved to issues section in the draft

• New diagram suggested by TAG: TAGReview_2007_09_pic.html
• TimBl on 20.9.2007: Feedback_2007_09_20_TimBl.html
• TimlBl on 24.9.2007: Feedback_2007_09_24_TimBl.html

Feedback that will not be taken into account (for now)

• The TAG minutes on 17.9.2007 (I assume they are summed up in the email from 19.9.2007) : http://www.w3.org/2007/09/17-tagmem-minutes.html
• new feedback by Ian Jacobs on 15.11.2007 Feedback_2007_11_15_IanJacobs.html
• http://www.w3.org/2001/tag/2007/09/17-tagmem-minutes if there is anything important that misses in the tag mail more in http://www.w3.org/2001/tag/2007/09/18-tagmem-minutes#item07 http://www.w3.org/2001/tag/2007/09/17-tagmem-minutes.html#action02

Notes

More todos can be found in the changelog of the document.

Things done

• replace acme.com and #acme by example.com and #exampleinc in the graphics
• Review by Native Speaker, (recommended by SWD): Though the overall language quality of the document is quite high, it would be good to do some spell-checking and language clean-up by a native speaker. Just to mention few things noticed at the first sight even by a reviewing non-native speaker - the fourth paragraph of Section 1 is inconsistent in the tense used (from the sentence "In the remainder of this paper..." on - future and present tense are mixed); the third paragraph of Section 6.1 contains a typo ("resourcse").

Handling of Danny Ayers' English-speaker review

Leo got the review from Danny on 10.12.2007 and replaced the existing document with Danny's. Leo did undo a few changes, though:

• no link to URI rfc in abstract: you don't do links and citations in abstracts
• accepted note [@@danja: file system]
• accepted note [@@ danja maybe title of target docs should be used in these links]
• added ref to GRDDL

Other Feedback already considered (will not be taken into account furthermore)

• From: Ed Summers <edsu@loc.gov>
  Date: Mon, 24 Sep 2007 11:18:57 -0400
  http://lists.w3.org/Archives/Public/public-swd-wg/2007Sep/0068.html

  Leo: its ok to continue using "web documents", the document addresses normal developers off the streets. I would be in favor of doing these things:

  • Also did the authors consider a few examples of an 'information-resource sniff test'? I think a few examples of how to determine if a resource is an information resource or a non-information resource would be useful.
  • p.5, paragraph 3: 'Requests for HTML would be redirected to the web page URLs we gave in section 2' might be clearer as 'HTTP requests for HTML content would be redirected to the HTML URLs we gave in section 2'#
  • p.9, paragraph 3: In addition to seeing the use of <link> to to allow
    agents to discover RDF associated with an HTML document, it would be useful
    to see a similar example using RDFa and GRDDL. Does the fact that RDFa
    isn't a recomendation yet preclude it from being used in this document?
    LEO: no, this is not a tutorial for embedding RDF in HTML. enough is enough
  • p. 10, section 5: I would like to see dbpedia [6] included since it uses the
    303 redirect technique to link directly to a SPARQL query, and it is such
    a rich and evolving dataset. It would also be useful to be referred to a
    good hash URI real world example.
    LEO: we may want to do that, but its not mandatory
  • - p. 14, section 9: Would the restriction against derivative works prevent
    this document from being used as a W3C reference document? For example the
    SWD had talked about possibly including portions of the document in the
    Recipes document or elsewhere and this license was perceived to restrict
    that usage.
    Leo: this is to keep our right as authors to choose who can make a derivative work for what reason. As with any license, there are exceptions, but we want to know who does what with the text and retain our right as authors. Inclusion of the text into other W3C documents is no problem, if asked beforehand and if appropriate credits are given (as with any other citation/copypasting you do)

• http://lists.w3.org/Archives/Public/public-swd-wg/2007Sep/0070.html
  Based on this, Leo proposes to add a section describing how to combine a dynamic hosting environment with #-uris. The GO is an ugly example, as it changes so often, but it is probalby the toughest thing you can find, we don't have to find a solution for it. The document is an introductionary text, not the solution for every problem.
• http://lists.w3.org/Archives/Public/public-swd-wg/2007Sep/0062.html
  Leo: many detailled comments and many demanding tasks. We cannot and wont do everything required here.
• http://lists.w3.org/Archives/Public/public-swd-wg/2007Sep/0061.html
  Leo: here also a merge of 303 and # is requested, this is ok.
  - The first paragraph of Section 1 could be a little more descriptive when mentioning the challenge of "...distributed modelling of the world with a shared data model...". If the audience of the document is (partially) not supposed to be absolutely familiar with the Semantic Web principles, the meaning of this could be explained in a little more detail.
  Leo: No, this document is only about URIs.
  - Maybe it would be better to change the font in the example statements presented in the second paragraph of Section 1 - for instance put "subjects" and "objects" in bold face and "predicates" in italic. This could improve the readability of this piece in line with the intended impact.
  Leo: sounds ok
  - The remark on the possible MediaWiki adoption for Wikipedia is perhaps not completely appropriate in the end of Section 5, until the software would have been actually adopted.
  Leo: ok, we change that
  - The following comment about the last note in Section 6.2 about personal URIs is rather "philosophical". Even though the note comes out from a strongly backed opinion;), it is really questionable how to actually establish such personal URIs in an ideal, practical and systematic way. Imagine creating URI of John Smith in a company XYZ - we can use company's dedicated namespace to distinguish among this John Smith and other John Smiths around the world. But what if more John Smiths are in a company? We can use perhaps a namespace or URI prefix according to the departments these guys work in. But what if they work in the same department? So maybe we can use a time-stamp or a respective slashed namespace inferred from the date when they joined the company. Etc... Such situations may of course rarely occur in practice for persons, but we should have a recommended way how to solve them, since similar problems may be encountered also with names of products, services and so on. Thus, the document should either propose a recommended way of how to deal with such problems, or be a little more "careful" and avoid such potentially questionable strict statements.
  Leo: its not only opinion. RESTful integration works when you have URIs, having only IFPs at hand requires a centralized Google-esque reverse index. The notion how personal uris are created is up to the reader, many web 2.0 services have no problem reserving personal URIs, we don't need to explain the obvious http://www.flickr.com/photos/leobard.
• - Though the overall language quality of the document is quite high, it would be good to do some spell-checking and language clean-up by a native speaker. Just to mention few things noticed at the first sight even by a reviewing non-native speaker - the fourth paragraph of Section 1 is inconsistent in the tense used (from the sentence "In the remainder of this paper..." on - future and present tense are mixed); the third paragraph of Section 6.1 contains a typo ("resourcse").
  Leo: yes.

Richard's issues list

Some stuff that Richard would like to update if there is enough time

Information Resource Sniff Test

Harry Halpin has proposed a nice test for identifying IRs

Shorten the New URI schemes section

No one is talking about these proposals any more. It should be sufficient to note that there are lots of other ideas, and that Thompson and Orchard discuss why they are bad. Remember, Be On The Web and Don't Be Ambiguous! An interesting question would be wether we can explicitly say that LSIDs are bad. We imply this, but saying it loud could generate protest.

Update the Reference by Description section

The most prominent example of this has been FOAF. But FOAF no longer recommends blank nodes, and the latest spec fits our recommendations quite nicely. Maybe we can shorten or even drop the section.