Re: PRIMER: draft data model section

>
>BTW:  Regarding both this issue, the other issues you raise below, and
>any others that come up, I don't necessarily feel strongly about these
>things; 
>>>
>
>I do feel strongly about this.
>
>There's this notion floating around the RDF community regarding name and
>entity when literals are property values in that properties must always
>point to the name. I think Drew McDermott asked this question about
>strings being implicated as entities publicly first on rdf-logic (I'll
>stand corrected on that), but I believe his point was about the
>semantics of properties, not literals.
>
>Please read a response I sent to Sean Palmer on this same matter:
>
>http://lists.w3.org/Archives/Public/www-rdf-interest/2001Sep/0050.html

You say there:
"Clearly in RDF processing, literals are opaque to RDF (i.e. if a literal
looks like a URI or more RDF, it is treated as a literal, not as a URI
or more RDF). However an application using RDF triples and able to
properly manipulate Dublin Core in your example would be entitled to
draw the inference that the literal names an entity."

I want to take issue with this, because to me it seems to contradict 
itself. As you say, to an RDF processor, literals are opaque. But you 
then say that an 'application using RDF triples' would be entitled to 
draw an inference which requires (?) NOT treating literals as opaque 
if they refer to the Dublin core. Is this application supposed to be 
an RDF application or not? If it is, then it is not entitled to make 
that inference, since there is nothing in the RDF that enables it to 
draw it. If on the other hand it is able to draw that conclusion, 
then it evidently is not using information (only) from the RDF 
triples, so why should an account of the RDF meanings of the triples 
be concerned with this information?

I think this is particularly tricky as an example since the part of 
the Dublin core that you quote is written in English, so presumably 
is not fully understandable by any software yet written by anyone.

>[Indeed most of the examples I've seen of literal values have literals
>naming an entity in a common-sense way. Yes that's folkware semantics
>but there's nothing wrong with common-sense just because computers don't
>have any.

There is if you are touting the formalism as something for computers 
to use. In fact it is dishonest and foolish, and would be valid 
grounds for having ones tenure case dismissed at any reputable 
university department.

>In any case it's up to the modeller (in this case, the primer)
>to make the semantics explicit. Surely that's what RDF is for?]
>
>Anyway. There is _nothing_ in RDF to make us think that when a property
>has a literal value the property means the literal itself is the entity
>and not what the value might denote

True, but what it can denote is severely restricted. The model theory 
at present assumes that literals have a *fixed value*. So whatever a 
literal denotes, it has to denote it once and for all, globally. It 
can't denote one thing in the Dublin core and something else 
somewhere else.

Now, that is a very simple and restrictive assumption, and Peter 
Patel-Schneider wants us to relax it to the extent of allowing 
datatype schemas for literals. The kind of examples he uses are where 
"070801" might mean either a date or a string or an integer, and one 
can determine from things like the rdfs:range information which 
datatype scheme is supposed to be applied to each literal occurrence. 
That is the scheme we have now worked out in full detail so that it 
COULD be incorporated into the MT for RDFS, if we want to do so, 
though right now its just kind of waiting to be put there. But even 
with this extension, the range of things that a literal can refer to 
is somewhat restricted to be the kinds of things that one finds in 
datatyping schemes. I'm not sure if having a literal like "creator" 
denote a particular human being would count as a datatyping scheme, 
but it sure doesn't sound like one to me.

>  and I don't want the primer to
>implicit mandate otherwise. If there's anything in the MT to that
>effect, I'd appreciate being told, because I didn't know RDF had
>constrained properties in such a way.

See above. There is no constraint on properties, but on the XL 
mapping from literals to literal values.

>In Frank's example, without clear semantics for 'creator' there isn't
>enough information to make a decision on what's being implied.

Right, and indeed that semantic content cannot be stated in RDF. I 
don't think we should pretend that it can if in fact it cannot.

>I suggest making it crystal that the example is to show how intuitive
>the triples form. Do this by pulling an example from natural language,
>as Frank is, and moving from a NL sentence to an RDF triple.

I think we should be very careful not to give the impression that we 
are saying that RDF can represent natural language meanings. It would 
be irresponsible, or just plain silly, to claim that 
existential-conjunctive logic can represent every meaning expressible 
in natural language. (If you think it can, then try publishing that 
claim in a refereed journal.)

Pat

-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Tuesday, 16 October 2001 00:34:36 UTC