- From: Dan Brickley <danbri@danbri.org>
- Date: Thu, 20 Oct 2011 14:01:15 +0200
- To: Steve Harris <steve.harris@garlik.com>
- Cc: RDF Working Group WG <public-rdf-wg@w3.org>
On 20 October 2011 11:17, Steve Harris <steve.harris@garlik.com> wrote: > On 2011-10-19, at 20:53, Dan Brickley wrote: >> >> On 19 Oct 2011, at 21:33, Pat Hayes <phayes@ihmc.us> wrote: >>> On Oct 19, 2011, at 7:32 AM, Andy Seaborne wrote: >>>> On 19/10/11 13:17, Sandro Hawke wrote: >>>>> On Wed, 2011-10-19 at 11:23 +0100, Andy Seaborne wrote: >>>>>> >>>> >>>>>> I don't mind how what we do to rdf:Seq but if we say "use blank nodes >>>>>> for Seq" (which then avoids the merge issues) it is a step forward (Ian >>>>>> -- skolemized system generated URIs would count as well) >>>>> >>>>> I can live with that, but I'm not sure why we'd say >>>>> dont-use-non-blank-nodes-for-Seq any stronger than dont-use-Seq. >>>> >>>> It avoids merge problems as the bNodes should stop two rdf:_1's on the same resource. >>> >>> Huh? How does that work? I mean, how do bnodes stop this happening? >> >> I'm having a hard time seeing that, either. >> >> The bNode could still carry properties e.g. Inverse Functional Properties, sufficient to get it mixed up with another node standing for the same thing. > > Doesn't that equally apply to lists and functional properties though? It's just a modelling error. In the presence of OWL reasoning with "bad" data or schema, all bets are off. Yes. I'm arguing against the idea that bnodes give some magic protection against this kind of mess. In my scenario the data wasn't even 'bad'; perhaps two files that were true at different times (e.g. dilbert room assignment scenarios could probably fit this issue). Without lists/containers/collections supported more deeply in the language, it's hard to avoid ordered data getting messed up. Dan
Received on Thursday, 20 October 2011 12:01:44 UTC