Re: Contextualization ---> Optional bundle in Specialization

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> 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> 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>
> 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 | (203) 785-6330
http://krauthammerlab.med.yale.edu

PhD Student
Tetherless World Constellation
Rensselaer Polytechnic Institute
mccusj@cs.rpi.edu
http://tw.rpi.edu