Re: ACTION on ALL - FPWDs

Hi all,

A few more comments on the profiles ontology, which I hadn't time to 
write down before.

The last paragraph of the introduction mentions:

"|Base Specifications| (a Standard not profiling any other Standard)"

However, the definition and the ontology indicate that BaseSpecification 
is a subClass of Profile:

https://w3c.github.io/dxwg/profilesont/#Class:BaseSpecification

The ontology goes further to indicate a cardinality restriction, 
indicating that BaseSpecifications won't be associated with any Profile 
through the 'isProfileOf' relationship:

:BaseSpecification rdf:type owl:Class ;
                    rdfs:subClassOf :Profile ,
                                    [ rdf:type owl:Restriction ;
                                      owl:onProperty :isProfileOf ;
                                      owl:maxCardinality "0"^^xsd:nonNegativeInteger
                                    ] ;
                    rdfs:label "Base Specification" ;
                    skos:definition "A specification that defines all implementation constraints, without applying constraints on usage of another specification"@en ;
                    skos:usageNote "This may not be a useful class: documents of any specification can be regarded as a trivial profile, so applications only need to be concerned with Profile conformance"@en .

I know this is representing 'trivial profiles', as any spec can be a 
profile of itself. However, I think we should make clearer the 
'differentiae' between Standard/BaseSpecification/Profiles. I know that 
there have been lots of discussions on this and, moreover, that the note 
indicates that the class might not be useful.

So, I suggest we add an issue in github to address this discussion and 
that the FPWD points to this new issue to allow for further comments.

Thanks,

Alejandra


On 13/11/2018 18:26, Makx Dekkers wrote:
> All,
>
> My apologies for coming in late with comments.
> I do have some issues with the Profiles Ontology at https://w3c.github.io/dxwg/profilesont/, mainly with the definitions.
>
> 1. several definitions are substitutions in the template "A <Domain> <property label> <Range>" (e.g. "A dct:Standard has a Profile") which is not really helpful, as it makes the definitions circular (e.g. hasProfile, hasResource, isProfileOf etc.). Others still use the same words: e.g. property hasRole "Functional role of an Resource"; hasResourceRole "The role that an Resource plays". Terms like "functional", "role" and "Resource" need to be explained. Actually, from the definitions of hasRole and hasResourceRole, it is not immediately clear what the difference is.
>
> 2. Other terms that should be explained are "aspect" (in the definition of Resource Descriptor), "artifact (resource)" (in the definition of hasArtifact) and "implementing resource object" (in the Usage Note for hasArtifact).
>
> 3. Not all definitions use the same style, e.g. some have "A ..", other have "The ...", still others do not start with an article, and the definition of hasToken starts with "A property for ...". This should be made consistent.
>
> 4. The usage note of Resource Descriptor (as I wrote in GitHub, I think this is a really bad name) puts constraints (using "must" twice) on the way it is to be implemented. It might be better to formulate this as suggestions rather than obligations, e.g. "the formalism used can be expressed using dct:format and any adherence to a dct:Standard can be expressed using dct:conformsTo to allow for machine mediation. For human understanding, its purpose can be expressed via a relation hasRole to a ResourceRole".
>
> 5. Dublin Core terms are sometimes given as dct: and sometimes as dcterms:.
>
> 6. The document needs a spelling/grammar check. There are broken sentences (e.g. "Base Specifications or Profiles can have Resource Descriptors associated with them that defines implementing rules for the it"), misspellings ("GeoDCAt", "RDf", "StatDTAC-AP", "available", "summarises") and singular/plural errors (A vocabulary .. are provided").
>
> I tend towards voting -1 if those issues, in particular 1 and 2 above, are not addressed, as I think these issues make the document hard to understand for an outside audience. However, because I am late with my comments, I can vote -0 if people think these are all minor issues that can be repaired in 2PWD.
>
> I'll vote +1 on the https://w3c.github.io/dxwg/conneg-by-ap/.
>
> Makx.
>
>
> -----Original Message-----
> From: Karen Coyle <kcoyle@kcoyle.net>
> Sent: 11 November 2018 16:35
> To: public-dxwg-wg@w3.org
> Subject: ACTION on ALL - FPWDs
>
> All,
>
> We have two documents that are ready to be issued as First Public Working Drafts,[1] [2]  and we want to promote them to this at the meeting on November 13.[3] The ACTION on everyone is to READ these documents and let us know IMMEDIATELY if you see a serious problem that would keep either of these from being published. Remember that a FPWD is a DRAFT and that anything can change in future drafts. The purpose of the draft is to solicit comments from the community on the direction of the work.
>
> You can also comment on the content of the drafts where you see the need for modifications to future drafts, and we will create github issues and discuss these, but these comments will not delay the FPWD.
>
> We will take a consensus vote on these at the meeting. If you are sending regrets, please also let us know how you would vote on these drafts:
>
> +1 issue as FPWD
> 0 abstain (but don't object)
> -1 object (and give your reason in enough detail that it can be addressed)
>
> kc
> [1] https://w3c.github.io/dxwg/conneg-by-ap/
> [2] https://w3c.github.io/dxwg/profilesont/
> [3] https://www.w3.org/2017/dxwg/wiki/Meetings:Telecon2018.11.13
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234 (Signal)
> skype: kcoylenet/+1-510-984-3600
>
>