W3C home > Mailing lists > Public > www-rdf-interest@w3.org > March 2000

Re: Subclass of Thing/Resource

From: Tim Berners-Lee <timbl@w3.org>
Date: Thu, 2 Mar 2000 13:02:31 -0500
Message-ID: <00f101bf8471$7ab47180$84001d12@politburo.w3.org>
To: "Pierre-Antoine CHAMPIN" <champin@bat710.univ-lyon1.fr>, "ML RDF-interest" <www-rdf-interest@w3c.org>

-----Original Message-----
From: Pierre-Antoine CHAMPIN <champin@bat710.univ-lyon1.fr>
To: Tim Berners-Lee <timbl@w3.org>; ML RDF-interest
<www-rdf-interest@w3c.org>
Date: Thursday, March 02, 2000 4:17 AM
Subject: Re: Subclass of Thing/Resource


>I'm not sure we have to make explicit the different levels of
interpretation of resources.
>Anyway, the real entity "behind" the resource is often out of range for the
system !

Nothing is "out of range" to our discussion or to RDF.

>And I think there is no such thing as easy as dereference for URI -
>there can be an arbitrary number of interpretation levels.

I disagree. The number of interpretation levels cannot be arbitrary or
hopeless confusion will result.  Documents describe documents which describe
documents, and you must be able to reefr to a specific one in the chain.

>e.g.
>
><rdf:Description about="http://www.somewhere.org/index.html">
>  <play:protocol> HTTP 1.1       </play:proptocol>
>  <play:size>     3 Kb           </play:size>
>  <play:mime>     text/html      </play:mime>
>  <play:creator>  Pierre-Antoine </play:author>
></rdf:Description>
>
>none of the properties above applies to the same interpretaion of the URI

The properties themselves can be defined to make sense here.  You may
not want to do it like that, but if really that is what you want to write,
you can
define the properties as

play:protocol  ......... the protocol used in a succesful derefernce of a
resource's URI.
play:size .................the number of bytes in the body of at least one
representation of the resource;
play:creator: the common name of the creator of the resource.

That works.  You can define things like "the only size of any representation
of the resource"
of course - one would have to look at the play spec.


>should we instead write ?
>
><rdf:Description about="http://www.somewhere.org/index.html">
>  <play:protocol> HTTP 1.1 </play:protocol>
>  <play:content>
>     <rdf:Description
about="file://server.somewhere.org/var/httpd/index.html">


Here you seem to be interoducing more information - stuff about another
resource,
and reating it to the original.

>       <play:size> 3 Kb </play:size>
>       <play:content>
>         <rdf:Description about="mime:xxx">
>           <play:type> text/html </play:type>
>           <play:content>
>             <rdf:Description about="abstract-document:yyy>
>               <play:creator> Pierre-Antoine </play:creator>
>             </rdf:Description>
>           </play:content>
>         </rdf:Description>
>       </play:content>
>     </rdf:Description>
>  </play:content>
></rdf:Description>
>
>I don't think so.


You don't have to define all that mess, no. You can just define the
"play:size" as the length of the resource.   That means the length of the
thing returned when the HTTP protocol is used to dereference it.  You don't
have to say that explicitly in RDF.   (You might one day in the schema for
play: inth edefinition of play:size)

>Sure a web page or an e-mail address IS NOT the corresponding person.
>Neither is its employee ID...

No. Either can be used to identify a person.
http://www.w3.org/DesignIssues/Identity.html#Expressing

>Though, could we prevent people using the dublin core properties this way :
>
><rdf:Description about="http://www.somewhere.org/somedoc">
>  <dc:Creator rdf:resource="mailto:John@somewhere.org"/>
>  <dc:Creator rdf:resource="http://www.somewhere.org/~Paul/"/>
>  <dc:Creator rdf:resource="employee://somewhere.org/12345"/>
></rdf:Description>
>
>I don't think so !


Yes we can, I hope!  IMHO the above is a mess.  Is this what dc expect to
happen?


0. We could define (if starting from zero) define dc:creator to have range
dc:person where
a person is the domain of properties dc:mailbox and sc:homepage and
dc:commonname.
That is the best solution.

1. We can write a schema which specifies the range of Creator as being a
string and says it is a common name.

2. We could define dc:creator-name and dc:creator-mailbox and
dc:craetor-homepage seperately with the semantci s being the same as 0 by
definition.

3. We can if people really want to do things like that we can define
dc:creator-whatever as the union of craetor-mailbox and creator-homepage
which
is yukky and forces oene to find the type of the object before it can be
used.
And that doesn't help until we have mutually disjoint types.

>URIs are ambiguous, yes, they have more than one interpretation level, yes.

No, no. We should be clean or no reasoning from all this will be possible.
IMHO.

>We can't prevent people from using URI with different interpretations,
>so we'll have to use the context to tackle with it.
>
> this is not a bug, this is a feature  -- IMHO


we agree to differ then.
tim

>  Pierre-Antoine
>
>
>--- Quid quid Latine dictum sit, altum viditur
>    Whatever is said in Latin sounds important.


sed quid quid in RDF dictum sit, altum est.
Received on Thursday, 2 March 2000 13:02:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:42 GMT