Re: RDF Extensibility

Henry Story schrieb:
> On 9 Jul 2010, at 11:42, Jakub Kotowski wrote:
> 
>> Henry Story schrieb:
>>> On 9 Jul 2010, at 09:29, Bernhard Schandl wrote:
>>>
>>>> Hi,
>>>>
>>>>> I agree with Pat in that case, that it would just be easier not to put restrictions
>>>>> in the abstract rdf syntax at all, instead of complicating things all over the place.
>>>>> There are pragmatic reasons why sentences such as 
>>>>>
>>>>> <http://bblfish.net/#hjs> "name" "Henry" .
>>>>>
>>>>> are not going to be successful, the main one being that it is impossible to 
>>>>> adjudicate what the relation "name" refers to is about.
>>>> In that respect, "name" is not different than any URI one has never seen before. What about adding
>>>>
>>>> "name" rdfs:subPropertyOf foaf:name .
>>>>
>>>> to this example?
>>> That would be an interesting theory one could have.
>>>
>>> But what if someone else, whom you never met, had decided
>>> that
>>>
>>> "name" rdfs:subPropertyOf nuclear:NuclearAtomMustExplode .
>>>
>>> and he published information with that meaning.
>>>
>> <snip>
>>> Or put it differently, if you come across a triple with a pure string
>>> literal relation, how would you know what relation the literal
>>> was referring to? Where is the ontology to be found?
>>>
>> <snip>
>>>   those types of issue seem to me to indicate that it is not practical to
>>> have pure string literals in predicate position. The only solution will be to
>>> assign some name space to them, such as 
>>>
>>>  <http://bblfish.net/#hjs> "name"^^<http://xmlns.com/foaf/0.1/> "Henry" .
>>>
>>> And as soon as a name space is assigned we can get going again.
>> This looks more like a typed literal, not a namespace.
> 
> And indeed, my point was to get you to see how oddly similar those two
> notions are :-) 
> 
> 
>> Otherwise, if literals somehow really had a namespace then you could use
>> the idea of ontology hijacking [1] to decide which RDF graphs are
>> authoritative and which not.
> 
> 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/

Which is exactly what hijacking is about. 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 .

>> 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.

> 
>> 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 .

>> 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.

> 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 :) )

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.

Jakub

Received on Friday, 9 July 2010 11:26:01 UTC