Another view of the cherry blossoms surrounding the Tidal Basin in Washington, DC on Sunday, 30 March 2008. The Combat Air Patrol contrails are visible over the Washington Monument.
Musings on books, the near future, the process of writing, the Semantic Web, the origins of agriculture, evolutionary meme theories, the venture capital process and the occasional political rant; not necessarily in that order. See my books at http://hyland-wood.org.
Monday, March 31, 2008
Cherry Blossoms 2008
Bernadette and I had the great fortune to view the cherry blossoms surrounding the Tidal Basin in Washington, DC at sunrise on Sunday, 30 March 2008. They were at their peak and the light was just perfect. It rained today, so we were especially lucky not to have put it off.
Appreciation of beauty seems so antithetical from the normal activities of Washington, DC, but perhaps that should make us try harder. The contrails of Combat Air Patrol jets painted the sky behind the blossoms.
Appreciation of beauty seems so antithetical from the normal activities of Washington, DC, but perhaps that should make us try harder. The contrails of Combat Air Patrol jets painted the sky behind the blossoms.
Sunday, February 24, 2008
Semantic Conference Scheduling Application
This year's Semantic Technology Conference has a nifty new semantic conference scheduling tool, courtesy of fellow Zepheirans Uche and Eric. Nicely done, guys!
The scheduler allows you to graphically fill out a calendar of sessions that you want to attend. Conflicts are immediately visible. The faceted navigation on the left allows you to find sessions based on tagged data (speaker, company, topic, day, etc). When you are happy, you can import your schedule right into your ical-compliant calendar. I wish all conferences had this.
The scheduler allows you to graphically fill out a calendar of sessions that you want to attend. Conflicts are immediately visible. The faceted navigation on the left allows you to find sessions based on tagged data (speaker, company, topic, day, etc). When you are happy, you can import your schedule right into your ical-compliant calendar. I wish all conferences had this.
Monday, February 18, 2008
Beyond Redirection: Rich and Active PURLs
It has been a while since I posted about the new Persistent URL work being done by Zepheira and OCLC. That is partially because the work has gone much more slowly than we had planned. We have been actively gold plating the new PURL server because we are trying to satisfy several communities. The result, though, is laying the foundations for new services for the Web.
The key to the new PURL service is the typing of PURLs. The existing public PURL service at OCLC returns an HTTP 302 (Found) response, causing a Web client to redirect to another URL. The new PURL server allows PURLs to return one of several status codes (301, 302, 303, 310, 404 and 410).
We can go even further, though. The original PURL server had some internal concepts like "cloning" a PURL (basing a new PURL definition on an existing one) and "chaining" a PURL (allowing multi-person management of a URL resolution process). Combining these concepts with the choice of HTTP response codes got us thinking about arbitrary types of PURLs.
We have been experimenting with types of PURLs that combine with other services. A "Rich" PURL, for example, is the combination of a PURL and metadata. We have a prototype service that combine strong identifiers with rich metadata, providing the building blocks for other semantic applications. Rich PURLs are a combination of two related services: A PURL server for management of the resolution and RDF (or other metadata format) file hosting.
The W3C TAG finding regarding the use of HTTP 303 responses seems to suggest that we could use rich PURLs in interesting ways. For example, we could do the following:
A 301 PURL pointing to an RDF resource == Metadata about an information resource
A 303 PURL pointing to an RDF resource == Metadata about a non-information resource (i.e. a physical or conceptual resource)
That usage would be consistent with the TAG finding, even if it goes a bit beyond it.
NB: You can tell if you get a PURL by looking at the PURL header in an HTTP response.
But wait, there's more. What if a PURL pointed to a Web service (in the sense of dynamic content, not necessarily limited to SOA Web Services, but including them)? The combination of a Rich PURL and a metadata reference to a Web service yields an "Active PURL". That is, an Active PURL is a PURL naming a graph of metadata describing a Web service.
Consider a simple Web service like an RSS feed. Placing an Active PURL in front of that feed allows you to describe how that feed should be handled. You could name the facets that you want to use to make an Exhibit or provide any other presentation advice you desired.
Alternatively, an Active PURL might itself by a sort of Web service that provides dynamic metadata about another Web service and can either serve the metadata or redirect to its target service. Such an Active PURL could be used to name a SPARQL graph, accept query parameters for it and return metadata about it, such as a count of results or information on the meanings of columns in the result set. I believe that named graphs are very handy things and something that we as a community are paying inadequate attention to. Given that SPARQL may be the query language that finally integrates our silos of relational databases, fronting them with Active PURLs seems like a promising line of research.
Lists of URLs as proposed by Stu Weibel would be easy to implement as an Active PURL.
Perhaps the most interesting use of Active PURLs to enterprises might be the ability to provide standardized RDF metadata about SOA Web Services as well as relational databases. UDDI is so broken, we might as well fix it with existing SemWeb standards. That is not a new idea, but the application of Active PURLs to the problem is, I think.
The key to the new PURL service is the typing of PURLs. The existing public PURL service at OCLC returns an HTTP 302 (Found) response, causing a Web client to redirect to another URL. The new PURL server allows PURLs to return one of several status codes (301, 302, 303, 310, 404 and 410).
We can go even further, though. The original PURL server had some internal concepts like "cloning" a PURL (basing a new PURL definition on an existing one) and "chaining" a PURL (allowing multi-person management of a URL resolution process). Combining these concepts with the choice of HTTP response codes got us thinking about arbitrary types of PURLs.
We have been experimenting with types of PURLs that combine with other services. A "Rich" PURL, for example, is the combination of a PURL and metadata. We have a prototype service that combine strong identifiers with rich metadata, providing the building blocks for other semantic applications. Rich PURLs are a combination of two related services: A PURL server for management of the resolution and RDF (or other metadata format) file hosting.
The W3C TAG finding regarding the use of HTTP 303 responses seems to suggest that we could use rich PURLs in interesting ways. For example, we could do the following:
A 301 PURL pointing to an RDF resource == Metadata about an information resource
A 303 PURL pointing to an RDF resource == Metadata about a non-information resource (i.e. a physical or conceptual resource)
That usage would be consistent with the TAG finding, even if it goes a bit beyond it.
NB: You can tell if you get a PURL by looking at the PURL header in an HTTP response.
But wait, there's more. What if a PURL pointed to a Web service (in the sense of dynamic content, not necessarily limited to SOA Web Services, but including them)? The combination of a Rich PURL and a metadata reference to a Web service yields an "Active PURL". That is, an Active PURL is a PURL naming a graph of metadata describing a Web service.
Consider a simple Web service like an RSS feed. Placing an Active PURL in front of that feed allows you to describe how that feed should be handled. You could name the facets that you want to use to make an Exhibit or provide any other presentation advice you desired.
Alternatively, an Active PURL might itself by a sort of Web service that provides dynamic metadata about another Web service and can either serve the metadata or redirect to its target service. Such an Active PURL could be used to name a SPARQL graph, accept query parameters for it and return metadata about it, such as a count of results or information on the meanings of columns in the result set. I believe that named graphs are very handy things and something that we as a community are paying inadequate attention to. Given that SPARQL may be the query language that finally integrates our silos of relational databases, fronting them with Active PURLs seems like a promising line of research.
Lists of URLs as proposed by Stu Weibel would be easy to implement as an Active PURL.
Perhaps the most interesting use of Active PURLs to enterprises might be the ability to provide standardized RDF metadata about SOA Web Services as well as relational databases. UDDI is so broken, we might as well fix it with existing SemWeb standards. That is not a new idea, but the application of Active PURLs to the problem is, I think.
Tuesday, February 12, 2008
Was That So Hard?
The new Australian Government finally apologized to the aborigines.
Friday, February 08, 2008
GRDDL Article on DevX
Brian has written a new DevX article entitled "Gleaning Information From Embedded Metadata", explaining GRDDL. He used my home page at Zepheira as an example of a live page with embedded, machine readable metadata.
Thursday, February 07, 2008
Wednesday, January 30, 2008
A Great Week for Old Technology
It seems that ships are again sailing the ocean using wind power. The inventor claims that his kites can reduce fuel consumption of most merchant ships by 10-35%. That's awesome.
Even more bizarre is the Mach 20 paper airplane that a Japanese origami expert wants to throw from the International Space Station. Really, you can't make this stuff up.
Even more bizarre is the Mach 20 paper airplane that a Japanese origami expert wants to throw from the International Space Station. Really, you can't make this stuff up.
Friday, January 25, 2008
Hang onto your towel
Burt Rutan and his business partner announced the design of SpaceShipTwo. Very cool! Oddly, his business partner is apparently Zaphod Beeblebrox...

