Jeni's Musings

Instead of using the URI of the document you retrieved the data from you can do the following when loading external data into your store (given that it's a HTTP URI!):

Use the HTTP vocabulary to record the details of the retrieval process. Create internal URIs for the http:Request and http:Response resources you're describing. Put all retrieved triples into your store using the URI of the http:Response resource as the named graph. The document URI would be available through http:requestURI. You can make the description as detailed as you want, from just storing basic facts about the retrieval process to storing all HTTP headers and the whole message body. That way you're actually building a HTTP cache. This also means that you can load one and the same document more than one time into your store and keep the data (which might have changed) separate. This seems more natural to me since the retrieved representation of the resource doesn't depend on the resource's URI alone but also on the request parameters and the time of retrieval.

Of course this doesn't solve the problem of what to do with the named graphs used in the response. As Richard said, you'd have to extend your store to be a quintuple store. And then you load data from someone who also uses quintuples and you need to add another dimension to your store (and to the serialisation syntax). Not workable. But I don't think the solution of creating classes for things like membership works either because then you can't re-use widely deployed vocabularies - and in the end, wouldn't you end up creating classes for everything?