Re: Scoping bnodes

On 12/12/18 8:56 AM, Antoine Zimmermann wrote:
> For me, the problem of scope goes beyond blank nodes.
> 
> It would be good to be able to say (in a standard way), for instance:
> 
> 1) within my scope, this graph has to be interpreted with a unique name 
> assumption (I know the things in my local system, I do not identify them 
> twice)
> 2) within my scope, this graph has to be interpreted with a closed world 
> assumption (I know everything about my things in my local system, if you 
> can't conclude a statement is true from my scoped graph, you can 
> conclude it is false)
> 3) within my scope, bnodes are interpreted as constants (so, the graph 
> "ex:s  ex:p  _:bn1, _:bn2" is effectively not equivalent to "ex:s ex:p 
> _:bn3")
> 4) within my scope, I abide by the RDFS entailment regime (or OWL 2 RL; 
> or OWL RDF-based semantics; or RDF recognising xsd:duration, 
> geo:wktLiterals; etc.) - which means I may not agree with other semantic 
> restrictions made by other standard regimes
> 5) within my scope, this specific set of inference rules hold (such as, 
> that owl:sameAs is reflective and symmetric, but not necessarily 
> transitive) - if you consume my data, you can assume what you want, but 
> you've been warned!
> 
> and possibly more:
> 
> 6) within this scope, the triples are assumed to be truthfuly describing 
> the world as it was at this specific time point / time intervale
> 7) within this scope, the triples are not trustworthy (or only trusted 
> to a certain degree)
> 8) within this scope, the graph describes Mr X's opinion
> etc.

+1.  I like this idea a lot.  And it seems to me that if we had a 
standard way to indicate a semantic extension within a particular scope, 
such a mechanism could address nearly all of these needs.
https://github.com/w3c/EasierRDF/issues/25

David Booth

> 
> 
> Any real life application that consumes an open set of data from the Web 
> has, in any case, to define its scoping mechanism. There's much research 
> work showing that RDF is used all over the web with different 
> assumptions: assumptions regarding bnodes, regarding unique names, 
> regarding closed world, even regarding the meaning of normative terms 
> like rdfs:domain, rdfs:range, owl:sameAs; regarding literals as well. If 
> one ever wants to build an application that consumes Web data at large, 
> one has to put barriers to the normative semantics of Semantic Web 
> standards.  Unfortunately, the standards do not make this explicit, and 
> people have to experience the big slap in the face of Web inference 
> before working out yet another scoping mechanism (or just give up and do 
> GraphQL...).
> 
> 
> 
> --AZ
> 
> 
> Le 10/12/2018 à 00:43, David Booth a écrit :
>> On 12/8/18 2:32 AM, Patrick J Hayes wrote:
>>>
>>>
>>>> On Dec 5, 2018, at 3:41 PM, David Booth <david@dbooth.org> wrote:
>>>>
>>>> On 12/3/18 4:38 PM, Patrick J Hayes wrote:
>>>>>>     Bnodes introduced to encode
>>>>>>     structures like n-ary relational assertions, or lists, or some
>>>>>>     complicated piece of OWL syntax, should have a very narrow scope
>>>>>>     corresponding to the exact boundaries of those structures, and
>>>>>>     hence should be ‘invisible’ from outside (which is why it is fine
>>>>>>     to make them vanish in a higher-level syntax using [ ] or ( ).)
>>>>>>
>>>>>>     Ideally, RDF2 should provide for these structures directly, but
>>>>>>     maybe we can get the benefit with a relatively tiny step, just by
>>>>>>     having a syntax for RDF which has explicit scoping brackets.
>>>>
>>>> Interesting idea, and I can see it being useful for RDF streams or 
>>>> very large RDF datasets -- to enable blank node labels to be safely 
>>>> reused without collision -- but I am also curious:
>>>>
>>>> 1. How would you envision scope names being used?
>>>
>>> I was thinking of them simply as a lexical trick to allow bnodes to 
>>> be ‘bound’ at a particular scope.
>>
>> Actually I was wondering about use cases.  What additional use cases 
>> do you think scoped bnode would address, other than the two that I 
>> mentioned above?
>>
>> Thanks,
>> David Booth
>>
>

Received on Wednesday, 12 December 2018 22:28:00 UTC