RE: Beginning Guidance deliverable

Dear Rob, all,


A couple of considerations, reflecting some thoughts following the profile discussion during the f2f.


We have to aspects that it may be worth addressing separately in the guidance doc:


1. Profile definition: This concerns the definition of the constraints / restrictions of a profile, and can be done by using "profile languages" (as the DC Singapore Framework, SHACL, ShEx, etc.).


2. Profile description: This is basically metadata about profiles, specifying which are the parent profile(s), linking to the (possibly different) profile definitions + other information.


The profile definition is not meant to be RDF-centric, and actually does not even require a formal, machine-actionable definition (although it would be desirable, whenever possible). We are not going to define a new profile language, but possibly to provide guidance on how to use existing ones, depending on what you need (e.g., profile definition, validation, form generation).


On the other hand, the profile description is likely to be RDF-centric, although it could be used to provide metadata about any type of profiles – not necessarily based on RDF. If I got it right, the profile guidance document is also going to explain why a profile description is needed / useful, and for which use cases.


Now, looking at the related requirements, two of the motivations are (a) being able to make use of the profile relationships for identifying inheritance, conformance, etc., and (b) being able to discover profiles.


The profiledesc vocabulary is addressing point (a). However, about point (b), I think it would be important to provide guidance on how to use existing vocabularies for describing schemas, vocabularies, ontologies - as ADMS (which has been specifically designed for this purpose) and VOAF (http://lov.okfn.org/vocommons/voaf/) -, and complement them with the profiledesc vocabulary. This will explain how existing ADMS and VOAF records about profiles could be extended accordingly, instead of being obliged to create new records.


Notably, ADMS and VOAF have properties that could turn to be useful also for point (a) – as adms:representationTechnique, to specify the language used in a profile definition, and, from VOAF, properties as voaf:reliesOn, voaf:extends, voaf:specializes, voaf:generalizes that can be used to specify relationships with the parent profile(s).


Does this make sense to you?


Cheers,


Andrea


----

Andrea Perego, Ph.D.

Scientific / Technical Project Officer

European Commission DG JRC

Directorate B - Growth and Innovation

Unit B6 - Digital Economy

Via E. Fermi, 2749 - TP 262

21027 Ispra VA, Italy


https://ec.europa.eu/jrc/


----


The views expressed are purely those of the writer and may


not in any circumstances be regarded as stating an official


position of the European Commission.



From: Rob Atkinson [mailto:rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>]

Sent: Thursday, May 10, 2018 11:53 PM

To: Karen Coyle

Cc: public-dxwg-wg@w3.org<mailto:public-dxwg-wg@w3.org>

Subject: Re: Beginning Guidance deliverable



I would suggest that the Guidance should say that profiles need to be described in a way that meets requirements X,Y,Z and that a suitable vocabulary has been developed to provide a canonical means to do this in the context of DCAT usage or other similar RDF implementations. Other platforms may choose equivalent approaches, noting the more standardised the profile description is the higher degree of interoperability that is supported between the resources that conform to such profiles.



Basically, as W3C ontology (with as yet no obvious identified alternatives) profiledesc would fit a general recommendation to use the W3C canon where appropriate... whilst future work might offer a different solution . We should aim to show it is fit-for-purpose for typical use cases.  The guidance may have equivalent sections for different aspects - e.g. around use of PROV, Datacube and other W3C we want to recommend and demystify, but without enforcing in DCAT itself for example.







On 10 May 2018 at 21:09, Karen Coyle  wrote:


All,


As you may have understood from the previous report from F2F3, a major

goal was to clarify the scope and contents of the Guidance document and

create the necessary structure around the work so that we can begin to

prepare a first public working draft.


Decisions and information were taken down during the meeting in a G-Doc:


https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gks5dDa8n2B5IN6rWa3kRpo/edit#



Actual work on the Guidance deliverable will probably be moved elsewhere

as this G-Doc is quite sketchy, but I wish to point out that there are

key sections on the Project Plan [1] and a beginning of an outline for

the document [2].


At the meeting, Karen, Rob and Antoine volunteered to be editors on the

document. Other editors are welcome, but do remember that everyone can

contribute.


We need to have a full working group discussion of profileDesc, [3]

which has so far been primarily the work of Rob and Nick, and make any

changes necessary so that it reflects the consensus of the entire group.

The current proposal is a first draft that has been offered to the group

for discussion and modification.


Note that we have not yet concluded how to integrate the guidance aspect

of the deliverable and the profileDesc ontology. The complication is

that the guidance document may read much like "best practices" but

profileDesc is an ontology. Tying them together in a recommendation

creates a dependency for maintenance that could be problematic. While

one could anticipate that profileDesc may be updated in the future after

additional experience, the more general guidance content of the document

may not need to change. Peter and I are soliciting advice from folks

with more W3C experience to try to discover the best solution.


kc


[1]

https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gks5dDa8n2B5IN6rWa3kRpo/edit#heading=h.bm0x3wnhiwa1


[2]

https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gks5dDa8n2B5IN6rWa3kRpo/edit#heading=h.cuvn3apl2413


[3] https://github.com/w3c/dxwg/tree/gh-pages/profiledesc


--

Karen Coyle

kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net> http://kcoyle.net


m: 1-510-435-8234 (Signal)

skype: kcoylenet/+1-510-984-3600