- From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
- Date: Fri, 25 Jan 2008 15:11:16 +0000
- To: Jonathan Rees <jar@creativecommons.org>, Pat Hayes <phayes@ihmc.us>
- CC: Alan Ruttenberg <alanruttenberg@gmail.com>, "public-awwsw@w3.org" <public-awwsw@w3.org>
Hello Jonathan, > -----Original Message----- > From: public-awwsw-request@w3.org > [mailto:public-awwsw-request@w3.org] On Behalf Of Jonathan Rees > Sent: 24 January 2008 17:02 > To: Pat Hayes > Cc: Alan Ruttenberg; public-awwsw@w3.org > Subject: Re: Example for consideration: Resource versus Representation > > > Pat, welcome back to the fray. <snip/> > Here's how RDF works, in my view. It is a language of > discourse, much as natural language is; a formal notation for > expressing *any* kind of declarative information - > information about biology and physics, about authorship and > publication, about data structures and screw pitch. You might > say it is a knowledge representation language, although I > find "knowledge" to be pretentious, and "representation" a > bit questionable. But let's not worry about this. The > important thing is that there is no a priori limit to what > may be the intended (denotation of the) subject, object, or > verb of an RDF statement. > > In order for this to work, it must be permissible to assign a > URI to anything at all. (We all agree on this, right?) Yes... <Aside> ...though sometime ago there was an 'entertaining' exchange on quite whether there were enough URI's available to assign [1] (which I suspect repeats from time to time). "...In particular, how can RDF say something a particular arbitrary real number? There just aren't enough URIs to provide names for them all." [1] [1] http://lists.w3.org/Archives/Public/www-rdf-interest/2002Jan/0028 (and ensuing thread). </Aside> > Assigning a URI incurs a sort of moral obligation to resolve > it somehow, but lack of resolution doesn't make the > assignment invalid. (We all agree on this, right?) Yes, if we are speaking of http scheme URI. For URN's (ie. URN namespaces) it intentions are not clear. Some see URNs as fundementally something that is intentionally unresolvable. At the same time, efforts abound (eg. DDDS) to provide means of resolving URNs into something... and it is not clear that such resolutions schemes (say around info: or doi: - whether as URI scheme or URN namespace - such variant have in the past been discussed though I do not know current status) are intended to resolve to resource representations or meta-data (or descriptions of) the resource. I suspect that there is mixed practice... eg: doi:10.1145/383952.383995 aka info:doi:10.1145/383952.383995 aka http://dx.doi.org/10.1145/383952.383995 are all URI based identifiers for a paper on web crawlers (the first is questionable because doi: is unregistered I think). Resolution of these lead to a page about the paper (and thence to the paper). "wget --debug http://dx.doi.org/10.1145/383952.383995" reveals an interesting chain of redirections. Also... URI of any scheme can appear in an HTTP protocol request line, local proxy/gateway configuration then influencing whether or not there is a response, meaning to say that one strategy for attempting to resolve a URI of any scheme is to submit in an http request. TAG issues schemeProtocol-49 [2] and URNsAndRegisties-50 [3] both seem relevant. [2] http://www.w3.org/2001/tag/group/track/issues/49 [3] http://www.w3.org/2001/tag/group/track/issues/50 > In order to write meaningful RDF, you have to have subjects > and objects, and verbs (= predicates = properties). A > fundamental assumption - speak up now if you don't believe > this - is that to be clear and useful a property [a terrible > word but we're stuck with it] must have a specified domain > and range -- classes to which the subject and object must > belong in order for statements using the property to be > acceptable in discourse. Hmmm...(speaking up) I think that we need to think about that. In some of the communities in which I work the practice seems increasingly to leave property domains as open as possible to encourage their re-use. > Our task is to define these properties and classes so that we > can make formal statements, ones that might be inferable from > HTTP interactions, that are helpful for all the things you > want to do in the semantic web: nonsense detection, query, > inference, action (such as sending or paying a bill), and so > on. Beyond specifying domain and range, of particular > interest are subsumption (subclassing), disjointness, and > property restrictions such as "inverse functional". Ok... though wrt to "inverse functional" what I think I'd really like is to be able to catalog distinguishing characteristic ie. the value of a single property is not neccessarily of itself a distinguishing characteristic - but the combined values of some collection of properties may be distinguishing between individuals (composite keys). And... while I'm on my wish list, I might like to be able to scope the universe over which such 'keys' have a discriminating property - eg. these 'ids' are unique within this system for example, or by class. But that is wishing perhaps for more than OWL can give me at the moment - and is probably out of scope for the core of this endeavour. > Specify which definition you're using in whatever you are > saying, if you have to use words like "resource" at all. Do > you think you're expressing what's in a spec, or are you > making it up as you go along? > Use a qname (e.g. rfc2616:Entity) if possible. Ask for > clarification of someone else's definition if it's unclear (I > think this is what Alan is trying to do in trying to draw out > Noah). Talk about how you would like to interpret some spec > if you have to, although if a spec is found to be vague or > inadequate it is probably better to just articulate a new > definition. > But remember that the task at hand is to specify > properties, the classes that are to be their domains and > ranges, and relationships among the classes and properties > that permit useful inference. Ok... though I think that there is a premise in that which is perhaps again not universally held. Roughly, one accumulates statements/assertions about things of interest by retrieval operations over the web. Individual representations may say quite contradictory things - eg. in the http://sw-app.org/mic.xhtml example that we considered on the call: IMO the contradiction is quite evident from an understanding of the representation's media-type and it's content - rather than from any fine detail of the HTTP interaction - and their aggregation is quite another thing. It seems evident to me that Pat, in messages such as [4] (that one in particular I greatly appreciate) and other related messages, urges us to make a few inferences as possible - perhaps ideally, well none - from what I might call the 'fine detail' of an http interaction. In part I think that Pat's advocacy has been roughly along the lines of admit only triples that you get from representations; and even then - you want to be careful about the statements you accept in good faith: malicious behaviour may seek to induce contradiction; and even with the best of intentions mistakes can also lead to contradiction and non-sense. That raises a whole raft of trust/provenance issues that I would have thought far more significant than what can be inferred from the 'fine detail' of an http interaction. Eg. in David's analysis [5] that we reviewed on the call for example, there is a step that blindly 'asserts' things that are found to be logical formula - which may be fine in a relatively closed and high-trust environment. I suspect more 'caution' is required on the wild, open, semantic web. How one (or one's agent) decides to trust a set of statements in a representation I think is a big issue and somewhat dwarfs what we can infer from a 200, 302 or a 303. All that said, I may also have misunderstood Pat's advocacy - but I think that it's close to, infer nothing from the response codes. In part that's why I have been seeking to have the inferences driven from the other end - what inferences do you want to be able to justify - which ought to lead us to 'proof-steps' that depend on inferences that can only be made on the basis of interaction detail - or pehaps not - maybe we will find that the content of representations is in general sufficient. [4] http://lists.w3.org/Archives/Public/www-tag/2007Sep/0017 [5] http://lists.w3.org/Archives/Public/public-awwsw/2008Jan/0001 > Defining the "right" class (or property) is usually an > iterative process. You may start out by knowing that some > particular thing is in a class that you need to articulate, > and then attempt generalizations in a variety of directions. > Or you may know that you have to write a property, and while > you don't know what its domain is yet, you give the domain > class a name as a temporary placeholder. > Getting precise limits for classes, so that all the boundary > cases are neatly handled, can be very difficult. We have to > tolerate some amount of imprecision as we figure out what > classes we need. > Eventually, though, class definitions have to converge to > relatively rigorous forms. > > I have started to write down some classes and properties > here: http://esw.w3.org/topic/AwwswAnalysis. David Booth has > done this in his email as well. If I/we have > mischaracterized some of these things (e.g. if you disagree > with me that rfc2616:Representation is a class > - fine, we don't need it since we have the more rigorously > defined rfc2616:Entity), then the best response is to propose > a different class that can be the domain or range of the > properties we care about (e.g. of rfc2616:representation), or > a different property that better captures the heretofore > unarticulated web architecture that you want to promote. I > think this is the best way to make progress. > > Also remember that we're not trying to come up with the right > answer; I think the best result would be a set of > architectural alternatives specified using a clear vocabulary. > > Best > Jonathan Regards Stuart -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England
Received on Friday, 25 January 2008 15:13:31 UTC