Re: Answer to the question: What is a "value" to RDF

At 05:31 PM 11/15/01 -0800, Sergey Melnik wrote:
>Pat Hayes wrote:
> > >and despite being clever or making some parts of the
> > >MT easier to define, I don't see it as making life any easier
> > >for implementors, but actually see it as making life harder
> > >for implementors (and knowledge producers)
> >
> > Actually I think there is a tradeoff here. The S and U proposals will
> > be harder on K. producers, since they require them to use a
> > particular syntax and insist that certain idioms be used. But they
> > will be easier on implementors, since inference will be simpler to
> > check and all applications can know exactly where to look for certain
> > kinds of information.

I'll offer my opinion that, in practical terms, ease-of-use for K. 
producers will be the most significant factor in easing take-up of RDF.  In 
a previous message 
[http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Sep/0111.html], I 
outlined my view on the importance of making it easy for existing 
applications to generate accessible data.

That said, I'm still hopeful we can have our cake and eat it...


> > As I understand the S option, that latter form would not be used
> > (except for cases like xsd:string, maybe, where the value space is
> > isomorphic to the lexical space)
> >
> > (Sergey, is that right??)
>
>It's hard say just "yes" or "no". I would regard the "locally typed"
>variant, of course, the best. In this case, the age of X is expressed
>using
>
>X --s:age--> D --s:inYears--> Y --s:inDecimal--> "12"
>
>Given that the semantics of s:age is that D must denote a duration,
>writing
>
>X --s:age--> "12"
>
>does not make any sense in S option. Hence, Pat, you are right - there
>is only one option.
>
>However, here is a different spin (inspired by Grahams CC/PP examples).
>Most certainly we'll find triples like
>
>X --my:age--> "12"
>
>(notice a different namespace - s:age and my:age are two different
>properties!)
>
>In S, the literal "12" denotes a string. Thus, my:age denotes a
>relationship between persons and strings, not between persons and
>durations. However, the property my:age can be viewed as a "shortcut"
>for
>
>X --s:age--> D --s:inYears--> Y --s:inDecimal--> "12"
>|                                                  ^
>+----------------------my:age----------------------+
>
>which may determine the duration D unambigously, or may not.
>
>my:age looks like some kind of "non-local" typing. However, I'm not sure
>Patrick had the same understanding when he was referring to it as the
>one I have in mind. The key point is that s:age and my:age are two
>distinct properties with different ranges and different semantics... In
>particular, using my:age has little to do with datatyping, since "12"
>still denotes just a string. No type is assigned to "12" by using the
>property my:age. The only immediate conclusion we can draw from (X
>my:age "12") is that the interpretation of X is restricted in some way.
>
> > >Honestly, I find that the S proposal bends (and breaks) just
> > >too many established intuitions and expectations about RDF
> > >semantics,
> >
> > I don't think it breaks the semantics at all; it just insists on a
> > rather rigorous way of understanding the meaning of literal labels.
> > That may ruffle many expectations, I concede. But part of our task
> > may be educational :-).

If we were working on a "greenfield site" [*] I'd adopt the S scheme 
straight away.  It's simple and coherent and doesn't preclude simplified 
use, as illustrated above..  But I still worry about backward 
compatibility.  ([*] UK planning (zoning) jargon for building on virgin 
land; preferred by property developers because it's cheaper than building 
on so-called "brownfield" sites.)

I'd like to consider a simple example:

     ex:foo ex:property "10" .
     ex:property rdfs:range xsd:integer .

Can this be legitimate?  If so, what can we say about it?

Could we, for example, allow rdf:type values like xsd:integer to be 
subclasses of rdfs:literal, so that the members of the value space are 
still just strings, but having a restricted lexical form?  Any 
interpretation of the string as (say) an integer would be outside the scope 
of RDF, but we could still have some inference from the above like:

     ex:foo ex:integerProperty _:int10node .
     _:int10node rdf:type xsdv:integer .
     _:int10node rdf:value "10" .

Here, xsdv:integer is informally related to xsd:integer in that 
ICEXT(I(xsd:integer)) is the lexical space of xsd:integer, and 
ICEXT(I(xsdv:integer)) is the value space, per XML schema.

#g


------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
       __
      /\ \
     /  \ \
    / /\ \ \
   / / /\ \ \
  / / /__\_\ \
/ / /________\
\/___________/

Received on Friday, 16 November 2001 07:36:41 UTC