W3C home > Mailing lists > Public > public-rdf-wg@w3.org > August 2013

RE: RDF-ISSUE-140 (dataset-comparison): RDF Dataset Comparison (Ivan Herman) [RDF Concepts]

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Sat, 10 Aug 2013 17:29:57 +0200
To: "'RDF Working Group'" <public-rdf-wg@w3.org>
Message-ID: <00ee01ce95de$79952960$6cbf7c20$@lanthaler@gmx.net>
On Saturday, August 10, 2013 4:50 PM, Pat Hayes wrote:
> On Aug 9, 2013, at 12:24 AM, Markus Lanthaler wrote:
> 
> > On Friday, August 09, 2013 12:20 AM, Gavin Carothers wrote:
> >> For clarity
> >>
> >> {
> >>  {
> >>    _:y rdf:type ex:graphsIlike .
> >>  }
> >>  _:y {
> >>    ex:a ex:b ex:c}
> >>  }
> >> }


[...]

> > Gavin, could you please explain ... why the first dataset isn't
> isomorphic to
> >
> > {
> >  {
> >    _:y rdf:type ex:graphsIlike .
> >  }
> >  _:x {
> >    ex:a ex:b ex:c}
> >  }
> > }
> >
> 
> The scope of bnode IDs is the entire dataset, because they can be
> shared between graphs in a dataset. So the first one of these has one
> bnode in it, and the second has two bnodes in it. Not isomorphic.

That's the question I'm trying to understand. As I see it, under the current
semantics the statement 

  _:y rdf:type ex:graphsIlike .

has nothing to do with the graph labeled with _:y (which, btw., I still
think is complete non-sense). I would interpret that as if the two _:y are
in different scopes.

So I would tend to say that the two datasets are structurally the same,
i.e., they are isomorphic


Dataset 1
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    ~~~~~~~~~~~~~~~~~~~~~~~
|                                    |  |                       |
|  ---   rdf:type    --------------  |  |  ---    ex:b    ----  |
| |_:y| ----------> |ex:graphsIlike| |  | |ex:a| ------> |ex:c| |
|  ---       -       --------------  |  |  ---      -     ----  |
|   -        -             -         |  |   -       -       -   |
 ~~~-~~<->~~~-~~~~~~~~~~~~~-~~~~~~~~~    ~~~-~<_:y>~-~~~~~~~-~~~
    -   -    -             -                -   -   -       -
    -   -    -             -                -  why  -       -
    -   -    -             -                -  not? -       -
    -   -    -             -                -   -   -       -
 ~~~-~~<->~~~-~~~~~~~~~~~~~-~~~~~~~~~    ~~~-~<_:x>~-~~~~~~~-~~~
|   -        -             -         |  |   -       -       -   |
|  ---   rdf:type    --------------  |  |  ---    ex:b    ----  |
| |_:y| ----------> |ex:graphsIlike| |  | |ex:a| ------> |ex:c| |
|  ---               --------------  |  |  ---            ----  |
|                                    |  |                       |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    ~~~~~~~~~~~~~~~~~~~~~~~
Dataset 2


Let me merge this with the other thread you just replied to


>> Yes, it's confusing. But I think it is a consequence of the decision to
not
>> define any dataset semantics. Blank nodes used as graph names do not
denote
>> the graph.
>
> It is not a consequence of that. There are two different issues here.
> 1. Is it the same bnode? (A syntactic issue.)

Is that really just a syntactic issue?


> 2. Does a graph label denote the graph it labels?  (A semantic issue.) We
have,
> regrettably, allowed the answer to 2 to be no, but that does not affect 1.


Here lies the crux IMO


>>> It looks way more obvious to me to consider a bnode as a label and
>>> a bnode in one of the graphs as being identical...
>> 
>> Fully agreed, but I think under the current semantics they are not.
>
> No, they can be the same bnode, but we don't impose the (obvious)
condition
> that the labelling B: {G} means that I(B)=G. BUt that does not mean it is
> not the same bnode. 

You lose me here. If I don't know what that blank node in the graph name
stands for, how can I say it is the same as the one used in a triple? If it
is the same, why aren't the statements about the graph? 

I can see your reasoning, it's also what would make most sense... but so
would making graph names denote the graphs. Unfortunately that's not the
case and thus I'm not sure whether this is consistent.


--
Markus Lanthaler
@markuslanthaler
Received on Saturday, 10 August 2013 15:30:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:31 UTC