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

Please see inline.

> From: Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au]
> Sent: Friday, April 28, 2017 1:14 AM
> 
> Thanks Francois.
> 
> As you note, we were very conservative and marked everything new as 'at
> risk'. On one hand this is an obvious call since none of the new things have
> two implementations (yet - working on that today in fact at Geoscience
> Australia). I was also under the impression that this was in fact your
> recommendation.

Oops, I am sorry about that. I should have been much clearer. This is not what I meant to recommend!


> However, as you note, if all the things that are marked 'at risk' were ripped
> out of the rec, it would be a much slimmer document, and the Principles and
> Overview section would need to be re-written and the diagrams re-drawn.
> So perhaps I went too far.
> 
> Backing right off, new elements that were included quite late and have been
> less tested are
> 
> :hasXSDDuration
> 
> which was added in response to a comment received in wide review
> 
> :MonthOfYear
> :monthOfYear
> 
> which were included in response to a request from the QB4ST group, and
> 
> :hasTime
> 
> was a response to a frequently mentioned need for 'generic predicates, but
> has not been exercised much
> 
> All the rest of the new stuff follows logically from the main requirement - to
> generalize the treatment of temporal reference systems. And even if the
> corpus of evidence of external use is small, it is not zero. Furthermore, a solid
> argument can be made that dropping any would compromise the integrity of
> the parts for which we do have evidence of use.
> 
> I will wind back the FAR labelling to just these elements. OK?

Yes, I believe it would be much better!

Note the sentence that talks about features at risk should appear in the Status of This Document section, not in a separate appendix. Perhaps something along the lines of "The :MonthOfYear class and the :monthOfYear, :hasXSDDuration, and :hasTime properties were included recently in response to comments received on the ontology. They are marked as features at risk".

Thanks,
Francois.


> 
> Simon
> 
> Simon J D Cox
> Research Scientist
> Land and Water
> CSIRO
> E simon.cox@csiro.au T +61 3 9545 2365 M +61 403 302 672
>    Physical: Reception Central, Bayview Avenue, Clayton, Vic 3168
>    Deliveries: Gate 3, Normanby Road, Clayton, Vic 3168
>    Postal: Private Bag 10, Clayton South, Vic 3169
> people.csiro.au/C/S/Simon-Cox
> orcid.org/0000-0002-3884-3420
> researchgate.net/profile/Simon_Cox3
> 
> ________________________________________
> From: Francois Daoust <fd@w3.org>
> Sent: Friday, 28 April 2017 12:32 AM
> To: Cox, Simon (L&W, Clayton); chris.little@metoffice.gov.uk
> Cc: public-sdw-wg@w3.org; phila@w3.org
> Subject: RE: OWL-Time ready to go - except for styling issues?
> 
> Hi Simon,
> 
> > From: Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au]
> > Sent: Wednesday, April 26, 2017 10:30 PM
> >
> > OK - fixed those nits. Now just waiting for Francois' comment on how I
> > marked the Features At Risk.
> 
> Hmm, you seem to have marked all features introduced in this version of the
> spec and that were not in the old 2006 version as being at risk. This strikes me
> as strange. Here, we're talking about 50% of the classes and roughly 25% of
> the properties. That seems a lot. It means you would be ready to publish a
> Proposed Recommendation that would be vastly different from the current
> draft in that most of its normative content could be removed. Don't we have
> a clearer understanding of the new classes and properties that people are
> effectively starting to use?
> 
> Features at risk are usually advanced features in a specification which, when
> dropped, do not affect the whole spec. The Time Ontology without
> "TemporalDuration" and/or "TemporalPosition" seems a completely
> different spec to me. Note I do not know whether the Director would feel
> the same, it may be ok. It's just that I was rather only expecting a couple of
> properties to be flagged as at risk, at most.
> 
> Francois
> 
> >
> > Simon J D Cox
> > Research Scientist
> > Land and Water
> > CSIRO
> > E simon.cox@csiro.au T +61 3 9545 2365 M +61 403 302 672
> >    Physical: Reception Central, Bayview Avenue, Clayton, Vic 3168
> >    Deliveries: Gate 3, Normanby Road, Clayton, Vic 3168
> >    Postal: Private Bag 10, Clayton South, Vic 3169
> > people.csiro.au/C/S/Simon-Cox
> > orcid.org/0000-0002-3884-3420
> > researchgate.net/profile/Simon_Cox3
> >
> > ________________________________________
> > From: Little, Chris <chris.little@metoffice.gov.uk>
> > Sent: Thursday, 27 April 2017 1:04 AM
> > To: Cox, Simon (L&W, Clayton); fd@w3.org
> > Cc: public-sdw-wg@w3.org; phila@w3.org
> > Subject: RE: OWL-Time ready to go - except for styling issues?
> >
> > Simon, Francois
> >
> > Thank you for all the hard work while I disappeared for a family holiday. The
> > document now feels concise, substantial and rigorous!
> >
> > A. I have now read closely the Editors' Draft dated 25 April and found only 4
> > very minor typos which hopefully Francois can fix, and not really a big deal if
> > cannot:
> >
> > 4.2.15 has XSD duration: definition repeats 'xsd:duration' as both plain text
> > and as a link. I suggest that the plain text is deleted.
> >
> > 4.3 Datatypes: the trailing pipe/vertical bar should be removed (unless a
> > software issue).
> > 4.4 Individuals: the trailing pipe/vertical bar should be removed (unless a
> > software issue).
> >
> > Annex D 5.39 tempral -> temporal
> >
> > B. The external links all seem to work, and the dbpedia.org links all work
> with
> > https as well as http, so they could be changed if W3C policy prefers.
> >
> > C. The UK government links have to stay as http, as https fails 504. A UK
> > government issue.
> >
> > D. All the OGC links fail with https with SSL record too long. Also, the link
> from
> > Example 5.3 (http://www.opengis.net/def/uom/ISO-8601/0/Gregorian)
> still
> > re-directs to the Australian SISSVOC site. These are OGC issues.
> >
> > HTH, Chris
> >
> >
> > > -----Original Message-----
> > > From: Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au]
> > > Sent: Wednesday, April 26, 2017 12:21 AM
> > > To: fd@w3.org; public-sdw-wg@w3.org; phila@w3.org
> > > Cc: Little, Chris
> > > Subject: 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 Friday, 28 April 2017 08:11:54 UTC