- From: <Patrick.Stickler@nokia.com>
- Date: Wed, 6 Jun 2001 18:44:10 +0300
- To: jborden@mediaone.net, Patrick.Stickler@nokia.com, www-rdf-interest@w3.org
- Cc: Ora.Lassila@nokia.com
Exactly! If I e.g. want to use XML Schema to provide strict data typing for my serialized RDF instances (e.g. strict date formats, enumerations of token value sets such as ISO language names, etc.) I need to be sure that both XML Schema and RDF Schema are using the same URIs to talk about the same things. If I try to use a class in an XML Schema as a superclass of an RDF class, per the DAML examples, then I run into all kinds of nastiness. Likewise, if I wish to define enumerations of token values for a property in XML Schema and then assign rankings (numeric values) for those in RDF Schema, the URI ref I have to use is tied to the XML Schema MIME content type and is not generic and portable, as it should be. XML Enumeration for 'status' RDF assigned rank --------------------------- ----------------- draft 1 draft_approved 2 approved 3 retired 4 (the rank is needed if I want to have queries such as 'status <= approved', etc.) Tricky, yes. Though I'd use a stronger term ;-) Thanks for the pointer to your algebra materials. I'll have a look. Cheers, Patrick > -----Original Message----- > From: ext Jonathan Borden [mailto:jborden@mediaone.net] > Sent: 06 June, 2001 18:17 > To: Patrick.Stickler@nokia.com; www-rdf-interest@w3.org > Cc: Ora.Lassila@nokia.com > Subject: Re: What to do about namespace derived URI refs... (long) > > > Ok I see. What is tricky about _that_ problem is that the fragment > identifier syntax is defined by the media type of the MIME > message. I have > started to consider these issues: > http://www.rddl.org/SchemaAlgebra . There > are some thorny issues here. Consider particularly the fact > that XML Schema > uses QNames not URI references to generally identify types, > and that a QName > may identify each an element, attribute, complexType etc. > > -Jonathan > > > > > > > No, this is still missing the point. Even if I am able > > to use RDDL to retrieve a DTD, an XML Schema, an RDF Schema, > > etc. etc. associated with a namespace, that *still* does > > not address the problem that the abstract information > > resources (e.g. properties, etc.) defined in any of those > > schemas may have varying URI references! > > > > There should be, e.g. for the DC 'Title' property, one consistent > > URI reference that can be used by RDF Schemas to reference it, and > > that URI reference should be the same regardless as to whether > > my system is using a DTD, an XML Schema, or any other schema > > to define well formedness or validity constraints on the > serialization > > of data streams for interchange into/out of that system. > > > > I think that RDDL solves a very important problem, but that's not > > the problem I'm talking about here. > > > > Patrick > > > > > -----Original Message----- > > > From: ext Jonathan Borden [mailto:jborden@mediaone.net] > > > Sent: 06 June, 2001 17:25 > > > To: Patrick.Stickler@nokia.com; sean@mysterylights.com; > > > www-rdf-interest@w3.org > > > Cc: Ora.Lassila@nokia.com > > > Subject: Re: What to do about namespace derived URI refs... (long) > > > > > > > > > > > > > > > > > The key point here is that (a) we use URNs rather than URLs > > > > to identify namespaces and abstract resources, and (b) we > > > > define the necessary mappings between a standardized URN > > > > scheme and the various schema and serialization schemes > > > > that might reify or reference those abstract resources > > > > within a given system (i.e. XML Schema, RDF, etc.). > > > > > > > > > > The XML-DEV group has been discussing this issue at length. RDDL > > > http://www.rddl.org is suggested as a format to describe > > > namespace related > > > resources such as schemata, CSS etc. A RDDL document may be > > > resolved by a > > > URL, or via a URN using something like the DDDS mechanism: > > > http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-03.txt > > > > -Jonathan > > >
Received on Wednesday, 6 June 2001 11:44:46 UTC