RE: RDF Extensibility

[Michael Schneider]

>-Original Message-
>From: semantic-web-requ...@w3.org [mailto:semantic-web-requ...@w3.org]
>On Behalf Of Ian Davis
>Sent: Tuesday, July 06, 2010 5:53 PM
>To: Dan Brickley
>Cc: Jiří Procházka; Toby Inkster; Michael Schneider; Linked Data
>community; Semantic Web; Pat Hayes
>Subject: Re: RDF Extensibility
>
>2010/7/6 Dan Brickley :
>> 2010/7/6 Jiří Procházka :
>>>>
>>>> It would have a meaning. It would just be a false statement. The
>>>> same as the following is a false statement:
>>>>
>>>>       foaf:Person a rdf:Property .
>>>
>>> Why do you think so?
>>> I believe it is valid RDF and even valid under RDFS semantic
>extension.
>>> Maybe OWL says something about disjointness of RDF properties and
>classes
>>> URI can be many things.
>>
>> It just so happens as a fact in the world, that the thing called
>> foaf:Person isn't a property. It's a class.
>>
>
>I think that is your view and the view you have codified as the
>authoritative definition that I can look up at that URI, but there is
>nothing preventing me from making any assertion I like and working
>with that in my own environment. If it's useful to me to say
>foaf:Person a rdf:Property then I can just do that. However, I
>shouldn't expect that assertion to interoperate with other people's
>views of the world.
>
>Ian

If one has some constraint like this in mind, one should consider trying to
make it explicit when creating the ontology. In the cited messages above, I
am reading: 

  "Maybe OWL says something about disjointness 
  of RDF properties and classes." 

Well, this is /not/ the case, but one could have explicitly stated:

  foaf:Person rdf:type [ owl:complementOf rdf:Property ] .

as an additional axiom in FOAF (and likewise for other classes, if desired),
or more generically:

  rdfs:Class owl:disjointWith rdf:Property .

Of course, this is not in OWL DL, but FOAF is outside OWL DL, anyway, due to
its inverse-functional data properties. However, the above is in OWL Full
(as FOAF is), and also within the scope of the OWL 2 RL/RDF Rules. So, under
these entailment regimes, if one asserts the statements:

  foaf:Person rdf:type rdfs:Class . 
  foaf:Person rdf:type rdf:Property .

this then leads to a semantic inconsistency (with either of the two
alternatives given above). And there are a number of reasoners around which
are able to detect these kinds of inconsistencies, e.g.:

  <http://www.ivan-herman.net/Misc/2008/owlrl/>

Michael

--
Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schnei...@fzi.de
WWW  : http://www.fzi.de/michael.schneider
===
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
===

Re: RDF Extensibility

[Henry Story]

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"^^
>> 
>> You would GET http://xmlns.com/foaf/0.1/
>> 
>> Perhaps that would just tell you that
>> 
>> "name"^^ owl:sameAs 
>>  .
>> 
>> Super cool. 
> Maybe, but it seems that you implicitly assume that you would discard
> from your reasoning any triples about
> "name"^^ 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"^^ 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 th

Re: RDF Extensibility

[Jakub Kotowski]

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 
>
>  "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.
>>>
>> 
>>> 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?
>>>
>> 
>>>   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 
>>>
>>>   "name"^^ "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"^^
> 
> You would GET http://xmlns.com/foaf/0.1/
> 
> Perhaps that would just tell you that
> 
> "name"^^ owl:sameAs 
>  .
> 
> Super cool. 
Maybe, but it seems that you implicitly assume that you would discard
from your reasoning any triples about
"name"^^ 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"^^ 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 easie

Re: RDF Extensibility

[Henry Story]

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 
 
  "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.
>> 
> 
>> 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?
>> 
> 
>>   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 
>> 
>>   "name"^^ "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"^^

You would GET http://xmlns.com/foaf/0.1/

Perhaps that would just tell you that

"name"^^ owl:sameAs 
 .

Super cool. 


> The problem is that literals don't have a namespace

Some of them do! Those that do are called typed literals :-)

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


> So it seems triples like:
> 
> "name" rdfs:subPropertyOf nuclear:NuclearAtomMustExplode .
> 
> would always be not authoritative (literals have no namespace therefore
> there is no source that speaks authoritatively about them).

absolutely true for non typed literals.

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

  This is just like the fact that foaf:Person is a class and not a relation. 
Some relations like  are both classes, 
relations and datatypes! But that is rare. 

   The advantage is that we can then allow certain literals to be predicates.
This may in fact make it easier to GRDDL some silly XML specs for example :-)

Henry


> 
> Jakub
> 
> [1] Scalable Authoritative OWL Reasoning for the Web, Aidan Hogan,
> Andreas Harth, Axel Polleres, DERI Technical Report 2009-04-21, page 14
> http://www.deri.ie/fileadmin/documents/DERI-TR-2009-04-21.pdf
> 
> 
>> 
>>   Henry
>> 
>> 
>> 
>>> Best
>>> Bernhard
>> 
>> 
>> 
> 
[1] http://www.leblogducinema.com/2010/06/25/critique-carlos/

