Re: Contextualization ---> Optional bundle in Specialization

On Jun 27, 2012, at 6:57 PM, Graham Klyne wrote:

> On 27/06/2012 22:21, Luc Moreau wrote:
>> Hi Jim,
>> 
>> ex:Bob refers to a single resource in this example.
>> The interpretation of ex:Bob does not change according to the graph it occurs in.
> 
> Quite.  So what basis is there for claiming that two specializations of ex:Bob are somehow distinct,

One doesn't know whether the specializations are distinct or if they are unique.
We do know that they are prov:alternates :-)

> and that inferences that are true for one such specialization are not true for the other?

We don't, since we can't prove identity or distinctness.

-Tim


> 
> #g
> --
> 
>> On 27/06/12 19:33, Jim McCusker wrote:
>>> What Graham is objecting to (I think) is the idea that ex:Bob in one graph is
>>> referring to something different from what ex:Bob is referring to in another
>>> graph. That's not possible in RDF, as while we can have more than one symbol
>>> (IRI) denote the same resource, it's by definition impossible for a symbol to
>>> denote multiple resources in different contexts. The symbol is universally
>>> scoped if it is an IRI. If it is not universally scoped, it needs to be
>>> anonymous or skolemized.
>>> 
>>> GK, correct me if I misunderstood.
>>> 
>>> Jim
>>> 
>>> On Wed, Jun 27, 2012 at 2:21 PM, Paul Groth <p.t.groth@vu.nl
>>> <mailto:p.t.groth@vu.nl>> wrote:
>>> 
>>> So the use case is the issue?
>>> 
>>> I really don't get how the example breaks any semantics. Sorry...
>>> 
>>> So I think that your approach to allowing a qualified
>>> specialization would be fine with me especially if we add a
>>> inBundle predicate that identifies a bundle. but Tim was really
>>> really against this because of the increased number of triples.
>>> 
>>> Paul
>>> 
>>> 
>>> On Jun 27, 2012, at 19:48, Graham Klyne <graham.klyne@zoo.ox.ac.uk
>>> <mailto:graham.klyne@zoo.ox.ac.uk>> wrote:
>>> 
>>> > On 27/06/2012 18:39, Paul Groth wrote:
>>> >> Hi Graham
>>> >>
>>> >> These are two different urls so they identify different things.
>>> >
>>> > Not necessarily, There is no unique-name assumption in RDF.
>>> They could denote
>>> > the same thing.
>>> >
>>> >> The fact that we add some properties like bundle or
>>> specializationof doesn't break anything. I can do that with any
>>> resource on the web, no?
>>> >
>>> > Adding the properties per se doesn't break anything, but when
>>> they are presented
>>> > as addressing a use-case that I don't believe can be addressed
>>> by RDF semantics,
>>> > they run the risk of encouraging people to creating RDF data
>>> that doesn't mean
>>> > what they think it means when interp[reted in accordance with
>>> RDF semantics.
>>> >
>>> > #g
>>> > --
>>> >
>>> >> Paul
>>> >>
>>> >> On Jun 27, 2012, at 19:09, Graham
>>> Klyne<graham.klyne@zoo.ox.ac.uk
>>> <mailto:graham.klyne@zoo.ox.ac.uk>> wrote:
>>> >>
>>> >>> On 27/06/2012 10:49, Luc Moreau wrote:
>>> >>>> All,
>>> >>>>
>>> >>>> At the face to face meeting, we have agreed to rename
>>> contextualization and mark
>>> >>>> this feature
>>> >>>> at risk. Tim, Stephan, Paul and I have worked a solution that
>>> we now share with
>>> >>>> the working group.
>>> >>>
>>> >>> I'm afraid I still have a problem with this.
>>> >>>
>>> >>> Considering your bundle tool:analysis01:
>>> >>> [[
>>> >>> bundle tool:analysis01
>>> >>> agent(tool:Bob-2011-11-16, [perf:rating="good"])
>>> >>> specializationOf(tool:Bob-2011-11-16, ex:Bob, ex:run1)
>>> >>>
>>> >>> agent(tool:Bob-2011-11-17, [perf:rating="bad"])
>>> >>> specializationOf(tool:Bob-2011-11-17, ex:Bob, ex:run2)
>>> >>> endBundle
>>> >>> ]]
>>> >>>
>>> >>> The problem is that, if subject to RDF semantics for URI
>>> interpretation, I can
>>> >>> see no semantic distinction is possible between
>>> >>>
>>> >>> tool:Bob-2011-11-16
>>> >>> and
>>> >>> tool:Bob-2011-11-17
>>> >>>
>>> >>> I.e. they are both specializations of ex:Bob, and that is all
>>> we can know about
>>> >>> them, as (by the nature of the semantics of URI
>>> interpretation) the denotation
>>> >>> of ex:Bob that appears in ex:run1 is the same as the
>>> denotation of ex:Bob that
>>> >>> appears in ex:run2.
>>> >>>
>>> >>> ...
>>> >>>
>>> >>> I do, however, have a different compromise that provides a
>>> hook for introducing
>>> >>> possible semantics later, or in private implementations,
>>> without sneaking in
>>> >>> something that could well turn out to be incompatible with, or
>>> just different
>>> >>> than, what the RDF group may do for semantics of datasets.
>>> >>>
>>> >>> The hook is this: simply allow attributes for the
>>> specializationOf relation, but
>>> >>> don't define a specific attribute for bundle. This would
>>> allow you to do a
>>> >>> private implementation of the scheme you describe, but would
>>> not allow it to be
>>> >>> mistaken for something that has standardized semantics. As in:
>>> >>>
>>> >>> specializationOf(tool:Bob-2011-11-17, ex:Bob,
>>> >>> [myprivateattribute:bundle=ex:run2])
>>> >>>
>>> >>> ...
>>> >>>
>>> >>> In case you think I'm jumping at shadows here, I'll note that
>>> RDF has been here
>>> >>> before. The original 1999 RDF specification described
>>> reification without
>>> >>> formal semantics. Reification was intended to allow for
>>> capturing this kind of
>>> >>> information - i.e. to make assertions about context of use,
>>> etc - a kind of
>>> >>> proto-provenance, if you like. But when the group came to
>>> define a formal
>>> >>> semantics for RDF, there were two possible, reasonable and
>>> semantically
>>> >>> incompatible approaches; looking at the way that reification
>>> was being used "in
>>> >>> the wild", it turned out that there was data out there that
>>> corresponded to both
>>> >>> of these (incompatible) approaches. This was in the very
>>> early days of the
>>> >>> semantic web, so the harm done was quite limited. I think a
>>> similar mistake
>>> >>> today would cause much greater harm.
>>> >>>
>>> >>> I think the appropriate way forward is to take this tool
>>> performance analysis
>>> >>> use-case to the RDF-PROV coordination group, and ask that it
>>> be considered as
>>> >>> input when defining semantics for RDF datasets. I would
>>> expect that whatever
>>> >>> semantic structure they choose, it should be able to
>>> accommodate the use-case.
>>> >>> Then, we should be better placed to create an appropriate and
>>> compatible
>>> >>> contextualization semantics for provenance bundles. But until
>>> then, I think we
>>> >>> invite problems by trying to create a standardized data model
>>> structure without
>>> >>> standardized RDF-compatible semantics to accommodate this
>>> use-case.
>>> >>>
>>> >>> #g
>>> >>> --
>>> >>>
>>> >>> Tracker, this is ISSUE-385
>>> >>>
>>> >>> On 27/06/2012 10:49, Luc Moreau wrote:
>>> >>>> All,
>>> >>>>
>>> >>>> At the face to face meeting, we have agreed to rename
>>> contextualization and mark
>>> >>>> this feature
>>> >>>> at risk. Tim, Stephan, Paul and I have worked a solution that
>>> we now share with
>>> >>>> the working group.
>>> >>>>
>>> >>>> Given that contextualization was already defined as a kind of
>>> specialization, we
>>> >>>> now allow an optional
>>> >>>> bundle argument in the specialization relation. (Hence, no
>>> need to create a new
>>> >>>> concept!)
>>> >>>>
>>> >>>> See section 5.5.1 in the current Editor's draft
>>> >>>>
>>> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-specialization
>>> 
>>> >>>>
>>> >>>> Feedback welcome.
>>> >>>>
>>> >>>> Regards,
>>> >>>> Luc
>>> >>>>
>>> >>>> PS. Tracker, this is ISSUE-385
>>> >>>>
>>> >>>
>>> >>
>>> >>
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Jim McCusker
>>> Programmer Analyst
>>> Krauthammer Lab, Pathology Informatics
>>> Yale School of Medicine
>>> james.mccusker@yale.edu <mailto:james.mccusker@yale.edu> | (203) 785-6330
>>> http://krauthammerlab.med.yale.edu
>>> 
>>> PhD Student
>>> Tetherless World Constellation
>>> Rensselaer Polytechnic Institute
>>> mccusj@cs.rpi.edu <mailto:mccusj@cs.rpi.edu>
>>> http://tw.rpi.edu
>> 
> 
>

Received on Thursday, 28 June 2012 12:00:20 UTC