Bitten by Polymorphism
Architecture discussions can get ugly. I was participating in one when Brian suggested the domain name turdpolisher.com for our activities. A quick check on register.com showed that someone is actually holding that domain, although nothing resolves there. The polymorphism arose when we realized that register.com suggested some alternative domain names, including PolishedToes.com and PolishHeritage.org. *Sigh*
Wednesday, January 16, 2008
SPARQL Set to Change the Web
The W3C announced yesterday the standardization of SPARQL. This broken and immature standard has the capability to rapidly change business operations, Web searching, the advertising model of most Web revenue and enable a new generation of Web-based services.
SPARQL is broken and immature for the simple reasons that it failed to include a way to write data. I have my gripes about the way it reads data, too, but those are less important. As long as the W3C continues to treat the Web as a read-only system, the longer the Web will primarily be a read-only system. It is bad enough that we have failed to widely implement and use HTTP PUT and DELETE (fully half of REST), but we really should know better than to create new standards in 2008 that make the Web look like an information retrieval system and not an information aggregation and creation system.
For all that, SPARQL is still an incredibly important set of standards. There are three of them, SPARQL the query language for the Semantic Web, SPARQL the protocol and SPARQL the results format in XML.
SPARQL is important because it gives the world a standard way to perform distributed queries across disparate data sets. In other words, it allows you to treat the Web (the Semantic Web) as a database. Relational databases and other data stores can play, too. They just need a SPARQL overlay. This is something that the relational database crowd has never been able to pull off. I suspect that a standards body would have failed do create a standard for an RDB distributed query language if they had tried due to industry competitive pressures, but SPARQL is that critical end run. By pursuing the goal in the Semantic Web community, we now have something that will work for the RDB folks, too.
I remain fussed that Mulgara doesn't have SPARQL support yet, but Paul tells me it should come soon. I certainly haven't done anything to help, so I shouldn't complain.
Why do I think SPARQL can fundamentally change business models? Because of my experiences with this blog. I started experimenting with advertising once my readership reached reasonable levels. Impressions are few, even though readership is decent. Why? RSS. Most people read this blog via news readers or aggregators and not via the Web. They don't ever see the ads. Cool, right? Yeah. Imagine, though, the impact on the online advertising market (which financially supports Google and its competitors) when the Web is a database. Nobody will see the ads. Watch out, world. Where there is chaos, there is opportunity. I can't wait to see what happens next.
SPARQL is broken and immature for the simple reasons that it failed to include a way to write data. I have my gripes about the way it reads data, too, but those are less important. As long as the W3C continues to treat the Web as a read-only system, the longer the Web will primarily be a read-only system. It is bad enough that we have failed to widely implement and use HTTP PUT and DELETE (fully half of REST), but we really should know better than to create new standards in 2008 that make the Web look like an information retrieval system and not an information aggregation and creation system.
For all that, SPARQL is still an incredibly important set of standards. There are three of them, SPARQL the query language for the Semantic Web, SPARQL the protocol and SPARQL the results format in XML.
SPARQL is important because it gives the world a standard way to perform distributed queries across disparate data sets. In other words, it allows you to treat the Web (the Semantic Web) as a database. Relational databases and other data stores can play, too. They just need a SPARQL overlay. This is something that the relational database crowd has never been able to pull off. I suspect that a standards body would have failed do create a standard for an RDB distributed query language if they had tried due to industry competitive pressures, but SPARQL is that critical end run. By pursuing the goal in the Semantic Web community, we now have something that will work for the RDB folks, too.
I remain fussed that Mulgara doesn't have SPARQL support yet, but Paul tells me it should come soon. I certainly haven't done anything to help, so I shouldn't complain.
Why do I think SPARQL can fundamentally change business models? Because of my experiences with this blog. I started experimenting with advertising once my readership reached reasonable levels. Impressions are few, even though readership is decent. Why? RSS. Most people read this blog via news readers or aggregators and not via the Web. They don't ever see the ads. Cool, right? Yeah. Imagine, though, the impact on the online advertising market (which financially supports Google and its competitors) when the Web is a database. Nobody will see the ads. Watch out, world. Where there is chaos, there is opportunity. I can't wait to see what happens next.
Tuesday, January 08, 2008
Tucana's Fate Sealed
Northrop Grumman Corporation's Electronic Systems Sector has been attempting to sell its Tucana RDF database software for some time. They have been quietly seeking buyers since they dropped public references to it as a "rsemd1-extweb50 Sensor1 Replacement Server" in August 2006. Unfortunately for them, potential buyers keep calling me.
Each call is similar in nature and goes something like this:
Buyer: We are very happy to tell you that Northop Grumman has accepted our cash offer for the Tucana technology. We would like to talk to you about how we can make use of it.
Dave: Sure. I am sure Northrop must have done some work on it since they bought it. What has been added to the code base?
Buyer: They made us swear to secrecy, so we can't tell you that.
Dave: OK, I understand. Can you tell me whether it differs substantially from its Open Source baseline, Mulgara?
Buyer: Umm, there is an Open Source project? What is the URL?
Dave: http://mulgara.org
Buyer: Is it an active project? Do people use it?
Dave: Oh, yes. It is used in production by a number of for-profit and non-profit companies and many researchers.
Buyer: I thought Northrop had killed the Open Source project?
Dave: Nope. They tried but failed. Mulgara was a fork to avoid any future legal disputes. It has no code contributed by Northrop or its contractors.
Buyer: Uh, perhaps we should look into that and get back to you.
Naturally, that is generally the last I hear about it until the next potential buyer calls. The last one was yesterday, but they weren't the first (or the second or the third) and probably won't be the last.
The sad thing is, of course, that if a single manager at Northrop had tried to work with the Open Source community instead of building an empire the project could have been wildly successful in their customer base. There is still a market need for a more scalable RDF database outside of the government, as evidenced by the list of potential buyers, the life sciences community's desire to represent genomic data semantically, Garlik's creation of a custom one last year and continued funding from Mulgara users for scalability development.
Each call is similar in nature and goes something like this:
Buyer: We are very happy to tell you that Northop Grumman has accepted our cash offer for the Tucana technology. We would like to talk to you about how we can make use of it.
Dave: Sure. I am sure Northrop must have done some work on it since they bought it. What has been added to the code base?
Buyer: They made us swear to secrecy, so we can't tell you that.
Dave: OK, I understand. Can you tell me whether it differs substantially from its Open Source baseline, Mulgara?
Buyer: Umm, there is an Open Source project? What is the URL?
Dave: http://mulgara.org
Buyer: Is it an active project? Do people use it?
Dave: Oh, yes. It is used in production by a number of for-profit and non-profit companies and many researchers.
Buyer: I thought Northrop had killed the Open Source project?
Dave: Nope. They tried but failed. Mulgara was a fork to avoid any future legal disputes. It has no code contributed by Northrop or its contractors.
Buyer: Uh, perhaps we should look into that and get back to you.
Naturally, that is generally the last I hear about it until the next potential buyer calls. The last one was yesterday, but they weren't the first (or the second or the third) and probably won't be the last.
The sad thing is, of course, that if a single manager at Northrop had tried to work with the Open Source community instead of building an empire the project could have been wildly successful in their customer base. There is still a market need for a more scalable RDF database outside of the government, as evidenced by the list of potential buyers, the life sciences community's desire to represent genomic data semantically, Garlik's creation of a custom one last year and continued funding from Mulgara users for scalability development.
Tuesday, December 04, 2007
UPDATED: Helping the Ogbuji Family
Some of you have contacted me about where to send items or other forms of well wishing to the family of Chime Ogbuji. The best way to help the family is to donate the Ogbuji Family Fund, set up by Chime's father, Dr. Linus Ogbuji. Donations may be made by clicking the "Donate" button on http://thekingdomkids.org/fund/.
Thanks in advance to anyone providing what comfort they can.
Thanks in advance to anyone providing what comfort they can.
Monday, December 03, 2007
Tragedy
Chime Ogbuji, SemWebber extraordinaire and brother to Zepheira business partner Uche has suffered the most tragic occurrence of which I can conceive. Chime lost two of his children in a fire over the weekend, and his third is in critical condition. I waited for the last two days to say something meaningful, but there just are no words for this. I am so, so sorry for Chime and his family. The sad tale is reported here. Chime, our thoughts are with you.
Sunday, November 04, 2007
The Poor State of SPARQL Implementations
*Sigh* I had a simple task. Really I did. I am putting the final touches on a journal article and wanted to expand an example to be more interesting. All I wanted to do was demonstrate (in SPARQL) that multiple RDF graphs can be pulled in from URLs and the dynamically-assembled graph queried. I wouldn't have thought that was such a big ask for 2007. Alas, I was wrong.
Here is the query:
Redland won't do it because it does not support FROM (or FROM NAMED). The same for OpenLink Virtuoso SPARQL and JRDF. Sesame 2.0 might do it, but I got tired of looking. I'll have to get back to it tomorrow.
In the meantime, I hacked around the problem by using a little-known feature of JRDF - one can import a series of RDF or OWL files and query the subsequent graph. It is annoying, and requires local copies of the documents, but it works (kind of).
The really sad thing is that Tucana had this feature (in the iTQL query language) in 2000 or 2001. Mulgara still does, of course. Paul assures me that SPARQL support in Mulgara is finally close. That is wonderful, but it does make me feel a bit guilty for not contributing to it given its obvious need.
I still (since 2000) think that querying multiple data sources from the WEB makes the SEMANTIC WEB a bit more useful, and interesting. *Sigh* I guess I will have to either contribute more or live with it.
UPDATE: Sesame does not support SPARQL datasets according to this bug, even though a patch has apparently already been contributed.
UPDATE: OpenLink Virtuoso demos at http://demo.openlinksw.com/sparql and http://demo.openlinksw.com/isparql now both return results. However, they return four results where I expect two.
Dave Beckett claims that the latest Redland/Rasql from svn now supports the query, but that he also gets four results.
Danny's SPARQLer now returns correct results (two).
Thanks to everyone who responded! Having proper FROM and FROM NAMED support opens a floodgate of potential new SemWeb applications.
UPDATE: Changing "SELECT" to "SELECT DISTINCT" returns the correct two results from Virtuoso. I suspect that change may be needed with others, too.
Here is the query:
prefix sec: <http://www.itee.uq.edu.au/~dwood/ontologies/sec.owl#>
prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT ?class ?test ?testresults
FROM <http://www.itee.uq.edu.au/~dwood/ontologies/sec-example.owl>
FROM <http://www.itee.uq.edu.au/~dwood/ontologies/sec-testresults.owl>
WHERE {
?class rdf:type sec:OOClass .
?test sec:isTestOf ?class .
?test sec:hasTestResults ?testresults
}
Redland won't do it because it does not support FROM (or FROM NAMED). The same for OpenLink Virtuoso SPARQL and JRDF. Sesame 2.0 might do it, but I got tired of looking. I'll have to get back to it tomorrow.
In the meantime, I hacked around the problem by using a little-known feature of JRDF - one can import a series of RDF or OWL files and query the subsequent graph. It is annoying, and requires local copies of the documents, but it works (kind of).
The really sad thing is that Tucana had this feature (in the iTQL query language) in 2000 or 2001. Mulgara still does, of course. Paul assures me that SPARQL support in Mulgara is finally close. That is wonderful, but it does make me feel a bit guilty for not contributing to it given its obvious need.
I still (since 2000) think that querying multiple data sources from the WEB makes the SEMANTIC WEB a bit more useful, and interesting. *Sigh* I guess I will have to either contribute more or live with it.
UPDATE: Sesame does not support SPARQL datasets according to this bug, even though a patch has apparently already been contributed.
UPDATE: OpenLink Virtuoso demos at http://demo.openlinksw.com/sparql and http://demo.openlinksw.com/isparql now both return results. However, they return four results where I expect two.
Dave Beckett claims that the latest Redland/Rasql from svn now supports the query, but that he also gets four results.
Danny's SPARQLer now returns correct results (two).
Thanks to everyone who responded! Having proper FROM and FROM NAMED support opens a floodgate of potential new SemWeb applications.
UPDATE: Changing "SELECT" to "SELECT DISTINCT" returns the correct two results from Virtuoso. I suspect that change may be needed with others, too.
Wednesday, August 29, 2007
Returning HTTP 303s for Semantic Web URIs
The World Wide Web Consortium's (W3C) Technical Architecture Group (TAG) attempted to settle a long standing debate about the use of URL resolution called http-range-14 a couple of years ago by ruling that "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." Roy Fielding's original suggestion for the TAG finding is here.
That is a very subtle point. The idea was to cleanly separate those resources that are referred to by an HTTP URL and those that cannot be referred to directly, but might have an HTTP URL assigned to them anyway. The latter include physical items in the real world. Importantly, many of the objects assigned URIs in Semantic Web descriptions are given HTTP URLs but cannot be directly referred to on the Web.
Programmatic resolution of an HTTP URL may refer to an object in the real world (that is, an arbitrary resource) or an information resource (in some virtual form, such as an HTML page or an image or a movie). In that case, the HTTP response code would be 303 instead of 200. A 303 is an indication that the thing referred to may not be an information resource, it may be either an information resource or a "real" object. The body of the 303 (and the Location header) can provide information about the resource without encouraging you to think that what was returned really was a representation of the resource (as you would with a 200 response).
Most HTTP resources are expected to respond to a GET request with a 200 (OK) response and the body of a 200 is an "information resource". The definition of an information resource is that the entire content of the referred object may be "conveyed in a message".
But what about resources that cannot be conveyed in a message? My dog is a resource, as is my car, or myself. These things cannot be conveyed in a message, they can only be referred to. That is where HTTP 303 response codes come in.
RFC 2616 defines HTTP version 1.1 and its response codes. Section 10 defines a 303 thusly:
Thus, the body of a 303 response is under-specified. There are several open questions. Some of them are:
I rather like the idea of using RDFa, but a broader solution may be to always include a text/html body part, but use a multipart/alternative structure to allow for the body to hold RDF data (in whatever form) if it is present. That way, an implementation would not have to run the body through an RDFa parser just to determine whether any RDF content was present. The use of an additional header to indicate the presence of RDF content would also do it, regardless of the body type.
Of course, others have derided the use of HTTP URLs (emphasis on the Locator aspect) to reference arbitrary resources in the universe (for which the URI, I for identifier, was designed) and for some good reasons. However, I see tremendous value in being able to marry information space with meat space via the resolution of HTTP URLs. In fact, the automated manipulation of Semantic Web content depends upon it. That is why the TAG's finding makes a lot of sense. The use of 303 response codes to both separate resolution from description while maintaining universal addressing ties the abstraction of the Internet to the real world.
The new Persistent URL (PURL) service, now in construction, will allow PURLs to be created that can return 303 responses. The use of 303s to represent arbitrary real-world resources will enable PURLs to coalesce the fragmented persistent identifier space. Do we really need LSIDs, DOIs, INFO URIs and the rest? My answer is, "Not if the Web Architecture supports all their requirements". The representation of arbitrary objects via HTTP URLs and the ability to return multiple See Also URLs from a response would seem to do just that.
TimBL has raised a concern that the information resource contained in a body of a 303 response should not contain anything very interesting, because it is not addressable (in context of the linked data discussion). I disagree. The address of the 303 body is directly addressable because that is what is returned when the URL that got you there is resolved. Further, the 303 status informs a user that the information resource in the body is not the requested resource itself, merely information about it. That is, the URL addresses both the (real world) resource and the information resource in the 303 body and the 303 status allows one to cleanly separate which one you may wish to refer to at any given time, either programmatically or by a human.
As Paul points out, the use of a 303 response code does not put a requirement on the semantics of the identifier. A 303 response may be used to present information to a human user, while at the same time providing an indication to a computer that the resource you addressed is not the one that was returned.
I have posted about http-range-14 issues before, but not in this amount of detail. I think that proper answers to the questions above will be critical to the success of the Semantic Web because we must have a mechanism to programmatically determine whether an HTTP URL refers to an arbitrary thing in the wide universe or that relatively small subset of things that we call information resources.
A big question in any new use of HTTP is how existing browsers have implemented handling of the return codes. I was quite surprised that Firefox and Apple's Safari redirect to the Location header in a 303! For example, go to the home page for Tom Heath (http://kmi.open.ac.uk/people/tom/) and you will be redirected to http://kmi.open.ac.uk/people/tom/html. Neither browser will show you that an intermediate 303 return code was issued or that the browser followed it. You can see the 303 by using something like HTTPTracer or wget. It is also interesting to note that Tom is using a text/html body describing in human terms what the Location header says (a "short hypertext note", captured using HTTPTracer):
Tom is using a 303 in the manner described by RFC 2616, and it is important to note that it does not conflict with the TAG finding regarding http-range-14. His response does, in fact, refer to "any resource".
The fact that browsers are automatically (and incorrectly, in my opinion) redirecting to the URLs specified in 303 Location headers suggests to me that Semantic Web applications will need to be careful. We can rely upon our own programmatic handling of 303s, but not the browsers'. We should also, again in my opinion, ensure that we do not break existing browser implementations if we can help it. The use of creative 303 body messages and perhaps new headers is one way out.
That is a very subtle point. The idea was to cleanly separate those resources that are referred to by an HTTP URL and those that cannot be referred to directly, but might have an HTTP URL assigned to them anyway. The latter include physical items in the real world. Importantly, many of the objects assigned URIs in Semantic Web descriptions are given HTTP URLs but cannot be directly referred to on the Web.
Programmatic resolution of an HTTP URL may refer to an object in the real world (that is, an arbitrary resource) or an information resource (in some virtual form, such as an HTML page or an image or a movie). In that case, the HTTP response code would be 303 instead of 200. A 303 is an indication that the thing referred to may not be an information resource, it may be either an information resource or a "real" object. The body of the 303 (and the Location header) can provide information about the resource without encouraging you to think that what was returned really was a representation of the resource (as you would with a 200 response).
Most HTTP resources are expected to respond to a GET request with a 200 (OK) response and the body of a 200 is an "information resource". The definition of an information resource is that the entire content of the referred object may be "conveyed in a message".
But what about resources that cannot be conveyed in a message? My dog is a resource, as is my car, or myself. These things cannot be conveyed in a message, they can only be referred to. That is where HTTP 303 response codes come in.
RFC 2616 defines HTTP version 1.1 and its response codes. Section 10 defines a 303 thusly:
NB: An information resource should only be returned by an HTTP GET, not a POST, hence the discussion of POST. I unfortunately don't know of many people who bother to comply with Web Architecture to that extent.
The response to the request can be found under a
different URI and SHOULD be retrieved using a GET
method on that resource. This method exists primarily
to allow the output of a POST-activated script to
redirect the user agent to a selected resource. The
new URI is not a substitute reference for the originally
requested resource. The 303 response MUST NOT be
cached, but the response to the second (redirected)
request might be cacheable.
The different URI SHOULD be given by the Location
field in the response. Unless the request method was
HEAD, the entity of the response SHOULD contain a
short hypertext note with a hyperlink to the new URI(s).
Thus, the body of a 303 response is under-specified. There are several open questions. Some of them are:
- What should it contain?
- How should it be formatted?
- Does a "short hypertext note" constrain implementations to a text/html MIME type?
- How short is "short"?
- Can there be more than one Location header?
- If not, what do all the other URIs in the hypertext tell a user? Arbitrarily anything? If so, there is no limitation.
I rather like the idea of using RDFa, but a broader solution may be to always include a text/html body part, but use a multipart/alternative structure to allow for the body to hold RDF data (in whatever form) if it is present. That way, an implementation would not have to run the body through an RDFa parser just to determine whether any RDF content was present. The use of an additional header to indicate the presence of RDF content would also do it, regardless of the body type.
Of course, others have derided the use of HTTP URLs (emphasis on the Locator aspect) to reference arbitrary resources in the universe (for which the URI, I for identifier, was designed) and for some good reasons. However, I see tremendous value in being able to marry information space with meat space via the resolution of HTTP URLs. In fact, the automated manipulation of Semantic Web content depends upon it. That is why the TAG's finding makes a lot of sense. The use of 303 response codes to both separate resolution from description while maintaining universal addressing ties the abstraction of the Internet to the real world.
The new Persistent URL (PURL) service, now in construction, will allow PURLs to be created that can return 303 responses. The use of 303s to represent arbitrary real-world resources will enable PURLs to coalesce the fragmented persistent identifier space. Do we really need LSIDs, DOIs, INFO URIs and the rest? My answer is, "Not if the Web Architecture supports all their requirements". The representation of arbitrary objects via HTTP URLs and the ability to return multiple See Also URLs from a response would seem to do just that.
TimBL has raised a concern that the information resource contained in a body of a 303 response should not contain anything very interesting, because it is not addressable (in context of the linked data discussion). I disagree. The address of the 303 body is directly addressable because that is what is returned when the URL that got you there is resolved. Further, the 303 status informs a user that the information resource in the body is not the requested resource itself, merely information about it. That is, the URL addresses both the (real world) resource and the information resource in the 303 body and the 303 status allows one to cleanly separate which one you may wish to refer to at any given time, either programmatically or by a human.
As Paul points out, the use of a 303 response code does not put a requirement on the semantics of the identifier. A 303 response may be used to present information to a human user, while at the same time providing an indication to a computer that the resource you addressed is not the one that was returned.
I have posted about http-range-14 issues before, but not in this amount of detail. I think that proper answers to the questions above will be critical to the success of the Semantic Web because we must have a mechanism to programmatically determine whether an HTTP URL refers to an arbitrary thing in the wide universe or that relatively small subset of things that we call information resources.
A big question in any new use of HTTP is how existing browsers have implemented handling of the return codes. I was quite surprised that Firefox and Apple's Safari redirect to the Location header in a 303! For example, go to the home page for Tom Heath (http://kmi.open.ac.uk/people/tom/) and you will be redirected to http://kmi.open.ac.uk/people/tom/html. Neither browser will show you that an intermediate 303 return code was issued or that the browser followed it. You can see the 303 by using something like HTTPTracer or wget. It is also interesting to note that Tom is using a text/html body describing in human terms what the Location header says (a "short hypertext note", captured using HTTPTracer):
HTTP/1.1 303 See Other
Date: Wed, 29 Aug 2007 16:54:19 GMT
Server: Apache/2.0.52 (Red Hat)
Location: http://kmi.open.ac.uk:8888/people/tom/html
Content-Length: 332
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>303 See Other</title>
</head><body>
<h1>See Other</h1>
<p>The answer to your request is located
<a href="http://kmi.open.ac.uk:8888/people/tom/html">here</a>.
</p>
<hr>
<address>Apache/2.0.52 (Red Hat) Server at kmi.open.ac.uk Port 8888</address>
</body></html>
Tom is using a 303 in the manner described by RFC 2616, and it is important to note that it does not conflict with the TAG finding regarding http-range-14. His response does, in fact, refer to "any resource".
The fact that browsers are automatically (and incorrectly, in my opinion) redirecting to the URLs specified in 303 Location headers suggests to me that Semantic Web applications will need to be careful. We can rely upon our own programmatic handling of 303s, but not the browsers'. We should also, again in my opinion, ensure that we do not break existing browser implementations if we can help it. The use of creative 303 body messages and perhaps new headers is one way out.
Sunday, July 15, 2007
Some Kind Words
Steve Goschnick at Solid Software in Melbourne, Australia had some kind words for my paper entitled "RESTful Software Development and Maintenance" given at the 2006 Open Source Developers Conference in Melbourne. Thanks, Steve!
Wednesday, July 11, 2007
Press Release for PURL Code Rewrite
Zepheira, OCLC and the W3C announced today a project that we have been working on for a month; the complete re-write of the software behind the Persistent URL (PURL) service.
The full press release is here.
I am particularly happy to say that we are working toward a proper Open Source (Apache 2) release of the new code, and enhancements to deal with important issues for the Semantic Web (such as support for HTTP Range-14 return codes). OCLC has also asked us to help build a community around the code to assist both its maintenance and its future direction. That is a refreshing change and should be welcomed by all.
I can't wait to start building services on top of this stuff.
The full press release is here.
I am particularly happy to say that we are working toward a proper Open Source (Apache 2) release of the new code, and enhancements to deal with important issues for the Semantic Web (such as support for HTTP Range-14 return codes). OCLC has also asked us to help build a community around the code to assist both its maintenance and its future direction. That is a refreshing change and should be welcomed by all.
I can't wait to start building services on top of this stuff.
Monday, July 09, 2007
Zepheira Team Picture
Here is a good shot of the current Zepheira team. It was taken at the 2007 Semantic Technologies Conference during the Zepheira reception.
Left to right are Brian Sletten, Eric Miller, Kathy MacDougall, Bernadette Hyland, Uche Ogbuji and yours truly.
Left to right are Brian Sletten, Eric Miller, Kathy MacDougall, Bernadette Hyland, Uche Ogbuji and yours truly.
Defining Liberalism
The Canadian Broadcasting Corporation's wonderful Quirks and Quarks radio show interviewed David Sloan Wilson on 23 June 2007 regarding his new book Evolution for Everyone. I belatedly caught the podcast while on holiday, oddly enough in Canada.
Prof. Wilson specifically addressed group dynamics and the thinking of humans in terms of social groups. It seems easy for Westerners to think of ourselves as individuals and ignore our obvious group dependencies. He mildly denigrated the thoughts of Richard Dawkins, Carl Sagan and the other evolutionary rationalists when he discussed the place of religion. Interestingly, Wilson noted that 95% (his measurement; I have not verified it but do not think he was speaking rhetorically) of conversations between people in a church relate not to theology but to group dynamics (how people can/could/should get along with each other). He uses this fact to suggest that religious thinking evolved (in a biological sense) to assist us with group behavior. He didn't mention the Baldwin Effect in the podcast, but I look forward to seeing whether it is discussed in the book.
I am particularly interested in the "us versus them" boundary in human behavior and Wilson discussed that. He noted the peculiar tendency of soldiers to act altruistically toward each other while killing the enemy; an extreme form of "us versus them" behavior and one close to the behavioral patterns found in and between hunter-gatherer groups. Then he said a fascinating thing: if one were to consider the group size to be larger, then one sees the killings as immoral. That immediately made me think about liberalism in our society.
What makes a liberal? Why do some people (myself included) become more liberal as they age? I was reared in a conservative, mostly rural society, attended a military college and was surrounded by conservative people until leaving the Navy. However, my thoughts became more liberal as I traveled and observed. Bill Clinton has said "The Democrats win when people think", which may be the same thing. Using Wilson's way of thinking, it suddenly makes sense that the ivory halls of academe are bastions of liberalism. Travel and thinking tend to make one see the world as a wider and more interconnected place. The group size one sees, in other words, becomes larger. Perhaps, as in the case of some, the observed group size becomes the size of the entire population.
I think this is a very, very useful meme. It is the first way of thinking about the differences between people's politics of which I am aware that both satisfies Occam's razor and provides a basis for further negotiation. Once the basis for disagreement is known, a solution is surely closer.
Prof. Wilson specifically addressed group dynamics and the thinking of humans in terms of social groups. It seems easy for Westerners to think of ourselves as individuals and ignore our obvious group dependencies. He mildly denigrated the thoughts of Richard Dawkins, Carl Sagan and the other evolutionary rationalists when he discussed the place of religion. Interestingly, Wilson noted that 95% (his measurement; I have not verified it but do not think he was speaking rhetorically) of conversations between people in a church relate not to theology but to group dynamics (how people can/could/should get along with each other). He uses this fact to suggest that religious thinking evolved (in a biological sense) to assist us with group behavior. He didn't mention the Baldwin Effect in the podcast, but I look forward to seeing whether it is discussed in the book.
I am particularly interested in the "us versus them" boundary in human behavior and Wilson discussed that. He noted the peculiar tendency of soldiers to act altruistically toward each other while killing the enemy; an extreme form of "us versus them" behavior and one close to the behavioral patterns found in and between hunter-gatherer groups. Then he said a fascinating thing: if one were to consider the group size to be larger, then one sees the killings as immoral. That immediately made me think about liberalism in our society.
What makes a liberal? Why do some people (myself included) become more liberal as they age? I was reared in a conservative, mostly rural society, attended a military college and was surrounded by conservative people until leaving the Navy. However, my thoughts became more liberal as I traveled and observed. Bill Clinton has said "The Democrats win when people think", which may be the same thing. Using Wilson's way of thinking, it suddenly makes sense that the ivory halls of academe are bastions of liberalism. Travel and thinking tend to make one see the world as a wider and more interconnected place. The group size one sees, in other words, becomes larger. Perhaps, as in the case of some, the observed group size becomes the size of the entire population.
I think this is a very, very useful meme. It is the first way of thinking about the differences between people's politics of which I am aware that both satisfies Occam's razor and provides a basis for further negotiation. Once the basis for disagreement is known, a solution is surely closer.
Subscribe to:
Posts (Atom)