Re: RDF Extensibility

[Jakub Kotowski]

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

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

>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 
> 
>    "name"^^ "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.

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.

The problem is that literals don't have a namespace and they are not
some meaningless local part of a URI, literals are resources the same
way URIs are. So it seems triples like:

"name" rdfs:subPropertyOf nuclear:NuclearAtomMustExplode .

would always be not authoritative (literals have no namespace therefore
there is no source that speaks authoritatively about them). In this
sense, inferences that use such triples would not be authoritative but
they could well make sense and be useful to someone locally.

Jakub

[1] Scalable Authoritative OWL Reasoning for the Web, Aidan Hogan,
Andreas Harth, Axel Polleres, DERI Technical Report 2009-04-21, page 14
http://www.deri.ie/fileadmin/documents/DERI-TR-2009-04-21.pdf


> 
>Henry
> 
> 
> 
>> Best
>> Bernhard
> 
> 
> 

Re: RDF Extensibility

[Henry Story]

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

Now how would he know when he came across your document what you meant, and how
would you know when you came across his document what he meant? And how would 
you
merge documents that came from each other's space?

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?

Or if you are a judge in a case that involves some accident attributable
to this issue, how would you be able to attribute blame (or rewards?)

   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 

   "name"^^ "Henry" .

And as soon as a name space is assigned we can get going again.

   Henry



> Best
> Bernhard

Re: RDF Extensibility

[Bernhard Schandl]

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 
> 
>  "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?

Best
Bernhard

Re: RDF Extensibility

[Henry Story]

On 8 Jul 2010, at 22:06, Reto Bachmann-Gmuer wrote:

> On Thu, Jul 8, 2010 at 7:21 PM, Pat Hayes  wrote:
> 
>> 
>> On Jul 7, 2010, at 11:31 AM, Reto Bachmann-Gmuer wrote:
>> 
>> On Wed, Jul 7, 2010 at 1:57 PM, Toby Inkster  wrote:
>> 
>>> Without knowing the definition of foaf:Person, it's difficult to
>>> conclude that foaf:Person is not a property. However, even without
>>> knowing the definition of a literal, it is easy to conclude that it is
>>> not a suitable node to be used as a property, so in my opinion, it is
>>> sensible to state that triples containing a literal as the predicate
>>> have no meaning (even though I think they should be syntactically
>>> allowed).

There may be a confusion with different meanings of literals.  

I certainly think that it is difficult to justify pure string literals
as predicates. But there are many other types of literals. If you allow 
for a relation between a string and the thing it refers to such as a 
log:reference datatype then it is clear  that we use those all the time:

 "http://xmlns.com/foaf/0.1/name"^^log:reference 
"Henry" .

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 

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


>> 
>> I think it would be perfectly possible to have a datatype mapping to a
>> value-space of properties. But I see no practical benefit with this so I'd
>> prefer not to support literal predicates syntactically.
>> 
>> 
>> I'd suggest, as a general principle, that one should ask: which is easier,
>> to allow them or to prohibit them? There are costs both ways. Words like
>> 'support' beg the question.
>> 
> 
> Evaluating the revision of a standard many questions are around the
> trade-off between stability and design elegance. The allegedly neutral terms
> "allow" and "prohibit" seem to beg this question.
> 
> Reto

Re: RDF Aggregation Operators (Was: RDF Extensibility)

[David Booth]

On Wed, 2010-07-07 at 14:43 -0400, Adrian Walker wrote:
> Hi Pat,
> 
> You wrote...
> 
> ..how do we know, given some RDF, what semantic extensions are
> appropriately to be used when interpreting it? That is a VERY good
> question. This is something that RDF2 could most usefully tackle,...

A fairly widely held view -- though I'm sure not universal -- is that
the URIs used in the graph should signal the intended semantic
extensions.  For example, if you use an OWL predicate, then the OWL
semantics for that predicate are intended.  This is described in "PART
3: Determining Resource Identity" of "Resource Identity and Semantic
Extensions: Making Sense of Ambiguity":
http://dbooth.org/2010/ambiguity/#part3 

HOWEVER, it is important to distinguish between the intent of the RDF
statement author and what the RDF consumer chooses to do with the graph.
It is critical that the RDF consumer be able to determine the intended
semantics of the graph, i.e., to be able to know what entailments the
RDF author intended.  This is essence of successful communication.  But
this does *not* obligate the RDF consumer to actually *produce* all of
those entailments.  That is a choice that is entirely up to the RDF
consumer and will vary by application.

The question that you are asking has to do with the roles,
responsibilities and expectations of the URI owner, RDF statement author
and RDF consumer.  I have proposed some standard guidelines in "The URI
Lifecycle in Semantic Web Architecture":
http://dbooth.org/2009/lifecycle/ 

There was some discussion at the RDF Next Steps workshop about having
the next RDF working group tackle this issue, but the prevailing view
was that it should not.  Personally, I think this was because the issue
is not yet well enough understood in the semantic web community as a
whole.  More education and discussion are needed first.



-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

Re: RDF Extensibility

[Pat Hayes]

