- From: Paul Walk <paul@paulwalk.net>
- Date: Tue, 29 Jan 2019 15:14:49 +0000
- To: "Car, Nicholas (L&W, Dutton Park)" <Nicholas.Car@csiro.au>
- Cc: "public-dxwg-comments@w3.org" <public-dxwg-comments@w3.org>
Hi Nick, Just on the important point you address at the end - the desirability or otherwise of having a machine-readable model for application profiles. I think this is where our main point of difference lies. I do not question the potential usefulness of machine-readable resources relating to application profiles. Clearly, tasks such as automated validation will require a standard way of describing constraints for example. However, I am completely unpersuaded by the need to place the application profiles themselves into some machine-readable discovery framework. I make this point also in my comment on one of the Github issues[^1], but I'll paste a little of that here: > ...This slightly reminds me of the huge efforts made to introduce Universal Description, Discovery, and Integration (UDDI) to web-services around the beginning of this century. Then Web2.0 came along and showed that all that was really needed was some nice clear documentation aimed at developers - what has become known as the 'Web API'. I accept that you have encountered this use-case, but I am sceptical that this is going to be widely encountered. On a related note (and I think this probably follows on from the previous point): I'm also very wary of building an inheritance model around application profiles. I see the utility of the application profile as bridging the gap between finely engineered standards, which must necessarily be non-optimised for a particular application, and actual system implementations, which may be optimised to address some problem space. While I can see (vaguely) how application profiles could inherit from each other, adding more constraints at each level, I have a three issues with this: 1. It will create a dependency-management problem (the trade-off from all class-inheritance models) which will be difficult to address with the typically low levels of resource allocated to this kind of work 2. I cannot actually see how it will be implemented. For example, validation would require somehow gathering the relevant resources from every profile in the hierarchy and then somehow combining these into one coherent validation process. 3. I don't think it solves a real problem. A proliferation of application profiles is, in the scheme of things, not a problem in itself. We could argue that this represents duplication and wasted effort - but I don't believe that this concern can justify the complexity of an ontology for application profiles based on such an inheritance model. I hope that helps clarify my view, and thanks again for the chance to comment, Cheers, Paul [^1]: https://github.com/w3c/dxwg/issues/698 > On 29 Jan 2019, at 00:26, Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au> wrote: > > Hi Paul, > >> I cannot see the utility in describing the idea of a metadata profile using an ontology of this sort > Well utility or otherwise will be revealed in time I suppose! I certainly hope this ontology's useful but of course we can't know for sure. Perhaps the few of us in DXWG have a particular way of working that others don't share - obsessed with ontologies etc. > > Our use cases stem from what we perceive to be needs in organisations with lots of profiles/standards (Open Geospatial Consortium, Linked Open Vocabularies, Australian Government etc.) and they motivate us to cater for the things we do in the ontology and also to use an ontology like this in the first place, but we're still not trying for adoption outside of our motivating situations yet so the main utility tests - independent use - are still to come I think. > > >> I think I would prefer to see a description of what a metadata profile is - expressed in prose > That's the purpose of the Guidance document: https://w3c.github.io/dxwg/profiles/ > > The ontology's a formalised way of describing profile parts and relations and, to stay reasonable in size, it won't include all the best practice notes that the Guidance document will. > > >> ... some useful resources to help people document their application profiles in useful ways, to express and validate constraints using available mechanisms (I would suppose Shacl and Shex, maybe even XSD...) > So this is indeed the purpose of the ontology! If the Guidance Best Practice tells you to express constraints, guidance etc. resources as parts of a profile, then the Profiles Ontology indicates a formal way to describe them. > > See this code repo: https://github.com/CSIRO-enviro-informatics/csiro-epub-dcap. It's a toy example of a profile but it has guidance notes, validators (in two constraint languages) , basic metadata (labels & descriptions) and all the parts described in Profiles Ontology. The diagram's a bit wild but the profile.ttl file's actually quite simple. > > >> Standards are expensive, formally engineered things. They often won't quite fit a given application, so we turn to application profiles to bridge the gap between standard(s) and real-world problems. > Indeed, and we hope to capture, formally, descriptions of the smaller profile-making work people are already doing. > > Based on this and your comments previously, I've suggested a couple more Roles for elements of a Profile: > > Aggregated Constraints > Extension Constraints > > See the so-far unmerged suggested Role hierarchy: https://github.com/w3c/dxwg/blob/roles-update/profilesont/resource_roles.svg > > These roles should allow someone to either include all the constraints for a Profile and dependents (parent standards) in one resource (Aggregated) or, conversely, create a resource containing only this Profile's additional constraints over its parents (Extension). This would allow someone to make a profile of a monster standard like ISO19115-1 and then just specify their additions which would then be a relatively small task. Or include everything from ISO19115-1 if they wanted to facilitate comprehensive validation (I've seen both use cases in previous work but had no formalised way of describing this). > > >> There are some common and useful processes that we might want to perform on data which asserts conformance with some application profile - notably validation. > This is the purpose of the Resource Roles vocab. Improved vocab at https://raw.githack.com/w3c/dxwg/roles-update/profilesont/resource_roles.html > > >> [from point above] None of this needs to be automatically discoverable - it just needs to be clearly documented and signposted. > I don't agree! We should both document clearly *and* provide machine-readable versions if possible. We see the power of machine-readable Internet data as opposed to 1995-era web pages every day... > > This ontology and the Guidance document might, hopefully, allow for many profiles 'out there' to be revealed through standard descriptions and then, when profile hierarchies get long or when profiles contain very many components, machine interoperability will be necessary. > > >> I am struggling to see what a formal ontology for the concept of the application profile adds gives us. > It gives us the same benefits a formal ontology for anything gives us over either no model or an informal model, e.g. prose descriptions, namely consistency of description, ability to run rule-based reasoning on data, efficient and powerful storage etc. > > Imagine trying to describe all 30,000 items in my old organisation's data catalogue not using DCAT in a catalogue tool but instead in just chunks of text. We'd never find anything! How would we store the text? Documents in TRIM? > > See the list of standards published by the OGC: https://www.opengeospatial.org/standards. Imagine including in that list all the application profiles anyone's ever made (as you say, they are easier to make than whole standards so therefore there are many more of them) and them imagine trying to work out regular components, dependencies etc. without something formal like the Profiles Ontology! > > >> I hope that's clearer. I realise that it's quite a fundamentally negative comment, for which I apologise... > Yes, it's clearer in that I think I understand your concerns well now. But as I've done just above, I challenge the core concern that machine readability (formal model use) is not a sensible goal. > > Cheers, > > Nick > > > -----Original Message----- > From: Paul Walk <paul@paulwalk.net> > Sent: Monday, 28 January 2019 10:47 PM > To: Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au> > Cc: public-dxwg-comments@w3.org > Subject: Re: feedback on the drafts relating to profiles > > Thanks Nick. > > On the "too much ontology": > > This comment - perhaps a little flippant - expresses my concern that I cannot see the utility in describing the idea of a metadata profile using an ontology of this sort. > > I think I would prefer to see a description of what a metadata profile is - expressed in prose - and then some useful resources to help people document their application profiles in useful ways, to express and validate constraints using available mechanisms (I would suppose Shacl and Shex, maybe even XSD...) > > I guess I see metadata application profiles as being the place where those who are trying to implement some application interface with standards. Standards are expensive, formally engineered things. They often won't quite fit a given application, so we turn to application profiles to bridge the gap between standard(s) and real-world problems. In my view, the concept of an application profiles must be flexible and pragmatic, and profiles must be (relatively) cheap and easy to construct. > > There are some common and useful processes that we might want to perform on data which asserts conformance with some application profile - notably validation. One or more of the available mechanisms might be supported by a given application profile. This can be documented - again in prose - and the relevant artefact made available to support the validation. None of this needs to be automatically discoverable - it just needs to be clearly documented and signposted. > > I am struggling to see what a formal ontology for the concept of the application profile adds gives us. > > I hope that's clearer. I realise that it's quite a fundamentally negative comment, for which I apologise... > > Paul > > > > >> On 26 Jan 2019, at 04:22, Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au> wrote: >> >> 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 >> ------------------------------------------- >> >> >> >> >> >> >> >> > > ------------------------------------------- > 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 > ------------------------------------------- > > > > ------------------------------------------- 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 Tuesday, 29 January 2019 15:15:17 UTC