Re: Uniform access to descriptions

Alan Ruttenberg wrote:
> On Apr 13, 2008, at 8:29 PM, Xiaoshu Wang wrote:
>> Alan Ruttenberg wrote:
>>> On Apr 13, 2008, at 6:53 PM, Xiaoshu Wang wrote:
>>>
>>>>  I failed to follow what is the difference between /representation/ 
>>>> vs. /description/
>>>
>>> You can make a distinction between them like this:
>>>
>>> Think about describing. When you describe something to someone you 
>>> say some things - you make some assertions about the thing. Suppose 
>>> you ask someone to describe what Alan looks like. You could say "he 
>>> has (some) brown hair". "he has a beard". Even if the person was 
>>> talented and able to draw Alan, they would say, when describing 
>>> Alan: "He looks like this" (pointing at the picture).
>>> On the other hand, think of the goal of representation as 
>>> re-presentation. A representation of Alan might be a drawing or a 
>>> picture, i.e. it may not necessarily be a set of assertions. On the 
>>> other hand, some descriptions can be used as representations (have 
>>> to think about whether *all* descriptions are representations). In 
>>> any case, not all representations are descriptions, since not all 
>>> representations are in the form of assertions.
>>
>
>> I can understand your viewpoint.  But you know I am a very simple 
>> minded person (:-)).  If I cannot find a clear-cut definition, I 
>> simply won't make it.  Here is my viewpoint, which I don't think it 
>> is important, but just want to illustrate my understanding.
>>
>> First, I simply take machine agents as a different kind of human 
>> beings.  They speak a different language than the rest of native 
>> languages.  When I say "x is read" in English is no different from "x 
>> color red" in RDF. It is simply the latter has much simpler grammar 
>> and its user is less intelligent than humans.
> I'm with you so far.
>> RDF itself indeed doesn't has much logic in there.  RDFS/OWL 
>> gradually provided it for somewhat more intelligent agent.  But in 
>> between there are many other specialized representation/agents who 
>> can handle different kind of representations.  An image is simply a 
>> pictorial representation/description of a resource, so does an audio 
>> file or even a binary data.
>
>> Our object in the web is communication through sharing resources.
> Well, according to the architecture the web is communication through 
> sharing representations ;-)
Yes, that is a more correct wording. :-)
>
>> Hence, all /representation/descriptions/ are doing one thing - to 
>> facilitate to understand by all means.
> Actually, there are a lots of things they can do. Perhaps this affects 
> your thinking or not. For example, with a
>> I just want to say architecturally they are not that much different 
>> from each other.  Of course, if useful, we can certainly make certain 
>> distinctions.  I have rarely use the word /metadata/ is because of 
>> its ambiguity.
> It's easy to use wrongly.
>> But we should make - again - syntactic definition.  We can define 
>> that all data expressed in RDF is /description/, etc.  I don't mind 
>> such kind of definition.   It is just like when we design database, 
>> we can all the schema the metadata because it is syntactic and clear 
>> so it is practical.
>
> I think we could give RDF a special status in Conneg, but I don't 
> think I'd go about that by trying to erase the distinction between 
> description and representation. Instead, since RDF is flexible enough, 
> clarify how RDF can have, in addition to the representation task it 
> inherits by being one of a member of the set of representations of a 
> resource, it can add, in an unambiguous way, additional description.
A MIME type has, in deed, given RDF a special status in Conneg, has it not?
> The thing about the database schema that differs from here is that RDF 
> can do both schema and data at the same time.
>
> But you probably remember my feeling about content negotiation. For 
> browsing the web it is great. For being clear in SW terms it is awful 
> because it gives several different things the same name.
Here, it should be "it gives several different things (*representation*) 
the same name".  (the word comes back to you now ;-)) Each thing 
(resource) should ideally have just one name.  But in reality, it might 
start with a few but eventually knowledge evolution will choose one (at 
most a couple) winner.

Representation doesn't have a canonical name (i.e., URI) even in the 
current sense of awww:Representation. Hence, I didn't create any problem 
that is not already in the existing web architecture.  It is just that 
before semantic web, most website (pages) etc., don't conneg that much. 
Hence, people casually treat the representation the same as resources.  
But in reality, they are two distinct entities.

But that doesn't mean that we cannot describe *representation*. I really 
don't want to make further proposal now to confuse the current debate, 
but I will just give you an outline to show - if I have the power, how I 
would have to solve that. 

First, I would like to make Conneg is based on URI but string because 
this allows us to easily  find the formats information too.  It also 
gives people more power to define their own mime-type to cater for their 
own specific need as opposed to go through the trouble of registration.

Second, we can, in fact, now meaningfully modeled HTTP in RDF.  For 
instance, we make an rdf:Property of http:Accept. Thus, any given 
MIME-type can be a rdfs:subPropertyOf http:Accept.  For example, if I 
made the following assertion,

rdf rdfs:subPropertyOf http:Accept.

Then the RDF representation of a particular resource can be clearly 
described with a b-node as such.

_:x rdf <whatever the resource URI is>.

Then, you can make any assertions on "_:x".

Third, but Pat told me "b-node" will create a lot of trouble for 
reasoner.  If this is the case, we can still solve it within the current 
UR specification (I think).  Because you can conjugate two URIs to form 
a new one.  Such as http://example.com/a/http://example.com/b.  Thus, we 
can use a pattern, such as follows,

mimetypePrefix:NamespacePrefix:fragment.

Of course, this might break existing XML parsers.  To avoid that, we can 
use a different character to separate the mimetype prefix from namespace 
prefix.

Again, this is just an outline of the design. Nothing concrete.  I want 
to describe this to you is to just want to show you that, technically, 
it is doable but it depends on how much TAG is willing to change. 

I can use the same idea to work within the current spec using b-node.  
But I just want to show there are many meaningful things that we can do.
> The reason I link LINK header is that it is unambiguously out of band 
> from the main communication channel. No matter what happens in the 
> awww:representations I know I can add some assertions about the resource.
Not really.  If you implement a browser, think about how do you handle 
LINK for a user?  Do you follow that link against your client's wishes?  
Or do you parse the information stored in the LINK and insert it into an 
HTML page RDF, or some data that you don't know how to insert, which 
might against the wishes of resource owner.

Regards,

Xiaoshu

Received on Monday, 14 April 2008 10:58:13 UTC