On Jul 8, 2010, at 2:28 PM, Toby Inkster wrote:


On Thu, 8 Jul 2010 12:16:06 -0500
Pat Hayes  wrote:


I would veto this option. To do this would be a lot more work than
not doing it; and it would greatly complicate the semantic
specification, which would have to keep track of this
'meaninglessness'.


Why would tools need to keep track of the meaninglessness? True
"meaning" is only assigned to triples by their human consumers.


One could have a situation, for example, in which A entails B entails
C, A and C are perfectly fine, but B has been declared 'meaningless'.
Should this inference be blocked? Should it be an error?


No, and no. While B is meaningless in itself, C might not be.
Rules/entailments operate over symbols, not over meaning.


Not exactly. See below.


It's
perfectly feasible that something meaningful might be discovered by
applying a set of rules to symbols that are meaningless.

An entailment that generates a meaningless statement is probably a
dodgy entailment, but that doesn't mean it should be considered an
error by the rules engine.


Well, but now I have to put on my semantics-maven hat. That word  
"entailment" has a particular meaning: A entails B when for every  
legal interpretation I, if A has the value 'true' in I, then so does  
B. That is, entailment is any inference that is guaranteed to preserve  
truth. Now, if something is meaningless, then its not true. So the  
inference of a meaningless B from a is *always* invalid (unless A is  
never true, ie a contradiction - a possibility that we can leave aside  
in this context.) So by declaring some syntactic forms to be required  
to be meaningless, we have broken any inference chains which use those  
forms: such chains can never be classed as entailments, even though  
the entailment of C for A may be perfectly OK.


In fact, disallowing literals as subjects produces exactly this kind  
of 'missing link' problem, where (what would be a) valid inference is  
blocked because it would have to go through an intermediate form which  
is disallowed. I know you do not propose to make these forms  
syntactically illegal, but the problem arises just as sharply if you  
override the natural model-theoretic rules by imposing an 'alien'  
interpretative value on them. The machinery of logic is simple, but it  
does have its own internal, um, logic, and it all kind of hangs  
together, and it gets broken by putting unnatural restrictions on it.


