RE: Comments on the Profiles Ontology FPWD from Leslie Sikos

Dear Leslie,

Thanks for your considered response.

I have attempted to create individual Issues (in our GitHub Issue tracker) for you points below but for several I've found I need more clarification and I've asked questions. For one I have created an Issue [7] and for another expanding PROF wiki documents. Please could you clarify the points I've raised questions for and then I will create additional Issues, if there's still work to be done.

Thanks,

Nick  


> The concept “Profile” has no clear machine-interpretable definition (only a human-readable description), and software agents can interpret nothing more from the ontology file that it is a subclass of dct:Standard.

I'm not sure I follow. If a software agent was to dereference a Profile's URI and be served with RDF data according to this ontology, it would likely receive information about both the relation of the Profile to any other Profiles of Standards (via prof:isProfileOf) and also parts that constitute the Profile (prof:hasResource properties indicating individuals of class prof:ResourceDescriptor). It may also receive some other sundry metadata.

For example. Considering the demonstration Profile (no resolving URI) "CSIRO ePublish Dublin Core Application Profile" [1], the RDF profile information (in [2]) indicates that:

* <http://test.linked.data.gov.au/test/def/CSIRO-ePub-DCAP> prof:isProfileOf <http://dublincore.org/documents/2012/06/14/dcmi-terms/> 
  * i.e. that this Profile is a profile of Dublin Core Terms (vocabulary) as identified by its namespace URI

* <http://test.linked.data.gov.au/test/def/CSIRO-ePub-DCAP> prof:hasResource _:1 , _:2 , _:3 , _:4 .
  * i.e. that there are four resources described for the Profile (given in the RDF file) and they are ResourceDescriptors with "Specification", "FullConstraints", "FullConstraints" and "Guidance" roles. ResourceDescriptor details indicate that the two resources with role "FullConstraints" differ in their formats (text/plain & text/turtle) but adhere to the same constraint language (Dublin Core's Description Set Profile)

Have I understood your point here? Are you perhaps expecting to see instance data within the ontology, not just, as you put it, the vocabulary to which instance data should conform?


> There are specific ontologies for particular resource types, so the need for defining general resource descriptors has to be justified. When referring to data exchange situations, it has to be specified what exactly can be captured as contextual information.

The Resource Descriptor class is an association class associating Profile class instances with resources (artifacts, such as files) while allowing for a few other, in the minds of the authors, significant bits of information, namely resource format (dct:format), any standards the resource conforms to (dct:conformsTo) and a role that the resource plays (prof:hasRole indicating a role:ResourceRole).

Are you suggesting that we use typing systems such as the DCMI Types Vocabulary [3] but perhaps more extensive ones to indicate resource types, perhaps such as this (building on an example in [2]):

_:3
    a                               prof:ResourceDescriptor ;
    rdfs:label                "Full constraints in DSP constraint language" ;
    dct:conformsTo    <http://dublincore.org/documents/2008/03/31/dc-dsp/> ; # the constraints conform to the DSP spec
    dct:format             <https://w3id.org/mediatype/text/plain> ; # it's in plain text format 
    prof:hasRole         role:FullConstraints ;
    prof:hasArtifact   <http://test.linked.data.gov.au/test/def/CSIRO-ePub-DCAP/constraints-dcap-syntax.txt> ;
    dct:type                <http://purl.org/dc/dcmitype/Text> .
    
We can't directly class the Resource Descriptor as being of a type as it's only an association class and doesn't directly represent the artifact but links to it via prof:hasArtifact.

Again, I don't think I've fully grasped the nub of your comment here!


> Relationship with standard and de facto standard vocabularies and ontologies, such as Dublin Core, PROV-O, and SKOS, should be defined (more) clearly in the specification and formally in the ontology file itself. For example, the range of :isTransitiveProfileOf is defined to be dct:Standard—much more similar definitions would be needed.

Alignments of PROF with other ontologies are given in the section Alignments [4] but it's far from complete. See the alignments we are working on in [5]. In particular, there is an emerging PROV-O mapping. A SKOS mapping has been requested by others too but not a Dublin Core mapping. For the moment. I've added fairly trivial tables to [5] for SKOS and Dublin Core. Note that PROF already makes use of several Dublin Core properties and a class (dct:format, dct:conformsTo & dct:Standard) and that we expect that there's little other mappings to DCT likely to emerge, but we could be wrong, hence the table addition in [5] to prompt us to investigate further.

You mention that it's good that range value for prof:isTransitiveProfileOf is given and that we should indicate more but for which properties? The PROF property list (those that it declares only) with notes on ranges is:

prof:hasResource - range given as prof:ResourceDescriptor
prof:isProfileOf - range given as dct:Standard
prof:isTransitiveProfileOf - range given as dct:Standard
prof:hasToken - range given as xsd:token
prof:hasArtifact - no range given
prof:hasRole - range given as skos:Concept
prof:isInheritedFrom - range given as prof:Profile

So, where do you suggest we include more range values? Only prof:hasArtifact is missing a range and it’s a property for indicating any resource described by a prof:ResourceDescriptor so it's hard to see how to sensibly restrict its range.


> By reading the specification, the relationship with SHACL remains somewhat unclear, and it is mentioned mainly in the context of implementations only, while the PROF ontology aims at setting constraints as well.

I have created the Issue #721 [7] and here is text I have added to the Issue as a comment.

PROF does not set any constraints itself; it only presents a way of describing Profile relations (to Standards and perhaps other Profiles) and profile components (via prof:ResourceDescriptors). PROF leaves to constraint languages in general, of which SHACL is one, to specify particular constrains for particular profiles.

An example: If Profile X of Standard Y imposed additional constraints on it and those constraints were presented using SHACL, you may have prof:Profile and prof:ResourceDescriptor RDF like this:

<Profile_X>
    rdf:type prof:Profile ;
    rdfs:label "Profile X" ;
    prof:isProfileOf <Standard_Y> ;
    prof:hasResource _:1 .

_:1
    rdf:type prof:ResourceDescriptor ;
    rdfs:label                "Profile-only constraints in SHACL" ;
    dct:conformsTo    <http://www.w3.org/ns/shacl#> ; # SHACL
    dct:format             <https://w3id.org/mediatype/text/turtle> ;
    prof:hasRole         role:ExtensionConstraints ;  # these constraints are in addition to the Standard Y constraints and does not include them
    prof:hasArtifact   <an_rdf_file_on_the_web.ttl> .

So <an_rdf_file_on_the_web.ttl> here contains SHACL Shapes graphs for use with this Profile but the profile description itself, this RDF, does not.

Does this answer your question? Please contribute to the Issue in place if it does not.

> The namespace of PROF... gives a 404 error
Yes, this is a known issue that we are trying to fix, sorry! A redirect should be in place in a day or two.


[1] https://github.com/CSIRO-enviro-informatics/csiro-epub-dcap

[2] https://github.com/CSIRO-enviro-informatics/csiro-epub-dcap/blob/master/profile.ttl 
[3] http://dublincore.org/documents/2000/07/11/dcmi-type-vocabulary/ 
[4] https://w3c.github.io/dxwg/profilesont/#alignments 
[5] https://github.com/w3c/dxwg/wiki/PROF-Alignments-and-crosswalks 
[6] https://w3c.github.io/dxwg/profilesont/#specification 
[7] https://github.com/w3c/dxwg/issues/721 



-----Original Message-----
From: Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au> 
Sent: Thursday, 31 January 2019 11:51 AM
To: public-dxwg-comments@w3.org
Subject: [ExternalEmail] Comments on the Profiles Ontology FPWD from Leslie Sikos

Please find my comments and suggestions to the PROF Ontology below.

The ontology file is syntactically correct. The ontology features a DL expressivity of ALIN(D), so no complex relationships are defined for the concepts of the ontology, and therefore it almost looks like a controlled vocabulary only rather than a fully-featured ontology.

The concept “Profile” has no clear machine-interpretable definition (only a human-readable description), and software agents can interpret nothing more from the ontology file that it is a subclass of dct:Standard.

There are specific ontologies for particular resource types, so the need for defining general resource descriptors has to be justified. When referring to data exchange situations, it has to be specified what exactly can be captured as contextual information.

Relationship with standard and de facto standard vocabularies and ontologies, such as Dublin Core, PROV-O, and SKOS, should be defined (more) clearly in the specification and formally in the ontology file itself. For example, the range of :isTransitiveProfileOf is defined to be dct:Standard—much more similar definitions would be needed.

By reading the specification, the relationship with SHACL remains somewhat unclear, and it is mentioned mainly in the context of implementations only, while the PROF ontology aims at setting constraints as well.

The namespace of PROF, https://www.w3.org/ns/dx/prof/, is a symbolic link only (gives a 404 error in the browser). The best practice is to point the namespace URI to the ontology file itself (for semantic agents), which in this case is https://www.w3.org/TR/2018/WD-dx-prof-20181218/profilesont.ttl, and to a dedicated webpage describing the ontology (for browsers), using content negotiation on the web server; and optionally dedicated webpages created for each term of the ontology with addresses concatenated in the form namespace URI + term + optional trailing slash.

Kind Regards

Leslie Sikos

Received on Thursday, 31 January 2019 10:52:25 UTC