OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Are URIs Resources? (WAS RE: [xml-dev] Re: Non-infoset)

[ Lists Home | Date Index | Thread Index ]

Fun indeed.  So by this definition, the URI itself is not part 
of the information space(s) of the WWW (it is not a single 
information space because some identified resources can have 
multiple simultaneous states) and by definition, a URI cannot 
identify another URI; therefore, information in a URI is not 
in any information space that can be identified by another URI.

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5
_2_1_1

"The only thing that is required to be static for a resource is the
semantics of the mapping, 
since the semantics is what distinguishes one resource from another."

'and now we entangle the audience...'

Then the only thing that a URI cannot identify ambiguously is a semantic
because 
the semantic is the invariant property of the resource which enables it to
be 
identified (by definition).  

The URI is meaningless to the reader (opaque: not information bearing) but
meaningful 
to the writer (information conveying). (Sure that is absurd to a human who
can clearly 
see what is meant but we are in spec abstraction land here.)

Try this:  The writer has a relative view (Boolean, local, deterministic,
discrete unique
           states).
           The reader has a quantum view (Lattice, non-local,
non-deterministic,
           continuous and therefore, multiple simultaneous states).

Because the logical operations of joins in these two types of logic return 
different sets, http ranges are ambiguous until measured.  Only the
operation 
of dereferencing settles the state for any URI for which there can be
multiple 
simultaneous states.   Observation/measurement collapses the wavefront for 
the observer.  It DOES NOT mean the observer/reader understands the writer's
intention, 
only the reader's interpretation of the measurement/observation.

I never thought quantum theory would help me decide anything.  I was wrong.
:-)

len


From: Jan Algermissen [mailto:jalgermissen@topicmapping.com]

Bullard, Claude L (Len) wrote:

>That's the critical observation for this and many other 
>threads that rely on ontological commitment to sustain 
>communications.
>
>Would anyone care to compare that to URIs as a unit of 
>information:
>  
>
Personally, I go with the definition of Resource and Resource Identifier 
provided by Roy:

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5
_2_1_1

as soon as I had started doing that, all the confusion suddenly ended 
and I have never ever had any problems with that decision. I believe 
that a technology itself gets to define what their 'elements' are and 
not whoever uses the technology.

A nice example of this is XTM (Topic Maps applied to XML/Web) which 
implicitly makes the assumption that URIs allways identify Documents 
(aka 'addressable subjects') and NEVER!! abstract concepts (aka 
'non-addressable subjects'). How can a technology (Topic Maps) that 
*uses* terms and infrastructure of another technology re-define the 
terms? Makes no sense to me.

>1.  Is a URI a resource?
>  
>
No.

>2.  If it is a resource, what operations are significant?
>
>3.  Are URIs ever ambiguous?
>
>  
>
Do you mean: "Can URIs ever be used ambiguous?"  ??

The string itself cannot really 'be ambigous', I'd say.

>Yes, I know: the permathread from hell.
>
>  
>
So much fun :o)

Jan



>len
>
>From: Alessandro Triglia [mailto:sandro@mclink.it]
>
>The writer makes choices, but a reader cannot always tell which of those
>choices (if any) convey some semantics in the intentions of the writer and
>which do not.  In other words, an XML document may contain more information
>than the writer considers significant, but a given reader may not be able
to
>separate the non-significant part from the significant part.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS