W3C home > Mailing lists > Public > public-webont-comments@w3.org > November 2002

Re: Comment on OWL media type registration draft

From: Jonathan Borden <jonathan@openhealth.org>
Date: Thu, 14 Nov 2002 18:33:31 -0500
Message-ID: <018f01c28c36$3ec33ba0$7c674544@ne.mediaone.net>
To: <public-webont-comments@w3.org>, "Dave Beckett" <dave.beckett@bristol.ac.uk>

Dave Beckett wrote:

>
> I was reading
>   http://lists.w3.org/Archives/Public/www-webont-wg/2002Nov/0151.html
> where Jonathan proposes closing 5.13
>
http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I5.13-Internet-Media-Typ
e-for-OWL
> by creating a mime type registration for OWL.
>
> [Speaking for myself, not RDF Core.]
>
> It seems the key aspect that it is recording is the entailment
> parameter which has a small set of fixed values:
>   simple, RDFS, lite, DL, full (latter being the default)

To be honest, I wrote those down as parsed from an email by Dan Connolly --
and the entailment parameter just occured to me -- i.e. this is probably a
half baked idea that I've posted for discussion.

>
> I was wondering several things:
>
>   * Is this not limiting to the users - how easy is it to create a
>     MIME TYPE parameter in a document (I'm thinking of the HTTP-Equiv
>     <meta> you have to use in the HTMl family)
>
>   * A fixed list of values seems odd to me from a semantic web
>     architecture point of view - don't we use URI(-ref)s?

Indeed, this would be a better idea. e.g. application/owl+xml;
entailment=http://example.org/OWL#DL

>
>   * Your list assumes these parameter values are distinct and
>     complete; surely there are more subtle relationships between them
>     that would have to be put in this registration document?

My idea is that each value of the entailment parameter might license
distinct entailments e.g.


ex:foo rdfs:range owl:Class .
ex:bar ex:foo ex:baz .

simple:

=> nothing new

RDFS

=>

ex:baz rdf:type owl:Class .

lite, DL:

=> error, classes can't be instances

full:

=>
ex:baz rdf:type owl:Class .


>
>   * If this is of such general utility would it be better to just add
>     this to the RDF mime type draft?  Seems occam's razor applies.

Not a document under our control.

>
>   * If this is such a key requirement, wouldn't it be better to add
>     it to the OWL abstract syntax, and consequently the RDF/XML, such
>     as a parameter off <rdf:RDF> ?   I was told in personal
>     communication that crawlers for some of this data use
>     namespaces, file name suffixes to try to guess the appropriate
>     semantics. Surely we can do better than that?

Surely and media types are limited, not a perfect means to indicate
semantics, particularly when any or combinations of several semantics might
apply, but this is (just) a media type registration, not part of OWL syntax.

On the other hand, this is not to say that a similar parameter off <rdf:RDF>
would not also be useful.

>
>     It would seem to benefit from being several layers higher than
>       (HTTP say) Content Type parameter
>       Content Type
>       Transfer Protocol
>       File name suffixes, (looking for .owl etc.)
>       abstract syntax
>     being at the
>       concrete syntax
>     level where users have more control and can put it in the files
>     directly.
>
>     I'm not even sure how you'd enable people to generate all 5 types
>     of entailment on one system using common tools such as apache -
>     you'd need five filename suffixes.  And which one would be .owl ?

well, perhaps .rdf, .rdfs, .owll, .owldl, .owl ...

>
>   * Of course if it was put in <rdf:RDF>, the default would have to
>     be RDF entailments, so that would mean OWL would have some more
>     boilerplate in the header.
>
> This seems more of a brain dump since this is only a proposal by
> Jonathan.

Thanks, to be honest, I'm not sure that this is the solution to the problem
of how to deal with the various possibilities of which entailments are
licensed according to which part of the various specs, but this is a
proposal on the table.

Jonathan
Received on Thursday, 14 November 2002 18:53:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:27 GMT