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

Re: DATATYPING: second draft

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Fri, 25 Jan 2002 11:14:19 +0000
Message-Id: <>
To: Pat Hayes <phayes@ai.uwf.edu>
Cc: w3c-rdfcore-wg@w3.org
At 10:31 AM 1/24/02 -0600, Pat Hayes wrote:
>>At 10:19 AM 12/14/01 -0800, Sergey Melnik wrote:
>>>  > Dan has raised an issue, rephrased by Pat as how many triples result 
>>> from
>>>>  merging:
>>>>     foo bar "10" .
>>>>  and
>>>>     foo bar "10" .
>>Ha!  I came up with exactly this issue in my review of the latest model 
>>theory draft.  Do we have a consensus yet?
>Well, let me suggest what the answer should be. This may seem odd, but....
>I think the answer depends on whether this is a single graph being 
>'merged' with itself, or whether it is two distinct, but identical (ie 
>isomorphic) graphs. If the former, then the 'merge' is just the same 
>graph, with 2 nodes and one arc: a single triple. If the latter, then it 
>is a larger graph with three nodes (assuming foo is a uriref) and two 
>arcs. This is because different occurrences of a 'bare' literal have to be 
>treated as distinct nodes (in case one of them should get itself attached 
>to a different datatyping scheme from the other...), unlike urirefs. 
>Notice that if you did a similar exercise with two copies of an all-uriref 
>foo bar baz .
>then the merged graph would be the same in either case, ie it would simply 
>be a single triple; since in this case, the merging would (re-)identify 
>the two copies of each uriref.

OK, that works for me.

I guess we might want to note that two copies of an N-triples document 
ipso-facto represent different isomorphic graphs, so in that case their 
merge would result in two triples for each one containing a literal?


Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
       /\ \
      /  \ \
     / /\ \ \
    / / /\ \ \
   / / /__\_\ \
  / / /________\
Received on Friday, 25 January 2002 08:25:06 UTC

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