What could { <#Alice> "56.2"^^xsd:decimal <#Bob> . } possibly mean?
If we assume the class of numbers and the class of relationships is
disjoint [1]


But RDF does NOT make this assumption. Nor, IMO, should it. Anything  
can be (more properly, can be interpreted to be) a relationship, in  
the RDF model theory. This simplest-possible assumption has proven to  
be extremely robust and extremely useful, and is used in the RDF and  
OWL-Full and ISO Common Logic semantics. It is, I suggest, a mistake  
to mess with it without a VERY good reason. Preserving old logical  
constraints is one quite good reason, given the utility of preserving  
legacy systems. Imposing it because one can't think of a reason not  
to, is not a good reason.



, then "56.2"^^xsd:decimal cannot be a relationship. If the
triple doesn't contain a relationship between a subject and an object,
but Concepts says that all RDF triples do. So a triple with an
xsd:decimal predicate makes no sense according to Concepts.


Sure it does, if you read the semantics properly. See above.



So my point in saying that literals should be allowed as predicates  
but

considered meaningless is to reconcile an arguably desirable feature
(the simplicity of allowing any node type to occupy any position in a
triple/quad) with an inescapable fact (that a triple with a literal
for a predicate doesn't make any sense).


But they can make sense, and indeed they have use cases. Pretty far  
out use cases, but uses nonetheless.



The pragmatic solution is to
just say, they're allowed -- tools can operate on them as normal --  
but

should have no meaning to humans.

In much the same way as { <#Alice> <#xyzzy> <#Bob> . } has no meaning
until we have additional information about <#xyzzy>.

I'll add that it has been mentioned that one could mint a datatype URI
for relationships (e.g. ^^rdf:relationship). As a datatype is
essentially a mapping from strings to things, this would allow for the
creation of literals that represent relationships. In this case, I'd
concede that a triple with one of these datatyped literals as a
predicate would be meaningful. However, this does seem to be a bit of
a pathological edge case.


The RDF semantics has had this mapping since day one, its the  
composition of the mapping called IEXT with an intepretation mapping.


Pat



--
Toby A Inkster







IHMC (850)434 89

Re: RDF Extensibility

[Reto Bachmann-Gmuer]

On Thu, Jul 8, 2010 at 7:21 PM, Pat Hayes  wrote:

>
> On Jul 7, 2010, at 11:31 AM, Reto Bachmann-Gmuer wrote:
>
> On Wed, Jul 7, 2010 at 1:57 PM, Toby Inkster  wrote:
>
>> Without knowing the definition of foaf:Person, it's difficult to
>> conclude that foaf:Person is not a property. However, even without
>> knowing the definition of a literal, it is easy to conclude that it is
>> not a suitable node to be used as a property, so in my opinion, it is
>> sensible to state that triples containing a literal as the predicate
>> have no meaning (even though I think they should be syntactically
>> allowed).
>>
>
> I think it would be perfectly possible to have a datatype mapping to a
> value-space of properties. But I see no practical benefit with this so I'd
> prefer not to support literal predicates syntactically.
>
>
> I'd suggest, as a general principle, that one should ask: which is easier,
> to allow them or to prohibit them? There are costs both ways. Words like
> 'support' beg the question.
>

Evaluating the revision of a standard many questions are around the
trade-off between stability and design elegance. The allegedly neutral terms
"allow" and "prohibit" seem to beg this question.

Reto

Re: RDF Extensibility

[Toby Inkster]

On Thu, 8 Jul 2010 12:16:06 -0500
Pat Hayes  wrote:

> I would veto this option. To do this would be a lot more work than
> not doing it; and it would greatly complicate the semantic
> specification, which would have to keep track of this
> 'meaninglessness'. 

Why would tools need to keep track of the meaninglessness? True
"meaning" is only assigned to triples by their human consumers.

> One could have a situation, for example, in which A entails B entails
> C, A and C are perfectly fine, but B has been declared 'meaningless'.
> Should this inference be blocked? Should it be an error? 

No, and no. While B is meaningless in itself, C might not be.
Rules/entailments operate over symbols, not over meaning. It's
perfectly feasible that something meaningful might be discovered by
applying a set of rules to symbols that are meaningless.

An entailment that generates a meaningless statement is probably a
dodgy entailment, but that doesn't mean it should be considered an
error by the rules engine.

What could { <#Alice> "56.2"^^xsd:decimal <#Bob> . } possibly mean?
If we assume the class of numbers and the class of relationships is
disjoint [1], then "56.2"^^xsd:decimal cannot be a relationship. If the
triple doesn't contain a relationship between a subject and an object,
but Concepts says that all RDF triples do. So a triple with an
xsd:decimal predicate makes no sense according to Concepts.

So my point in saying that literals should be allowed as predicates but
considered meaningless is to reconcile an arguably desirable feature
(the simplicity of allowing any node type to occupy any position in a
triple/quad) with an inescapable fact (that a triple with a literal
for a predicate doesn't make any sense). The pragmatic solution is to
just say, they're allowed -- tools can operate on them as normal -- but
should have no meaning to humans. 

In much the same way as { <#Alice> <#xyzzy> <#Bob> . } has no meaning
until we have additional information about <#xyzzy>.

I'll add that it has been mentioned that one could mint a datatype URI
for relationships (e.g. ^^rdf:relationship). As a datatype is
essentially a mapping from strings to things, this would allow for the
creation of literals that represent relationships. In this case, I'd
concede that a triple with one of these datatyped literals as a
predicate would be meaningful. However, this does seem to be a bit of
a pathological edge case.

-- 
Toby A Inkster

Re: RDF Extensibility

[Pat Hayes]

On Jul 7, 2010, at 11:31 AM, Reto Bachmann-Gmuer wrote:


On Wed, Jul 7, 2010 at 1:57 PM, Toby Inkster  wrote:
Without knowing the definition of foaf:Person, it's difficult to
conclude that foaf:Person is not a property. However, even without
knowing the definition of a literal, it is easy to conclude that it is
not a suitable node to be used as a property, so in my opinion, it is
sensible to state that triples containing a literal as the predicate
have no meaning (even though I think they should be syntactically
allowed).

I think it would be perfectly possible to have a datatype mapping to  
a value-space of properties. But I see no practical benefit with  
this so I'd prefer not to support literal predicates syntactically.




I'd suggest, as a general principle, that one should ask: which is  
easier, to allow them or to prohibit them? There are costs both ways.  
Words like 'support' beg the question.


Pat Hayes



Reto



IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St.   (850)202 4416   office
Pensacola(850)202 4440   fax
FL 32502  (850)291 0667   mobile
phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes

Re: RDF Extensibility

[Pat Hayes]

On Jul 7, 2010, at 6:57 AM, Toby Inkster wrote:


On Tue, 6 Jul 2010 16:11:19 -0500
Pat Hayes  wrote:


The world doesn't have facts like that in it. Classes and properties
are intellectual constructs, not the stuff of reality. Hell, if a
particle can be a wave, then surely a class can be a property.
Anyway, RDF doesn't make logical a priori rulings about these kind
of metaphysical segregations. For example, xsd:Number is a class, a
property and an individual in RDF.


Indeed - but who has claimed that classes and properties are disjoint?
Although they may well overlap in some cases, foaf:Person still  
isn't a

property.

Without knowing the definition of foaf:Person, it's difficult to
conclude that foaf:Person is not a property. However, even without
knowing the definition of a literal, it is easy to conclude that it is
not a suitable node to be used as a property


Well, thats what I thought too, until people started using them that  
way in CLIF/IKL. It is very dangerous to presume that one can see  
clearly, ahead of time, that a construct cannot be usefully be used by  
anybody else. And such triples do have a meaning, technically, since  
the RDF semantics gives them one, without indeed any modification *at  
all*.



, so in my opinion, it is
sensible to state that triples containing a literal as the predicate
have no meaning (even though I think they should be syntactically
allowed).


I would veto this option. To do this would be a lot more work than not  
doing it; and it would greatly complicate the semantic specification,  
which would have to keep track of this 'meaninglessness'. One could  
have a situation, for example, in which A entails B entails C, A and C  
are perfectly fine, but B has been declared 'meaningless'. Should this  
inference be blocked? Should it be an error? Why are we even asking  
this question?


Pat



--
Toby A Inkster







IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St.   (850)202 4416   office
Pensacola(850)202 4440   fax
FL 32502  (850)291 0667   mobile
phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes

RDF Aggregation Operators (Was: RDF Extensibility)

[Adrian Walker]

Hi Pat,

You wrote...

*..how do we know, given some RDF, what semantic extensions are
appropriately to be used when interpreting it? That is a VERY good question.
This is something that RDF2 could most usefully tackle,...*

One as yet uncharted direction in which RDF semantics standardization could
in future do much better than SQL concerns aggregation. An approach is in
the executable file [1].

HTH,  -- Adrian

[1]  www.reengineeringllc.com/demo_agents/RDFQueryLangComparison1.agent
See: 6. the publication that-title has that-number author(s)

Internet Business Logic
A Wiki and SOA Endpoint for Executable Open Vocabulary English Q/A over SQL
and RDF
Online at www.reengineeringllc.com
Shared use is free, and there are no advertisements

Adrian Walker
Reengineering


2010/7/6 Pat Hayes 

>
> On Jul 6, 2010, at 9:34 AM, Jiří Procházka wrote:
>
>  On 07/06/2010 03:35 PM, Toby Inkster wrote:
>>
>>> On Tue, 6 Jul 2010 14:03:19 +0200
>>> "Michael Schneider"  wrote:
>>>
>>>  So, if
>>>>
>>>>   :s "lit" :o .
>>>>
>>>> must not have a semantic meaning, what about
>>>>
>>>>   "lit" rdf:type rdf:Property .
>>>>
>>>> ? As, according to what you say above, you are willing to allow for
>>>> literals in subject position, this triple is fine for you
>>>> syntactically. But what about its meaning? Would this also be
>>>> officially defined to have no meaning?
>>>>
>>>
>>> It would have a meaning. It would just be a false statement. The
>>> same as the following is a false statement:
>>>
>>>foaf:Person a rdf:Property .
>>>
>>
>> Why do you think so?
>> I believe it is valid RDF and even valid under RDFS semantic extension.
>> Maybe OWL says something about disjointness of RDF properties and classes
>> URI can be many things.
>>
>> I think there are issues about RDF extensibility which haven't been
>> solved and they concern:
>> a) semantics
>> b) serializations
>>
>> In case of a) I don't have cleared up my thoughts yet, but generally I
>> would like to know:
>> How are semantic extensions to work together in automated system?
>>
>
> Well, the semantics always defines some notion of entailment, and your
> system is supposed to respect that notion: not draw invalid conclusions,
> draw as many valid conclusions as you feel are useful, don't say things are
> inconsistent when they aren't, etc.. Otherwise, you have free rein. So, if
> you have several semantic extensions, they are each provide a set of such
> entailments and they should add up to one single set of legal entailments.
>
>
>  How to let agent know that the data is described using new RDF
>> extension, which the client doesn't know and the data could be (or
>> definitely are) false if it is interpreted using vanilla RDF semantics?
>>
>
> NOt false, if its a semantic extension (they can't contradict the RDF
> semantics., only extend it.) BUt same point more generally: how do we know,
> given some RDF, what semantic extensions are appropriately to be used when
> interpreting it? That is a VERY good question. This is something that RDF2
> could most usefully tackle, if only in a first-step (ham-fisted?) kind of a
> way. We were aware that this was an issue in the first WG, but it was just
> too far outside out charter, and our energy level, to tackle properly. One
> obvious (?) thing to say is that using a construction from a namespace which
> is associated with the definition of any RDF semantic extension is deemed to
> bring along the necessary interpretation conditions from the extension, so
> that for example if I use owl:sameAs in some RDF, then I mean it to be
> understood using the OWL semantic conditions. We all do this without
> remarking upon it, but loosely, and to make this precise and normative would
> be a very interesting (and useful) exercise. (An issue already here is,
> which version of the OWL semantics is intended? Does the use in RDF also
> "import" the OWL-DL syntactic restrictions on its use, for example?)
>
> Pat
>
>
>
>
>> b) How should my system know that the data which is just being processed
>> is new revision of RDF/XML and not malformed RDF/XML when forward
>> compatibility was out of sight, out of mind when RDF/XML was designed?
>>
>> Best,
>> Jiri Prochazka
>>
>>
> 
> IHMC (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.   (850)202 4416   office
> Pensacola(850)202 4440   fax
> FL 32502  (850)291 0667   mobile
> phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes
>
>
>
>
>
>
>

Re: RDF Extensibility

[Jiří Procházka]

On 07/06/2010 11:05 PM, Pat Hayes wrote:
> 
> On Jul 6, 2010, at 9:34 AM, Jiří Procházka wrote:
>>
>> [snipped]
>>
>> In case of a) I don't have cleared up my thoughts yet, but generally I
>> would like to know:
>> How are semantic extensions to work together in automated system?
> 
> Well, the semantics always defines some notion of entailment, and your
> system is supposed to respect that notion: not draw invalid conclusions,
> draw as many valid conclusions as you feel are useful, don't say things
> are inconsistent when they aren't, etc.. Otherwise, you have free rein.
> So, if you have several semantic extensions, they are each provide a set
> of such entailments and they should add up to one single set of legal
> entailments.
> 
>> How to let agent know that the data is described using new RDF
>> extension, which the client doesn't know and the data could be (or
>> definitely are) false if it is interpreted using vanilla RDF semantics?
> 
> NOt false, if its a semantic extension (they can't contradict the RDF
> semantics., only extend it.) BUt same point more generally: how do we
> know, given some RDF, what semantic extensions are appropriately to be
> used when interpreting it? That is a VERY good question. This is
> something that RDF2 could most usefully tackle, if only in a first-step
> (ham-fisted?) kind of a way. We were aware that this was an issue in the
> first WG, but it was just too far outside out charter, and our energy
> level, to tackle properly. One obvious (?) thing to say is that using a
> construction from a namespace which is associated with the definition of
> any RDF semantic extension is deemed to bring along the necessary
> interpretation conditions from the extension, so that for example if I
> use owl:sameAs in some RDF, then I mean it to be understood using the
> OWL semantic conditions. We all do this without remarking upon it, but
> loosely, and to make this precise and normative would be a very
> interesting (and useful) exercise. (An issue already here is, which
> version of the OWL semantics is intended? Does the use in RDF also
> "import" the OWL-DL syntactic restrictions on its use, for example?)

