Re: NEW DRAFT: Documentation and OA/OAX

It is not a asbsolute requirement in W3C that a single namespace
corresponds to a single document. For instance, in PROV, we moved from
having separate namespaces to using http://www.w3.org/ns/prov# across the
different documents PROV-O and PROV-DM.

It does bring it's own set of worries, such as if you resolve
http://www.w3.org/ns/prov# for RDF/XML, you only get the PROV-O terms, and
not PROV-AQ terms like prov:hasProvenance. In PROV, we intend to present a
'merged' ontology when you resolve the namespace, with the standalone
ontologies reachable from the different documents. The HTML browser gets a
landing page pointing to the different documents; this landing page and owl
can be updated independently of recommendation track (for instance to fix
syntactic errors or keep up with technical OWL spec changes).

Some of these challenges disappear if you end namespace with a / rather
than #, so individual terms can redirect to correct spec/owl.

That said, I agree that the current split is not very ideal ; but I am not
sure about going for a single document. I agree with Jacco in that a simple
and straight forward 'core' specification makes it much more likely for the
standard to be picked up, understood and used.  It is a bit of the beauty
of the current OA spec, in my view, and I think several things could be
moved out of the current "core".

So I would generally not prefer a big, merged document. Is that what you
are proposing? I would not mind a single namespace though.

The OAX could be made more of an "OA Expanded" rather than "OA Extended";
showing the preferred way to do common scenarios such as CSS styling, sets,
HTTP headers and other more "complex" structures that perhaps do not need
to be in the core. With this I would downgrade the OAX role as a sandbox.
Such new features should be in additional mini specs before being formally
added to OAX.

I would not argue for a CSS2 kind of modular splitting.

Another alternative is however to do a multipage split, so you get
"chapters" that are not as independent as separate specs, but more modular
than the single HTML. Many do however like to download and print, and this
could be tricky unless a "all in one" alternative version is made available.

On Thu, Nov 8, 2012 at 9:11 PM, Robert Sanderson <azaroth42@gmail.com>
wrote:
>
> Dear all,
>
> With the recent additions and modifications to the data model, as editors
we
> feel that the current split of the specification using OA/OAX as a
dividing
> line is no longer sustainable or useful. Although it is our prerogative as
> editors to choose the means we feel most appropriate to convey the
consensus
> of the community group, we of course value all of your feedback and hence
> would like to discuss the issue openly.
>
> The proposed structure for the specification is to follow the approach of
> many larger specifications and have a table of contents page, which links
to
> different chapters and appendices.
>
> The Table of Contents would look something like:
>
> 1. Annotation Basics
> 1.1 Body and Target
> 1.1.1 Typing of Resources
> 1.2 Provenance
> 1.2.1 Agents
> 1.3 Motivations
> 1.4 Style
>
> 2. Specifiers
> 2.1 Selectors
> 2.1.1 Fragment Selector
> 2.1.2 Text Selectors
> 2.1.3 Image Selectors
> 2.2 State
> 2.2.1 TimeState
> 2.2.2 RequestState
> 2.3 Scope
>
> 3. Cardinality and Structure
> 3.1 Annotations without a Body
> 3.2 Multiple Bodies and Targets
> 3.3 Semantic Structures
> 3.3.1 Choice
> 3.3.2 Set/Composite
> 3.3.3 List
> 3.3.4 Application to Body, Target and Specifiers
>
> 4. Publishing Model
> 4.1 Serialization formats
> 4.1.1 Named Graphs
> 4.2 Inline Resources
> 4.3 Equivalency of Resources
>
> Appendix A: Provenance Ontology Mapping
>
> This and previous discussion brings into question the utility of the
OA/OAX
> split, and we propose to collapse them to a single namespace for the
> following reasons:
>
> * The current reasoning behind the split is not well understood, or
adhered
> to in decisions. For example, Choice/Set/List fulfils the requirements for
> OA, yet the general feeling is that it should be in OAX. The same arguably
> applies to Style.
> * The OAX ontology tends to be seen as a dumping ground or staging area,
> which undermines the approach
> * OAX was also intended to allow documentation for the extension to be
> updated separately from the core, however this would be impossible with
the
> above layout. Two separate specifications with independent evolutions, yet
> inextricably linked, is not a common pattern for W3C documents and likely
> would be difficult in a Working Group environment rather than Community
> Group. We feel that the documentation issue is better solved by a layout
> like that described above
> * A single ontology would make the modelVersion issue much easier to deal
> with
> * It’s confusing to have multiple, very similar namespaces and to remember
> which one is which.
> * It can always be re-introduced later
>
> Thanks for your feedback on this!
>
> Rob & Paolo

-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester