Re: feedback on the drafts relating to profiles

Hi Paul,

Thanks for your comments. Here are some quick, off the top of my head responses and I've indicated where I've created GitHub Issues to address some of your points in more depth. Please feel free to respond to my characterisations of your issues or if I've missed any.


> I find the diagrams quite difficult to understand.
Created https://github.com/w3c/dxwg/issues/697


In short, the diagrams used are perhaps best described as OWL class and property diagrams, somewhat akin to UML class diagrams so they are neither ER or OO diagrams. They can't be as OWL/RDF is not an ER or an OO thing.

Similar diagrams are used in the recent SSN ontology: https://www.w3.org/TR/vocab-ssn/#overview-of-classes-and-properties, Figures 4+.

More traditional UML Class Diagram-style diagrams are used in the Time Ontology in OWL, see https://www.w3.org/TR/owl-time/#topology. These latter diagrams are created by the TopBraid tool. 

Do either of the SSN or TIME diagrams strike you as more understandable than these? Perhaps you could respond within the Issue I've created.


> ...the relationships between Standard and Profile
The diagram echoes the RDF here with prof:Profile being both a subClassOf dct:Standard and instances of prof:Profile being able to be related to dct:Standards (and therefor prof:Profiles which are dct:Standards) by prof:isProfileOf. The inverse property prof:hasProfile has recently been removed from the ontology as redundant.


> ... broken link...
Thanks, fixed.


> This describes a standard thus...
You said, "In this formulation, 'standard' is closer to 'namespace', and so I would expect a many-to-many relationship between standard and profile."

This is the case. No cardinality constraints are given for the property that relates prof:Profiles and dct:Strandards, prof:isProfileOf so one Profile can profile many Standards or Profiles and one Standard (or Profile) can be profiled by many Profiles.


> From my perspective, the most pressing issues with application profiles are:
> 1. we don't have a conventional way to document them yet
> 2. we don't have a conventional way to automatically validate data instances of application profiles (i.e. data which allegedly conforms to the constraints of a given application profile)
Your thought here then echo those of most of the Working Group!

The ontology provides a standard way to identify profiles (via URI), describe their relationships to Standards and other Profiles, and to describe their parts. This should constitute a "conventional way to document them".

Regarding 2.: you can imagine a method deriving from the structures of this ontology where code could find a Profiles' resource with prof:role Validation (and perhaps a particular formalism of a Validation resource, such as SHACL or similar) and then it could recurse up a isProfileOf hierarchy finding all similar resources. Then, joining all those resources together, data claiming conformance could be validated against all. This would both ensure data is valid to a Profile and it's dependencies and also potentially allow Profile implementors to only have to define their extensions on the things they profile, not the full set of constraints.

An example along these lines is currently being prepared for the Second Public Working Draft of the document and I've indicated its here: https://github.com/w3c/dxwg/issues/698



> ...my initial reaction to the ontology in general is that it is "too much ontology"
Can you please expand on this? The ontology only has 3 classes (Profile, ResourceDescriptor & ResourceRole - we have removed BaseSpecification) and only declares 8 properties, several of which are just variations on well-known properties (e.g. hadRole) so, in terms of classes and properties, we have a small ontology. Also, as I mentioned above, this ontology only does a couple of things (describes Profiles' relationships to Standards and other Profiles, and describes Profiles' parts).

Thanks,

Nick



On 26/1/19, 2:56 am, "Paul Walk" <paul@paulwalk.net> wrote:

    I'm hoping that you might get some useful feedback from those in the Dublin Core community who have a much better understanding of this area than I. In the meantime, I'll offer some general comments (these are personal, and are not meant to represent a 'DCMI view').
    
    # General comment 1:
    I'm glad that this continues to be explored. The Singapore Framework was pioneering in its day, but was probably developed a little too early. The importance of metadata application profiles is now more widely accepted, if not entirely understood, so I think any effort to develop a better understanding of this is valuable.
    
    # Diagrams - relationships
    I find the diagrams quite difficult to understand. I think I'm unclear whether the diagrams represent entity relationships or object-oriented-hierarchies. These seem to be mixed together - for example the relationships between Standard and Profile. I guess it's not necessarily invalid for these to be mixed in this way, but I find it unusual and a little confusing.
    
    # Standards
    Reading the page at:
    
    https://github.com/w3c/dxwg/tree/gh-pages/profilesont

    
    (BTW - there's a broken link on that page to the "(DXWG)'s Profile Guidance work").
    
    This describes a standard thus: "A Standard can be either a Base Specification (a Standard not profiling any other Standard) or a Profile (a Standard which does profile others)." 
    
    This is an interesting use of the word 'standard'. I appreciate that we have these imprecise terms, and that we have to arrange them somehow, and that this definition is not necessarily any worse than any other but, nonetheless, I find it a bit surprising. I have tended to view metadata application profiles as being an arrangement of properties and constraints, drawing from one or more namespaces (frequently from more than one namespace in the domains with which I am most familiar), in order to either facilitate some task, or to describe some domain. In this formulation, 'standard' is closer to 'namespace', and so I would expect a many-to-many relationship between standard and profile.
    
    
    # General comment 2:
    My view, when approaching these things, is always coloured by my main experience which is as a software and systems developer, rather than as an information scientist. So, when I face a new ontology, there is one over-riding question in my mind:
    
    Will this help me to do something useful?
    
    I haven't had time yet to explore the indicative examples offered on the GitHub site, so the answer to my question may lie in those.
    
    From my perspective, the most pressing issues with application profiles are:
    
    1. we don't have a conventional way to document them yet
    2. we don't have a conventional way to automatically validate data instances of application profiles (i.e. data which allegedly conforms to the constraints of a given application profile)
    
    I'm aware that there are efforts to address these concerns, and this ontology does point to these - especially in the second diagram with the "Resource Roles".
    
    However, my initial reaction to the ontology in general is that it is "too much ontology", and that something quite a bit simpler than this might help to position application profiles in a frame which allows us to develop these conventions.
    
    I hope that these comments are useful. As I said, I am glad that there is ongoing work to explore this space.
    
    thanks for the opportunity to comment,
    
    cheers,
    
    Paul
    -------------------------------------------
    Paul Walk
    http://www.paulwalk.net

    
    Founder and Director, Antleaf Ltd  
    http://www.antleaf.com

    
    Antleaf provides Management Services to DCMI  
    http://www.dublincore.org

    -------------------------------------------

Received on Saturday, 26 January 2019 04:23:32 UTC