W3C home > Mailing lists > Public > public-dxwg-comments@w3.org > February 2019

RE: W3C Profiles Ontology First Public Working Draft - comments sought - ARDC

From: Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au>
Date: Tue, 12 Feb 2019 04:11:45 +0000
To: public-dxwg-comments <public-dxwg-comments@w3.org>, Rob Atkinson <rob@metalinkage.com.au>, Melanie Barlow <melanie.barlow@ardc.edu.au>
Message-ID: <SYCPR01MB4703B198926C6BE592D69D03E7650@SYCPR01MB4703.ausprd01.prod.outlook.com>
These are comments in reply to Melanie’s email from Rob Atkinson and Issues created by Nicholas Car.


Melanie said, regarding Content Negotiation By Profile - 7.2.2 get resource by profile:

I'm not sure whether this is possible with the current design, but it may be useful for clients to be able to 'get resource by profile' by a characteristic of the profile - for example, the more recently updated, or the fully/most compliant, or which uses a particular vocabulary, or something else maybe? This is for systems that can use more than one profile and are looking for the richest - where a resource is described in multiple profiles, but these are not dynamically updated from the authoritative source, or where particular vocabularies are of interest; a kind of helper-method to prevent the client having to go through each profile one by one to determine this?  Characteristics could be listed in order of preference as profile uri can be.

Rob’s Reply:

I think these can be supported by linking DCAT to profiles (via dct:conformsTo property on dcat:Distribution or dcat:Dataset) - then annotating the profile with appropriate properties.
(e.g. dublin core or others for times, VoiD for vocabulary usage (profiles itself only supports the specific usage case of refinement by constraints)

the responsibilities of the client are always a contract between the client and the metadata source about the closure of the metadata graph (how much the server decides to hold or access on the clients behalf) and the "shape" - the set of property paths (bits of possible graph) it will bundle.  So what you are really looking at I think is the case of defining profiles of DCAT for catalogs (that themselves contain profile descriptions) to meet these query requirements.

At this stage we dont have "qualified compliance" support - the semantics are "conforming to".  If you have a strong need to have a "measure of conformance" thats probably something for the DCAT sub-team to handle - but a response to this can be redirected to them :-)

Issue created: https://github.com/w3c/dxwg/issues/753



Melanie said, regarding Content Negotiation By Profile - 7.2.1 list profiles:

Another way to help as per above is to have info in the response of 'list profiles' that can help in determining which one is preferred, and to be able to ask for such info.  For example, which profile is fully/most compliant, which is newest, what vocabs are used (this last one could help for example if you are seeking a resource with a particular vocab term within its profile)

Rob’s Reply:

as above - this is a function of the profile of DCAT + profiles a catalog supports.

We dont really deal with the metrics of preference - although we do potentially support it during content negotiation. I guess you would have service metadata containing this preference information from the server perspective, but mainly this would be a function of a catalog API able to sort results by a provided preference model, or a client effectively negotiating via a catalog by searching or ordering results by preference.

Issue for this taken to be 753 created for the point above.


Melanie said, regarding Profile Ontology:

When we have received a resource by a particular profile can we ask whether the populated profile complies with the profile specification? Or can we find, from the profile's description, uris to tools for checking compliance to that profile?

Rob’s Reply:

the latter - its up to the catalog to establish what data quality it enforces when it allows the assertion that a data set complies. the Profiles ontology allows any resource to be attached to a profile with a role description.  If you wanted to enumerate the roles you think you would want to see supported that would be useful when we decide what basic roles we canonically define - but you can make up your own at any time)

No Issue created as question answered within reply.


Melanie said, further to the point above:

If a resource is available in a profile that we don't usually deal with, can we find from the profile's description, uris of online resources available to convert it to another base schema?  For example, a resource is available in GA Profile but our system likes to interpret DCAT - can we find in the profile description (i.e. does the ontology include this?) a uri to a tool that converts from GA Profile to DCAT, and if that's not available, seek the base schema of the GA Profile (ISO19115-3) and from it, discovery a uri to a tool that converts from ISO19115-3 to DCAT (or many of them, each with their own metadata so that we can understand who created them and more).

