Re: URI for abstract concepts (domain, host, origin, site, etc.)

Martin J. Dürst wrote:
> On 2009/06/29 0:02, Xiaoshu Wang wrote:
>   
>> Martin J. Dürst wrote:
>>     
>>> On 2009/06/27 3:36, Xiaoshu Wang wrote:
>>>
>>>       
>>>> Thus,
>>>>
>>>> "http://danbri.org/foaf.rdf#danbri" denotes a person.
>>>> "http://danbri.org/foaf.rdf#(application/rdf+xml)danbri" denotes an RDF
>>>> node.
>>>> "http://danbri.org/foaf.rdf#(application/xhtml+xml)danbri" denotes an
>>>> HTML element ided "danbri
>>>>         
>>> I don't understand this. Why wouldn't I just use
>>> http://danbri.org/foo.html#danbri
>>> or anything similar for HTML fragments? (I'm assuming that foaf.rdf
>>> returns an application/rdf+xml documend, and foo.html returns an
>>> application/xhtml+xml document; the extensions may be meaningless to
>>> the protocol but help to keep things apart for humans and computers.)
>>>       
>
>   
>> Well, then it just doesn't work for extending the referential range of
>> URI to denote things beyond engineering entities. If you take a URI
>> (fragment or not) to denote document (or its sub-structure), then the
>> Web is not much useful to our daily use. If you take a URI to denote
>> other things, like a human or person, then you cannot describe a
>> document structure. And there is one URI, then you have to make a
>> decision which one it denotes, right?
>>     
>
> Yes, each URI better denotes only one thing. But that doesn't mean that 
> all URIs (with fragment identifiers) denote subdocuments, and it doesn't 
> mean that all URIs (with fragment identifiers) denote 'other things'. It 
> means that each individual URI denotes either one or the other, and that 
> you find out which one (if you need to) by getting more information 
> about it.
>   
Well, I don't know if we agree or disagree.   If you think that a URI 
always denote a resource, and we can describe its representation with 
additional property or b-node, then we completely agree.  But in this 
case, if "http://danbri.org/foaf.rdf#danbri" is used to denote an HTML 
element only because the URI's owner makes it so.  It does not denote an 
HTML element just because you happened to receive an HTML document since 
we can use non-HTML things, such as an RDF, to describe this HTML element. 

But, on the other hand, if you think that a URI can be used to denote 
both a resource and its representation, then, I don't know how it can 
work.  For instance, if I deployed an HTML document (as a resource) at 
"http://example.com/foo"and then you get a copy by dereference the URI.  
What does the URI denote? my copy or your copy? Of course, we can still 
make this model work such as by defining some server-client vocabulary.  
But would it be important to standardize this "vocabulary" since it is 
the built-in semantics of the Web architecture?

Xiaoshu

>>> Also, I don't see much of a need to denote an RDF node per se. I'm
>>> sure there are special applications one can come up with where
>>> reasoning about RDF nodes per se is helpful/necessary/whatever, but
>>> for such cases, there are other techniques available already. A single
>>> special property and blank nodes would do the job.
>>>       
>> Sure, we can use special property and blank nodes, but don't we need to
>> know a URI does first before applying a property to that right?
>>     
>
> People who 'apply properties' to URIs (which I assume you mean to add 
> properties about an URI) will know an URI from other information or 
> because they created the URI and decided what they want to use it for. 
> People who see an URI for the first time have to find out what it stands 
> for either from context or from dereferencing (or probably from both).
>
> Regards,   Martin.
>

Received on Monday, 29 June 2009 13:29:55 UTC