Re: RDF Extensibility

On 9 Jul 2010, at 13:25, Jakub Kotowski wrote:
> Henry Story wrote:
>> No need then for any hijacking, that's just such a 70ies thing [1].
>> 
>> You could just follow your nose by dereferencing the "namespace", or 
>> the literal type to get the meaning.  We'd be back to linked data, 
>> but now with literals. How cool is that! :-)
>> 
>> So to understand the literal
>> 
>> "name"^^<http://xmlns.com/foaf/0.1/>
>> 
>> You would GET http://xmlns.com/foaf/0.1/
>> 
>> Perhaps that would just tell you that
>> 
>> "name"^^<http://xmlns.com/foaf/0.1/> owl:sameAs <http://xmlns.com/foaf/0.1/name> .
>> 
>> Super cool. 
> Maybe, but it seems that you implicitly assume that you would discard
> from your reasoning any triples about
> "name"^^<http://xmlns.com/foaf/0.1/> which would come from a document
> other than http://xmlns.com/foaf/0.1/

Well of course usually we accept relations from any other foaf document we trust
containing foaf:name in predicate position.

In fact what we accept is related to what we trust in other documents. If
a non namespace document makes what would usually considered an ontological
statement about foaf:name then there are cases where that is ok and others
where it is not. 

> Which is exactly what hijacking is about.

Ah ok. But see below.

> It is not enough to just
> dereference http://xmlns.com/foaf/0.1/ to avoid the problem with:
> 
> "name"^^<http://xmlns.com/foaf/0.1/> rdfs:subPropertyOf
> nuclear:NuclearAtomMustExplode .


There are many things one could do with it. 
  - one could reject the document
  - one could accept that document minus that statement
  - one could accept it, but not allow that fact to be used for 
    inferencing for  example


It is really up to the consumer of a doc to decide what facts he accepts, 
as well as what rules he decides to reason with.

  As such this is not really hijacking another name space. It is just some
agent making a claim about the definition at another space. Given that this 
document will not be at the  namespace location:

  1- it won't be found often
  2- it will by default be considered a secondary document 
     (if only just for the pragmatic reasons that any reasoner can argue that
      everyone else will find the name space document first)


> 
>>> The problem is that literals don't have a namespace
>> 
>> Some of them do! Those that do are called typed literals :-)
> 
> Kind of. I just checked the RDF Semantics spec and I haven't noticed any
> problem with this. It also says that how exactly datatypes are defined
> is a matter external to RDF. So perhaps it could be defined to include
> this kind of dereferencing.

I think so. :-)

> 
>> 
>>> and they are not
>>> some meaningless local part of a URI, literals are resources the same
>>> way URIs are.
>> 
>> Indeed. No arguing that. Well in fact that's why we are arguing they
>> should be allowed in subject and predicate position too.
>> 
> Yes I know and I agree :) I also like how it could simplify the RDF
> entailment rules. For example, instead of rules:
> 
> rdfs4a: 	uuu aaa xxx -->	uuu rdf:type rdfs:Resource .
> rdfs4b: 	uuu aaa vvv -->	vvv rdf:type rdfs:Resource .
> (and maybe the stuff with blank-nodes allocated to literals, I am not
> sure I understand this completely)
> 
> There could be just:
> 
> 	true --> xxx rdf:type rdfs:Resource .
> 
> i.e. (forall xxx) xxx rdf:type rdfs:Resource .

yep.

> 
>>> In this
>>> sense, inferences that use such triples would not be authoritative but
>>> they could well make sense and be useful to someone locally.
>> 
>> Indeed. It's just that you would have to be very careful about merging.
>> In my view for all practical purposes, literals of the type
>> 
>> "hello" 
>>  "dog"@en  
>>  "string"^^xsd:string
>>  etc,
>> 
>>  Ie all pure literal strings, are not relations as a matter of fact.  
> But they could be, according to the current semantics.

Well that is a bit like arguing that pigs can fly because you did not find
a dictionary definition that says they can't. If you use the dictionary definition
of pigs to identify them, and consider them carefully, you will see that they
don't.

This is not quite the same, but I would argue that it is nearly an empirical matter
of fact that pure string literals are not predicates.

> 
>> Those are a posteriori truths about them, and need not made to be logical
>> truths by incorporating that info the core RDF spec. You could get exactly
>> the same effect more easily by defining that the class of string literals
>> cannot be properties, by defining 
>> 
>>   xsd:string owl:disjointWith rdf:Property .
> ( I guess you mean this just as an illustration, it wouldn't be nice to
> use owl:disjointWith in an RDF spec :) )

Oh, I think those are just issues of historical priority, not of logical priority. owl:disjointWith is a relation that was named after the rdf spec, but the 
relation has always existed. And there is no reason one cannot use it.

> 
> And I am not sure this would be easier. I have the feeling this is the
> kind of restriction that Pat Hayes says makes things in fact more
> complicated.

To the contrary, I think that this would be quite in line with Pat's thinking.
But I am interested to see what he really thinks :-)

Henry

> 
> Jakub

Received on Friday, 9 July 2010 13:39:16 UTC