Provenance Working Group Teleconference -- 24 Jan 2013

<trackbot> Date: 24 January 2013

<pgroth> Scribe: Curt Tilmes

<Curt> scribe: Curt

<stain> minutes from last week, btw: http://www.w3.org/2011/prov/meeting/2013-01-17

Admin

<pgroth> http://www.w3.org/2011/prov/meeting/2013-01-17

<tlebo> +1

<dgarijo> +1

<stain> -1

<stain> All reviewers have submitted their report. All are fine for a new working draft to be released.

<jcheney> 0 was away

<smiles> +1

<Luc> that was my understanding too

pgroth: Will edit minutes to indicate Stain not ready to approve release
... will delete the line about ready to release working draft

<stain> Stain: had not said yes/no to it being released as WD (I don't remember that being mentioned at all) but I said no for it to be last working draft.

<pgroth> http://www.w3.org/2011/prov/meeting/2013-01-17

<stain> +1

<pgroth> approved: Minutes of Jan. 17, 2013

WG Implementations

pgroth: went through implementation reports, quite a few more submitted

<stain> I read the chat log - we agreed that we would in a later meeting vote if PROV-AQ would go out as a WD - not as LC

pgroth: we're ok with prov-o, need to check with prov-n to hit requirements

<Luc> paolo says that his implementation can consume prov-n

pgroth: with constraints, Paul is still working on one, should be ready to go before next week, not sure if there will be others

<stain> what about the clarkparsia one

pgroth: may get one more, not sure

<Luc> maybe we can check he can consume prov-n generated by toolbox or Dong's store

pgroth: are other reports expected?

Stephan and I will be submitting one

<tlebo> I owe at least one :-)

<Luc> GLD Org

<stain> I have my vocabulary to go in

<stain> PAV

<Luc> +q

luc: paolo indicated he can consume prov-n
... dong's tool exports prov-n, so we can check if those implementations can exchange prov-n

<TomDN> not yet

<TomDN> will do next week

pgroth: Tom, can your's work with prov-n?

<Luc> no he sent regrets

pgroth: Try to get all reports in by next week to satisfy implementation requirements
... We will follow up with Paolo and Dong to try to get a prov-n repot
... Keep encouraging others to submit

Public Response on wasQuotedFrom

simon: the primer was unclear in the direction of the wasQuotedFrom, sounded incorrect to the reviewer -- will revise the language in the primer
... will also include something about collections, this might help explain the concepts

<pgroth> http://www.w3.org/2011/prov/wiki/ResponsesToPublicCommentsCR#ISSUE-616

pgroth: several people expressed support for simon's proposed response already
... any objections?

<pgroth> Approved: http://www.w3.org/2011/prov/wiki/ResponsesToPublicCommentsCR#ISSUE-616 as a working group response

<smiles> I'm happy to send it

PROV-O outstanding issue on inferences

<pgroth> http://lists.w3.org/Archives/Public/public-prov-comments/2013Jan/0016.html

pgroth: we responded to clarkparsia's issues, they were mostly fine with the responses except for one:

<tlebo> do we have a start of a response to this?

pgroth: They are concerned we are encoded some constraints and not others and want to understand rationale

tlebo: The critique is understandable, queried James about constraints, plan is to analyze constraints and come up with a rationale for which ones are in and which ones aren't

<tlebo> +1 to survey.

<Luc> http://lists.w3.org/Archives/Public/public-prov-wg/2013Jan/0104.html

<tlebo> where is our draft response?

Luc: not certain we need to change prov-o, the design had a hierarchy for influence

<pgroth> This was our original response http://www.w3.org/2011/prov/wiki/ResponsesToPublicCommentsCR#ISSUE-612_.28Encoding_of_Constraints_in_OWL.29

<tlebo> are we updating the same response for this?

Luc: This hierarchy happens to include one of the constraints, but it isn't really included because it is a constraint, rather it is satisfied by the expression of the hierarchy

<dgarijo> @tlebo: I'm not been following this thread very much, but wasn't prov-o aimed to be as simple as possible (owl-RL profile)?. If no further violations happen, we could add some..

<stain> +1 @Luc -- if we are to remove all subproperty/subclass rules that might happen to be also a constraint/inference - then it would just become a very flat vocabulary and not an ontology.

<satya> +1 @Daniel

<dgarijo> +1 to survey as well.

tlebo: Until we understand which are in, which are out, can't respond. If we can describe a rationale that matches the implementation, that will be fine.

<stain> We could however see the most obvious ones and see if they can go in without changing the design and OWL RL level - like revision-is-alternate-inference

<dgarijo> yep.

pgroth: we didn't intend to include constraints in prov-o, we will create a new issue to address this

<dgarijo> +q

dgarijo: are we planning to deliver a version with constraints?

pgroth: no

<dgarijo> ok.

Luc: Back to modifying prov-o -- that would take us back to last call: we don't want to take that step lightly

tlebo: we'll search hard for a rule that describes the current implementation

<dgarijo> @stian : I can't hear you very well.

