Re: Start of profiles analysis page - 2nd reply

(My two cents)

I don’t think it’s up to any vocabulary WG to limit the potential of adding extra elements to an application profile (if the don’t exist already elsewhere)K

In a case where one needs an extra element, one should (off course)  search existing solutions in order to enhance interoperability to the maximum (and minimize competing semantics). But saying you can’t add something that isn’t already defined just seems very wrong to me. These things have their own lifecycle and dynamics and we shouldn’t (can’t) try to limit future evolutions.

In a utopian world, you start an exercise defining/updating a vocabulary (with a broad interest group, a clear method, etc...) and we should strive to that image. But I’m afraid that in the real world sometimes you just need to move faster. And I’ve rather have those people sharing their insights (& maybe creating a base for a new vocabulary) - also if they perhaps skip a step in the process. The dynamics that come with that is what I believe we need in the long run.



Op 5 dec. 2017 om 20:15 heeft Annette Greiner <amgreiner@lbl.gov<mailto:amgreiner@lbl.gov>> het volgende geschreven:

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<mailto: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> [mailto:Peter.Winstanley@gov.scot]
Sent: 05 December 2017 17:32
To: kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net>; Ruben.Verborgh@UGent.be<mailto:Ruben.Verborgh@UGent.be>
Cc: public-dxwg-wg@w3.org<mailto: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<mailto: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