Re: Another try.

On Feb 22, 2012, at 02:14 , Pat Hayes wrote:

> 
> On Feb 21, 2012, at 3:43 PM, Pat Hayes wrote:
> 
>> 
>> On Feb 21, 2012, at 5:44 AM, Andy Seaborne wrote:
>> 
>>> 
>>> 
>>> On 21/02/12 07:56, Pat Hayes wrote:
>>>> For conservatives among us, the opposite re-interpretation is always
>>>> available. Any quad-graph can be thought of as a SPARQL dataset, by
>>>> 'slicing' the quads according to their last argument, and
>>>> re-declaring this parameter to be a graph label. However, to retain
>>>> the semantic flexibility (ie to have the triples in each graph able
>>>> to be re-interpreted differently in each labeled graph), we would
>>>> have to modify the RDF semantics to allow for this graph-local
>>>> context being involved in the truth recursions. And as already noted,
>>>> it is simpler, and much less of a change ot the basic RDF model,  to
>>>> do this by thinking of this construction in the quad-graph way as
>>>> being a set of property-with-three-argument quads rather than as a
>>>> collection of labelled sets of two-argument triples. And as so many
>>>> of the 'natural' uses of datasets seem to want to take advantage of
>>>> the apparent contextual' possibility of the graph label, and this
>>>> option is only available in a quad-store format in any case, it seems
>>>> comparatively harmless to attach the needed semantics directly to
>>>> this quad store format, rather than tinker with the semantics of
>>>> triples or try to make sense of graph 'names' which do not denote
>>>> graphs.
>>> 
>>> I was wondering about existing vocabularies.
>>> 
>>> If I understand the quad proposal, then all existing vocabularies are technically undefined because they never define P(S,O,G), only P(S,O).
>> 
>> No, that is fine. IEXT can be purely a set of triples in the new semantics, so every old interpretation is still a new interpretation. And that does "define" the value of P(S, O, G): its always flase, for any G. But in any case, RDF vocabularies are never *defined*, strictly speaking. They mean whatever their owner specifies them to mean. Right now, for example, any quad with a property in the rdf: or rdfs: namespaces is simply false, as a kind of default, but we are free to change this if we want to (without changing any of the triples, of course.) Actually I would recommend that we don't, since the rdf: and rdfs: vocabularies are not intended to be used 'contextually' (eg they dont change with time and should be resistant to subjective re-interpretation) so it would be good to restrict them to a purely triple-based meaningful use. Then writing something like 
>> 
>> G: { :A rdfs:subClass :B + } 
>> 
>> would be formally a contradiction (since that *quad* is defined to be false. because being a subclass isn't comething that you can put into a context. Or, we could decide it was, but then we would need to talk rather a lot about kinds of context and what effect they have on subclassing and so forth.) 
>> 
> 
> As an alternative, by the way, we could stipulate that IEXT(I(rdf:anything)) contains *every* triple <x y z>  exactly when it contains <x y>. This makes all the unstated quads have the same vlaue as their inner triple, so that the above example would true just when the triple is true by itself. In this case, there is no real difference between writing it with a dot or with a plus sign, since adding the graph name as a context makes no difference to the truth. This is probably a neater option than forcing an inconsistency, in fact. It is a bit like, if someone says,  2+2=4 on Tuesday, just deciding to ignore the "on Tuesday" rather than making an argument about it. 
> 
> Pat

But the only vocabulary over which we have such control is W3C's vocabularies (RDF(S), OWL, SKOS, whatever). What happens with the others like dcterms or foaf? Wouldn't we still need the '+' syntax somehow

(We would need something else, syntactically. I do not like the '+' sign at that position. But that is obviously a detail.)

Ivan

> 
> 
> 
> 
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf