Re: Contexts of use, a semantic idea

On 14/10/11 04:36, Pat Hayes wrote:
>
> On Oct 13, 2011, at 5:16 AM, Andy Seaborne wrote:
>
>> This looks interesting.
>
> Ok, good :-)
>
>>> So, try this for size. We introduce a notion of a 'context of use'
>>> into the RDF concepts/semantics. Every IRI has a unique referent *in
>>> a given context of use*. It might have several of them at once,
>>> however. A CoU can be defined very broadly and can be user-defined,
>>> but it must satisfy some conditions.
>>
>>> 1. It MUST be agreed within a community of use in such a way that
>>> every participant can determine the conditions defining the CoU.
>>
>> Yes
>>
>>> 2. Every CoU MUST specify precise conditions which locally,
>>> syntactically determine for every occurrence of every IRI token
>>> whether that occurrence is governed by the CoU.
>>
>> In practical terms, the context is the 4th slot in the quad?
>
> That is the only example so far, yes. We might call this the
SPARQL/quad CoU convention. But the general idea seems like it might be
of wider utility. What this would be doing, if we put it into the spec,
would be kind of encouraging people to feel free to hack RDF in some
special way if they feel like doing so, and can keep their idiosyncratic
uses from contaminating other RDF. So for example, one way would be to
say that any triple which uses a certain namespace in its property IRIs
is allowed to re-interpret the object IRI in a special way, allowing
metadata to be expressed using graph labels even when those labels have
other interpretations 'externally'.


When boiling the ocean, there are 3 axes but it's a 2-D space:

1/ Size of ocean
2/ Rate of flow of heat
3/ Time to completion

Choose 2, and the 3rd is determined.

So as not to have (3/time) zooming off to infinity, can we start by 
limiting (1/problem space) to just the 4th slot in the quad?


[[
Personally, I'm interested in the whole context discussions; and it it 
probably worth continuing in the general even if it does not direct 
impact the specs updated because it's underlying the discussion anyway.
]]

>>> 3. No IRI occurrence can be in two CoUs simultaneously.
>>
>>> 4. To resolve cases that would violate 3., one CoU can override
>>> another, so that any IRI token which satisfies the conditions for
>>> both CoUs is assigned to the first and not to the second. This may
>>> require agreement between the communities which use each CoU.
>>
>> Do you have an example where collisions of CoU, especially two non-web ones, might arise in one graph?
>
> Sure, consider where an IRI referring to a person, say, is also used in the 4th slot as a graph name. That overrides the person interpretation there. (This is where our present troubles started, right?)
>
>>> 5. There is a default CoU, which is the entire Web. All other CoUs
>>> override the Web CoU. Any IRI token which is not in a more
>>> restricted CoU is in the Web CoU.
>>
>>> If we go with this idea (which has wider utility, I think) then we
>>> don't have to keep getting so anal about 'naming' versus
>>> 'association' , which I think is going to be widely seen as very
>>> confusing and puzzling.
>>
>> "Associates" is certainly a word used to avoid directly "naming".
>>
>> It's an indirection:
>>
>> (<URI>, G)
>>     ==>
>> <URI>  :something :X .  :X :somethingelse G
>
> ? Really? I dont see how the 4th-slot or graph-label<uri, G>  pairings are indirect in this way. They seem quite direct. Am I missing something?

Indirect in the sense it's not directly written out like that.

  (<URI>, G) is short for:

<URI>  :something :X .  :X :somethingelse G


and :X wasn't explicit - it's the nearly-syntactic sugar of the CoU rules.

	Andy

>
> Pat
>
> ------------------------------------------------------------
> 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 Friday, 14 October 2011 12:19:24 UTC