Re: Contextualization ---> Optional bundle in Specialization

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.

Luc

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