Re: New Editors Draft of the httpRange-14 Finding

Rhys Lewis wrote:
> Hello Alan,  
>
>   
>> It's ok if they make the assertions. But there needs to be a 
>> way to see that they make sense (at least if the plan is that 
>> the SW is to be used for science).
>>     
> But that's the core of the problem isn't it? We can encourage people to
> make assertions that make sense, but there is no way to check it. At some
> level, languages like RDF and OWL help authors make consistent assertions.
> I'm forever checking my ontologies to make sure I haven't written complete
> rubbish. But I can still assert that the moon is made of cheese if I wish.
> RDF lets me make such assertions with precision, but not necessarily
> accuracy.
>
> I don't see that web technology can provide any more guarentee of
> correctness of assertions than a printing process that allows papers to be
> distributed in learned scientific journals. Any sense of correctness for
> papers needs to be applied above that level, during the refereeing
> process, for example.
>   
I think Alan has mixed the machine consistency to reality.  A machine 
can only assert the consistency among statements, it cannot verify if a 
statement is valid in reality.  The latter is done by a social process.  
Good ontologies that mimics the world of our interest will be shared 
more than those that does not. In other words, I agree your statement by 
importing yours.  Else, we live in separate worlds. Web architecture 
cannot and should not prevent people from making "unpopular" statements.
>> That's a nice example. The resource is "a thing that lets you 
>> find a barbeque". This measures the information content as 
>> the outcome of the agent evaluating the instructions. Is that 
>> a commonly accepted idea about what an information resource is?
>>     
If your resource is defined as "a thing that let's you find a barbeque", 
then any of your representation returned is correct because all of them 
- map, text, audio - fits the description. Then, it is up to the client 
to choose which kind of content type or language they prefer.  But if 
you define your resource as "a visual map that let's you find a 
barbeque", then returning an audio or text is inconsistent with your 
assertions.  With the latter definition,  a client should not expect to 
get an audio or text and the server shouldn't return an audio or text 
even if it has one.  I am not sure why this is confusing...

Cheers,

Xiaoshu Wang

Received on Wednesday, 29 August 2007 09:10:06 UTC