Re: Literal vs. predefined values

Hi,

Beyond the equivalence issue, I think we also had a comment on the RDFS 
definition of the fieldName property (if the unionOf hack really works 
as we are assuming). At this time, the arguments are making me lean more 
towards the "simplified approach" -the fieldName should be a literal and 
the application needs to deal with the casing issue.

On the other hand, in the past we have received several comments on 
pre-processing the values and normalizing them. We've collected all 
these headers into a namespace, I'm tempted to think of reusing them in 
some way. What do people think of an additional and optional property in 
the MessageHeader class called headerName?

So in your example below, <http:fieldName>Accept</http:fieldName> will 
be available and applications using HTTP-in-RDF will be expected to 
process this type of information. Additionally, we could allow this 
information to be supplemented by the property <http:headerName 
rdf:resource="http://www.w3.org/2006/http-header#accept"/> when such a 
header is available.

We may still be dealing too much with application-level processing 
instead of merely recording the HTTP exchange between a client and a 
server as per our initial scope of work. So I think I could also live 
with the proposal to discard the predefined values.


Regards,
   Shadi


Johannes Koch wrote:
> 
> Hi group,
> 
> at the end of our last teleconference we started discussing comments 
> about the complexity in the current HTTP-in-RDF approach. One comment 
> was about predefined values for the header names. The proposed 
> simplification was to get rid of the predefined values and use just 
> literals.
> 
> <http:fieldName>Accept</http:fieldName>
> 
> instead of
> 
> <http:fieldName
>   rdf:resource="http://www.w3.org/2006/http-header#accept"/>
> 
> When using the simplified approach it would be easier to create the RDF, 
> because you just create a literal object and add it to the statement. 
> Using the current approach you would have to look into the list of 
> predifined header names, if the header name is a predefined one, create 
> a resource for the predefined value (or use an already existing one), if 
> not create a literal object, then add (resource|literal) to the statement.
> 
> A disadvantage with the simplified approach is: How to deal with case? 
> Is "Accept" to be treated the same as "accept"? But it's a similar thing 
> with the current approach: Should "Accept" be semantically the same as 
> "http://www.w3.org/2006/http-header#accept"? Example: When more header 
> names are being registered in RFC4229 the list of predefined values will 
> have to be updated. One application uses an older list than another. 
> Both want to record a header. One uses the predefined value from the 
> newer list, the other creates a literal because the header name is not 
> in the older list. Do both applications mean the same header?
> 

-- 
Shadi Abou-Zahra     Web Accessibility Specialist for Europe |
Chair & Staff Contact for the Evaluation and Repair Tools WG |
World Wide Web Consortium (W3C)           http://www.w3.org/ |
Web Accessibility Initiative (WAI),   http://www.w3.org/WAI/ |
WAI-TIES Project,                http://www.w3.org/WAI/TIES/ |
Evaluation and Repair Tools WG,    http://www.w3.org/WAI/ER/ |
2004, Route des Lucioles - 06560,  Sophia-Antipolis - France |
Voice: +33(0)4 92 38 50 64          Fax: +33(0)4 92 38 78 22 |

Received on Tuesday, 22 May 2007 08:09:10 UTC