RE: OWL-Time ready to go - except for styling issues?

Thank you Francois

I have added a note in the SOTD section about the features at risk. 
All FAR are indicated clearly in the tabulations. 
I also added an Exit Criteria appendix. 

See https://github.com/w3c/sdw/pull/749 

Hope this satisfies your concerns. 

Simon 

-----Original Message-----
From: Francois Daoust [mailto:fd@w3.org] 
Sent: Friday, 21 April, 2017 16:58
To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; public-sdw-wg@w3.org; phila@w3.org
Cc: chris.little@metoffice.gov.uk
Subject: Re: OWL-Time ready to go - except for styling issues?

Hi Simon,

Le 21/04/2017 à 07:50, Simon.Cox@csiro.au a écrit :
> Colleagues –
>
>
>
> I’ve done the work requested in yesterday’s vote to advance OWL-Time 
> to the next stage, specifically
>
> 1.      I added some material in section 1, to address a comment
> received during side review, (briefly) positioning OWL-Time relative 
> to ISO 8601 and XML Schema temporal datatypes – ISSUE-158 ;
>
> 2.      The list of external implementations has been moved from
> ‘Examples’ to a Wiki page
> https://www.w3.org/2015/spatial/wiki/OWL_Time_Ontology_adoption and 
> linked from an appendix
>
> 3.      A summary of the results of the wide review is provided on the
> Wiki
> https://www.w3.org/2015/spatial/wiki/Wide_Review#Disposition_of_issues

> _raised
> and linked from an appendix

Many thanks for preparing all of this!

Two more things that do not seem to have been discussed during the call:

- Possible *features at risk*, meaning classes, properties or sections that are in the spec but that could be dropped from it before publication of a Proposed Recommendation, e.g. because the group cannot provide implementation evidence. If you need to drop features that have not been identified as at risk, you would need to publish another Candidate Recommendation. "No feature at risk" is a good answer in this case, but I just want to make sure that you're aware of it.

- *Exit criteria* for the Candidate Recommendation phase. It is good practice to include them in the spec. For instance, see the Web Annotation Vocabulary:
http://www.w3.org/TR/2016/CR-annotation-vocab-20161122/#candidate-recommendation-exit-criteria


I doubt you need something as complex in your case. Essentially, the goal is to tell the Director what you consider will be enough evidence to advance the spec to Proposed Recommendation.

Typically, the document you called "OWL Time Ontology adoption" is what I would call an "implementation report":
https://www.w3.org/2015/spatial/wiki/OWL_Time_Ontology_adoption


... and exit criteria could probably be something as loose as "The group expects to request transition to Proposed Recommendation once it has reviewed datasets that have adopted the ontology and completed the implementation report" (with a link to it). This sentence should typically appear in the Status of This Document section.

DCAT's implementation report comes to mind for instance:
https://www.w3.org/2011/gld/wiki/DCAT_Implementations



> There are still some issues with styling and ReSpec – in particular, 
> there are two lists of References – one from the HTML file, the other 
> a subset of the ones I transferred to the config.js file.

I'll fix them as soon as I can and prepare the transition request (I'm traveling though, may take a few days). Some answers below in the meantime.

>
> (i)                 I don’t know why the ones from config.js aren’t all
> showing up – if that could be fixed, the set in the .html document 
> could be removed

The references in config.js only show up provided you reference them from the spec, using "[[REF]]" for an informative reference and "[[!REF]]" for a normative reference.


>
> (ii)               Anyway, the formatting of the ones that are showing
> up from config.js is incomplete – no editor names for example

I'll check and update as needed.


>
> (iii)             I understand that there is a central database of W3C
> documents at least. Since a lot of the citations are to those, it 
> would be better to enable the use of the central facility.

That database is called Specref:
http://www.specref.org/


It is already enabled. For instance, if you add "[[owl2-manchester-syntax]]" somewhere in the spec, the Manchester Syntax should appear in the list of references. Specref won't contain all the references you need though.


> Francois – can you help clean up these mechanics please?

Yes, will do.

Thanks,
Francois.

>
>
>
> Now I’ll get back onto SSN figures …
>
>
>
> Simon
>
>
>
> *Simon J D Cox *
>
> Research Scientist
>
> Environmental Informatics
>
> CSIRO Land and Water <http://www.csiro.au/Research/LWF>
>
>
>
> *E*simon.cox@csiro.au <mailto:simon.cox@csiro.au>*T*+61 3 9545 2365
> *M*+61 403 302 672
>
>    /Mail:/Private Bag 10, Clayton South, Vic 3169
>
> /   Visit: /Central Reception,//Research Way, Clayton, Vic 3168
>
> /   Deliver: /Gate 3, Normanby Road, Clayton, Vic 3168
>
> people.csiro.au/Simon-Cox <http://people.csiro.au/Simon-Cox>
>
> orcid.org/0000-0002-3884-3420 <http://orcid.org/0000-0002-3884-3420>
>
> researchgate.net/profile/Simon_Cox3
> <https://www.researchgate.net/profile/Simon_Cox3>
>
> github.com/dr-shorthair <https://github.com/dr-shorthair>
>
>
>
> *PLEASE NOTE*
>
> The information contained in this email may be confidential or 
> privileged. Any unauthorised use or disclosure is prohibited. If you 
> have received this email in error, please delete it immediately and 
> notify the sender by return email. Thank you. To the extent permitted 
> by law, CSIRO does not represent, warrant and/or guarantee that the 
> integrity of this communication has been maintained or that the 
> communication is free of errors, virus, interception or interference.
>
>
>
> /Please consider the environment before printing this email./
>
>
>
>
>

Received on Tuesday, 25 April 2017 23:21:43 UTC