Re: Requirements for profiles

Hi Karen,


>>
>> I'm trying to work on it.
>> But I have to say I'm a bit lost, what has happened to our use case
>> (5.37) and requirements. At some point everything was included at
>> https://w3c.github.io/dxwg/ucr/#ID37
>> but the requirement list seems to have been really simplified, not the
>> only requirement derived from 5.37 is
>> https://w3c.github.io/dxwg/ucr/#RID11
>>
>> When we contributed our use case we had listed these requirements:
>> - Each application profile needs to be documented, preferably by
>> showing/reusing what is common across profiles
> 
> We'll make sure that these get in. I do have a very basic question,
> though, which is whether you have any assumptions about the content of a
> profile. This says that it is documented, that it is machine-readable,
> that it contains validation, and that profiles can contain pieces of
> data from other profiles. Is there some statement that can be made about
> the nature of this data? Are you assuming that profiles contain
> vocabulary terms? This seems to be the missing background information
> from our requirements.
> kc


This is a tricky point indeed.
In the end, Europeana has defined its notion of profile by just doing one. The bottom line is that everything that is included is in the documentation for profiles should count. So for example:
- https://pro.europeana.eu/edm-documentation (especially the 'EDM Definition', EDM templates' and 'EDM Mapping Guidelines'.
- https://dp.la/info/developers/map/ for DPLA
- https://w3c.github.io/dxwg/ucr/#ID37 contains other examples.

In all of these, vocabulary terms appear. I'm not sure if we can say that these are 'contained' in the profile, though. Perhaps for the case where a profile uses elements from an own namespace that is created at the same time (e.g. the EDM own namespace) we can talk about containment. For external vocabularies, perhaps 'reference' is a better word than 'containment'? The profile could be rather said to 'contain' patterns and constraints that 'refer' to external elements.
All this sounds a bit like splitting hair, but there may be subtle consequences of using one word or the other, especially when we talk to Semantic Web ontologists or XML Schema designers, where 'containment', 'reference', 'import' etc can correspond to rather precise notions.
One thing is sure, our WG is chartered to help us talk about these things, as per the 'Guidance on publishing application profiles of vocabularies' at https://www.w3.org/2017/dxwg/charter

Finally there's one point which is left implicit in our use case: the expressiveness of the specs within a profile: I'd say that our requirements wrt to these are well represented by the ones from the DCMI group
http://wiki.dublincore.org/index.php/RDF_Application_Profiles/UCR_Deliverable
Should we be more explicit about it?

Cheers,  

Antoine


> 
>> - Machine-readable specifications of application profiles need to be
>> easily publishable, and optimize re-use of existing specification.
>> - Application profiles need a rich expression for the the validation of
>> metadata
>> - publishers (data providers, intermediary aggregators, Europeana and
>> DPLA) need to be able to indicate the profile to which a certain piece
>> of data (record describing an individual cultural object, or a whole
>> dataset) belong.
>> - Data publishers need to be able to serve different profiles of the
>> same data via the same data publication channel (Web API)
>> - Data consumers (intermediary aggregators, Europeana and DPLA, data
>> consumers) need to be able to specify the profile they are interested in
>> - Europeana needs to be able to accept the data described using EDM
>> extensions that are compatible with its EDM-external profile whether it
>> doesn't ingest this data entirely (i.e. some elements will be left out
>> are they are useless for the main Europeana Collections portal) or it
>> does ingest it (e.g. for Thematic Collections portals or domain-specific
>> applications that Europeana or third parties would develop)
>>
>> I'm going to see how it aligns to your list. But I prefered to send you
>> our raw list now, so that you can have a brief look at. If just because
>> this list supports your point " Also, there are some obvious
>> requirements, like being both machine and human-readable, having
>> identifiers, etc., that we do not have use cases for". Valentine and I
>> wanted our use case to be a motivation for such requirements...
>>
>> Cheers,
>>
>> Antoine
>>
>> On 21/11/17 16:34, Karen Coyle wrote:
>>> Because we need to move to FPWD, if we can agree on the requirements for
>>> profiles as written here, we can amend those for the next publication of
>>> the UCR. We can add a note that these are still in flux.
>>>
>>> kc
>>>
>>> On 11/20/17 1:57 PM, Antoine Isaac wrote:
>>>> Hi Karen, all,
>>>>
>>>> Sorry I wanted to do this today but I will probably won't have time,
>>>> also seeing that a considerable thread has appeared after your initial
>>>> email and will probably require reading...
>>>> I'll try to do this week, though reorganization at Europeana is keeping
>>>> me busy.
>>>>
>>>> Very likely regrets for tomorrow by the way :-/
>>>>
>>>> Antoine
>>>>
>>>> On 15/11/17 04:32, Karen Coyle wrote:
>>>>> All, I'm not sure that this requirement list is complete but it is what
>>>>> I could come up with in a short time so that we could have something to
>>>>> discuss. [Note to Antoine and Valentine: please see if I correctly
>>>>> captured the requirements from your use case.]
>>>>>
>>>>> I want to mention that I believe there may be more than one definition
>>>>> of "profile" being used in the use cases. In particular, UC 5.3
>>>>> (submitted by Ruben) didn't seem to me to be a function of profiles but
>>>>> of the connection service. There may be other such differences in the
>>>>> use cases where I'm not sure if the reference is to the profile or to a
>>>>> specific selection of instance data.
>>>>>
>>>>> Also, there are some obvious requirements, like being both machine and
>>>>> human-readable, having identifiers, etc., that we do not have use cases
>>>>> for. I did a talk at the recent Dublin Core conference that included a
>>>>> number of requirements of this nature that we may wish to examine.
>>>>>
>>>>> http://dcevents.dublincore.org/IntConf/dc-2017/paper/view/520/643
>>>>>
>>>>>
>>>>> ****
>>>>> profiles list valid vocabulary terms for a metadata usage environment
>>>>> (5.37)
>>>>>
>>>>> profile vocabulary lists may be defined as closed (no other terms are
>>>>> allowed) or open (other terms are allowed) (5.37)
>>>>>
>>>>> conceptually, profiles can extend other vocabularies or profiles, or
>>>>> can
>>>>> be refinements of other vocabularies or profiles (5.37)
>>>>>
>>>>> profiles can be "cascading", inheriting from other profiles or profile
>>>>> fragments (discussion at first f2f)
>>>>>
>>>>> profiles reuse vocabulary terms defined elsewhere (Dublin Core
>>>>> profiles;
>>>>> no use case)
>>>>>
>>>>> profiles must be able to define finer-grained semantics for vocabulary
>>>>> terms that are used (visible in DCAT APs)
>>>>>
>>>>> profiles must be able to express rules that support data validation
>>>>> (cardinality, valid values) (5.41)
>>>>>
>>>>> profiles must be able to express cardinality rules of vocabulary terms
>>>>> (5.41)
>>>>>
>>>>> profiles can contain links to detailed validation rules or to
>>>>> validation
>>>>> applications that can process the profile (5.48)
>>>>>
>>>>> profiles must be able to support information that can drive data
>>>>> creation functions, including brief and detailed documentation (5.46)
>>>>>
>>>>> profiles must be able to express what standards (including creation
>>>>> rules) the data conforms to (5.43) (5.42)
>>>>>
>>>>> profiles must support discoverability via search engines (5.40)
>>>>>
>>>>> profiles must have identifiers that can be used to link the DCAT
>>>>> description to the relevant profile (seems obvious; no use case)
>>>>>
>>>>> *Not covered* (because I didn't know what the requirement would be):
>>>>> 5.3
>>>>> Responses can conform to multiple, modular profiles (by Ruben)
>>>>>
>>>>> kc
>>>>>
>>>>
>>>
>>
>

Received on Wednesday, 22 November 2017 10:23:46 UTC