That is indeed what I had in mind. I think sooner or later this has to
be dealt with, and I think the sooner the better...

I don't think the namespace thing is obvious, since I don't think there
is a concept of namespace defined in RDF. It is just some graph
containing some terms related to a semantic extension of RDF. How does
the processing application know? Which entailment rules are to be
applied to the graph? How should the patterns triggering application of
a rule be defined? Having multiple rulesets, in what order and how to
apply them? What about rules modifying rules and rulesets? How to define
interpretation of graphs (which rulesets to apply, which to ignore)? Is
a graph and entailment rules everything what is used in interpretation
according to a semantic extension or are there also some attributes like
graph consistency (if so, how do pass them on? as added triples?)?
These are just questions I am pulling off top of my head...

Best,
Jiri

> Pat
> 
> 
>>
>> b) How should my system know that the data which is just being processed
>> is new revision of RDF/XML and not malformed RDF/XML when forward
>> compatibility was out of sight, out of mind when RDF/XML was designed?
>>
>> Best,
>> Jiri Prochazka
>>
> 
> 
> IHMC (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.   (850)202 4416   office
> Pensacola(850)202 4440   fax
> FL 32502  (850)291 0667   mobile
> phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes
> 
> 
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: RDF Extensibility

[Reto Bachmann-Gmuer]

On Wed, Jul 7, 2010 at 1:57 PM, Toby Inkster  wrote:

> Without knowing the definition of foaf:Person, it's difficult to
> conclude that foaf:Person is not a property. However, even without
> knowing the definition of a literal, it is easy to conclude that it is
> not a suitable node to be used as a property, so in my opinion, it is
> sensible to state that triples containing a literal as the predicate
> have no meaning (even though I think they should be syntactically
> allowed).
>

I think it would be perfectly possible to have a datatype mapping to a
value-space of properties. But I see no practical benefit with this so I'd
prefer not to support literal predicates syntactically.

Reto

Re: RDF Extensibility

[Toby Inkster]

On Tue, 6 Jul 2010 16:11:19 -0500
Pat Hayes  wrote:

> The world doesn't have facts like that in it. Classes and properties  
> are intellectual constructs, not the stuff of reality. Hell, if a  
> particle can be a wave, then surely a class can be a property.
> Anyway, RDF doesn't make logical a priori rulings about these kind
> of metaphysical segregations. For example, xsd:Number is a class, a  
> property and an individual in RDF.

Indeed - but who has claimed that classes and properties are disjoint?
Although they may well overlap in some cases, foaf:Person still isn't a
property.

Without knowing the definition of foaf:Person, it's difficult to
conclude that foaf:Person is not a property. However, even without
knowing the definition of a literal, it is easy to conclude that it is
not a suitable node to be used as a property, so in my opinion, it is
sensible to state that triples containing a literal as the predicate
have no meaning (even though I think they should be syntactically
allowed).

-- 
Toby A Inkster

Re: RDF Extensibility

[Pat Hayes]

On Jul 6, 2010, at 10:03 AM, Dan Brickley wrote:


2010/7/6 Jiří Procházka :

On 07/06/2010 03:35 PM, Toby Inkster wrote:

On Tue, 6 Jul 2010 14:03:19 +0200
"Michael Schneider"  wrote:


So, if

:s "lit" :o .

must not have a semantic meaning, what about

"lit" rdf:type rdf:Property .

? As, according to what you say above, you are willing to allow for
literals in subject position, this triple is fine for you
syntactically. But what about its meaning? Would this also be
officially defined to have no meaning?


It would have a meaning. It would just be a false statement. The
same as the following is a false statement:

  foaf:Person a rdf:Property .


Why do you think so?
I believe it is valid RDF and even valid under RDFS semantic  
extension.
Maybe OWL says something about disjointness of RDF properties and  
classes

URI can be many things.


It just so happens as a fact in the world, that the thing called
foaf:Person isn't a property. It's a class.


The world doesn't have facts like that in it. Classes and properties  
are intellectual constructs, not the stuff of reality. Hell, if a  
particle can be a wave, then surely a class can be a property. Anyway,  
RDF doesn't make logical a priori rulings about these kind of  
metaphysical segregations. For example, xsd:Number is a class, a  
property and an individual in RDF.


Pat



Some might argue that there are no things that are simultaneously RDF
classes and properties, but that doesn't matter for the FOAF case. The
RSS1 vocabulary btw tried to define something that was both,
rss1:image I think; but this was a backwards-compatibility hack.

cheers,

Dan





IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St.   (850)202 4416   office
Pensacola(850)202 4440   fax
FL 32502  (850)291 0667   mobile
phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes

Re: RDF Extensibility

[Pat Hayes]

On Jul 6, 2010, at 9:34 AM, Jiří Procházka wrote:


On 07/06/2010 03:35 PM, Toby Inkster wrote:

On Tue, 6 Jul 2010 14:03:19 +0200
"Michael Schneider"  wrote:


So, if

   :s "lit" :o .

must not have a semantic meaning, what about

   "lit" rdf:type rdf:Property .

? As, according to what you say above, you are willing to allow for
literals in subject position, this triple is fine for you
syntactically. But what about its meaning? Would this also be
officially defined to have no meaning?


It would have a meaning. It would just be a false statement. The
same as the following is a false statement:

foaf:Person a rdf:Property .


Why do you think so?
I believe it is valid RDF and even valid under RDFS semantic  
extension.
Maybe OWL says something about disjointness of RDF properties and  
classes

URI can be many things.

I think there are issues about RDF extensibility which haven't been
solved and they concern:
a) semantics
b) serializations

