- From: Jonathan Rees <jar@creativecommons.org>
- Date: Thu, 18 Dec 2008 11:19:00 -0500
- To: public-awwsw@w3.org
I'm glad to see contributions to the document I started and that we discussed on Tuesday: http://esw.w3.org/topic/AwwswVocabulary I just made some more changes. You may want to look at the diffs: http://esw.w3.org/topic/AwwswVocabulary?action=diff&rev2=18&rev1=14 Unfortunately the deiff is not as useful as it should be since I moved some things around, and the diff algorithm doesn't handle that well. Highlights follow. I added these meta-rules: * Multiple labels allowed. If you don't like what's there, add your choice to the list. Do not use a label as a substitute for a definition. * class names should be capitalized * Use case or strong motivation is required - please don't add terms idly - we already have other wiki pages where we can add terms without motivation. I rewrote the discussion of RFC2616 entity to agree with comments from David and Harry. David, I listed some constraints that you might want to impose on ftrr:InformationResource. If the class can be placed into a potential validation scenario - an explanation that would justify why a response or request would be invalid or false (i.e. classify interactions into 'ok' and 'not ok' categories) - that would help me to see what this is good for. I don't think RFC 2616 can be read as requiring that a resource has to have a URI. E.g. you could open an HTTP connection to a host that has no DNS host name, or a resource that lost its URI after the request was received but before the response was sent (I know this is ridiculous, but hope it helps make the point). Of course if for some application we need to name the class of RFC 2616 resources that have URIs, we can do that. It the applications that are most interesting, not the ontology. Nothing in RFC 2616 (that I could find) requires that a resource be accessible in the GET sense. You could have a resource that only handled POST requests, for example. Harry, you had added something called awww:representation, but the definition you gave was from RFC 3986, which is different from the one in AWWW. Check what I did to the entry to make sure I didn't butcher it. If we could put historical notes in the 'discussion' section instead of under 'definition' I think that will help. Maybe there should be a separate 'history' item? I added a "consequences" section that describes the data: URI example. Jonathan
Received on Thursday, 18 December 2008 16:19:40 UTC