[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Question for the TC about resolving the OpenDocument v1.2 namespace URIs [#11216]
This topic was on the agenda for our TC call yesterday. I'm sorry you were not able to participate. In the call we agreed that content negotiation was the preferred approach, but if that was not possible on the OASIS servers currently, that the preferred alternative was the human-readable namespace resolution page. None of the meeting participants were able to point to a case where an application relied on resolving the URI to an ontology document. One observation was that if such an application did exist we would have heard about it by now since the URI has failed to resolve to anything for a couple of years now.
I'm happy to add this topic to the agenda for our next TC call if you feel strongly about resolving to the OWL file and want the TC to reconsider.
<email@example.com> wrote on 04/28/2014 05:33:27 PM:
> From: Michael Stahl <firstname.lastname@example.org>
> To: Robin Cover <email@example.com>, OASIS OpenDocument TC List
> Cc: Rob Weir <firstname.lastname@example.org>
> Date: 04/28/2014 05:28 PM
> Subject: Re: [office] Question for the TC about resolving the
> OpenDocument v1.2 namespace URIs
> Sent by: <email@example.com>
> hello Robin,
> sorry for taking so long to reply.
> On 14/04/14 16:56, Robin Cover wrote:
> > OpenDocument TC Members,
> > On the matter of DNS+HTTP resolution of the two URI references
> > (identifying namespace names) as mentioned earlier , I have fixed the
> > OASIS Web server configuration so that the URIs now resolve. However,
> thanks for your work on this!
> > my investigation into recommended server configurations for
> > "semantic-web" style NS URIs [often the "hash" type] also prompts an
> > additional question for the TC members:
> > Do you have a preference as to whether the two URI references resolve to
> > A or B ?
> > A) directly to the formal OWL ontology files (.owl)
> > B) indirectly, via the existing XML namespace documents
> > Documentation available to me on this topic reflects varying
> > professional opinion, as does past/current practice with respect to
> > resolution that best serves the interests of the users, whether human
> > agents or machines .
> > If you think OpenDocument v1.2 implementations involve semantic web
> > applications that directly make use of the two namespace URIs -- e.g.,
> > where a machine defeferences the URI so as to fetch and process the OWL
> > (RFD/XML) source file -- then it may be preferable to implement "A" above
> > If you think the XML namespace name URIs are typically (or exclusively)
> > used by human agents, e.g., readers who view the prose OpenDocument
> > specifications and click on the two corresponding hyperlinks from the
> > spec cover page, then it may be preferable to implement "B", as is
> > currently done
> > As far as I know, I can implement "A" or "B" using server directives
> > currently under our control, but I need to know which you prefer.
> all the documents that i've read from the W3C indicate that it must be
> possible to deliver the OWL ontology files if the client explicitly
> requests it via the "Accept: application/rdf+xml" header, i.e., this is
> a hard requirement... and if content negotiation is not currently
> possible on the OASIS server, then that means the URI should directly
> resolve to the OWL ontology.
> > d) http://www.w3.org/2005/sparql-results#
> ^ interestingly, although this one is related to RDF it is actually
> not defined by a RDF schema or ontology but by XML Schema.
> Michael Stahl | Software Engineer
> Platform Engineering - Desktop Team
> Red Hat
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> Red Hat GmbH, http://www.de.redhat.com/ Sitz: Grasbrunn,
> Handelsregister: Amtsgericht München, HRB 153243
> Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey,
> Charles Peters
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at: