Re: Dublin Core - PROV Mapping, Call for Feedback (until June 5th)

Hi Kai and Daniel,
I found the mapping to be very helpful especially in terms of using the
construct function to implement the complex mappings.

A few comments that may be useful as starting points for further
discussions/review :
1.  Many terms currently listed in the description metadata are also
provenance-specific:
educationLevel (the qualification of person/agent is relevant provenance in
appointments/promotions etc.)
license (why - type of license is relevant provenance for legal/contractual
enforcement)
spatial (where - corresponds to prov:Location)
temporal (when - corresponds to xsd:DateTime)
isRequiredBy (why, who - relevant provenance for legal/contracts)
type (which - relevant provenance for all PROV type attribute)
language, format (what - provenance information for rendering)

Additional terms that describe provenance include accessRights (why - why
is agent not liable for sharing object with given access rights),
accrualPeriodicity (when)

2. Both rdfs:subPropertyOf and rdfs:subClassOf are specialization (of
property and class respectively). Hence, both "Direct Mappings" and "PROV
Specializations" can be merged into a single section of "Specialization"

3. The mechanism to reconcile blank nodes to a specific URI is not clear.
Will it be done manually or automatically?

Thanks.

Best,
Satya


On Thu, May 31, 2012 at 4:06 AM, Daniel Garijo <
dgarijo@delicias.dia.fi.upm.es> wrote:

> Hello everyone,
>
> in the Dublin Core Metada Provenance Task Group (with the help of Simon
> Miles), we have released an initial DC to PROV mapping draft.
>
> The work has been divided in several documents to improve readability:
>
> - The mapping primer [1] explains the process followed to do the mapping,
> the main rationale of our decisions and our next steps.
>
> - The Direct Mappings document [2] shows the direct mappings found between
> DC and PROV (e.g., subPropertyOf relations).
>
> - The PROV Specializations document [3] extends PROV-O with some basic
> roles and properties to be able to perform the complex mappings.
>
> - Finally, the Complex-Mappings document [4] infers PROV statements from
> DC statements that are not covered by the direct mappings.
>
> Please give us your feedback on our approach and the documents within one
> week (until Tuesday, June 5th).
>
> We sent this mail both to the relevant DCMI mailinglists and the PROV
> mailinglist in order to reach consensus.
>
> We are on a quite strict timetable now and aim at finishing the mapping
> (Stage 2, and the mapping back from PROV to DC) until end of June to reach
> the state of a public draft.
>
> If you have any questions or comments, please don't hesitate to contact us.
>
> Thanks,
> Kai, Daniel, Michael and Simon.
>
> [1] https://github.com/dcmi/DC-**PROV-Mapping/wiki/Mapping-**primer<https://github.com/dcmi/DC-PROV-Mapping/wiki/Mapping-primer>
> [2] https://github.com/dcmi/DC-**PROV-Mapping/wiki/Direct-**Mappings<https://github.com/dcmi/DC-PROV-Mapping/wiki/Direct-Mappings>
> [3] https://github.com/dcmi/DC-**PROV-Mapping/wiki/Prov-**Specializations<https://github.com/dcmi/DC-PROV-Mapping/wiki/Prov-Specializations>
> [4] https://github.com/dcmi/DC-**PROV-Mapping/wiki/Complex-**Mappings-S1<https://github.com/dcmi/DC-PROV-Mapping/wiki/Complex-Mappings-S1>
>
>
>