Re: Start of profiles analysis page - 2nd reply

Annette's is an important point. The Dublin Core AP assumes that the
metadata being described uses terms from an external ontology. Those
terms have to be described in RDF or OWL, and the formal description of
the terms isn't supported within the profile itself, so terms cannot be
defined in the AP. This means that anyone needing terms that do not
already exist in some other RDF or OWL ontology has to define them
(correctly) before using them.

This brings up a number of issues:

1. How can we (or "can we") define an AP that works for both RDF/OWL and
non-RDF/OWL metadata? Or do we need to provide more than on option in
our guidance?

1a. Do we require that terms are identified with an IRI? Non-RDF/OWL may
not have IRIs.

2. Could an RDF/OWL-based AP define terms within the AP?

I'm sure those aren't the only questions.

kc

On 12/5/17 11:12 AM, Annette Greiner wrote:
> 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
>>>
> 

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 6 December 2017 08:18:34 UTC