Rob’s Reply:

yep - see above - its a potential role description for attached resources.  You would need further metadata to specify the target profile for transformations - unless you had two roles

Profile A - hasResource (role = transformFrom)  R

Profile B - hasResource (role = transformTo) R

ie. to find an XSLT

Select ?xsltfile
WHERE {
 ?p1 prof:hasResource ?r1 .
 ?r1 prof:hasRole myns:transformFrom ?p2 .
 ?r1 prof:hasArtifact ?xsltfile .
 ?r1 dct:conformsTo <uri of XSLT spec> .
 ?p2 prof:hasResource ?r2 .
 ?r2 prof:hasRole myns:transformTo ?p1 .
 ?r2 prof:hasArtifact ?xsltfile .
}

Issue created for an example: https://github.com/w3c/dxwg/issues/754



Melanie said Extra:

I understand that this level of API has prerequisite that we know resource URIs, so perhaps we have already asked a server for all of its resource ids, (as with RESTful api) - it's useful then for such APIs that we can also ask:  get all resource ids of a particular profile, or ask for a list of resource ids per each profile, or something like this?

Rob’s Reply:

as above - thats a question for DCAT - however profiles allows you to also handle general and specific profiles

eg.

select ?dataset ?specificprofile ?generalprofile
WHERE
{
 ?dataset a dcat:Dataset .
 ?dataset dcat:distribution ?dd .
 ?dd dct:conformsTo  ?specificprofile   .
  OPTIONAL { ?specificprofile   prof:profileOf* ?generalprofile . }
}

No Issue created as question answered within reply.











From: Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au>
Sent: Tuesday, 12 February 2019 1:28 PM
To: public-dxwg-comments <public-dxwg-comments@w3.org>
Subject: [ExternalEmail] FW: W3C Profiles Ontology First Public Working Draft - comments sought - ARDC

These comments are from Melanie Barlow at the Australian Research Data Commons who maintains a large catalogue of research datasets and projects, collected by them and also harvested from elsewhere.


From: Melanie Barlow <melanie.barlow@ardc.edu.au<mailto:melanie.barlow@ardc.edu.au>>
Sent: Friday, 8 February 2019 11:12 AM
To: Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au<mailto:Nicholas.Car@csiro.au>>
Cc: Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>>
Subject: Re: W3C Profiles Ontology First Public Working Draft - comments sought

Hi Nick and Rob,

Thank you for sharing this.

I have some responses below; please would you mind just checking through to confirm whether they are ok for the mailing list before I post them - i.e. valid for what's being proposed?

Thank you,
Melanie


Content Negotiation By Profile and Profile Ontology

  1.  Do you agree with the direction of travel of this ontology?
Yes, a nice idea and useful for the use-cases stated, and associated use-cases.

  1.  Are there any areas where we could improve what we have done? [please illustrate]
Not that I have noticed yet; as a work in progress, its principles are sound, and as with all things: will evolve as further use-cases are identified.

  1.  Are there any areas where you think the proposal/modelling is wrong or could lead us into describing profiles that are unhelpful? [please give examples and reasons]
As longs as profiles aren't described incorrectly, it seems fine to proceed.

  1.  Are there other use cases for formal profile descriptions that we have not considered? [please illustrate]

