- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 22 Mar 2004 13:01:17 -0600
- To: Mark Baker <distobj@acm.org>
- Cc: public-sw-meaning@w3.org
On Mon, 2004-03-22 at 12:30, Mark Baker wrote: > Hi, > > I've got a simple requirement I need met, driven largely by my desire to > build RESTful Semantic Web apps. Could you be more specific? What sort of app has this requirement? > When GETting some RDF from a URI, I need a self-descriptive path from > that representation to a statement about the "assertedness" of the > enclosed graph. To not have that path is to introduce an ambiguity in > the semantics of the data as intended by the publisher of that data. I don't think it introduces ambiguity in the semantics of the data. The data says what it says. The ambiguity in who said it or didn't say it or meant it or didn't mean it is just life. What suggests that RDF should be different from plain text in this respect? If you GET some text that says The world is flat. You can sorta tell from common sense that it's not asserted... unless it was written a _long_ time ago. But if you find Four out of five dentists recommend trident for their patients who chew gum. You don't really know if it's in jest or serious without poking around. If you see an ADA logo at the bottom of the page, linked to an ADA homepage, and you find zillions of links to the ADA homepage (e.g. via google or some other backlink service), and there's a path from the ADA homepage to the 4-out-of-5 page, then that suggests strongly that (a) the ADA is widely respected, and (b) they meant it. Similarly, most RDF data that published in a way that the author expects others to believe enough to act on has dc:creator link or some such. At the end of the day, whether to believe something or not is a risk/reward game. We act on some data we find if we expect we'll win by doing so. I hope to see semantic web escrow services before too much longer. If I *really* want you to believe me that I'm going to the web conference in NY, I could say so in my travel schedule and put $500 in escrow to be collected by anybody who can prove (mathematically) that I'm not (or more likely: that I didn't.). I think that could bootstrap a lot of stuff. > One very simple way to provide that path would be to say that all > RDF/XML documents described with the application/rdf+xml media type are > asserted. Another would be to say that all are *un*asserted. Yet > another would be to have some way of indicating in an RDF/XML document, > but outside the graph encoded within that document, whether some of the > triples are asserted or not. There are certainly other approaches. > > But currently, when considering the existing RDF specifications, and > the in-progress registration document for the application/rdf+xml > media type, there is no path, and therefore the aforementioned > ambiguity exists. I don't think it can be specified away. > As I understand the discussion that happened on this list last year, > it seems that folks here have some extremely interesting ideas for > how this could best be managed going forward. And that's great; I > don't want to take anything away from what might eventually make its > way down the pipe (though I hope it's still self-descriptive). But I > *also* want to be able to be self-descriptive here and now, before all > that happens. How can I do that? Er... you somehow want to get a widespread understanding that some RDF is asserted, but you want to short-circuit the process of getting widespread agreement. I don't see how to do that. > FWIW, IMO, the simplest way forward is to say that publishing RDF/XML > using the application/rdf+xml media type asserts all the enclosed > triples, which is why I sent in this comment; > > http://lists.w3.org/Archives/Public/www-rdf-comments/2004JanMar/0075.html > > which spurned this thread; > > http://lists.w3.org/Archives/Public/www-rdf-comments/2004JanMar/thread.html#75 > > Thanks. > > Mark. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ see you at the WWW2004 in NY 17-22 May?
Received on Monday, 22 March 2004 14:01:13 UTC