RE: Start of profiles analysis page - 2nd reply

Karen,

1. This raises the question whether there is a 'conceptual level' for APs, i.e. a technology-independent definition of the constraints and semantic interpretations. If there is, a 'conceptual AP' could then be expressed in different 'formats' for specific technologies, e.g. RDF/XML, RDF/TTL (OWL or SHACL), Schematron, JSON.

1a. I'd like to point to some earlier work concerning identifying metadata terms with URIs : http://www.dlib.org/dlib/july03/baker/07baker.html. I still think this is good practice.

2. I would vote for not mixing definitions of terms (in namespaces) with definition of constraints (in Application Profiles).

Makx.



-----Original Message-----
From: Karen Coyle [mailto:kcoyle@kcoyle.net] 
Sent: 06 December 2017 09:18
To: public-dxwg-wg@w3.org
Subject: 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:47:29 UTC