Re: For namespace reuse

On Jun 3, 2008, at 9:34 AM, Ivan Herman wrote:

> Bijan,
> although I fully understand and agree with the frustration on the  
> namespaces that no one remembers (me neither),

It's not just not remembering, it's having a huge set of namespace  
with prefix and entity mappings. That is, it's not just the header  
(which is bad enough) the pain is spread everywhere. (I just reviewed  
a paper that talked about owl:subClassOf!).

> I am afraid we might have to separate the OWL/XML namespace from  
> the OWL one (I think we did agree that we would reuse the same OWL  
> namespace for OWL2, so the issue is really only between these two).

I agree that it's only for the OWL/XML. I even agree that there might  
be reasons for separating them. The question is what kinds of  
argument and evidence are there and how should they determine what we  

> Caveat: I am not a real XML expert, and we might want to ask advise  
> from one if we continue to disagree:-). While I give some of my  
> thoughts below why I think those two should be separated, I must  
> admit that I also have a general feeling that "something else might  
> go wrong that I do not know about, let us avoid possible problems  
> for the future". I know this is not a rational argument but,  
> well...:-)

It's not irrational esp if the cost of an additional namespace were  
cheap or free. I believe it's not particularly cheap thus I would  
like some more specific bit.

Put it another way, if we are just avoiding unknown problems, there  
could be unknown problems with coining a new one :)

> First of all: you say "", which is  
> the right namespace for OWL, but probably not in the 'real' XML  
> sense which should be "" (note the  
> missing '#'). So there you go: there is already a difference:-(

I don't think it matters which. I'm happy to go with the hashless.  
Actually, ideally we'd parallel the rdf in rdf:about.

> One of my problems is that, conceptually,

Can we agree that conceptual arguments are fairly weak? That is,  
conceptual purity without beneficial effect on actual use (or with  
harmful effect on actual use) is not particularly valuable?

> the usage of namespaces in the RDF world is very different from the  
> XML world (yes, I know, RDF/XML uses the namespaces, and I am not  
> sure it is 100% kosher in the XML sense...).

For the syntax items, it's fine (e.g., rdf:about). For the terms it  
definitely is not. Many electrons have been spilt over this.

> In the case of RDF, namespaces are really used for an abbreviation  
> of URI-s, much as CURIE-s do (and will be used in the functional  
> syntax).

Actually, they are also used for syntax items that only appear in the  
XML, never in a triple. e.g., rdf:RDF, rdf:about, rdf:ID, etc.

> Hence the usage of the '#' or '/' characters in the URI-s we use.  
> In the XML world, namespaces have an effect on the abstract  
> 'meaning' of the XML (I use the word _very_ loosely here!): they  
> are indeed integral part of the XML Infoset, affect the way the DOM  
> works, etc. Hence also their usage of URI-s without the fragment  
> part, ie, the '#' character (as far as I know, formally, the  
> meaning of '#' and what comes after it, is dependent on the mime- 
> type, it does not have a generic meaning, that is why the XML  
> community keeps away using it there.)

Whenever you have something like application/xml or even text/xml the  
mime type is an xml variant, hence controlled by the XML spec, hence  
it's kosher to use the XML interpretation. Of course, none of this  
matters, in some sense, since XML never concats to make a URI. I.e.,  
the qname is {xxxxx#, localName} so, there's no issue.

> Another point: in the RDF world, a possible action is to  
> dereference the URI in the namespace and hope to see, eg, the RDF/ 
> XML representation for the terms.

Putting aside the general case, we need to keep in mind that we are  
in a very special circumstances: defining built in vocabulary. What  
we're doing is inherently centralized and requires software to be  
custom tailored. OWL cannot fully describe itself and to put up a  
misleading description is dodgy at best. We could put up an RDF/XML  
consisting of a comment "See the OWL specs" if we must meet this  
nominal goal. Futhermore, OWL is heavily advertised in the RDF world.

In my experience, owl.owl was a very bad idea. When owl first came  
out, I constantly had to correct people who wanted to import it (thus  
making their documents necessarily OWL Full). We only recently weaned  
some SWRL people off that antipattern as well (importing the swrl  
namespace does horrible things to your ontology). Furthermore, in  
Swoop we had hyperlinks to the builtin terms that originally loaded  
the owl.owl etc. files. We switched it to going to a custom help  
screen. Not a person noticed or complained

> I know this is does not always work (eg, for the XSD namespace) but  
> it certainly works for
> or
> already! (And I would not expect us to change the existing file  
> there by removing anything and hence creating backward  
> compatibility problems, just adding the new OWL 2 terms, eventually.)

Actually, I would strongly urge replacing owl.owl. A RDDL document  
would be fine.

> I do believe this becomes more an more common with people using  
> RDF, eg, using the various RDF browsers (tabulator, zeitgeist,  
> disco, etc) and I believe it is a strong requirement for  
> communities like the Linking Open Data one, for example, have in  
> their practice (we can check this for more specific references if  
> we want).

The only use of owl.owl I know of is in swi-prolog, which bundles it.

I think it's really of no utility even to the linked data community  
in this specific case. Indeed, if you cannot capture your data  
correctly in RDF, one *should not* pretend that one can.

A RDDL document with RDFa that points to the specs would be fine with  

> As a purely anecdotal fact, I know that when I mix different  
> vocabularies and I am not sure about the exact term, my first  
> instinct is to try to dereference the URI and see what is there.

Dereference with a web browser?

> I do that fairly often. Sure, when I have a bookmark against the  
> textual specification of the terms I use that (say, for DC or  
> indeed OWL), but that is not always the case.

Sure, but that's the generic argument. We need to consider the  
specifics here. The tax you are imposing is on every author of an owl/ 
xml document and it's a pretty high one. Is it really worth it?

Can we compromise with a RDDL document with some RDFa? (I.e., clearly  
documentation RDF, not pseudospecification.)? That seems to meet all  
needs without a different namespace.

> However, if you look at the same URI from an XML sense, you would  
> expect something different. The dereferenced URI would give  
> information on the terms used in the XML space ie, in our case,  
> Declaration, ObjectAllValuesFrom, etc.

There's no reason it can't give both. I.e., a pointer to the OWL/XML  
spec and a pointer to the structural syntax.

> These are not RDF terms (I would not use owl:ObjectAllValuesFrom in  
> RDF), they are specific to the OWL/XML only. Ie, I would not want  
> to see these terms listed there as an RDF user, because it would  
> just mess me up... Whether what you have at the end of that URI is  
> in RDDL format or anything else (and I agree RDDL is a good idea)  
> is a secondary issue.
> B.t.w., we did discuss some possible URI-s for RDF/XML at the  
> telco, but we did not consider:
> which might certainly ease the pain, being a logical step from the  
> core OWL namespace...

That's better, but the main cause isn't in the header, it's in the  
use scattered throughout.


Received on Tuesday, 3 June 2008 09:30:03 UTC