W3C home > Mailing lists > Public > public-owl-wg@w3.org > June 2008

Re: For namespace reuse

From: Ivan Herman <ivan@w3.org>
Date: Tue, 03 Jun 2008 13:05:57 +0200
Message-ID: <48452595.1000708@w3.org>
To: Bijan Parsia <bparsia@cs.man.ac.uk>
CC: OWL Working Group WG <public-owl-wg@w3.org>


Bijan Parsia wrote:
> 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!).

True. And I must admit that I still hesitate whether a specific term is 
in the rdf: or the rdfs: namespace:-( But, well, the harm is done...

[snip]

>> 
>> First of all: you say "http://www.w3.org/2002/07/owl#", which is the 
>> right namespace for OWL, but probably not in the 'real' XML sense 
>> which should be "http://www.w3.org/2002/07/owl" (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. 

I am not sure we can/should go for the hashless (for the RDF case). 
First of all, there is also a bunch of deployed stuff out there with 
'#', and the '#' is also necessary for Turtle, SPARQL, RDFa, etc... Ie, 
if the end of the discussion the decision of the group is to use one URI 
for both OWL and OWL/XML, I think it should be the one with '#'.

> 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?
> 

I am not sure I fully agree, but that is also a matter of taste...

>> 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.
>     <http://www.jenitennison.com/blog/node/49>
> 	
>> 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.
> 

Yeah. True. My personal opinion is that it would have been cleaner and 
better to separate the namespace used for purely RDF/XML things like 
rdf:about and the namespace used to abbreviate the URI-s of the RDF 
terms that are part of the RDF vocabulary. Yes, that would have meant 
yet another namespace, but nevertheless (hm. This may be 'conceptual 
argument' again:-)...

If we put the RDF/XML serialization issue aside, I believe my statement 
is true (in the semantics part as well as in turtle, SPARQL, RDFa, RIF, 
... and, I believe, for our own functional syntax, I am not sure about 
the M'ter syntax)

>> 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.
> 

That is where I would prefer to ask an XML expert. I do not have any 
argument at hand, but I do not remember having ever seen a URI with a 
'/' or a '#' used as an XML Namespace URI. There may be no real reason 
for that; I simply do not know.

>> 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
> 

O.k., I did not know about these bad experiences (where did the 
misconception come from that owl.owl should be imported?).

>> I know this is does not always work (eg, for the XSD namespace) but it 
>> certainly works for
>>
>> http://www.w3.org/2002/07/owl#
>>
>> or
>>
>> http://www.w3.org/2002/07/owl
>>
>> 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 am not convinced we should do that. It is already there, going back 
and remove the content would be a major step that should not be taken 
lightly...

>> 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. 


Not sure. I know it is a very very minor example, but if you go to

http://dbpedia.org/page/Budapest

that page uses (at the moment) one owl statement (owl:sameAs); you can 
then click on it and it would automatically come up with some (yes, 
minimal) information on what owl:sameAs is. (The same holds for rdf:type 
or for geo:long, for example).

The example is bad or, shall we say, not really mature yet, I know. 
Doing this for humans running with IE or Opera or Firefox without a 
proper plugin currently is still fairly bad, the information you get is 
fairly minimal, etc. But the principle (sorry:-) is important here and 
the usage can evolve significantly. Also, RDF processors can suck in the 
appropriate files for their own purposes (eg, if they have only RDFS 
reasoning, they still can do _something_ with owl.owl).

Because there is something going on in this space already, I think 
removing the owl.owl content would be a bad idea... (but this is, 
actually, a side issue in our current discussion, isn't it, if we take 
your RDFa approach into account...)

>                      Indeed, if you cannot capture your data correctly in 
> RDF, one *should not* pretend that one can.
> 

I am not sure I understand the last remark. But it may not be important.

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

See below.

>> 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?
> 

Yes. I have (latest version of) the Tabulator Mozilla extension 
installed and that gives a fairly readable, nice output of RDF which is 
well suited for most of the simple vocabularies. Of course, I would not 
use that for an ontology with thousands of terms, but I rarely hit those 
in my practice... And OWL does not have thousands terms either, so 
displaying it (ie, owl.owl) in firefox is a perfectly viable and 
workable alternative (I just did it when I wrote my previous mail...).


>> 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?
> 

Well, I am still not convinced (ie, that "it's a pretty high one"). The 
URI we are discussing here is used exclusively in OWL/XML, and nowhere 
else. My understanding is that OWL/XML is used primarily by tools as an 
exchange format for OWL ontologies (never having used the previous 
OWL/XML format I can just guess here, I must admit), so I am not sure 
humans would frequently author such files. If so, the tax might be much 
lower.

> 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.
> 

As a fan (and implementer:-) of RDFa I clearly cannot object to that:-) 
Yes, that might be a possibility, although we would then take on an 
extra job in the group to convert the current owl.owl plus the OWL2 
terms into RDDL+RDFa... Is it really worth it?

Actually... formally, RDDL+RDFa is not defined. XHTML+RDFa will be 
finalized as a Rec shortly, but the adaptation of RDFa to other XML 
dialects, though probably easy, has not been done yet. But we can drop 
the RDDL part and use pure XHTML, for example...

[snip]

>>
>> B.t.w., we did discuss some possible URI-s for RDF/XML at the telco, 
>> but we did not consider:
>>
>> http://www.w3.org/2002/07/owl/xml
>>
>> 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.
> 

To repeat myself, and sorry about that: the 'scattered' around in this 
case would be exclusively for OWL/XML files, a fairly restricted and 
(again if I am right) not-done-by-human case. It would have no effect 
whatsoever on the functional syntax, on the M'ter syntax, on Turtle, 
RDF/XML, RIF...

> Cheers,

Cheers back:-)

I.

> Bijan.

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf


Received on Tuesday, 3 June 2008 11:06:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 June 2008 11:06:28 GMT