Re: Contextualization ---> Optional bundle in Specialization

<snip>

> All attributes are considered to be Entities' presented aspects. So it counts "towards the specialization".
> 
> -Tim

Hi,

[I'll continue to call the 3-ary relation "ctxOf", for now.]

I don't view the property "being described in bundle b" as the same kind of attribute as normal attributes - to me, attributes describe properties of the underlying Thing, in the semantics, not properties of the entities describing the Thing in the syntax.  Of course, not all of us believe in Things.

One can easily get paradoxes by blurring this distinction [1].

If all that we need is a way to be able to say "e2 is a specialization of e1 which is described in bundle b", then would the following suffice:

1.  Leave out ctxOf (or the 3-ary form of specializationOf)
2.  Add a special attribute "prov:inBundle" that any entity (or indeed anything else) can have, linking each entity id to a bundle it appears in (there may be more than one).
3.  Then instead of ctxOf(e2,e1,b) we just say specializationOf(e2,e1).  The fact that e1 happens to be in bundle b gets transferred by e2, along with all other attributes.  (Which seems weird to me, since e2 isn't explicitly mentioned in b, but if being in a bundle is just an ordinary attribute, then it should be transferred by specialization just like every other attribute).

I don't see how this addresses the original motivation for ctxOf, but don't see that it does any harm - the complications arise if we start trying to assign different meaning to "entity e" and "entity e in bundle b".

Just putting this out there - I am not pretending to understand that I understand what ctxOf means at this point, and so the probability that I'm barking up the wrong tree is high.  But maybe finding out why this is wrong will be educational.

--James

[1] http://en.wikipedia.org/wiki/Richard%27s_paradox

> 
> 
>> 
>> Best,
>> Satya 
>> 
>> 
>> Professor Luc Moreau
>> Electronics and Computer Science
>> University of Southampton 
>> Southampton SO17 1BJ
>> United Kingdom
>> 
>> On 27 Jun 2012, at 22:53, "Satya Sahoo" <satya.sahoo@case.edu> wrote:
>> 
>>> Hi,
>>> 
>>> Are you trying to say that if
>>> 
>>> specializationOf(luc-in-boston,luc)
>>> specializationOf(luc-in-soton,luc)
>>> 
>>> You cannot see any semantic distinction between luc-in-boston and luc-in-soton?????
>>> Surely, there is a difference!
>>> 
>>> Difference in identifiers (string value) does not mean they will be interpreted differently (semantics), unless the "-boston" and "-soton" have associated formal semantics - with just the above two assertions they do not. 
>>> 
>>> specializationOf(UK, country) (actually should be instantiation in SW...)
>>> specializationOf(UnitedKingdom, country) 
>>> 
>>> 
>>> Best,
>>> Satya
>>>  
>>> Likewise, tool:Bob-2011-11-16 and tool:Bob-2011-11-17 can be distinguished by the additional aspect
>>> they present (bundle ex:run1 or bundle ex:run2).
>>> 
>>> In this example, we have three different identifiers
>>> ex:Bob
>>> tool:Bob-2011-11-16
>>> tool:Bob-2011-11-17
>>> each with a single denotation: i.e. no denotation that is context specific.
>>> 
>>> I don't see what the issue is.
>>> 
>>> Luc
>>> 
>>> 
>>> 
>>> 
>>> Luc
>>> 
>>> 
>>> ...
>>> 
>>> 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
>>> 
>>> 
>>> 
>> 
>