[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, [log in to unmask]]

> What about an innocent URI like
>
> voc://infospring.com/foolishPeople/12345 ?
>
> Do you think such would qualify as well to be publically used ?

If you chose to take issue with that URI, it would be based
on (presumably) what its mnemonic properties might suggest to
someone who speaks English, but not based on the fact that I
minted my own name for you.

Again, you are not differentiating between the act of simply creating
the name and what might be said with that name (either by explicit
statement or in this case implicitly by the choice of characters
making up the name).

> > As for "reissuing" codes, if a code defined by some other agency is
> > used as a component of a URI, such that the meaning of the code is
> > not changed, how is that an infringement on the owner of that code.
>
> Trademark issues ?

If those codes or other referenced identifiers are in fact trademarks,
then yes, trademark law does come into play, but a that may be addressed
simply enough by clarifying the rights of the trademark owner.

Though since such codes are intended to be publicly used/referenced,
I would be very surprised if trademark law would be a real issue in
practice for the kinds of vocabularies we're talking about.

> > Does the URN urn:issn:123... infringe upon the owner of that ISSN
> > code, by being a component of a URI that they didn't define? I think
> > not.
>
> urn:issn:  Different issue by RFC3044.

OK, whatever, then I'll use a different example:

   voc://infospring.com/isbn/0-13-009369-6

Surely, if my use of that ISBN number in such a URI denoting that
particular book constitutes some kind of infringement on the rights
of the owners of that book, then a whole heck of alot of systems
that deal with books are in big trouble...

And as there is no official URN scheme for ISBNs, what else am I
to do if I wish to have URIs based on ISBNs denoting books?

>
> >
> > > -------
> > >
> > >
> > > xsi:schemaLocation -
> > >
> > > One could have an xml-element preceding rdf:RDF,
> > > which carries this information -
> > >
> > > I'm not sure, whether RDF/XML parser generally be happy
> > > with that - as they might conclude on RDF/XML not enclosed
> > > by rdf:RDF .
> > >
> > > xsi:type cumbersome as well. It's use typically will result in
> > > RDF/XML syntax errors.
> > >
> > > Seems to me one of the reasons, which make it difficult to
> > > create XML schema for XML dialects as RDF/XML, which make
> > > their content models in dependency of attribute configurations.
> > >
> > > One could think this is a problem of XMLSchema rather than RDF/XML -
> > > but ...
> >
> > I think that the entire xsi: vocabulary is a mistake and reflects
> > a certain arrogance of XML Schema over the broader XML community.
>
> Excuse me: XMLSchema is from the SAME standards organization RDF is.

And how does that matter, exactly?

Just because both RDF and XML Schema are both children of the W3C
does not mean that they should be inextricably dependent.

> > I don't expect that any RDF/XML parser should have to correctly
> > interpret any xsi: vocabulary. RDF uses XML for its serialization,
> > not XML Schema.
>
> How does this fit with http://dublincore.org/2002/07/31/dcmes-xml
> Appendix B ??

One may use XML Schema to define a particular content model without
using any of the xsi: vocabulary in any instance of that content
model.

So I see no conflict with what I said and the XML Schemas referenced
by the above document.

Again, I'm not saying that RDF and XML Schema are in conflict, in
principle, but simply that the use of xsi: vocabulary terms in
an RDF/XML instance is not valid, and need not be required.

It's of course interesting to note that RDF's striping syntax
model cannot actually be captured by an XML Schema (though I
have heard that RELAX NG is up to the task) so one might wish
to ask the more appropriate question of why this is so, since
both RDF and XML Schema are, after all, both defined by the W3C...

> > I hope that in future editions of the XML Schema specs, the xsi:
> > vocabulary would be deprecated.
>
> Is there activity by rdf-core to serve for?

It has absolutely nothing to do with the RDF Core WG.

> Are you saying
> http://www.dublincore.org/documents/2002/09/09/dc-xml-guidelines
>
> Recommendation 7 is to be deprecated?

Well, not if you change the name from "Guidelines for implementing Dublin
Core in XML" to "Guidelines for implementing Dublin Core in XML *Schema*"
since the requirement to use xsi:type to capture key parts of the
DC ontology require an XML Schema parser, not simply an XML parser.

> > > When it is true, that RDF effectively (!) thinks about datatyping just
> > > as providing a pair of objects (x, y) ; x a character sequence not using < > </ >
> > > and a URIref - why the drafts
> > > go for a literal2value map at all?
> >
> > Because the lexical form is just a means to an end, and that end
> > is the datatype value.
> >
> > Furthermore, the L2V mapping is essential because the mapping
> > is N:1 where N>=1 -- i.e. there may be more than one lexical form
> > that maps to the same value, and thus, simple comparison of
> > typed literals is insufficient to determine equality.
> >
> > E.g.  "1.0"^^xsd:decimal == "1"^^xsd:integer == "000001"^^xsd:byte
>
>
> Where such equations are provided by RDF semantics ??

Sure. See the MT and the test cases.

http://www.w3.org/TR/2002/WD-rdf-mt-20021112/
http://www.w3.org/TR/2002/WD-rdf-testcases-20021112/

> > > If it is completely to the application to
> > > make any sense of such a pair, one
> > > could give "RDF datatyping"
> > > a much simpler wording with less philosophy in it.
> >
> > It is important to define the foundational machinery of
> > datatypes so that interpretations of typed literals are
> > constant accross applications. E.g. if we didn't state
> > explicitly that the L2V mapping must be N:1 then it would
> > be possible to define a datatype that was ambiguous, where
> > the same lexical form could map to different values, and
> > that would hardly be a good thing.
> >
> > Trust me, we worked very hard at making the RDF datatyping
> > solution as simple, minimal, and generic as possible while
> > still getting the job done. If there's something there, it's
> > necessary.
> >
> > > As the Primer is doing: In partice one can simply use any URI to
> > > indicate a datatype.
> >
> > Well, a datatype is denoted by a URI, and RDF datatyping is
> > designed to work for any datatype that conforms to the
> > characteristics as defined for members of rdfs:Datatype,
> > and not necessarily XML Schema datatypes.
>
>
> It is thought for working with any datatype, but it seems to
> me, that is does not deliver.
>
> Sure i think the L2V map is essential, but i can't see how
> the RDF drafts supports them - other than by asserting they are
> essential.

RDF does not define any L2V mapping. But it does say that
one must exist for any rdfs:Datatype and that for any given
lexical form of a particular datatype, it denotes one and only
one value.

Stating this in such generic terms is no different than the
XML spec stating that ID values must be unique within a given
infoset. You don't have to say what those ID values are to
know that each is unique, no more than you have to say what
datatype value a given lexical form maps to to know that it
maps to only one.

Applications which grok the datatype in question will know
which value is denoted by the lexical form, but RDF doesn't
have to say what it is.

That's what makes the RDF datatyping machinery extensible.

Patrick