Re: Start of profiles analysis page - 2nd reply

I worry that limiting profiles to only including what is defined 
elsewhere will limit their use in the sciences, where the chance of any 
particular dataset being described fully enough (to enable 
interoperability) with existing terms is pretty low in many fields.

Saying that makes me wonder briefly if we need more use cases, but I 
don't think it's even possible to come up with enough of them to cover 
all the potential bases. One example I'm working on lately is log data 
from supercomputers. I don't know of any existing vocabulary for the 
columns represented, and it would be way beyond the scope of this group 
to start creating terms for such things. But if there were a way to 
define a profile for this log data so that others who used that profile 
could create tools that work with it, that would be a win.

-Annette


On 12/5/17 9:33 AM, mail@makxdekkers.com wrote:
> Peter,
>
> Good point. I think that Ruben's working definition implies that restriction as it limits a profile to defining "a set of additional structural constraints and/or semantic interpretations".
>
> I do have a bit of a problem with the word "document" in that definition. Can we define what that means in our specific context -- a computer file?
>
> Makx.
>
> -----Original Message-----
> From: Peter.Winstanley@gov.scot [mailto:Peter.Winstanley@gov.scot]
> Sent: 05 December 2017 17:32
> To: kcoyle@kcoyle.net; Ruben.Verborgh@UGent.be
> Cc: public-dxwg-wg@w3.org
> Subject: RE: Start of profiles analysis page - 2nd reply
>
> http://www.ariadne.ac.uk/issue25/app-profiles is quite old now, but is helpful in this discussion
>
> I think a critical aspect is that of bringing together pre-existing components - i.e. in the application profile there is nothing that you won't find elsewhere
>
> Do colleagues agree that this is an important characteristic of an AP?
>
> -----Original Message-----
> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> Sent: 05 December 2017 14:36
> To: Ruben Verborgh
> Cc: public-dxwg-wg@w3.org
> Subject: Re: Start of profiles analysis page - 2nd reply
>
>
>
> 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
>>

-- 
Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory

Received on Tuesday, 5 December 2017 19:12:56 UTC