W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2001

RE: datatypes and MT (#rdfms-graph)

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Thu, 15 Nov 2001 12:56:39 -0600
Message-Id: <p05101066b819be5f099d@[65.212.118.147]>
To: Patrick.Stickler@nokia.com
Cc: w3c-rdfcore-wg@w3.org
>  > ...The other proposals (S, DC and oldX=URV) don't need
>>  this complication, however, since they can assume tidiness on literal
>>  nodes as well as urirefs.
>
>Can someone please point me to the most concise, prose definition
>of tidiness as it relates to the graph?

Sorry, local jargon. I invented the term in the MT document, by 
defining an RDF graph to be 'tidy' if had no duplicated names, so 
each uriref or literal occurs only on a single node. (At that time I 
was assuming (naively) a U-style treatment of literals. ) Since then 
it has also been used to refer to the condition that triples are not 
duplicated in any graph, for example.

The reason for having such a term is that forming the simple union of 
two graphs can produce a non-tidy graph, so one has to get explicit 
about the tidying process (ie the merging of nodes with the same 
label to create a tidy merged graph.)

When we started taking literals more seriously, some ways of treating 
them (the P(++) ways) require that different occurrences of the same 
literal may have different meanings, so it is no longer appropriate 
to insist on tidiness for literal nodes. In fact, this is one way 
that the P(++) proposals (and I think the X, though I'm not sure) can 
be distinguished from the U/S/DC proposals, in that the latter will 
work with graphs that are tidy on literals, while the others will 
not. So this decision has consequences even for the graph syntax.

Hope this helps.

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 Thursday, 15 November 2001 13:56:18 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:42:42 EDT