thanks for that comprehensive response Jeremy. I'll have to re-read that a few times to fully grok it, but now I'll think of your name whenever I see those j.N namespaces.
My approach to namespaces in general has not been very well thought out; I've been putting off dealing with it until I better understand all the ramifications. looks like now is that time. On Oct 16, 1:23 pm, "Jeremy Carroll" <[EMAIL PROTECTED]> wrote: > I wrote the code that introduces these prefixes - I never really decided > whether the j stands for Jena or Jeremy! > > The code writes RDF/XML documents, given an RDF graph. > > Here is the logic, understanding it may help you choose prefixes better and > avoid the problems - points 5 and 6 may be under your control (also 7 but > probably not the issue here). Point 9 may be the cause of your problems, but > is somewhat different from the others. > > 1) The namespace prefixes are not a crucial part of the data, and can be > thrown away (and replaced with these generated symbols) > > 2) Many users are unhappy if this is done, so try not to do it. > > 3) The generated files have the following format > > <rdf:RDF > ALL NAMESPACES DECLARED HERE > ... > ... > > > TRIPLE-DATA > </rdf:RDF> > > 4) The input files from which the namespace prefixes came may have different > legal XML formats, or be N3 formats, and may be numerous. > > 5) Hence namespace prefix clashes can occur: > The same prefix is used to abbreviate different URIs in different places: > - either in different parts of the same XML document (legal: supported > for input but not for output) > - or in different XML or N3 documents > > I cannot remember whether when a clash occurs if both bindings are > discarded or one is chosen (at random); the implementation of clash > resolution has gone through several iterations. > > 6) If the prefix is chosen in a manner other than in an XML document, it > might not be a legal XML namespace prefix. Legal XML namespace prefixes match > the NCName construct in the Namespaces in XML Recommendation, and do not > start (case-insenstively) in "xml". > > 7) A different sort of namespace clash occurs when the same namespace URI is > given different prefixes in different documents (or document sections). Again > this triggers clash resolution code, whose behavior has gone through many > iterations - since there is no obviously right solution; and many solutions > that are also not obviously wrong. > > 8) The clash resolution code maintains a "prefix mapping" which is, > essentially a one-one map between prefixes and URIs. > > 9) Typically the namespace URI is determined from a URI using the following > algorithm: > Start at the end of the URI. > Work to the left, and find the leftmost alphabetic character that is > followed by alphanumeric characters. > (The actual character sets are NCNameStartChar and NCNameChar defined in > Namespaces in XML Rec. These extend to much of Unicode, and also allow > certain, but not all punctuation characters). A poor choice of Namespace URI > will lead to problems. > Bad namespace URI > http://example.org/myNamespace > http://example.org/myProject#myNamespace > Good namespace URIs end in "#" or "/" > > Example of how a bad choice of namespace URI goes wrong: > xmlns:eg="http://example.org/myNamespace"; > > then > eg:foo abbreviateshttp://example.org/myNamespacefoo > eg:bar abbreviateshttp://example.org/myNamespacebar > > these are split as > http://example.org/myNamespacefoo > and > http://example.org/myNamespacebar > > So we introduce j.0 ashttp://example.org/(since no prefix was used in the > input) > And these come out as > j.0:myNamespacefoo > and > j.0:myNamespacebar > > ==== > > The suggestion then is to review whether your data either includes illegal > prefixes (point 6) or prefix clashes (point 5), and to fix at source. > > ==== > > One further point: when writing the TRIPLE-DATA above, the code very > occasionally finds it doesn't have a namespace that it needs: at this point > it introduces a j.cook.up prefix which is purely local in scope (i.e. it is > only used for the element and attributes on which the namespace is declared), > this could end up in Composer's rendition in some unusual circumstance > perhaps. > > Jeremy > > PS I also point out that this sort of processing is entirely the point of > namespace URIs. > What really matters is the namespace URI - and this doesn't get lost. > When merging data from many sources it is not surprising if more than one > source uses the same short form for different things; when this happens tools > need to resolve the problem somehow, and Jena (underlying TBC here), resolves > things as described above. > > PPS I think in the first versions all namespaces were assigned j.N prefixes! > > > -----Original Message----- > > From: [email protected] [mailto:topbraid-composer- > > [EMAIL PROTECTED] On Behalf Of Scott Henninger > > Sent: Thursday, October 16, 2008 8:34 AM > > To: TopBraid Composer Users > > Subject: [tbc-users] Re: j.1:, j.2: .... j.n: namespaces spontaneously > > created. > > > Don; The spontaneous namespace prefixes has to do with element naming > > when creating legal XML. In particular, element names have to be > > qnames (<prefix>:<name>). The underlying XML serialization writer > > will create legal XML names by creating a qname (j.x:<name>) and > > adding the prefix statement xmlns:j.x="..." To make the prefixes > > meaningful, go to the ontology home and re-name the prefix. > > > -- Scott > > > On Oct 16, 8:37 am, donundeen <[EMAIL PROTECTED]> wrote: > > > Hi, > > > What's up with these j.n (where n is an integer) namespace prefixes > > > being spontaneously created in my ontologies? > > > > I've been importing xml, running constructs to create new classes, and > > > I'm noticing these namespaces are being created by the system as > > > abbreviations for some of my ad-hoc URIs. > > > > why does that happen? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/topbraid-composer-users?hl=en -~----------~----~----~----~------~----~------~--~---
