- From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Date: Fri, 16 Nov 2001 12:24:03 +0000
- To: Sergey Melnik <melnik@db.stanford.edu>
- Cc: Pat Hayes <phayes@ai.uwf.edu>, Patrick.Stickler@nokia.com, w3c-rdfcore-wg@w3.org
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