W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > December 2003

Reviewing postponed issues

From: Graham Klyne <gk@ninebynine.org>
Date: Fri, 05 Dec 2003 17:26:20 +0000
Message-Id: <>
To: w3c-rdfcore-wg@w3.org

In the 2003-12-05 telecon, DanC asked for thoughts about the postponed 
issues while they're still reasonably fresh in our minds.  Here are mine.

Postponed issues summary:  http://www.w3.org/2000/03/rdf-tracking/#futures

Comments below are headed by specific issue URIs.



I think that CWM defines a property that can be used, in conjunction with 
Cwm rules, to do something like this.  This, maybe:
log:uri This allows one to look at the actual string of the URI which 
identifies this. (Cwm can get the URI of a resource or get the resource 
from the URI.) This is a level breaker, breaking the rule of not looking 
inside a URI. Use (eg with string:match) to replace RDF's old "aboutEach" 
functionality. Use to implement the URI spec and protocol specs, etc.
-- http://www.w3.org/2000/10/swap/doc/CwmBuiltins.html

If this is enough, then I think this can fall under subsequent work to 
define some useful RDF vocabularies.



I think this aspect of RDF/XML is somewhat of a mess.  It's an unholy mix 
of qname and spelt-out URIs.  A quick-fix might be (per DanC's suggestion 
of long ago) to introduce new properties, e.g. rdf:aboutQ, rdf:resourceQ, etc.

Maybe more satisfactory would be to take this into any future work to 
redesign the RDF/XML syntax (though I have my doubts about the utility of 
such an activity).



I've lumped these together as they all relate to shortcomings of the 
current RDF/XML syntax, rather than a fundamental limitation of the RDF 
graph model.

As such, these would be considerations for a new XML syntax for RDF, if 
such is attempted.

Assuming that use of RDF is becoming more widespread, I don't feel that a 
wholesale redesign of RDF syntax is likely to be very helpful.  But I did 
recently notice an alternative XML syntax proposal that seemed quite neat 
in some respects:  http://rx4rdf.liminalzone.org/RxML (big difference from 
RDF/XML:  an element name is resource id rather than type id).

I do wonder if it would be feasible/possible to design a general-purpose 
simplified subset of the existing RDF/XML subset that is more amenable to 
dependable processing with XML tools, by eliminating many of the 
alternative forms, and which is easily generated automatically from 
arbitrary RDF.



I don't think this can be meaningfully tackled in isolation from the more 
general issue of embedding RDF in other XML data.



It's not clear to me that there's any problem here that is not adequately 
addressed by owl:sameAs.



Now we have collections as well as containers.  We also have rdfs:member, 
of which all the rdf:_n are sub-properties.  I'm not sure there's anything 
to add (though maybe things to take away?).

(I noted somewhere that I think an RDF container can be "closed" using Owl 
by imposing a cardinality constraint on rdfs:member.  I'm not sure that's 



In hindsight, I think we should have relaxed this restriction in the RDF 
abstract syntax.  Pat has commented that the formal semantics would have 
been much simplified.  I think this is a relatively change (though there 
may be consequences for Owl).

Less clear is how one might carry over such a relaxation into RDF/XML 
syntax.  One approach that occurred to me is something like:
     <rdf:litValue> text </rdf:litValue>

This sits within the current syntactic framework for Resources, so could 
also address issue:



I think this would be a useful improvement to RDF/XML syntax.

Also, see above:



In isolation from the issue literals as subjects (see baove), I don't 
really advocate this.

I think we should try to minimize alternative ways (i.e. other than RDF) 
from saying things about pieces of data.



This seems to be an issue for rules rather than raw RDF data, so I'm not 
sure it needs to be regarded as a high priority for basic RDF.



I was one who raised this, mainly as I felt a need to deal with provenance 
issues.  Many implementations have some kind of context support, though it 
is, of course, outside current RDF.  Current applications seem to use a web 
document as a unit of context ... this feels to me like a kind of layer 
violation:  I'd want to be able to express the same idea inline.

Notation 3 has a model for contexts/formulae.

I think a small extension to RDF/XML syntax could support this model, viz.

   <rdf:RDF rdf:about="..." >
   <rdf:RDF rdf:nodeid="..." >

being legitimate ways of defining a resource whose value is a subgraph, 
within an RDF document.  Based on my implementation work, I think this 
matches the N3 model of a formula.



These both appear to relate to the "social meaning" question.  There is a 
mailing list that discusses this, but
(a) it seems to have fizzled out, and
(b) I'm not sure that it ever really started to address the issue.

I guess the world will find its way on this, whatever we may affirm.



I'm sympathetic to this, and it I think wouldn't be a big deal to add a new 
property whose extension contains every pair of values in IR.



I think this layered approach has been done for us by (some flavours of) 
Owl.  I see no reason for further work on RDF.



I'm not sure why this is felt to be needed.  I think a *complete* mapping 
could be tricky, though some partial mapping might be simple enough.

My gut feeling is that this will be more hassle than it's worth, but 
applications are free to introduce any equivalences they need in their data.



I think the goal here should be to tease apart the *syntactic* mechanism 
for including XML text as an RDF lexical form from the *semantic* matter of 
indicating that some literal value is (in some sense) an XML 
infoset.  Currently, the rdf:parseType="rdf:Literal" does both;  i.e. it 
affects RDF/XML parsing, *and* it applies the rdf:XMLLiteral datatype.

E.g. suppose we have a syntax extension, say rdf:parseType="rdf:Text", and 
this were treated just like rdf:parseType="rdf:Literal" except that the 
resulting literal is plain text, not datatyped as XMLLiteral.  Thus, any 
in-scope xml:lang would be honoured.  I think this satisfies the stated 



I think the mistake made here might be a useful topic for a note about 
designing RDF vocabularies.  I made a similar mistake in some of my own 
work, and I think the RDF calendaring task force came close to committing 
it too.

I also think that, in practice, applications will always find closed-world 
ways to use RDF, and that we probably can't hold back this particular tide 
if RDF is as successful as we hope.  So I think the thrust would be 
something like:  "if you want your RDF data to be sharable by a range of 
diverse RDF applications, here's how to do it".


That's all.


Graham Klyne
For email:
Received on Friday, 5 December 2003 12:27:09 UTC

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