In case of a) I don't have cleared up my thoughts yet, but generally I
would like to know:
How are semantic extensions to work together in automated system?


Well, the semantics always defines some notion of entailment, and your  
system is supposed to respect that notion: not draw invalid  
conclusions, draw as many valid conclusions as you feel are useful,  
don't say things are inconsistent when they aren't, etc.. Otherwise,  
you have free rein. So, if you have several semantic extensions, they  
are each provide a set of such entailments and they should add up to  
one single set of legal entailments.



How to let agent know that the data is described using new RDF
extension, which the client doesn't know and the data could be (or
definitely are) false if it is interpreted using vanilla RDF  
semantics?


NOt false, if its a semantic extension (they can't contradict the RDF  
semantics., only extend it.) BUt same point more generally: how do we  
know, given some RDF, what semantic extensions are appropriately to be  
used when interpreting it? That is a VERY good question. This is  
something that RDF2 could most usefully tackle, if only in a first- 
step (ham-fisted?) kind of a way. We were aware that this was an issue  
in the first WG, but it was just too far outside out charter, and our  
energy level, to tackle properly. One obvious (?) thing to say is that  
using a construction from a namespace which is associated with the  
definition of any RDF semantic extension is deemed to bring along the  
necessary interpretation conditions from the extension, so that for  
example if I use owl:sameAs in some RDF, then I mean it to be  
understood using the OWL semantic conditions. We all do this without  
remarking upon it, but loosely, and to make this precise and normative  
would be a very interesting (and useful) exercise. (An issue already  
here is, which version of the OWL semantics is intended? Does the use  
in RDF also "import" the OWL-DL syntactic restrictions on its use, for  
example?)