See below for comment on both 'Content Negotiation By Profile', and the 'Profile Ontology'
Content Negotiation By Profile
7.2.2 get resource by profile
I'm not sure whether this is possible with the current design, but it may be useful for clients to be able to 'get resource by profile' by a characteristic of the profile - for example, the more recently updated, or the fully/most compliant, or which uses a particular vocabulary, or something else maybe? This is for systems that can use more than one profile and are looking for the richest - where a resource is described in multiple profiles, but these are not dynamically updated from the authoritative source, or where particular vocabularies are of interest; a kind of helper-method to prevent the client having to go through each profile one by one to determine this?  Characteristics could be listed in order of preference as profile uri can be.
7.2.1 list profiles
Another way to help as per above is to have info in the response of 'list profiles' that can help in determining which one is preferred, and to be able to ask for such info.  For example, which profile is fully/most compliant, which is newest, what vocabs are used (this last one could help for example if you are seeking a resource with a particular vocab term within its profile)

Profile Ontology
When we have received a resource by a particular profile can we ask whether the populated profile complies with the profile specification? Or can we find, from the profile's description, uris to tools for checking compliance to that profile?

If a resource is available in a profile that we don't usually deal with, can we find from the profile's description, uris of online resources available to convert it to another base schema?  For example, a resource is available in GA Profile but our system likes to interpret DCAT - can we find in the profile description (i.e. does the ontology include this?) a uri to a tool that converts from GA Profile to DCAT, and if that's not available, seek the base schema of the GA Profile (ISO19115-3) and from it, discovery a uri to a tool that converts from ISO19115-3 to DCAT (or many of them, each with their own metadata so that we can understand who created them and more).

Extra
I understand that this level of API has prerequisite that we know resource URIs, so perhaps we have already asked a server for all of its resource ids, (as with RESTful api) - it's useful then for such APIs that we can also ask:  get all resource ids of a particular profile, or ask for a list of resource ids per each profile, or something like this?


Please also feel free to make any other comments and suggestions regarding the draft. Note that positive comments or general assent to the work's design are very welcome, as these provide evidence of community acceptance. We would like to receive comments on this draft by January 31, 2019, so that those can inform our next working draft.

Thank you for developing these things - they will be very handy for clients depending on resource metadata for resource access and use.

Melanie










Melanie Barlow

Technical Analyst

melanie.barlow@ardc.edu.au<mailto:tsuey.cham@ardc.edu.au>
ardc.edu.au<http://ardc.edu.au>


[ardc.edu.au]<http://ardc.edu.au>


Physical address: 9 Liversidge Street, Australian National University, Acton, ACT 2601
Postal address: 101 Liversidge Street, Australian National University, Acton, ACT 2601

