Re: Terminology: How to call "IRI or blank node"?

On 1/10/15, 9:13 AM, Peter F. Patel-Schneider wrote:
>
>
> On 01/09/2015 02:52 PM, Holger Knublauch wrote:
>> On 1/9/15, 12:40 PM, Peter F. Patel-Schneider wrote:
>>>
>>> This is absolutely counter to the requirement that the working group 
>>> must
>>> use rdfs:Resource in a way that abides by its meaning as defined in 
>>> the RDF
>>> specification.
>>
>> Peter,
>>
>> I think the situation is not as clear-cut. Using rdfs:Resource in the 
>> context
>> of :valueType would IMHO be perfectly fine with the RDF specification.
>>
>> Look at rdfs:domain for example. The triple
>>
>>      ex:property rdfs:domain rdfs:Resource
>>
>> means that the domain of ex:property is IRIs or blank nodes- literals 
>> are
>> excluded because there is *another* rule in RDF which disallows 
>> literals to
>> appear as subjects in RDF triples.
>
> This it not correct.

Of course it is correct. You state yourself below that it is a syntactic 
restriction. What does it matter if some abstract semantics allow some 
philosophically inspired interpretation that has no practical relevance 
because it cannot be syntactically expressed?

>
>> All these semantic rules are conjoined.
>
> That literals cannot appear as the subject of triples does not mean 
> that literal values cannot be the first element of pairs in the 
> extension of properties.  The rule that literals cannot appear as the 
> subject of triples is a syntactic restriction, not a semantic one.
>
>> In
>> the same spirit, I see no reason why we cannot add an additional rule 
>> that in
>> the context of :valueType, the meaning is narrowed down to IRIs or blank
>> nodes. As long as we only narrow down the value space, this is IMHO 
>> perfectly
>> fine.
>
> This is not fine at all, in my opinion.
>
>> Another example is
>>
>>      ex:property rdfs:range rdfs:Literal
>>
>> According to the RDF Schema spec,
>>
>> "The class rdfs:Literal is the class of literal values such as 
>> strings and
>> integers. Property values such as textual strings are examples of RDF 
>> literals."
>>
>> Well, this is quite ambiguous. Does this mean that the following is 
>> in the range?
>>
>>      ex:MyLiteral a rdfs:Literal .
>>      ex:MySubject ex:property ex:MyLiteral .
>
>
> These three triples do not form an inconsistent RDF graph under the 
> RDFS semantics.

Yes, they are valid RDF graphs of course, where ex:MyLiteral is a IRI 
and not a literal.

>
>> I guess not, because otherwise almost every existing RDF processor is 
>> wrong.
>
> These processors may or may not be wrong, but that doesn't affect the 
> definition of RDFS.

It is a huge mistake to ignore practical use only because of some formal 
specification that very few people understand. How is such a mindset 
helping the adoption of this technology? It has not worked so far, so 
let's please try to do better.

>
>> However, how can rdfs:Literal then be a class, if it cannot really have
>> meaningful instances?
>
> Why do you say that rdfs:Literal cannot be a class?  It has many 
> meaningful instances, such as the string "5" and the integer 5.

How is "5" an instance of the class xsd:string? It is a literal node, 
not an instance with an rdf:type triple.

Holger

>
>> So apparently, rdfs:Literal is interpreted differently
>> when it is used in the context of rdfs:range.
>
> Not at all.
>
>> Finally, let's not forget that - in addition to remaining as 
>> compatible as
>> possible to the existing specs - this WG works in unchartered 
>> territory in
>> which many original RDF design decisions such as the open world 
>> assumption are
>> no longer valid. Furthermore, the group also has the goal to create a
>> user-friendly and intuitive language. The fact that the vast majority 
>> of users
>> find the current interpretations of rdfs:Resource confusing should 
>> encourage
>> us to think outside of the box.
>
> The working group is free to set up new concepts if it feels that such 
> are necessary.  The working group is not free to change the meaning of 
> things that are defined in RDF.
>
>> Regards,
>> Holger
>
> peter
>
>

Received on Friday, 9 January 2015 23:23:18 UTC