Pat




b) How should my system know that the data which is just being  
processed

is new revision of RDF/XML and not malformed RDF/XML when forward
compatibility was out of sight, out of mind when RDF/XML was designed?

Best,
Jiri Prochazka




IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St.   (850)202 4416   office
Pensacola(850)202 4440   fax
FL 32502  (850)291 0667   mobile
phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes

RE: RDF Extensibility

[Michael Schneider]

Dan Brickley wrote:

>2010/7/6 Jiří Procházka :
>> On 07/06/2010 03:35 PM, Toby Inkster wrote:

>>> It would have a meaning. It would just be a false statement. The
>>> same as the following is a false statement:
>>>
>>>       foaf:Person a rdf:Property .
>>
>> Why do you think so?
>> I believe it is valid RDF and even valid under RDFS semantic
>extension.
>> Maybe OWL says something about disjointness of RDF properties and
>classes
>> URI can be many things.
>
>It just so happens as a fact in the world, that the thing called
>foaf:Person isn't a property. It's a class.

The semantics of RDFS allows to use the same name for both a class and a
property.

What you call a "fact in the world" is, from a semantics point of view, just
one particular interpretation that you have in mind. Other interpretations
than yours are possible (I hope :)). And the (model-theoretic) semantics of
RDFS is of a form that a given RDF statement is false, only if /all/
possible interpretations are false. (This is not specific to the RDF
semantics, btw.)

