Re: relative uri references

Hi Boris,

I want to reiterate my concern about the issue of relative URIs in
imports. Having things defined so that these can not possibly be round
tripped would be a real problem.

-Alan

On Mon, Nov 24, 2008 at 11:14 AM, Boris Motik
<boris.motik@comlab.ox.ac.uk> wrote:
> Hello,
>
> I think this is actually much better. Given that we can't have relative IRIs anyway, there is no point in not having the default
> prefix defined. Hence, I've changed the spec according to your suggestion.
>
> Regards,
>
>        Boris
>
>> -----Original Message-----
>> From: Peter F. Patel-Schneider [mailto:pfps@research.bell-labs.com]
>> Sent: 24 November 2008 15:39
>> To: ivan@w3.org
>> Cc: boris.motik@comlab.ox.ac.uk; alanruttenberg@gmail.com; public-owl-wg@w3.org
>> Subject: Re: relative uri references
>>
>> 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:22:48 UTC