RE: Start of profiles analysis page - 2nd reply

Annette, Thomas,

 

In Ruben’s definition, Application Profiles are about expressing structural constraints and/or semantic interpretations. 

 

That is not to say that, if you need a property that does not exist elsewhere, you can’t define it for your own use or for use in your community. It just says that you cannot do that *inside* the Application Profile.

 

Suppose you want to develop an Application Profile for you application and publish it at a URL like: http://example.org/profiles/profile001.rdf. This would refer to various classes and properties from various namespaces and define constraints on those.

 

Now, if you needed a specific property to describe the resources that the application is concerned with, for example their colour, the *definition* of that property would not be in the Application Profile. You would need to define it in a separate namespace, for example in http://example.org/ns/terms/ that includes the property http://example.org/ns/terms/colour. In your Application Profile, you can then define constraints on that property.

 

This keep the definition of “Application Profile” clean, and leaves all the necessary flexibility to define properties that are needed for a particular application or community. It also enables the change and release management of a Application Profile to be different from the change and release management of a namespace.

 

Makx.

 

 

 

 

From: D'Haenens Thomas [mailto:thomas.dhaenens@kb.vlaanderen.be] 
Sent: 05 December 2017 20:44
To: public-dxwg-wg@w3.org
Subject: 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