>Some might argue that there are no things that are simultaneously RDF
>classes and properties, but that doesn't matter for the FOAF case. 

Let's not forget that we are here discussing a suggested change of the
syntax and (possibly) semantics of the RDF specification, and the FOAF case
doesn't matter for this, I would say. FOAF refers to RDFS (and OWL), not the
other way round (except, perhaps, as a usecase). Of course, one could define
an extension of the RDFS semantics specifically for FOAF that better
reflects the intended situation (either formally or informally, or
implicitly by a reference implementation of a specific FOAF reasoner). But
that's a different discussion.

>The
>RSS1 vocabulary btw tried to define something that was both,
>rss1:image I think; but this was a backwards-compatibility hack.

You might find more of these "hacks" elsewhere, and more to come in the
future. Interestingly, the idea of using the same name for both a class and
a property is somewhat that has been introduced in OWL DL just in OWL 2, so
it exists in OWL DL for less than a year now (officially). In RDFS and
(therefore) in OWL Full, it has always been allowed, though.

>cheers,
>
>Dan

Best,
Michael

--
Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schnei...@fzi.de
WWW  : http://www.fzi.de/michael.schneider
===
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
===

Re: RDF Extensibility

[Ian Davis]

2010/7/6 Dan Brickley :
> 2010/7/6 Jiří Procházka :
>>>
>>> It would have a meaning. It would just be a false statement. The
>>> same as the following is a false statement:
>>>
>>>       foaf:Person a rdf:Property .
>>
>> Why do you think so?
>> I believe it is valid RDF and even valid under RDFS semantic extension.
>> Maybe OWL says something about disjointness of RDF properties and classes
>> URI can be many things.
>
> It just so happens as a fact in the world, that the thing called
> foaf:Person isn't a property. It's a class.
>

I think that is your view and the view you have codified as the
authoritative definition that I can look up at that URI, but there is
nothing preventing me from making any assertion I like and working
with that in my own environment. If it's useful to me to say
foaf:Person a rdf:Property then I can just do that. However, I
shouldn't expect that assertion to interoperate with other people's
views of the world.

Ian

Re: RDF Extensibility

[Dan Brickley]

2010/7/6 Jiří Procházka :
> On 07/06/2010 03:35 PM, Toby Inkster wrote:
>> On Tue, 6 Jul 2010 14:03:19 +0200
>> "Michael Schneider"  wrote:
>>
>>> So, if
>>>
>>>     :s "lit" :o .
>>>
>>> must not have a semantic meaning, what about
>>>
>>>     "lit" rdf:type rdf:Property .
>>>
>>> ? As, according to what you say above, you are willing to allow for
>>> literals in subject position, this triple is fine for you
>>> syntactically. But what about its meaning? Would this also be
>>> officially defined to have no meaning?
>>
>> It would have a meaning. It would just be a false statement. The
>> same as the following is a false statement:
>>
>>       foaf:Person a rdf:Property .
>
> Why do you think so?
> I believe it is valid RDF and even valid under RDFS semantic extension.
> Maybe OWL says something about disjointness of RDF properties and classes
> URI can be many things.

It just so happens as a fact in the world, that the thing called
foaf:Person isn't a property. It's a class.

Some might argue that there are no things that are simultaneously RDF
classes and properties, but that doesn't matter for the FOAF case. The
RSS1 vocabulary btw tried to define something that was both,
rss1:image I think; but this was a backwards-compatibility hack.

cheers,

Dan

RDF Extensibility

[Jiří Procházka]

On 07/06/2010 03:35 PM, Toby Inkster wrote:
> On Tue, 6 Jul 2010 14:03:19 +0200
> "Michael Schneider"  wrote:
> 
>> So, if 
>>
>> :s "lit" :o .
>>
>> must not have a semantic meaning, what about
>>
>> "lit" rdf:type rdf:Property .
>>
>> ? As, according to what you say above, you are willing to allow for
>> literals in subject position, this triple is fine for you
>> syntactically. But what about its meaning? Would this also be
>> officially defined to have no meaning?
> 
> It would have a meaning. It would just be a false statement. The
> same as the following is a false statement:
> 
>   foaf:Person a rdf:Property .

Why do you think so?
I believe it is valid RDF and even valid under RDFS semantic extension.
Maybe OWL says something about disjointness of RDF properties and classes
URI can be many things.

I think there are issues about RDF extensibility which haven't been
solved and they concern:
a) semantics
b) serializations

In case of a) I don't have cleared up my thoughts yet, but generally I
would like to know:
How are semantic extensions to work together in automated system?
How to let agent know that the data is described using new RDF
extension, which the client doesn't know and the data could be (or
definitely are) false if it is interpreted using vanilla RDF semantics?

b) How should my system know that the data which is just being processed
is new revision of RDF/XML and not malformed RDF/XML when forward
compatibility was out of sight, out of mind when RDF/XML was designed?

Best,
Jiri Prochazka



signature.asc
Description: OpenPGP digital signature