W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > November 2017

Re: Requirements for profiles

From: Annette Greiner <amgreiner@lbl.gov>
Date: Fri, 17 Nov 2017 12:32:48 -0700
To: public-dxwg-wg@w3.org
Message-ID: <9a7a1d94-21ce-6821-54ea-409426f42490@lbl.gov>
If we allow hierarchies of profiles, then we would need to deal with the 
fact that profiles will change over time. That is, what happens when I 
have a profile that inherits from another that is later updated and I 
either want or don't want to incorporate that update? That could be 
solved by versions, and specifying a version for a profile if it is 
incorporated into another profile. But I also want to keep profiles 
usable, so one concern I have is allowing profiles to specify other 
profiles that the user then needs to track down and address. 
Inheritance is a nice shortcut for the person writing a profile, but not 
necessarily friendly for the end user, because relying on inheritance 
creates dependency. I do think that stating a relationship in a child 
profile can be a good thing (that is, detailing the specifics but 
additionally stating that a child profile also conforms to a specific 
version of its parent). But I would only want to allow this complexity 
if it seems likely people would need it.


On 11/17/17 9:55 AM, Karen Coyle wrote:
> On 11/17/17 7:30 AM, Ruben Verborgh wrote:
>> Hi Karen,
>>> Not sure what you mean by "composed."
>> Maybe I should have just said "combination",
>> but I meant using multiple profiles in conjunction.
>> Example:
>>  Profile A: "use FOAF to describe people"
>>  Profile B: "use Schema.org to describe books"
>> When a representation does both of the above,
>> then it conforms to both profiles
>> and we essentially have a composition of profiles A and B.
> Ruben, I think this is a variant view of profiles, so we should discuss
> it as a group. The APs that exist today for DCAT are complete
> descriptions of all of the elements of a metadata schema. As I read them
> they cannot be combined as they are, nor can parts or fragments be
> combined as new profiles because they haven't been designed to be
> uniformly combinable. That is an interesting interpretation but not one
> that we have yet as a requirement.
> Your use case appears to assume profiles that each conform to a single
> entity description, in one case people in the other case books. However,
> a "book" description (as I show here [1] and that is the case for real
> book metadata [2]) includes everything needed to describe a book
> including information about the people who write them.
> If you have profiles that, for example, are metadata descriptions for
> books, and they have these characteristics:
> 1 - FOAF for people, BIBO for books
> 2 - BIBFRAME for people, schema.org for books
> it seems to me unlikely that any combination of them would be workable.
> At the same time, having a way to create profiles as "fragments" that
> can be combined is an interesting idea, so we should explore that.
> kc
> [1] http://dublincore.org/documents/profile-guidelines/
> [2] http://www.loc.gov/bibframe/docs/index.html
>>> conformance to multiple profiles is a function of
>>> the service that is determining "conformance". The profiles are
>>> essentially inert in that process - they are being acted on.
>> Conformance isn't necessarily determined afterwards by a service.
>> A server could also just directly generate a conforming representation.
>> I'd say that the profile itself defines with conformance means,
>> regardless of the way to validate it.
>>> What isn't clear to me is the "response" part. What is doing the
>>> responding? or what is the nature of this thing called "response"?
>> This is in the context of an HTTP request and response.
>> A client sends an HTTP request to receive a representation of a resource.
>> The server responds with that representation.
>> So given a dataset, the server will respond with a representation
>> of that dataset that conforms to zero or more profiles.
>> Best,
>> Ruben

Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory
Received on Friday, 17 November 2017 19:33:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:41:58 UTC