W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > June 2002

Re: refining closure text for rdfs-isDefinedBy-semantics

From: Frank Manola <fmanola@mitre.org>
Date: Mon, 10 Jun 2002 14:14:07 -0400
Message-ID: <3D04EC6F.DD0C5E32@mitre.org>
To: Eric Miller <em@w3.org>
CC: RDF Core <w3c-rdfcore-wg@w3.org>


I'm a tad concerned that this seems to be trying to define text
describing rdfs:isDefinedBy in isolation from addressing the issue Dan
Brickley raised regarding what the M&S said about there being a
connection between properties and defining schemas.  It seems to me that
both of these need to be nailed down in one "transaction".


Eric Miller wrote:
> In opening this discussion at the last telecon, I wanted to get a quick
> sense from this group if this was an easy issue to scope and tackle, or
> not... My quick assessment after a couple minutes was more on the 'not'
> side :)
> I'm hopeful however the problem is with scope. The scope (that I suggest
> we rdfcore take) is to stay away from issues of best cataloging
> practice. That means, that we stay away from issues of what is
> 'correct', 'true', 'the one', etc.
> As both Frank and Patrick have correctly identified, information about
> terms can and will be found in many different resources. But this is no
> different than descriptions of books, errata, reviews, etc. all being
> different resources and different communities binding this information
> together in their respective ways.
> So the simple suggestion that we rdfcore might take wrt to this issue is
> to define rdfs:isDefinedBy to relate a term to a schema resource.  Thats
> it... Wording that doesn't over commit what isDefinedBy is and how more
> accurately schema resources and namespaces relate is still needed but
> thats the gist of it.
> btw, here is an example of this limited view in practice...
> http://wip.dublincore.org:8080/dcregistry/queryServlet?reqType=schemas
> ->
> http://wip.dublincore.org:8080/dcregistry/queryServlet?reqType=sdetail&item=http%3A%2F%2Fpurl.org%2Fdc%2Felements%2F1.1%2F
> (isDefinedBy in this case is useful as well in identifying terms defined
> by a schema resource)
> A couple of open issues come to mind...
> - do we formally give a name to a schema resource rather than let
> different communities define them (this request has surfaced from the DC
> community working on Registries).  As was mentioned on the telecon, this
> approach may be useful for clarifying the relationship between rdf
> Schemas and Web Ontologies (e.g. rdfs:Schema subclassof web:Ontology)
> my suggestion would be 'yes'
> - do we formalize the range rdfs:isDefinedBy to be one of these schema
> resources
> my suggestion would be 'yes'
> 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?
> --
> eric miller                              http://www.w3.org/people/em/
> semantic web activity lead               http://www.w3.org/2001/sw/
> w3c world wide web consortium            http://www.w3.org/

Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-8752
Received on Monday, 10 June 2002 14:14:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:13 UTC