Re: For namespace reuse

On 3 Jun 2008, at 12:05, Ivan Herman wrote:

> Bijan Parsia wrote:
>> On Jun 3, 2008, at 9:34 AM, Ivan Herman wrote:
[snipped aggrement]
>>> 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 '#',

First, from the OWL perspective, there is currently no OWL namespace.  
XML namespaces do not exist in RDF and currently we have no specific  
XML information item associated with OWL (or RDFS, only RDF). So it's  
a bit of a red herring.

My point was that I'm happy for the namespace for OWL/XML information  
items to be either <http://www.w3.org/2002/07/owl#> or <http:// 
www.w3.org/2002/07/owl> though I prefer the former. One already has  
to futz with both versions  (for correct base/ID resolution).

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

Fine with me.

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

Well, since we are trying to resolve an issue, we need at least SOME  
points of common agreement. If we cannot agree methodologically, then  
we are unlikely to agree substantively.

My position is that actual affect on users and implementors should be  
weighed higher than conceptual purity. That is, conceptual purity is  
to be primarily valued instrumentally, not intrisincally. (I don't  
think the conceptual argument is very good either, but there you go ;)).

[snip]
>> 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,

Well, if we put the OWL/XML serialization issue aside then we're in  
the same boat. I really don't see how we can *not* pay attention to  
XML based serialization.

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

I hence don't see the relevance.

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

AFAIK, I *am* 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.

There is no technical reason for it (though loads of social including  
the big hash vs. slash fight):
	http://www.w3.org/TR/REC-xml-names/#iri-use
Talks of "URI References" which is old school talk for URIs that may  
include a fragment as defined by:
	http://www.rfc-editor.org/rfc/rfc3986.txt
(which is referenced from the Namespaces rec).

[snip]
>> 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?).

Partly from DAML+OIL where imports was poorly or not defined. Partly  
from loose talk of namespaces and of the conflation of namespaces and  
documents. Partly from slightly strange notions of bootstrapping and  
"the principle of partial understanding". A few other bits too.

[snip]
>> 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...

A major step toward good.

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

See my experience with Swoop above. We had this, it was not good. We  
replaced it with custom help, no one noticed. I would argue that such  
tools *should* provide custom handling of built in (and other well  
known vocabulary). I think we should not encourage them not to.

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

You are trading hypothetical future benefit for current (and ongoing)  
cost. I don't think that's wise.

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

Then we are providing a poor implementation. All my arguments against  
GRDDL and the W3C providing implementation (esp. poor ones!) fly. If  
a vendor wants to sell a product based on an owl.owl like  
implementation, they are free to do so. We shouldn't *sanction* it by  
not only publishing it, but by letting people believe it's useful or  
potentially correct.

Again, it's been an *ongoing* pain to educate people about this issue.

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

Well, I'd want to revise the owl.owl so it contained no substantive  
axioms, but only comments or better yet, a pointer to our specs.

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

owl.owl doesn't remotely capture the semantics (or the syntax) of  
OWL. It doesn't capture a known useful fragment (it's not in our  
profiles document). By putting it up there and suggesting that it  
might be used automatically means that we, again, bless a poor  
implementation. And, in this case, one that is inherently poor (i.e.,  
it's not a mere matter of programming but a matter of the inherent  
expressive limits).

[snip]
> Yes. I have (latest version of) the Tabulator Mozilla extension  
> installed

Surely, Tabulator users are a tiny minority of OWL or RDF users.

> and that gives a fairly readable, nice output of RDF which is well  
> suited for most of the simple vocabularies.

The OWL vocabulary is not simple (at least in this sense; neither is  
the RDF vocabulary). See our specs ;)

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

This is easily handled by bundling a file or building in OWL smarts  
(as is actually done by swi prolog). So I fail to see the utility of  
the W3C publishing it, esp. at that valuable web space.

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

Yes.

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

No. A major use is in SOAP and other web services, but a major point  
of the OWL/XML is to let people engage the whole XML tool chain from  
schema aware editors on up. That's how I use it.

I'm likely to publish things in RDF/XML for the forseeable future,  
but I'm much more likely to author either in Protege or in OWL/XML.

> so I am not sure humans would frequently author such files. If so,  
> the tax might be much lower.

I've already encountered the tax.

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

See above.

> It would have no effect whatsoever on the functional syntax, on the  
> M'ter syntax, on Turtle, RDF/XML, RIF...

Of course not, but I'm not discussing them. :)

Matthew (an implementor) has also requested this (in private  
communication with me).

Cheers,
Bijan.

Received on Tuesday, 3 June 2008 13:46:35 UTC