W3C home > Mailing lists > Public > public-prov-wg@w3.org > June 2012

Re: Forwarding a comment from SemTech...

From: Reza B'Far (Oracle) <reza.bfar@oracle.com>
Date: Sat, 09 Jun 2012 23:33:41 -0700
Message-ID: <4FD43FC5.9020501@oracle.com>
To: public-prov-wg@w3.org
Ivan (et. al.)

I tried to answer the gentleman who asked the question by saying that 
there was an effort going on in providing the mapping.  Nevertheless, I 
think the discussion is worthwhile as Ivan is suggesting.  Also, for 
Ivan's benefit, we should probably merge this discussion with thread 
between Kai and other folks (which I'm cutting-pasting below -- alas, 
there is no good way to merge threads that I know of).

I have added Antoine's feedback as Issue 405.


2012/6/8 Kai Eckert <kai@informatik.uni-mannheim.de 

    Hi all,

    here is feedback from Antoine Isaac regarding the Dublin Core
    mapping. Unfortunately I was not able to work on the mapping this
    week, I will get back to it next week.



    -------- Original-Nachricht --------
    Betreff: Fwd: Re: Dublin Core - PROV Mapping, Call for Feedback
    (until June 5th)
    Datum: Wed, 6 Jun 2012 11:56:12 +0200
    Von: Antoine Isaac <aisaac@few.vu.nl <mailto:aisaac@few.vu.nl>>
    An: Kai Eckert <kai@informatik.uni-mannheim.de
    <mailto:kai@informatik.uni-mannheim.de>>, "Panzer,Michael"
    <panzerm@oclc.org <mailto:panzerm@oclc.org>>

    Hi Kai, Michael,

    Something that I've forgotten to state in my hurry. Or course the
    only document I've really reviewed carefully is the Primer.
    Especially, I did not check the complex mapping document. I think
    for the Direct Mapping and the PROV specialization, this is less a
    problem---they're much shorter, and my comments on the corresponding
    sections in the Primer would apply to the content of these two
    documents, as well...

    I sincerely hope these late comments won't be a problem for you,


    -------- Original Message --------
    Subject: Re: Dublin Core - PROV Mapping, Call for Feedback (until
    June 5th)
    Date: Wed, 6 Jun 2012 11:50:47 +0200
    From: Antoine Isaac <aisaac@FEW.VU.NL <mailto:aisaac@FEW.VU.NL>>
    Reply-To: DCMI Architecture Forum <DC-ARCHITECTURE@JISCMAIL.AC.UK

    Hi Kai, Daniel, Michael and Simon,

    Thanks a lot for the work on this. In fact I found it a great help
    for an outsider (from the Dublin Core community) to have a first
    glance into the work of the PROV working group.

    I have some comments that I'm hastily putting together below. Please
    apologize if it's unclear sometimes, and of course sorry for the
    late feedback. You just gave one week... hopefully it's still June 5
    somewhere on Earth.



    ====== PROV reference

    It seems that you are using really "fresh" documents from the PROV
    working group. E.g. the property prov:generatedAtTime can be found in
    but not in the latest official working draft
    Putting the reference to the latest draft in your docs could be handy!

    ====== Dublin Core as a Simple Provenance Vocabulary

    I'm uncomfortable with the strict categorization of elements into
    "descriptive" and "provenance" metadata. Some elements are
    questionable to belong to one or the other. You've addressed already
    many doubts, but maybe you should acknowledge that you
    categorization is not "hard" or if it is, give more rationale for
    the questionable elements...
    My personal list:
    - hasPart, isPartOf: Perhaps isPartOf has indeed often a provenance
    flavor, especially when it's used from one element of a collection
    to that collection. But I'd argue many of their uses can be
    descriptive, especially hasPart. Unless you consider a mereological
    description of objects (typical example of a car having wheels) to
    be always about provenance?
    - conformsTo, rights and accessRights may reflect provenance info
    (though it is "derived")
    - accrual properties: I wonder whether all should be in
    (accrualPolicy seems interesting for provenance) or out
    (accrualMethod could be questioned). But a mixed position seems strange.

    By the way method-wise, should there be strict correspondence
    between the elements in the "provenance" category and the ones that
    are mapped to a PROV element in the direct mapping?
    What does it say on an a given element, if it's in the "provenance"
    category but is not mapped to PROV?

    Other comment:
    It can be questioned if a resource changes by being published,
    however, we consider the publication as an action that affects the
    state of the resource and therefore it is relevant for the provenance.
    -> if provenance is about "where does an object come from", then
    this one is a no-brainer!

    ====== Basic considerations

    if a specialization of a document is generated by one activity and a
    specialization is used by a different activity later in time,
    -> What does "specialization" mean, in practice? I know that it is a
    notion from PROV, but the word is highly ambiguous, a Primer would
    benefit from some (short) explanation here.

    By the way yourself are using "specialization" for something else
    (the extension of PROV for handling DC "nuances").

    ====== What is ex:doc1?

    it is semantically incorrect to have several activities that all
    generate the same entity at different points in time.
    -> Please cite the PROV context explicitly here!
    Many people (I'd expect most) will gladly accept that several
    activities contribute to the realization of one same resource. Even
    in a FRBR or CIDOC-CRM context, which are already seen as (too)
    fine-grained models by many.
    By the way, I think later you try indeed to relate to simpler
    approaches, so that must mean you thing it is *not* semantically
    incorrect ;-)

    ====== Direct mappings

    dct:date rdfs:subPropertyOf prov:generatedAtTime .
    seems dubious. dct:valid is a sub-property of dct:date, which means
    that it is also a sub-property of prov:generatedAtTime. You
    correctly represent this in the mapping document, btw. But I'm quite
    sure this relation does not hold in absolute.

    dct:rightsHolder rdfs:subPropertyOf prov:wasAttributedTo .
    This also seems strange at first sight. Looking at the definition
    for dct:rightsHolder:
    "A person or organization owning or managing rights over the
    resource." This may include some institution who manages/stores a
    resource on behalf of its creator, or anyone who "owns" the resource.
    I think is compatible with PROV's super-vague meaning of attribution
    ("Attribution is the ascribing of an entity to an agent.",
    http://www.w3.org/TR/prov-dm/). But that's quite a stretch from what
    many Dublin Core readers will understand for "attribution". Perhaps
    you could give some explanation!

    ======= PROV Specializations (and rationale for complex mappings)

    The constructs introduced and their mapping to PROV seem ok.
    But I think you could say one sentence about the rationale of these
    specializations. I understand the need to "properly reflect the
    meaning of the Dublin Core terms". Yet, do we need to go for a
    solution that result in having the complexity of patterns of PROV
    next to the semantic distinctions made in DC? We could as well just
    keep the granularity of DC, in terms of patterns. I.e., using the
    simple mappings between DC properties and the related "short-cut
    properties" in the PROV patterns (e.g., prov:wasAttributedTo).

    This of course relates for the rationale for having complex mappings
    in the first step. There are several options that PROV offers, in
    terms of granularity. Especially, having more or less fine
    distinctions for linking agents to entities. For a same "creation
    data" PROV can represent direct links between persons and created
    resource (prov:wasAttributedTo), links between persons and resources
    via Activity (prov:wasAssociatedWith) and links between persons and
    Activity via Roles.

    Having all of these levels of granularity at once is probably more
    harmful than beneficial, given the complexity of the PROV pattern in
    general (especially with "specializations"!). Or are the complex
    mappings just an *option* you provide? If yes, a small paragraph
    elaborating on this would be useful for your primer. In fact, it may
    be enough to gather some sentences you already have scattered in
    different sections.

    ======= Complex mappings, Stage 1

    A lot of blank nodes are created, however, keep in mind that we
    envision a second stage that relates them and provides stable URIs
    for the entities.
    -> Everyone won't be ready to create and maintain URIs for all the
    entity/activity/role splitting in the PROV pattern, certainly. What
    is the application scenario for this? I guess it would depend. So
    maybe at this stage it's safer to say that some applications would
    create URIs, some would keep to blank nodes. And of course many
    others won't use the more complex mappings.

    Other comments:

    - I don't get why you opted for a simpler mapping pattern for
    "Entity/Entity (How)". It's quite equivalent to the sub-property
    mappings you have in the "Direct mappings" sections. According to
    the PROV model, for a simple "version" link you can create one or
    several creation activities, as well as half a dozen of "in" and
    "out" views/specializations of the document, which play each a
    different role in these activities.
    I understand you would want a simple mapping (so do I) but in this
    Primer perhaps you should make a bit clearer reference on why you
    made that choice here, as opposed to the more complex mappings that
    are listed before this one.

    - Is Prov:Entity provided with any specific semantics? If not, then
    perhaps you can remove the explicit rdf:type that links to it. That
    would make the example graphs simpler.

    ====== Conflating PROV specializations

    I understand that the stage 2 of the complex mapping will "merge" a
    lot of the "ins" and "outs" nodes of individual activities. This
    should already a progress compared to the extreme atomization that
    is currently carried out. I'm looking forward to seeing the details!

    However, it seems this will still result in one entity being
    specialized into at least as many "versions" as there will be
    activities. I expect many in our community will just hate having
    that. In fact that could be smartly related to modeling distinctions
    such as the ones made in FRBR.
    But then (or even without it) we run into the kind of problems
    denounced here:
    http://blogs.ecs.soton.ac.uk/webteam/2010/09/02/the-modeler/ ;-)

    In this respect, it would be a good idea to at least make these
    specialization distinctions *optional*. Is it really not possible to
    have several activities carried out on a single instance of entity,
    say, the ex:doc1 in your example?

    ======= [end]

        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

        The work has been divided in several documents to improve

        - 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

        - Finally, the Complex-Mappings document [4] infers PROV
        statements from DC statements that are not covered by the direct

        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.

        Daniel will briefly present the current state in the PROV call
        tomorrow. If you have any questions or comments, please don't
        hesitate to contact us.

        Kai, Daniel, Michael and Simon.

        [1] https://github.com/dcmi/DC-PROV-Mapping/wiki/Mapping-primer
        [2] https://github.com/dcmi/DC-PROV-Mapping/wiki/Direct-Mappings
        [4] https://github.com/dcmi/DC-PROV-Mapping/wiki/Complex-Mappings-S1

On 6/9/12 11:32 PM, Ivan Herman wrote:
> There was a presentation on Prov at SemTech, as you all know, done by Reza. There was a brief discussion regarding the relationship of Prov to Dublin Core, essentially asking why Prov uses its own Agent or Person and not the Dublin Core one. We told the commenter that there is a document coming up that makes connections and equivalences between the two. However, the persons (I think both were from governmental organizations) were not absolutely happy. Essentially, they said having, say, an owl equivalence set up between dct:Agent and prov:Agent is all good and does things on a theoretical level, but when a government agency has to choose which terms they want to use, it is very disturbing to have two formally defined one, and RDF environments do not necessarily handle owl equivalences. Ie, they would prefer if prov would simply use, say, dct:Agent outright, rather than having its own term (I have not checked whether there are more such 'equivalences' set up between DC and Prov, or whether all the others are subclasses/subproperties).
> The argument is compelling, we should probably consider this.
> Cheers
> Ivan
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Sunday, 10 June 2012 06:34:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:16 UTC