stain: [mumble, mumble]
... opposed to adding new things to current prov-o

pgroth: we don't intend to put constraints in prov-o, but are fine if someone else develops an ontology that does so

<stain> sorry - I was suggesting to NOT add more to PROV-O - but make something on the side (another Note) with the OWL encodings of constraints - it could be based on the work that clarkparsia has already started if the licensing/sharing of that is OK.

pgroth: we will describe the rationale for why certain constraints happen to be in prov-o

<satya> +1 @paul, the original design aim of prov-o was a reference ontology, so we should be careful of adding new constructs

<Luc> scruffy provenance

Luc: Tim -- when do you think it will be ready?

tlebo: a couple of hours at most

<stain> Stian: to also add to rational "why we do NOT include some 'obvious' constraints like property functionality --- basically to support expressing 'scruffy provenance' according to PROV-DM which might not be PROV-Constraint valid

Luc: Would be nice to draft response by Monday and send ASAP

pgroth: There could be test cases for entailments -- would be fine if someone else supplied them

Luc: not sure we would express them -- we are only concerned with validity of the provenance

<Dong> I wondering what would be the extra benefits of having such test cases for the working group?

pgroth: If someone invented the test case, we would look at it
... More test cases that conform to the spec are welcome

<Luc> +1

<Dong> I'm afraid that we don't have enough bandwidth for this

pgroth: I'll write that up and send it out with the response on the prov-o

Prov-Dictionary

TomDN: Looked at all the reviews, 3 already incorporated, 1 more extensive one will go in

<stain> but I'm on mute..

<TomDN> Tom: All sections got good, extensive reviews

<TomDN> Tom: Some remaining issues:

<TomDN> Tom: 1. (Luc) In the notation hadDictionaryMember(d, e0, "k0"), key follows entity, whereas it precedes in derivedByInsertionFrom(d2, d1, {("k1", e3)}). Should this be made uniform? Is it worth the extra effort?

<TomDN> Tom: 2. (Luc) http://www.w3.org/TR/prov-n/#extensibility states: the predicate MUST be a qualifiedName with a non-empty prefix. However, we will be using the prov namespace. How do we proceed?

<TomDN> Tom: 3. (Luc) PROV-O: should qualifiedInsertion and qualifiedRemoval imply qualifiedDerivation? If yes, how do we specify this? Through a sub-property? Does that break anything?

<TomDN> Tom: 4. (Paolo) PROV-O: clarify delta with REC ontology

<TomDN> Tom: 5. (James) Do we need inference 7 to guarantee completeness when a dictionary is derived by insertions/removals from an empty dictionary?

<TomDN> http://dvcs.w3.org/hg/prov/raw-file/default/dictionary/prov-dictionary.html#insertion-removal-membership-inference

<TomDN> Tom: 6. Stian has lots of blocking issues, and I haven't had time to address them all.

<TomDN> Most are relatively easy to fix or have been fixed already. Most work will be to create the downloadable grammar, ontology and xml schema.

<TomDN> Propose we vote for publication as FPWD under the condition that all Stian's blockers are addressed, and that (placeholder) links are placed in the document, where the grammar, ontology and xml schema will become available next week.

<Luc> given this is fpwd, grammar/schema/ontology can be released later

<Zakim> stain, you wanted to suggest just adding note on the PROV-N namespace/extension for 1WD

stain: Sorry about big list of blockers, but renaming can remain as now, other yellow boxes noting changes would be ok

pgroth: Note where discussion is still underway or big changes are to come

<pgroth> Proposed: Release Prov-dictionary as first public working draft

<TomDN> +1

<khalidBelhajjame> +1

<satya> +1

<dgarijo> +1

<Dong> +1

<hook_> +1

<SamCoppens> +1

<TomDN> conditional :)

<smiles> +1

<tlebo> +1

stain: is FPWD conditional on my blockers?

<pgroth> Proposed: Release Prov-dictionary as first public working draft conditional on addressing or noting blocking issues in the document

pgroth: they will be addressed or noted

<stain> +1

<khalidBelhajjame> +1

<TomDN> +1

<dgarijo> +1

<smiles> +1

<jcheney> +1

<hook_> +1

<pgroth> Accepted: Release Prov-dictionary as first public working draft conditional on addressing or noting blocking issues in the document

<TomDN> and sam :)

PROV-xml

http://www.w3.org/2011/prov/wiki/Prov-XML_Identifiers

hook_: wiki document summarizes options and differences between them

<Luc> ID is now workable since we can have multiple assertions about a given resource in a same document (whether wihtin a same bundle or different bundles)

<zednik> I have joined, sorry for the late arrival

<pgroth> maybe stephan can respond

Luc: Why assume we need uniqueness of identifiers, we need to have multiple assertions about a given resource resource in the same document

hook_: We don't have a requirement, but the uniqueness implemented by an XML would be useful, but not a hard requirement

Luc: if you use xs:ID, it would require uniqueness

zednik: looked at how parsers expect the document to act -- they expect identifiers to be unique.
... is this something we desire or do not?

