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>
__
/\ \
/ \ \
/ /\ \ \
/ / /\ \ \
/ / /__\_\ \
/ / /________\
\/___________/