W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2002

Re: why S doesn't require double properties [was: Datatyping Summary V4]

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Mon, 4 Feb 2002 17:47:41 -0600
Message-Id: <p05101408b884cb6394a5@[]>
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: w3c-rdfcore-wg@w3.org
>On 2002-02-04 19:15, "ext Dan Connolly" <connolly@w3.org> wrote:
>>>  Issue B1:
>>>  =========
>>>  status: disputed by Sergey.  Sergey you owe us an explanation of why.
>>  Perhaps Sergey's position is the same as mine...
>>>  ..
>>>  two properties have to be used, <age> and <ageD>, in this example.
>>  Yes, *if* one wants to use both idioms, one needs both sorts
>>  of properties.
>Thank you. I'm glad we finally got that clarified.
>>  But I don't think most communities want to use both idioms.
>Hmmm.... and what about that nice characteristic of RDF that
>is supposed to allow us to syndicate knowledge from *different*
>communities in order to synergenically obtain new knowledge
>by inference or make decisions based on comparison of
>knowledge from those disparate sources.
>I'm sorry Dan but you continue to reflect a very closed-system
>view of datatyping, such that knowledge will not flow freely
>between systems and be used in contexts where the knowledge
>creator never dreamed of.
>I thought the whole point of RDF and the Semantic Web was
>the free interchange of knowledge between disparate systems.
>>  For example, I expect Dublin Core (and maybe prism?) to
>>  recommend S-B exclusively; hence they only need <age>,
>>  not <agedD>.
>Who are they to tell me or anyone which idiom I am to use?!
>People must be free to use either idiom, and since folks
>*will* be using both idioms, even if not in the same
>knowledge base, there will *have* to be two versions of
>every ontology, one for each idiom.

Well, it may not be this bad. Here's a worst-case scenario. There are 
ontologies out there using all the idioms, and you want to be able to 
get information from them all and interrelate it all together. One 
way you can do this is to choose the idiom you like, and translate 
the others into that one on the fly. For local typing this is easy; 
you could do it with a simple scripting language. (You have to be 
able to recognize urirefs denoting datatypes, but those are supposed 
to be 'global' in any case, right?)
For range-style typing you have an option,  but the easiest way to 
handle it (and the safest) would be to  try to infer a 'local' 
statement of type from the range information and then, as a 
precaution, applying your transformations rules on the local 
assertion (that you have managed to conclude) to make sure it is in 
the local idiom you prefer.

If everyone is prepared to do this much work, then you can publish 
your RDF using any idiom and be sure that people will understand you. 
But in any case, you can publish it any way you want ( which I think 
is Dan's point) and if some folk don't entirely follow your meaning, 
well the world is like that already.
>>>  Issue B5: Storage Requirements
>>>  ===============================
>>>  status: disputed.
>>>  TDL requires significantly more storage to implement.
>>  Sergey got back on this one, no?
>>  In short: you may not need to store the whole string
>>  lots of times, but you do need to store some sort
>>  of distinct identity for each occurence of a string.
>We've already clarified that there are means to allow
>TDL to support tidy literals, both by idiom as well
>as MT. I believe that this is a non-issue, or at most
>an issue nearing resolution.

I agree. The only case that absolutely requires untidy literal nodes 
is the old P++ case, where an in-line literal is used 'directly', but 
what it denotes is sensitive to property ranges, as in

<mary> <age> "10" .
<age> <rdfs:range> <xsd:integer> .

meaning Mary is 10 (not "10") years old. Apart from this, we can have 
tidy literal nodes.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Monday, 4 February 2002 20:40:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:09 UTC