hook_: ID/IDREF are the normal, recommended ways to handle identifiers

stain: XML identifiers are useful for the external (non provenance) world
... But for provenance, we need to express certain things

<Luc> good point stian

stain: Do you want to force things to be explicitly identified in that manner? It isn't required in the other forms

Luc: We can express a usage between an activity and an entity without declaring them.

pgroth: we could also use prov:ref?

<stain> also some XML libraries will parse the xml:idref as if the referenced element was actually inserted there - like a symlink

<stain> @pgroth - ah, so you propose a hybrid approach where you could fall back to prov:ref to be 'loose'?

hook_: You may want to declare activities/entities without the constraints on ids. How can we validate the trace without a formal identification?

<stain> it's not the job of the XML parser to do PROV validation

Luc: That is the job of PROV-CONSTRAINTS.
... With constraints, you can infer those things for validity, but we also want to allow "scruffy" provenance
... With ID, you are making a schema for a 'normal form' of provenance, but we aren't really describing that in the other documents

stain: You can still use IDs to identify things outside of PROV

zednik: We haven't tried something like that

<satya> * sorry, have to leave for a meeting

pgroth: Some good feedback of the limitations to the approaches -- could you revisit the question?

Luc: There are other options, in the schema we had prov:ref with xsd:QName, we could define them as in prov-n, that would work find with XSD2
... Consider that other option

<Luc> ex:001

Luc: If we require an identifier to be an xsd:QName, we can't use many URIs

<stain> some URIs can't be qname - even if you do an xmlns for it - as a qname can't have a 0-length local name

<stain> like... http://example.com/

hook_: I see the need for "scruffy", the XML community uses ID/IDREF, but is there something we can use that is simple, but also allows scruffy
... perhaps the XPointers can enable the scruffiness, pointing to non-existent items

<stain> xpointer can select on anything ("has 3 children"), xpath needs element/id

<Luc> yes

pgroth: QNames are widely used in XML community, right?
... where do we want to go with this? need a decision soon
... Look at other options, come up with rationale for why you think one is the best and we can discuss on the mailing list
... You are leaning toward ID/IDREF with XPointer?

zednik: It fits best with XML community, but difficult constraints for provenance

hook_: Need to take into account need for scruffy provenance

<stain> +1 - the PROV identifiers are like the open-world semantic web identifiers - they don't identify elements in an XML document, but things and activities in the world

Luc: If I write my provenance in XML, can I use the XPointer to refer to entities in RDF? Does this require everything to be in XML?

<tlebo> Why would RDF people bother with Xlink and Xpointers?

hook_: Are there implementations of RDF that can use XLink/XPointers?

<zednik> +1 to tlebo

<khalidBelhajjame> +1 to tlebo

<zednik> +q

pgroth: You have some feedback on identifiers, can you take another look at it and come back with a new proposal or recommendation?

zednik: We can come up with some constraints to drive the search for a solution: "scruffy" must be allowed, must be compatible with PROV-O provenance

<stain> xlink:href can target anything with an URI, not just XML elements - it's just like HTML's <a href> for XML

<Luc> prov-dm says that qualified names can be mapped to uri

zednik: We'll capture the constraints, which will probably eliminate ID/IDREF

pgroth: Other constraint is to work well with XML tools
... There might not be a solution that satisfies all of those, we need a rationale for a choice

<stain> @Luc - so there could be two different qnames resulting in same URI - right. So if this is to be understood by regular XML tools you would have to represent everything as full URIs

hook_: Constraints may be mutually exclusive, which is the most important? scruffy?

pgroth: We want to enable adoption by the XML community, that should be number 1

<Luc> @stain yes, it's possible. XML tools don't map them to uris but a prov processor would

<stain> I guess the question is how much PROV 'tooling' do we imagine would be purely XML based - like using XPointers to find the activity that made an entity that tihs other entity was derived from

pgroth: what do others think about that?

Luc: We didn't discuss the schema namespace reorg -- I have some questions about that

pgroth: Let's discuss the namespace reorg next week

<stain> perhaps we can make more example documents

zednik: Could also put questions on mailing list and also discuss next week

pgroth: Enough guidance for now?

zednik: yes

pgroth: Those are the two big issues: identifiers and namespace?

Luc: We haven't resolved the ordering issue, subtyping either
... Still several other issues

zednik: Subtyping -- we modified the schema to address that, extending elements with new elements

<Luc> @zednik: can you point to this message on primary source?

pgroth: We want to wrap this up, resolving final issues

<zednik> @Luc I will look

<Luc> thank

pgroth: Remember to get in implementation reports

<dgarijo> bbye

<Dong> thanks, bye

<pgroth> trackbot, end telcon

- DRAFT -

Provenance Working Group Teleconference

24 Jan 2013

Attendees

Contents

Admin

WG Implementations

Public Response on wasQuotedFrom

PROV-O outstanding issue on inferences

Prov-Dictionary

PROV-xml

Summary of Action Items

Scribe.perl diagnostic output