Re: owl:sameAs - Is it used in a right way?

On Mar 17, 2013, at 8:40 PM, David Booth wrote:

> > On Sun, Mar 17, 2013 at 12:51 AM, Alan Ruttenberg wrote:
> >
> >     My dad's name is Danny. I've known him a Long time, during which
> >     he's changed a lot. Am I supposed to stop calling him dad because
> >     he's not precisely the same as he was when I was 10?
> 
> On 03/17/2013 01:05 AM, Jim McCusker wrote:
>> No, that symbol contains the full scope over which you've known your
>> dad, plus anything you've learned about him before. However, there are
>> narrower contextual scopes in which you may make specific claims about
>> that may not always be true (my Dad when I was 12, for instance).
> 
> Exactly.  In one contextual scope certain properties of :alansDad hold -- that's the notion of :alansDad over his whole life -- and in a narrower contextual scope certain *additional* properties of :alansDad hold, such as the fact that he is 12 years old.

If you are understanding the person identifier to denote a continuant (the most usual decision in this case) then to assert something time-sensitive about him without an explicit time marker or time parameter, is simply wrong.  If, on the other hand, you are understanding :alansDad to denote a 4-dimensional entity extended in time, then you should assert the property not of him as a whole but rather as applying to a temporal part of him. Either way, you need to be explicit about the time parameter somewhere in your data. 

> In the semantic web world, these "contextual scopes" are RDF graphs.

No, they aren't. That interpretation of RDF graphs is in direct violation of the RDF specifications. RDF graphs are simply sets of assertions, all in a non-contextual (and non-indexical) logic with no contextual sensitivity. 

> 
> Now we can see that in a different "narrower contextual scope" (i.e., a different RDF graph), someone might make statements about :alansDad when he was 26.

This is simply a design error when using RDF. One should not make contextual assertions in RDF, as RDF assertions are defined by the normative RDF specifications to be non-contextual. 

>   Suddenly, this graph is inconsistent with the graph that asserted that :alansDad was 12.

Indeed, which is why this is a bad way to proceed. It is not a "problem", it is just an RDF/ontological mistake. 

>  This is exactly the problem illustrated in Figure 26:
> http://dbooth.org/2010/ambiguity/paper.html#inconsistent-merge
> 
> A different URI could be used for Alan's dad in each of these "narrower contextual scopes" (i.e., different graphs), such as :alansDadAt12 and :alansDadAt26.  The downside of this is that if different URIs are used, it is much harder to know that they are all talking about the same thing . . .  well, the same thing at one granularity (:alansDad), but different things at a finer granularity (:alansDadAt12 and :alansDadAt26).  

There are no granularities built into RDF or in IRI usage. If you want ideas like this, you need to invent (or find) an ontology of granularities and use whatever machinery it describes. For example, you might have 

:alansDadAt12  gr:temporalPartOf  :alansDad .

and give an OWL ontology for temporalPartOf. It might be transitive, for example, or it might be functional, but probably not both.

> This problem can be mitigated by using RDF properties to relate these URIs, such as broader/narrower relations as first proposed in
> http://dbooth.org/2007/splitting/#isBroaderThanDeclaration
> and later defined slightly differently by the Provenance working group:
> http://www.w3.org/ns/prov#specializationOf
> 
> The dilemma is that *every* new RDF statement that you make about a resource creates a "narrower contextual scope". Thus, if we are to completely avoid this problem, we would have to mint a new URI every time we want to make any statements at all about :alansDad !   This certainly seems like a good approach in some cases -- as Jeremy suggested -- but I am not sure that it would be very palatable to do that every time you wish to use any URI.  Yet if you don't do that every time, then you run the risk of creating specializations that become inconsistent when they are merged, as previously discussed.

There is no risk associated with forming a merge. You only get an inconsistency from a merge when the inconsistency was already present in the un-merged RDF. Merging is always a logically valid operation in RDF. 

Pat


> 
> My guess at present is that the best approach is to try to choose a good balance between reusing existing URIs and minting new URIs with more specialized definitions.  But that's just a guess: I could certainly be convinced differently tomorrow.
> 
> David
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 18 March 2013 05:25:40 UTC