W3C home > Mailing lists > Public > public-awwsw@w3.org > December 2008

AWWSW Vocabulary

From: Jonathan Rees <jar@creativecommons.org>
Date: Thu, 18 Dec 2008 11:19:00 -0500
Message-Id: <40C26F02-1775-4DB4-AC30-FE5EC0FFB117@creativecommons.org>
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:


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  
  * 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  

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.

Received on Thursday, 18 December 2008 16:19:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:06 UTC