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

Re: new semantics initiative

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 13 Jun 2002 11:43:44 +0300
To: ext Dan Brickley <danbri@w3.org>
CC: Pat Hayes <phayes@ai.uwf.edu>, RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <B92E35F0.16AAA%patrick.stickler@nokia.com>

On 2002-06-13 11:14, "ext Dan Brickley" <danbri@w3.org> wrote:

> On Thu, 13 Jun 2002, Patrick Stickler wrote:
>> On 2002-06-12 19:46, "ext patrick hayes" <phayes@ai.uwf.edu> wrote:
>>>> On 2002-06-12 7:23, "ext patrick hayes" <phayes@ai.uwf.edu> wrote:
>>>>>  ...instead, we (ie the RDF coreWG) assume that the W3C will
>>>>>  eventually have the good sense to declare that a certain namespace is
>>>>>  *globally* understood to be 'rdf-invisible', in that any triples
>>>>>  which use urirefs from that namespace are not asserted in any RDF
>>>>>  graph.
>>>> Sorry to rain on the parade, but this is nonsense. Namespaces
>>>> are not significant nor represented in the RDF graph, and there
>>>> is no formal relationship between a URI and whatever namespace
>>>> prefix was used to hack it into the RDF/XML serialization.
>>>> Basing the designation of dark triples on namespace distinction
>>>> is impossible, since that distinction is an illusion.
>>> Then the entire WWW is an illusion. I will leave others to draw a
>>> conclusion about that.
>>>> C.f. http://lists.w3.org/Archives/Public/www-rdf-interest/2002Jun/0172.html
>>>> If you wish to simply say that the use of namespaces to trigger
>>>> an RDF parser to flag such statements as dark, well, fine, but
>>>> let's please be clear that it is a syntactic mechanism and not
>>>> a semantic one, and to that end, I can think of a number of
>>>> other possible (and IMO better) syntactic mechanisms for
>>>> indicating dark triples that are not based on namespace prefixes.
>>>> But saying "any triples which use urirefs from that namespace"
>>>> is nonsense since urirefs have no namespace. They are URIs,
>>>> not qnames, and they are fully opaque.
>>>> Presuming that triples have some indication of being dark
>>>> which is not based on namespaces, such as a simple bit,
>>>> then we're OK, and can proceed with dark triples and
>>>> the introduction of the proposed layering tweaks to the MT.
>>>> But there are *no* namespaces in the RDF graph. None whatsoever.
>>> Well, sorry, but *that* is nonsense. If there are no namespaces in
>>> the RDF graph then there is no connection between any RDF graph and
>>> the RDF + RDFS vocabulary, so all of RDF(S) is meaningless.
>> No. The connection is between an RDF graph and vocabulary terms
>> which are denoted by URIs. The fact that a set of terms are grouped
>> together in a functional collection, and for editorial convenience
>> that collection is given the same XML namespace prefix in the RDF/XML
>> serialization is *irrelevant*.
>> We could just as easily give every single RDF and RDFS term a different
>> XML namespace prefix, and the connections between those terms and
>> their semantics in the graph would be the same (it would just make
>> RDF/XML a bit harder to write).
>>> Maybe we are using 'namespace' in different senses?? I just mean a
>>> set of URIs that belong to someone (in this case, the W3C).
>> But what is the formal connection between a term and that collection
>> of terms? Where in the graph do we see that relation? Where is
>> that collection explicitly denoted in the graph as produced by
>> *every* conformant RDF parser?
>> You seem to be missing some pieces to your puzzle, Pat.
>> Yes, the W3C defines a functional vocabulary called RDF, and
>> another called RDFS, and yes, the terms of those vocabularies
>> are grounded in the same XML namespace for each vocabulary,
>> and yes, the namespace URI is taken to denote those functional
>> vocabularies, *BUT* in the graph itself, there is *no* explicit
>> representation of the relationship between term and vocabulary
>> which is accessible to any RDF application.
>> Show me where I'm wrong.
>> (and no fair peeking into URIs either, those are opaque, no?)
> This is why the original RDF Schema WG provided the rdfs:isDefinedBy relation.
> For apps that care, it provides a common name for indicating that
> relationship.
> Sure, it doesn't force parsers to emit this information, schema authors to
> assert it, or database administrators to keep it lying around if they
> think it is using up too much disk space.

OK, but I don't see the utility in this, really. If you need to record
the source of a statement, you have reification to do that. So the
use for recording provenance of statements is not motivating to me
for the existence of this property.

And the property doesn't work really if it is meant to tell some
application where to go when it encounters some unknown term. The
term has no relation to the schema without the rdfs:isDefinedBy
statement, yet that statement is likely going to be in the schema
itself, so there's a catch-22 situation. Either the application
has knowledge about the term or it doesn't. If it does, it probably
doesn't need to go and get any schema. If it doesn't, then it
won't know where to get the schema. So what's the point.

> But that's why we created it. That's all it was intended to do.

If folks find it useful, fine. I just want to be sure that its
definition (sorry Pat) does not further exacerbate the whole
"what is a namespace" debate by (incorrectly) claiming that
(a) a term relates to only one schema, (b) a vocabulary
is grounded in only one namespace, and (c) namespace URIs
must be URLs that are resolvable to RDF/XML instances. All
of which I strongly disagree with.

> rdfs:isDefinedBy was a bad name. We'll live. Let's please move on...

Fair enough. Thus my recommendations to just use rdfs:schema to
point specifically to an RDF/XML instance, or simply to
make that clarification explicitly with rdfs:Schema.


Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Thursday, 13 June 2002 04:39:35 UTC

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