[https://lh3.googleusercontent.com/w4V8Osu0QNOl62CfxqjvlCn8w82UcqLZn_15yM8cbSVIqhIt0lm34n7wr2PSr5pMtPggb_oGZuxUj9enUeoT4lQOywiFxcPxFYMUXG_Q9oAqwXzuOmAVlHcCTQBcI2h18W0R3jzzslH_wsnrFuU4jTKXCsWsc8MKlR73WfEnyhR0lzs23zmUO8CO1uVM-AfcOd5jCT4n2vhpdzBx6S7slFPNUn74SQJaIOC_yh3-MM0R4NgJ5L5Qgv2I1JJkP_evDjSY205-EUavuFpMiSTsRSl5PWT0l9HL81x3b8OhpiVr6TGJOpKUbMOvD_JkjijKzJTjySfjDywrfo1ZeRnyHKDt8YBY7cQlIAYmhyGC3CFqYrrurwtch3_BcNPKe96bnimHddlJJ4gbi0IPGAXeEyyQAe05TTSSmu3Rdyd9NLQDTxRpHdS-moDsuaZle-6gBuXlkGfmdiuSMX2nokjyL1bih1uDW0rOHWkSL_G1WheJ0pPJdkS9J56QOLtO3YxE6lSizKq7ifTuECHx5eBJA-x0zhdkBpV1Q2iCgLeDetRE1QkiwHtrxjdFA2N3FfmSZcP6D17kePxxaFx6n_8NNmgtDw=w320-h200-k]


[https://lh3.googleusercontent.com/mq9gMXdFq5POuTV9v9pdedYaKS4kCOCpaBr2dtZjIqtejxtE4-M8lrMCjXAzh5ZteRRmLcuNgJTDEbZ6Qd8PeinVqIw_5a3_SsjAWCMbihFF8bppWp3VfOimLjT3Krpg4MxpLoW9tHL_Qz0I1x6eOms_vQukMCpTK2rkKCGTGLKVmqFXBsT0ZvCZzjbGGJvTPnhdako3Rh9vE7N8MXth6guh2oaMeKN-7RRmIapEdZK_vIvq6zxsc8WRzGBKb6Yv6nJ51Qdvd-HBJXtRisu84j30OVs2sJpClZNqOf057EVHOvsN9FH44Pog_WK_0zVZS0XRgIye_pcnnUvV5UxPH9nGZvVY4mB0XlK0a8SSuhbXgNW0vckjqfl_a3oVA3YynREr2pWTS77ZxI8YUDxgEevCrIkF9jCrzn0Yr_9xmWKaWSgXnOaSfv9P-BuF1eQMLBty84TAE-69L6NwVTVzPJ6L9H8Caq3x5S3Rs85xQIeumxk_pzP4GAGmIlHHMVKxeQWDiHgmlN8QwykHu3F3vgHTG74uyVreg5-3BmxvYyIs28I_cp2OMYBBFWfBvcCbZNk9gNfPtc9SyVnacNeHcx9C5Q=w320-h200-k]<https://twitter.com/ands_nectar_rds>

[https://lh3.googleusercontent.com/Niao3q9A99V4w1LhlPKvWWbzBQeEjiQWKPjnohFU37VH4J50eGVESL2y_AoW_M1XEKndyDIqQCtQPc4x0_5_Q4h9rs3ISDpta-VwHYW-eEnHDDb1KidNlTdFUG-7H7ctfM6JZXeF1SWXQh94euRGGnzOII2YW3_fqqCia6PujJH3fVNkEmoruNkDxbdz36GT3FegLEpaIm4Mb4U_BKbls47e_HkLXiq921tY4ElztauY_3ATt2BwhxkRnfgn_GOagslNoLwVnAjuEx25K0H7IHZHTiQjh4KztfGPj75BotkvmyvFrbgVbUPu7vhM6N2UjZ5W_ohOPWz7QzTRl_oSjZMbv1YMvTzvVFY91tHFnJbiTx8gMh1BIdg2tjI3GedntKhgDn_6Jum0mhNhjdkwf3f7RQScwbKwYloDIGBMNzIjlD5m7mqd8Dn6aQ095ulzm6yAKUAwecVrixCPpKM3qK45-_O04vlP9pNJoXoLTXlCLIZ-rAEp7wwAX7my3g0VOk0ZqH8OJoFfR67yr0MoTlooRBiTmsbxH93MBPgU7gaaGAkuFzBY-Xhpvmi5vXy7Im0wEaO43WpWs3NhX_WYSYSjTQ=w320-h200-k]<https://www.youtube.com/user/andsdata>


ARDC acknowledges the Traditional Owners of the lands
that we live and work on across Australia and pays its respect
to Elders past and present.

Please consider the environment before printing this e-mail.



On Tue, Jan 29, 2019 at 5:53 PM Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au<mailto:Nicholas.Car@csiro.au>> wrote:
Hi Melanie/Adrian/Rowan,

Would ARDC like to make comments on the request below? Also, there is a second document also released by the DXWG that’s related to the Profiles Ontology and also now requesting feedback:

https://w3c.github.io/dxwg/conneg-by-ap/


Taken together, the Profiles Ontology and the Conneg by Profiles docs will assist orgs like ARDC if implemented by data/standards publishers.

I won’t copy in the text of this second invite but it’s here if you want to read it: https://github.com/w3c/dxwg/wiki/Profiles-Ont-&-Conneg-RFQ-emails


Cheers,

Nick


From: Car, Nicholas (L&W, Dutton Park)
Sent: Wednesday, 2 January 2019 12:32 PM
To: Melanie.Barlow@ardc.edu.au<mailto:Melanie.Barlow@ardc.edu.au>; 'adrian.burton@ardc.edu.au<mailto:adrian.burton@ardc.edu.au>' <adrian.burton@ardc.edu.au<mailto:adrian.burton@ardc.edu.au>>; 'rowan.brownlee@ardc.edu.au<mailto:rowan.brownlee@ardc.edu.au>' <rowan.brownlee@ardc.edu.au<mailto:rowan.brownlee@ardc.edu.au>>
Cc: Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>>
Subject: W3C Profiles Ontology First Public Working Draft - comments sought


Dear Melanie, Adrian & ARDC,

Hi Melanie & Adrian. This ontology, along with the Profiles Guidance document that is currently still heading towards a public working draft – due mid Jan – could help, in the longer term, with the way ARDC works with catalogue content providers to define the profiles of things like DCAT that they use. It’s a simple ontology but it could be extended for purposes that interest you as we have plenty of left. Cheers, Nick

The W3C's Dataset eXchange Working Group (DXWG) [1] has published a First Public Working Draft of The Profiles Ontology [2]. The Profiles Ontology is an RDF vocabulary to describe profiles of (one or more) standards for information resources.

The DXWG is chartered to provide a guidance document on publishing application profiles of vocabularies and a recommendation for content negotiation by application profile. This ontology was not an anticipated output of the DXWG but has been created to allow for formal semantic descriptions of the components of profiles and for relations between profiles and standards. A more complete description of the ontology is given below.

We would greatly appreciate your feedback on this ontology. In reviewing the draft, it might be helpful for you to keep in mind the "Use Cases and Requirements" document that we are working to [3]. We would find it most helpful to get feedback on the following lines:

  1.  Do you agree with the direction of travel of this ontology?
  2.  Are there any areas where we could improve what we have done? [please illustrate]
  3.  Are there any areas where you think the proposal/modelling is wrong or could lead us into describing profiles that are unhelpful? [please give examples and reasons]
  4.  Are there other use cases for formal profile descriptions that we have not considered? [please illustrate]

Please also feel free to make any other comments and suggestions regarding the draft. Note that positive comments or general assent to the work's design are very welcome, as these provide evidence of community acceptance. We would like to receive comments on this draft by January 31, 2019, so that those can inform our next working draft.

Please send comments through GitHub issues (https://github.com/w3c/dxwg/issues - tag 'profile-description') or through email at public-dxwg-comments@w3.org<mailto:public-dxwg-comments@w3.org>.

Thank you,

Nicholas (on behalf of the W3C DXWG)

[1] https://www.w3.org/2017/dxwg/charter

[2] https://www.w3.org/TR/2018/WD-dx-prof-20181218/

[3] https://www.w3.org/TR/dcat-ucr/


The Profiles Ontology - description

The Profiles Ontology (PROF) is a small RDF vocabulary to describe profiles of (one or more) data specifications, i.e., a named set of constraints over those specifications. It provides the general pattern of narrowing the scope of a specification with additional, but consistent, constraints. It is particularly relevant to data exchange situations where conformance to profiles is expected and carries additional context. PROF enables profile descriptions to specify the role of resources related to data exchange such as schemas, ontologies, rules about use of controlled vocabularies, validation tools, and guidelines. PROF may, however, be used to describe the role of resources in any situation where constraints are made on the usage of more general specifications, as well as the relationships between profiles.


Nicholas Car
Senior Experimental Scientist
CSIRO Land & Water
41 Boggo Road, Dutton Park, QLD 4102, Australia
E nicholas.car@csiro.au<mailto:nicholas.car@csiro.au> M 0477 560 177 P 07 3833 5632

Received on Tuesday, 12 February 2019 04:12:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 12 February 2019 04:12:25 UTC