Re: Agenda February 6 -- profile definition

Hi Makx,

I am not so worried about some of the points here. The definition says that a namespace could be considered as a profile ('if there is no 'identification of chosen classes, conforming subsets, options and parameters'). But this is a specific case, and anyway it wouldn't impact how the management of the namespace should happen. Say, it's not because I would use Dublin Core as an unmodified base for my own AP that the DCMI consortium should start changing their management...

As for the discussion we had, I agree with you that I don't see the benefit in general of lumping things together, it's just that in some cases it could be judged easier [1]. My point now (in case it was different then) would be that there's no need to turn a good practice into a definition.

Antoine

[1] For example, the DPLA application profile: https://drive.google.com/file/d/1fJEWhnYy5Ch7_ef_-V48-FAViA72OieG/
Unless you would claim that the namespace for the elements at http://dp.la/about/map/ is not 'lumped' into the profile?

On 04/02/18 20:53, mail@makxdekkers.com wrote:
> I agree with Ruben here.
> 
> The definition as it is now being proposed implies that a namespace
> document, i.e. a document that specifies a 'base standard' or (better) a
> 'base vocabulary specification', like http://purl.org/dc/terms/ or all
> documents under https://www.w3.org/ns/, are 'profiles'.
> 
> I would rather see that we stay closer to Ruben's proposal that defines
> profiles as being fundamentally about "structural constraints and/or
> semantic interpretations" related to base vocabulary specifications that, in
> my opinion, should be declared separately.
> 
> In an earlier discussion with Antoine, I argued that namespace documents,
> i.e. definitions of semantics, and profiles in the sense of Ruben's
> definition have different maintenance requirements and that it therefore
> would make sense to keep them separate. I personally do not see the benefit
> of lumping these two different types of things together. In practice, it has
> always been helpful to treat them differently.
> 
> Makx.
> 
> -----Original Message-----
> From: Ruben Verborgh [mailto:Ruben.Verborgh@UGent.be]
> Sent: 04 February 2018 19:01
> To: kcoyle@kcoyle.net
> Cc: public-dxwg-wg@w3.org
> Subject: Re: Agenda February 6
> 
>> Ruben, could you take either Rob's or Antoine's suggested wordings and
>> add what you think would make one of these acceptable to you?
> 
> It's unfortunately not that straightforward to just add things to the draft
> definition.
> The definition as a whole takes a different direction than what was
> discussed previously.
> 
> I think we should start with a list of things we need, and then write that
> definition, instead of retrofitting another definition.
> 
> For instance, something we all seem to agree on is that a profile is
> identified by an IRI, that it describes a set of constraints that can apply
> to a document.
> None of these can be found in the current draft.
> 
> Best,
> 
> Ruben
> 
> 
>

Received on Sunday, 4 February 2018 21:34:08 UTC