- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 5 Dec 2017 06:36:09 -0800
- To: Ruben Verborgh <Ruben.Verborgh@UGent.be>
- Cc: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
On 12/5/17 6:19 AM, Ruben Verborgh wrote: > Hi Karen, > >> Actually, there are other, more relevant, distinctions. > > That might be the case indeed. > >> I'm not sure what "profiles" alone means > > A working definition from an earlier thread was: > > A profile defines a set of additional structural and constraints and/or semantic interpretations > that can apply to a given document in addition to any rules—particularly syntactical ones— > mandated by the media type used to serialize the information content. > >> but there are two other concepts that we might >> be able to define: >> >> application profile - this includes profiles of executable files such as [1] >> >> metadata application profile - profiles that define "a set of metadata >> elements, policies, and guidelines defined for a particular application."[2] >> >> I suspect that [2] is closer to our charge, but we can debate that. > > These are all fine with me, > and I don't have any strong opinion on this. > > The only strong opinion I have is that a profile, > for the purpose of content negotiation, > is something very generic, independent of DCAT. Indeed, "application profile" as defined in our charge is independent of DCAT. Whether it is "very generic" depends of course on what one means by that. > > To indicate with an example how generic I want it, > the following would be considered a profile: > “has a fullName field at the top level with a string as value" > This seems to be more generic than what Dublin Core > defines as an Application Profile, hence "profile". > I think it all depends on whether you have the ability to read and understand such a natural language phrase in a way that is useful within content negotiation. I have generally assumed that a useful profile would be some more "machine friendly", such that defining a property (in the form of an identifier that is unambiguous and a value type that is a known data type) would be the minimum of utility. > The reason for defining this at such a generic level > is so we are able to define profile-based content negotiation > sufficiently broadly, not just for (DCAT) AP. Rest assured that in no way are we charged with defining DCAT APs. However, calling such a deliverable "profile" would in my opinion be overly ambiguous, since there is nothing inherent in the term "profile" to intend that it has anything to do with data processing. I strongly suggest that we be more specific in our terminology. kc > > Best, > > Ruben > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 (Signal) skype: kcoylenet/+1-510-984-3600
Received on Tuesday, 5 December 2017 14:36:38 UTC