Re: Issue-57

On 6/23/11 4:08 PM, Xiaoshu Wang wrote:
> On 6/22/11 8:06 PM, "Jonathan Rees"<jar@creativecommons.org>  wrote:
>
>> On Thu, Jun 16, 2011 at 7:35 PM, Xiaoshu Wang<xiao@renci.org>  wrote:
>>> For me, I don't care because if there is no ontology that classify
>>> everything in the world into IR and if there is no reasoner that
>>> implements
>>> code to check every URI's response code and triggers subsequence
>>> inference,
>>> following httpRange-14 (even if I can) is simply a waste of time.
>>> Hence, I
>>> doubt I will ever do it. But for those who cares, 2xx code is cheaper
>>> than
>>> 303.
>>> Xiaoshu Wang
>> The reason for the httpRange-14 rule is that it lets us write metadata
>> for things on the web in a direct way, and be understood.
> http://example.com/xiaoshuwang is a Person.
>
> Assuming the URI respond with 200.

Address of a Resource that carries (bears) representation.

Now, let's say we name an Object: http://example.com/xiaoshuwang#this, 
we now have a Name that resolves to a Representation. Depending on the 
actual Resource itself (e.g. its actual data representation format and 
associated semantics e.g. of the kind in RDF) one could infer that:

Name: http://example.com/xiaoshuwang#this  resolves to a representation 
of its referent.
Address: http://example.com/xiaoshuwang resolves to a resource bearing 
(carrying) the representation (e.g. an EAV/SPO graph pictorial). Of 
course, it could be a plain old human readable HTML document too :-)

Now if one opts not to terminate the URI Name with a # we have to use 
HTTP 303 to implement the >1 level of indirection so that Name and 
Address are disambiguated.


Kingsley

> What is not 'indirect' and what cannot
> be understood?
>
>> The
>> inference rule you are looking for is: If U is a dereferenceable
>> absolute URI, and M(<U>) for some metadata M, and a retrieval of U
>> yields a representation Z, then M(Z). E.g. if an information resource
>> has dc:title "Little mouse", then its associated representations do,
>> too. Conversely, if M(Z) consistently for Z retrieved from U, then
>> M(<U>).
> I don't quite understand it. But whatever it is: do you think any reasoner
> will implement the necessary code to check how every URIs in an RDF doc
> get responded?
>
>> I agree with you: if nothing important follows about<U>  from
>> retrievals of U, then there is absolutely no reason to assume anything
>> about the relation between<U>  and U. But metadata is important and it
>> does follow. Maybe my logic is a bit too simplistic, but I think
>> metadata is the previously unarticulated justification for the rule.
>> And it is very consequential - statements of license and authorship
>> can have quite serious ramifications. There is no metaphysics
>> involved.
> What is metadata (or for that matter, what is data)? Excuse for me picking
> bones from egg. But I do get confused with the word metadata, especially
> in RDF world. Given an RDF doc, can you tell part of them is metadata and
> the other not?
>
>
>> The rule is misstated and that has confused everyone; it seems to be
>> about an "information resource" type distinction but it makes a whole
>> lot more sense if it is about the relation between a URI and the
>> particular metadata subject (information resource, document, whatever)
>> *served from that URI* - not to just any old information resource, but
>> that particular one. I think the creators of the resolution took this
>> as a given.
>>
>> I've written this up here:   http://www.w3.org/2001/tag/awwsw/ir/20110517/
>>
>> Now, if you have a better way to write this kind of metadata, then you
>> don't need the httpRange-14 rule, but we absolutely need *some* way to
>> write metadata and I have yet to see anyone propose a better one. All
>> the alternatives I've come up with are very ugly as they involve an
>> occurrence of the URI as a string.
>>
>> You ask what we gain from this; it's the ability to talk easily,
>> naturally, and consequentially about what's on the web. Practically
>> every rdfs:seeAlso, owl:imports, foaf:homePage, dc:creator,
>> xhtml:license depends on this convention. There's a ton of metadata
>> out there, often doing its job inconspicuously. People usually follow
>> the httpRange-14 rule without even thinking about it. That's why it
>> has so few champions. Without the rule, there is huge FUD about every
>> use of all of these properties, very serious ambiguity when a page
>> could be about a page, and we may as well just stop writing metadata
>> the way we do now. This is the direction we're headed if we can't get
>> stronger agreement.
> If I receive a message saying:
>
> U1 a :Person.
>
> I don't see anything difficult to understand it. And if I try to
> dereference U1, I should expect something about a person. If not, I would
> think that the person who authorized the U1's response is sloppy, or has
> mal-intension. Whether I got back 200 or not doesn't affect my
> understanding at all.
>
> Of course, this is not what you have in mind. You were thinking the case
> such as:
>
> U1 a :Person.
> U1 foaf:homePage U1.
>
> People's first reaction is: this is wrong. But, what if this is the
> author's intention. That is: he is using U1 to reference the entity that
> is both a Person and a Web Page. (Please do not say that such a thing does
> not exist because then you must define the word 'existence'. For this, I
> recommend reading Quine's "On What There is".)
>
> I am not recommending people to practice like this. But my point is: the
> Web is about communication. We might not believe other's theory, but who
> are we to tell them "to shut up"?
>
> If the author of U1 wants to describe the webpage of U1 without raising
> unnecessary confusion, he can still do it with
>
> U1 a :Person.
> <__:webpage>  ex:webpageof U1.
> <__:webpage>  foaf:homePage U1.
> <__:webpage>  dc:title "blah, blah".
>
> Is it difficult? I don't think so. Is it clear? I think so.
>
> Please note, I am not suggesting replacing 303 use this approach. If
> people don't feel comfortable of b-node, then can by all means use 303.
> The point that I want to stress is: the ambiguity problem resides in how
> we describe things. It has nothing to do with HTTP protocol.
>
>
>> (And by the way a lot of people think 303 means not-an-IR. There is no
>> justification for this idea and it is false in practice. A good
>> example is the 303 responses served from dx.doi.org, where the URIs
>> name documents without any commitment as to whether they are or aren't
>> on the web.)
>>
>> I'm not trying to persuade you it's a good design (although if you
>> think otherwise I'd like to see what you'd substitute as a metadata
>> notation), I'm just trying to get you to stop saying the rule is
>> inconsequential or without serious purpose.
> The original purpose of httpRange-14, I guess, is to avoid ambiguity. But
> ambiguity can only be cleared with more ontological assertions.
> httpRange-14 has raised more confusion/debate. Except transferring
> ambiguity to a different term, what problem it has solved?
>
> Xiaoshu
>
>
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Friday, 24 June 2011 07:03:55 UTC