- From: Peter Crowther <Peter.Crowther@melandra.com>
- Date: Tue, 10 Apr 2001 10:13:37 +0100
- To: "'Danny Ayers'" <danny@panlanka.net>
- Cc: www-rdf-logic@w3.org
> From: Danny Ayers [mailto:danny@panlanka.net] > <- You cannot control what reads your RDF if you express something > <- in RDF (just as with HTML or with XML). > > I believe you can. OK, I'll go one stage further in my argument: If you embed some RDF in a resource [for example as some annotation on a Web page] and place that resource in a location where it is accessible from the Web, then any user agent accessing that resource can and should get the RDF as well. Yes, you can play tricks with the server handing out different RDF depending on the user agent, but there are still the usual problems of unknown UAs, pre-caching proxies, and crawlers that use fake UA identifiers. So I contend that it is not, in the general case, possible to limit what a particular agent sees. I'd be interested to see you justify your belief in a similar way, bearing in mind that we're talking about the Web, not about EDI between two mainframes with a dedicated link between them. > That reader may not be able to cope with your > <- range of expression, but may still try to extract what meaning > <- it can (just > <- as with HTML or XML); and it may get entirely the wrong > end of the stick > <- (unlike HTML or XML). > > Why should it be different than HTML/XML? HTML is designed in such a way that tags that are not understood can simply be ignored. XML is sort-of designed in this way, in that it doesn't pretend to carry descriptions; it carries data. I agree with you in one respect: two systems implementing a particular XML application would have to agree on the processing of a <not> tag in that XML application, just as they would have to agree on the processing of any other tag. But nobody really seems to expect a system that understands MathML also to understand MyCustomML; in fact, the very notion of XML applications reinforces this approach that a system should cope with the entire application, or nothing at all. RDF is not designed in this way. From the intro to the RDF spec (http://www.w3.org/TR/REC-rdf-syntax/, section 1): "The broad goal of RDF is to define a mechanism for describing resources that makes no assumptions about a particular application domain, nor defines (a priori) the semantics of any application domain. The definition of the mechanism should be domain neutral, yet the mechanism should be suitable for describing information about any domain." [...] "Due to RDF's incremental extensibility, agents processing metadata will be able to trace the origins of schemata they are unfamiliar with back to known schemata and perform meaningful actions on metadata they weren't originally designed to process." The problem here is when a system receives some RDF, tries to do this, and falls flat on its face because it's unaware of some nuance of the way a property is being used within a particular piece of RDF. [...] > Ignore the tag would be preferable fallback, I'd have thought. First find your 'tag'. RDF properties are probably the closest equivalent to *ML tags. The problem is that you can't do this with RDF at all, because *all* the properties carry data with uncertain interpretation. With RDFS, a limited number of properties have some informal definition; for example, it would be possible to use rdfs:subClassOf to extract hierarchies from any piece of RDFS without understanding the rest. However, if you wish to produce any system that can answer queries about arbitrary RDF structures, you're still screwed: without a standard definition of (for example) negation, your system may give answers that are quite different to those produced by a system that knows about the particular way a structure's creator chose to express negation. For those of us who like to produce generic solutions that we can re-sell, this is a big problem :-). > I see your point anyway - personally I think it would be > better in the case > of uncertainty for the trumpets to sound, the drawbridge to > be raised and > the oil put on the stove (or at least the transaction to be > rolled back). That's fine, but 'uncertainty' in this case would have to be the discovery of *any* piece of RDF where the system didn't know the meaning of a property, as any unknown property could describe negation, disjunction or some other semantic addition to RDF. This might be theoretically attractive, but is impractical in a world of evolving communication standards. Imagine a Web browser that refused to display any page that included an unknown tag, or an XML parser that broke if the received XML didn't adhere precisely to its own preconceived DTD or schema specification... now imagine the same components two years down the line as the standards have evolved. Not a pretty thought. I don't want software I write to have those problems! - Peter
Received on Tuesday, 10 April 2001 05:13:39 UTC