Re: relative uri references

My only concern about having the structural specification only allow
for absolute URIs is that it is common idiom to use relative URIs in
imports statements. Doing so allows one to move a hierarchy of
ontologies from one place to another without having to rewrite all the
import statements. If the structural specification only has absolute
URIs and serializes a document that uses relative URIs in this way,
that will no longer work as the resultant imports will use full URIs.

-Alan

On Mon, Nov 24, 2008 at 10:39 AM, Peter F. Patel-Schneider
<pfps@research.bell-labs.com> wrote:
> Actually the structural specfication uses IRIs (from RFC 3987) as
> identifiers (but it calls them URIs - section 2.3).  My reading of
> RFC3987 http://www.ietf.org/rfc/rfc3987.txt has an IRI as absolute and
> has an optional fragment (at least, IRI has the same expansion as
> absolute-IRI plus an optional fragment).  Thus the structural
> specfication is correct with respect to the need for absolute URIs.
>
> In the functional syntax (section 2.3) one can use
> - an IRI - which is absolute and allows fragments
> - a curie - which is the combination of
>  - a optional namespace name - which expands to an IRI
>  - an irelative-ref - which is appended to the IRI
>
> The only issue then is ontologies that use curies with no namespace
> names in documents that do not have a namespace expansion for the empty
> namespace.  The rule for this just uses the irelative-ref, which can
> result in a relative URI (but this is forbidden because "[t]he full URI
> obtained by this expansion must be a valid URI" [Section 3.2.1.]).
>
> Therefore the following document is not a valid OWL 2 ontology:
>   Ontology(foo)
> because the ontology URI does not expand into a valid IRI.
>
> However, in my view it would be better to be more clear, by modifying
> the CURIE expansion rules at the end of 3.2.1 as follows.
>
> * If the prefix of the CURIE is not present, then
>  prefix definitions of the ontology document being parsed MUST contain
>  a definition of the empty (missing) prefix. The resulting
>  full URI is obtained by concatenating the namespace with the CURIE's
>  reference.
> * If the prefix of the CURIE is present, then either Table 2 or the
>  prefix definitions of the ontology document being parsed MUST contain
>  a definition for the prefix. The resulting
>  full URI is obtained by concatenating the namespace with the CURIE's
>  reference.
>
> peter
>
>
> From: Ivan Herman <ivan@w3.org>
> Subject: Re: relative uri references
> Date: Mon, 24 Nov 2008 15:49:59 +0100
>
>> Boris,
>>
>> at the moment, the syntax document says that OWL uses URIs for
>> identifiers which are more than just symbols. And yes, one of the core
>> approach on the Semantic Web is to use URIs (well, plus bnodes and
>> literals, but let us put that aside as they are not relevant for the
>> discussion). So I would propose to that on the structural level we
>> indeed have full blown, ie, absolute URIs.
>>
>> Ivan
>>
>> Boris Motik wrote:
>> > Hello,
>> >
>> > Well, it is clear that in the context of Internet protocols, relative URIs don't make sense: you can't make a GET request from a
>> > relative URI; instead, you always need an enclosing base URI to do so.
>> >
>> > From a logic point of view, however, a URI is nothing more than a symbol. Thus, a URI <blah.owl> is a symbol that is completely
>> > different from, say, <http://www.example.com/blah.owl>. These two URIs are not identical, so there is no problem from a logical
>> > point of view. In other words, from a logical point of view, URIs are just symbols, and we don't care whether they are absolute or
>> > relative.
>> >
>> > I don't know whether this may be objectionable from a Semantic Web point of view. This question is not as relevant to the
>> > functional-style syntax as it is relevant to the structural specification (after all, FS just encodes the structural specification).
>> > There, we are currently not requiring URIs to be absolute -- that is, we are allowing classes that are fully identified with the
>> > relative URI <blah.owl>. Note that, <blah.owl> is in this case the full name of the class, so you shouldn't perform any expansion.
>> >
>> > To summarize, we need to decide whether it is OK to have classes that are completely identified by a relative URI. If we ban them
>> > from the structural specification, then the FS should just follow suit.
>> >
>> > Regards,
>> >
>> >     Boris
>> >
>> >> -----Original Message-----
>> >> From: Ivan Herman [mailto:ivan@w3.org]
>> >> Sent: 24 November 2008 13:02
>> >> To: Boris Motik
>> >> Cc: 'Alan Ruttenberg'; 'W3C OWL Working Group'
>> >> Subject: Re: relative uri references
>> >>
>> >> Hi Boris,
>> >>
>> >> I actually tried to re-read what you wrote in your original reply and, I
>> >> must admit, I am not sure I understand. You say:
>> >>
>> >> [[[
>> >>                                In the functional-style syntax ontology
>> >> documents, only namespace declarations are expanded, and relative URIs
>> >> are not expanded. I think this is correct: we never say that the URIs of
>> >> ontology entities must be absolute. Thus, if someone actually creates
>> >> ontology entities with relative URIs, the functional-style syntax will
>> >> correctly capture this.
>> >>
>> >> Note that URIs have a well-defined identity. Therefore, a relative URI
>> >> provides a perfect way of identifying some ontology entity - that is, it
>> >> is a URI just like any other.
>> >> ]]]
>> >>
>> >> What I do not understand is your statement that 'relative URI [...] is a
>> >> URI just like any other'.
>> >>
>> >> Looking at the URI spec (I use the Apache version because it has nice
>> >> hyperlinks built in),
>> >>
>> >> http://labs.apache.org/webarch/uri/rfc/rfc3986.html#relative-ref
>> >>
>> >> says that a relative URI expresses a 'real' URI (they call it target URI
>> >> there) using the references resolution mechanism in
>> >>
>> >> http://labs.apache.org/webarch/uri/rfc/rfc3986.html#reference-resolution
>> >>
>> >> which also says that
>> >>
>> >> [[[
>> >> relative references are only usable when a base URI is known. A base URI
>> >> must be established by the parser prior to parsing URI references that
>> >> might be relative.
>> >> ]]]
>> >>
>> >> According to
>> >>
>> >> http://labs.apache.org/webarch/uri/rfc/rfc3986.html#base-retrieval
>> >>
>> >> [[[
>> >> If no base URI is embedded and the representation is not encapsulated
>> >> within some other entity, then, if a URI was used to retrieve the
>> >> representation, that URI shall be considered the base URI.
>> >> ]]]
>> >>
>> >> Ie, a relative URI is not a 'URI just like any other', it makes sense
>> >> only in term of a base URI (which can be, of course, a file:/// URI of
>> >> the encapsulating file). This is not dependent on the syntax used.
>> >>
>> >> As a consequence, I believe that a relative URI in a FS syntax document
>> >> should be viewed as an abbreviation for a full URI with the file name or
>> >> retrieval URI of that FS document serving as a base. This is by no means
>> >> different from what happens in the M'ter syntax, OWL/XML, RDF/XML, or
>> >> Turtle.
>> >>
>> >> If all this is true, then introducing a @base to the FS and the M'ter
>> >> syntax does make sense if we want a final control over the exact
>> >> interpretation of the relative URI-s in the FS.
>> >>
>> >> (Alternatively, we could say that the base URI for a relative URI is the
>> >> Ontology URI if it exists, but I am not 100% sure that mixing
>> >> functionalities on that level is wise.)
>> >>
>> >> Cheers
>> >>
>> >> Ivan
>> >>
>> >>
>> >> Boris Motik wrote:
>> >>> Hello,
>> >>>
>> >>> The main difficultly I see is that turning base off on a particular subset of the document might
>> >> not be straightforward. You might
>> >>> need to turn base off in case you really want to use relative Uris to identify entities. Now in
>> >> XML, this is not difficult because
>> >>> any element can contain xml:base; hence, you can always locally turn xml:base off by placing
>> >> xml:base on the element with its value
>> >>> equal to some opaque URI. To simulate that, we'd need to be able to enclose arbitrary subsets of
>> >> the FS document into a local base
>> >>> declaration. It is doable, but I wonder whether it is worth the trouble.
>> >>>
>> >>> Note that in FS you can have a default namespace. Although this is not identical to xml:base (for
>> >> example, this default namespace is
>> >>> not affected by the physical URI of the document, and namespace expansion is by simply pasting the
>> >> prefix rather than using URI
>> >>> resolution algorithm), it achieves a similar goal as xml:base: you can write most of the URIs in
>> >> the document without prefixing them
>> >>> with any namespace.
>> >>>
>> >>> Please let me know if you consider this insufficient.
>> >>>
>> >>> Regards,
>> >>>
>> >>>   Boris
>> >>>
>> >>>> -----Original Message-----
>> >>>> From: Ivan Herman [mailto:ivan@w3.org]
>> >>>> Sent: 24 November 2008 11:49
>> >>>> To: Boris Motik
>> >>>> Cc: 'Alan Ruttenberg'; 'W3C OWL Working Group'
>> >>>> Subject: Re: relative uri references
>> >>>>
>> >>>> Boris,
>> >>>>
>> >>>> did we ever consider adding a 'base', like 'xml:base', to the functional
>> >>>> and the m'ter syntaxes?
>> >>>>
>> >>>> Note that this is the only difference, for example, between the turtle
>> >>>> specification as a team submission[1] and the earlier turtle
>> >>>> specification: the former introduced a @base directive (alongside the
>> >>>> @prefix ones). It might make sense to do this for the FS and M'Ter.
>> >>>>
>> >>>> Just a thought
>> >>>>
>> >>>> Ivan
>> >>>>
>> >>>>
>> >>>>
>> >>>> [1] http://www.w3.org/TeamSubmission/turtle/
>> >>>>
>> >>>> Boris Motik wrote:
>> >>>>> Hello,
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> In the RDF syntax, the resolution of URI references is governed fully by
>> >>>>> the underlying RDF format. For example, if you are working with RDF/XML,
>> >>>>> then the RDF parser should use xml:base. In addition, the XML parser
>> >>>>> will expand any XML entities as well. There is no equivalent of the
>> >>>>> Namespace declaration in the RDF syntax.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> In the XML Syntax, there are no Namespace declarations either. Again,
>> >>>>> you have is xsd:base for relative URIs, and this is explicitly mentioned
>> >>>>> in the document. Furthermore, we don't need a specific URI abbreviation
>> >>>>> mechanism is because XML Syntax ontology documents can use XML entities
>> >>>>> for abbreviation of long URIs.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> The functional-style syntax and the Manchester syntax, in contrast,
>> >>>>> cannot rely on other specifications (such as RDF of XML) for
>> >>>>> abbreviation and expansion of URI references, so they need their own URI
>> >>>>> resolution mechanisms. In the functional-style syntax ontology
>> >>>>> documents, only namespace declarations are expanded, and relative URIs
>> >>>>> are not expanded. I think this is correct: we never say that the URIs of
>> >>>>> ontology entities must be absolute. Thus, if someone actually creates
>> >>>>> ontology entities with relative URIs, the functional-style syntax will
>> >>>>> correctly capture this.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Note that URIs have a well-defined identity. Therefore, a relative URI
>> >>>>> provides a perfect way of identifying some ontology entity - that is, it
>> >>>>> is a URI just like any other.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Hence, it seems to me that we don't really need to say anything more
>> >>>>> than what we've already said. We might only introduce additional
>> >>>>> clarification into the XML Syntax document about relative URIs: we might
>> >>>>> say that if you want to store such URIs, then you should explicitly turn
>> >>>>> xml:base off on the element whether you are doing so; otherwise, your
>> >>>>> relative URIs will accidentally be resolved against the xml:base and
>> >>>>> that wopuld lead to problems. You can turn this resolution off by
>> >>>>> placing on the element an xml:base with some opaque URI.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Regards,
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>             Boris
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> ------------------------------------------------------------------------
>> >>>>>
>> >>>>> *From:* public-owl-wg-request@w3.org
>> >>>>> [mailto:public-owl-wg-request@w3.org] *On Behalf Of *Alan Ruttenberg
>> >>>>> *Sent:* 24 November 2008 06:05
>> >>>>> *To:* W3C OWL Working Group
>> >>>>> *Subject:* relative uri references
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Do we not  have to say how these are resolved in the functional and
>> >>>>> manchester syntax, and might it not be best to explicitly say so for all
>> >>>>> syntaxes?
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> -Alan
>> >>>>>
>> >>>> --
>> >>>>
>> >>>> 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
>> >>>
>> >> --
>> >>
>> >> 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
>> >
>>
>> --
>>
>> 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 Monday, 24 November 2008 16:07:55 UTC