W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > January 2019

RE: [profguid] Profile definition v Profile in profiles ontology

From: Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au>
Date: Thu, 10 Jan 2019 02:40:07 +0000
To: Antoine Isaac <aisaac@few.vu.nl>, "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <SYCPR01MB47034AB4B96CA050E35113FCE7840@SYCPR01MB4703.ausprd01.prod.outlook.com>
This discussion is interesting. Can it please be attached to the Issue https://github.com/w3c/dxwg/issues/537? That issue is marked for resolution before the FPWD of the Guidance doc (https://github.com/w3c/dxwg/milestone/10) which seems appropriate given the importance of getting this right in order to keep the docs in sync.

If so, I'll leave it to Antoine & Karen to coy the content below into the Issue.

Nick

-----Original Message-----
From: Antoine Isaac <aisaac@few.vu.nl> 
Sent: Thursday, 10 January 2019 10:20 AM
To: public-dxwg-wg@w3.org
Subject: Re: [profguid] Profile definition v Profile in profiles ontology

Hi Karen,

Good questions.
As I'm a bit hesitant to re-open the discussion on definition. Maybe the current one can be understood in a way that alleviates your doubts?
(and that's perhaps a part of my action on aligning the view on this ;-) )

On the cardinality aspect, the fact that a profile is a named set (singular) of constraints doesn't rule out that there can be several expressions (i.e. resource descriptors) of this set of constraints, some of which may be partial.

On the question of mandating representations (such as the (human-readable) guidance to be a good expression of the constraints, I'm not sure we can do much. The enforcement of whatever PROF would say would have to rely on other mechanisms, as representations that play a guidance role certainly belong to a level which is not the one at which PROF operates (i.e. RDF or any other machine-readable implementation of PROF). I don't see other choice than doing a manual inspection of the representation. Or did you have something else in mind and I've not understood correctly the kind of thing you'd like to mandate?

Cheers,

Antoine

On 09/01/2019 17:42, Karen Coyle wrote:
> I don't know whether we want to re-open this, but I see a disconnect 
> between our current definition of profile and the graph structure for 
> profiles provided by the profiles ontology. Our definition was written 
> before we considered the profiles ontology as describing profiles, and 
> my impression is that we were considering "profile" to be a single 
> resource like DCAT-AP. Should we lean more toward the multi-resource 
> possibility of prof:Profile in ProfGui, and does that mean that we 
> need to have a definition of profile that looks more compatible with 
> the profiles ontology?
> 
> First, our definition states profile as a single thing:
> 
> "A named set ..."
> 
> which makes it compatible with prof:Profile. That's good. But then the 
> definition moves on to say:
> 
> "A named set of constraints ..."
> 
> And this is where I begin to have issues. At the moment our definition 
> goes on to say (in whole):
> 
> "A named set of constraints on one or more identified base 
> specifications, including the identification of any implementing 
> subclasses of datatypes, semantic interpretations, vocabularies, 
> options and parameters of those base specifications necessary to 
> accomplish a particular function."
> 
> However, the profiles ontology does not mandate the existence of a 
> resource with either the role ":fullConstraints" or 
> ":partialConstraints", and it isn't clear to me if a prof:Profile with 
> only one resource that has the role ":guidance" would meet our 
> definition of profile. Therefore it may be necessary for the ProfGui 
> document to mandate certain content to meet the definition of "profile"
> as we are using it.
> 
> In addition, nothing in our definition indicates that there can be 
> more than one resource in this "set". I don't think that the 
> one-sentence definition needs to do this but this becomes an issue for 
> the guidance document that so far is not included there. This could 
> become text for the section on Profile Description but I also think it 
> needs to be introduced earlier on in the document. This would be where 
> Antoine's revised diagram could be useful, and it may require a 
> section in the profiles definition area that talks about the 
> multi-faceted nature of profiles.
> 
> If we think we need to discuss this I will open a github issue.
> 

Received on Thursday, 10 January 2019 02:40:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 25 March 2019 10:33:28 UTC