- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Wed, 6 Jun 2012 19:37:23 +0000
- To: Timothy Lebo <lebot@rpi.edu>
- CC: "public-prov-wg@w3.org" <public-prov-wg@w3.org>
- Message-ID: <EMEW3|f133b5a096e3a29dc7e7751ae280c999o55KbY08L.Moreau|ecs.soton.ac.uk|41A02C2E>
Hi Tim,
It's not about a trade-off data model vs reasoning, it's about defining a data structure
that makes sense.
I would argue that you are not defining a collection of entities but a collection of uris.
That's exactly why we introduced keys in prov dictionaries, so that we could decide
whether something is in dictionary or not.
Professor Luc Moreau
Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom
On 6 Jun 2012, at 20:22, "Timothy Lebo" <lebot@rpi.edu<mailto:lebot@rpi.edu>> wrote:
On Jun 6, 2012, at 3:05 PM, Luc Moreau wrote:
Hi Tim,
Whats the matter?
If you have one entity denoted by two different URIs, and the following assertion:
:collection
a prov:Collection;
prov:hadMember :myMember;
Then I know that one of them is in, and am not sure about the other one.
How are you able to decide if the entity denoted by:myMember-alias is also member of the collection?
Why is identity resolution a requirement for simply saying that something is in a set?
That's an awfully tall order.
Impossible, even.
Since I can mint a URI and make it the same as any of your members's URIs and never tell you about my URI.
Why are we back to choosing when reasoning applies to DM, and when DM just gets to be a data model?
Am I getting confused?
-Tim
Professor Luc Moreau
Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom
On 6 Jun 2012, at 14:49, "Timothy Lebo" <lebot@rpi.edu<mailto:lebot@rpi.edu>> wrote:
Luc,
On Jun 6, 2012, at 12:46 AM, Luc Moreau wrote:
On 5 Jun 2012, at 23:01, "Timothy Lebo" <lebot@rpi.edu<mailto:lebot@rpi.edu>> wrote:
On Jun 5, 2012, at 5:55 PM, Luc Moreau wrote:
Sure, but we said we would just define a collection type for extensibility, and nothing else.
Yes. But with no way to put something into it?
"Thanks for the canoe, W3C… can I have a paddle?"
Then, we should drop the type Collection entirely.
If I have to choose a memberless Collection and no Collection at all, I'd choose a memberless Collection.
membership of entities is not clear,
Yes it is clear, using:
:collection
a prov:Collection;
prov:hadMember :myMember;
.
:myMember a prov:Entity .
Done!
since we don't have
a predicate to decide whether two entities are equal.
Why does this matter?
Are you trying to fulfill a notion of "complete collection".
If so, why?
Furthermore, why not insertion and removal relations?
(… and Membership)
Because it's beyond scope, as the WG agreed during the rename to Dictionary.
We agreed to provide the "harder" Dictionary and let those operations and qualifications to an extension.
We also agreed to include the name of the "abstract" collection.
In the latest PROV-O, prov:Dictionary reuses the prov:hadMember that could also be used for simple Collections.
The latest PROV-O prov:Dictionary is a cheap win, I don't see the reason to go out of our way to prevent people from using or extending Collection.
And, the focus is clearly on prov:Dictionary, as we agreed.
-Tim
Luc
All the rest would be dictionary specific.
Yes, all of the meat would be Dictionary specific.
Insertion and Removal and Membership are Dictionary specific.
That's fine.
I'm having all of that reuse the Collection's hadMember.
(new OWL is up, I'm putting the HTML up now).
-Tim
Professor Luc Moreau
Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom
On 5 Jun 2012, at 22:39, "Timothy Lebo" <lebot@rpi.edu<mailto:lebot@rpi.edu>> wrote:
On Jun 5, 2012, at 5:34 PM, Luc Moreau wrote:
The only membership defined in dm is:
Membership<http://www.w3.org/TR/prov-dm/#concept-membership> memberOf(c, {(key_1, e_1), ..., (key_n, e_n)})<http://www.w3.org/TR/prov-dm/#dfn-memberof>
Why should we define membership on collections?
Because we defined Collection?
"A collection is an entity that provides a structure to some constituents, which are themselves entities. These constituents are said to be member of the collections. "
http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-collection
-Tim
Professor Luc Moreau
Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom
On 5 Jun 2012, at 22:29, "Timothy Lebo" <lebot@rpi.edu<mailto:lebot@rpi.edu>> wrote:
On Jun 5, 2012, at 5:26 PM, Luc Moreau wrote:
Dictionary keys can be compared. Hence, after insertion and removal, we can always determine a new dictionary state if we knew the state before operation.
okay. But why should that prevent someone from asserting that an Entity is a member of a Collection?
I feel like your "we can't assume reasoning/inference; it's a data model" argument applies here (this time, against your position).
-Tim
Professor Luc Moreau
Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom
On 5 Jun 2012, at 22:11, "Timothy Lebo" <lebot@rpi.edu<mailto:lebot@rpi.edu>> wrote:
On Jun 5, 2012, at 5:05 PM, Luc Moreau wrote:
Hi Tim,
Thanks for your example.
The following is not valid according to prov-dm:
prov:hadMember # These would be asserted on a simple (first step)
36<http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l36> <http://dbpedia.org/resource/John_Glover_Roberts,_Jr.><http://dbpedia.org/resource/John_Glover_Roberts,_Jr.>, # prov:Collection.
37<http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l37> <http://dbpedia.org/resource/Antonin_Scalia><http://dbpedia.org/resource/Antonin_Scalia>, #
38<http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l38> <http://dbpedia.org/resource/Anthony_Kennedy><http://dbpedia.org/resource/Anthony_Kennedy>, #
39<http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l39> <http://dbpedia.org/resource/Clarence_Thomas><http://dbpedia.org/resource/Clarence_Thomas>, #
40<http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l40> <http://dbpedia.org/resource/Ruth_Bader_Ginsburg><http://dbpedia.org/resource/Ruth_Bader_Ginsburg>, #
41<http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l41> <http://dbpedia.org/resource/Stephen_Breyer><http://dbpedia.org/resource/Stephen_Breyer>, #
42<http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l42> <http://dbpedia.org/resource/Samuel_Alito><http://dbpedia.org/resource/Samuel_Alito>, #
43<http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l43> <http://dbpedia.org/resource/Sonia_Sotomayor><http://dbpedia.org/resource/Sonia_Sotomayor>, #
44<http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l44> <http://dbpedia.org/resource/Elena_Kagan><http://dbpedia.org/resource/Elena_Kagan>;
The key reason why we went for a dictionary and, say, a set of entities,
is that we are unable to decide whether an entity belongs to a set on the basis of
its urls (since the same entity may be denoted by multiple urls).
huh? Why does that matter? In that case, we wouldn't be able to do it for Dictionaries, either.
-Tim
Luc
On 05/06/2012 06:25, Timothy Lebo wrote:
prov-wg,
I tried my hand at modeling the provenance of the U.S. Supreme Court's current membership, and its derivation to it's first membership.
The wiki page for the example is at:
http://www.w3.org/2011/prov/wiki/Eg-34-us-supreme-court-membership
In an attempt to take a fresh look at how we're modeling dictionaries (and collections?), I didn't reference PROV-DM, PROV-O, or any other examples or documentation -- I just tried to describe the subject matter.
How does it look?
I'd like to move PROV-O (and DM, if it needs tweaking) towards this kind of modeling and naming.
Discussion and feedback encouraged.
Later today, I'll try to start from scratch on the DM and work through the current PROV-O modeling, and then the recent threads on this topic.
I hope by then we can converge on a satisfactory design.
Regards,
Tim
Received on Wednesday, 6 June 2012 19:37:59 UTC