- From: patrick hayes <phayes@ai.uwf.edu>
- Date: Fri, 14 Jun 2002 18:02:04 -0500
- To: Patrick Stickler <patrick.stickler@nokia.com>
- Cc: w3c-rdfcore-wg@w3.org
>On 2002-06-12 20:35, "ext patrick hayes" <phayes@ai.uwf.edu> wrote: > >> >>> On 2002-06-11 10:29, "ext Patrick Stickler" <patrick.stickler@nokia.com> >>> wrote: >>> >>>> >>>> On 2002-06-10 19:01, "ext Eric Miller" <em@w3.org> wrote: >>>> >>>>> Now that i'm back online, I see Patrick's suggestion... >>>>> >>>>> On Fri, 2002-06-07 at 11:15, Patrick Stickler wrote: >>>>> >>>>>> My specific recommendations are: >>>>>> >>>>>> 1. Leave the definition of rdfs:isDefinedBy as is, though removing >>>>>> the incorrect language about namespaces, allowing any instance >>>>>> of rdf:Resource and multiple statements. >>>>>> >>>>>> 2. Qualify objects of rdfs:isDefinedBy by class, in the case of >>>>>> RDF/XML instances, by the proposed rdfs:Schema class. This permits >>>>>> those who want/need to, to be explicit about the nature of the >>>>>> defining resource. >>>>>> >>>>>> 3. Clearly state that there is no functional relationship between >>>>>> the URI of a term and the namespace URI used in its RDF/XML >>>>>> serialization -- that the RDF model is based on URIs, not >>>>>> qnames, and as such, namespaces have no significance whatsoever. >>>>> >>>>> yep, i believe we're saying similar things. >>>>> >>>>> Patrick, have you taken a crack at this rewording? >>>> >>>> Not yet, but I would be happy to do so prior to Friday's telecon. >>> >>> Here goes: >>> >>> <rdfs:Property rdf:about="&rdfs;isDefinedBy"> >>> <rdfs:subPropertyOf rdf:resource="&rdfs;seeAlso"/> >>> <rdfs:domain rdf:resource="&rdf;Resource"/> >>> <rdfs:range rdf:resource="&rdf;Resource"/> >>> <rdfs:comment> >>> This property indicates a resource which fully or partially >>> defines the subject resource. >> >> I insist that we do not put this into a spec unless we also say >> something about what we mean by 'define'. That word has no formal >> meaning in an assertional language like RDF and RDFS, and it is a >> very dangerous word to use casually. (For example, the difference >> between a simple contradiction and a very nasty paradox turns on the >> distinction between 'assert' and 'define', and this has been a >> central issue in the Webont layering problems.). I would prefer to >> avoid the use of the 'define' word altogether if we possibly can, >> particularly when used with 'resource'. > >Would you like to suggest a word to use other than 'define' that >fits into the above text? Unfortunately, I can't think of one. I honestly do not think that this whole business means anything at all. If I were writing an RDF engine it would simply ignore all 'isDefinedBy' assertions, and in fact I would feel entitled to delete them from a graph, on the grounds that they have no entailments. They say, literally, nothing. I would love to be proved wrong. What do you think they mean?? BUt OK, let me try to be more constructive. How about: <rdfs:comment> This property indicates a resource which contains information about the subject. Often, this property is used to indicate the source of the subject uriref, where its owner specifies its intended meaning. The subject node of this property can be any uriref, and the value may be any document or resource; the usage is not restricted to a particular form or schema. In the case that the value is a web resource which contains RDF triples, the assertion of rdfs:isDefinedBy can be taken as a confirming or assenting to the content of those triples, ie an assertion that those triples are considered by the author of the document to be definitively true, and that any consequences of them together with the triples in the current document may be safely assumed. </rdfs:comment> Is that more or less what is meant? Ive tried to avoid saying 'define' and also avoid talking about 'namespaces'. Pat -- --------------------------------------------------------------------- IHMC (850)322 0319 cell 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax
Received on Friday, 14 June 2002 19:02:04 UTC