- From: Seth Russell <seth@robustai.net>
- Date: Wed, 19 Jun 2002 06:37:13 -0700
- To: "Danny Ayers" <danny666@virgilio.it>, "Jonathan Borden" <jonathan@openhealth.org>, <www-rdf-logic@w3.org>
From: "Danny Ayers" <danny666@virgilio.it> > Presumably the edge (==arc) can have as an attribute the URI of a property > (e.g. dc:creator), but that this wouldn't be unique. The edge itself would > have an identity status akin to that of bNodes, only existing in relation to > the nodes to which it is connected. > Is there any good reason within RDF MT why the edge shouldn't have it's own > (instance) URI? ... probably because that's the way they designed it. The standard structure, defined by RDF which we now call a triple or edge, has 3 and only 3, attributes: (<SubjectUri>, <PropertyUri>, <ObjectUri>). It *is* it's own instance; but it does *not* have a URI; at least not one defined by RDF. Me thinks giving it a URI, in the sense that a URI is supposed to identify the same unique thing to everybody in the world, would be folly. These triple thingies only become unique in that sense when they are seen in some context. If your application or file defines that context, well then give each edge a number ... that's what lots of API's actually do .... but then don't call it a URI, because everybody will have their own different number for it. The way I would like to see RDF extended is to give the context of a triple a URI. That way the triple becomes a quad: (<ContextUri>, <SubjectUri>, <PropertyUri>, <ObjectUri>). Unique triples can now flow into a context from whatever source; not just one file. They can flow into the same context because now we have a name for it. This <ContextUri> identifies the same thing that is delineated in TimBl's N3 by { .... } enclosures. But TimBl doesn't call it a context (which is a dirty word in some circles), he calls it formulae. I think programmers and the man in the street will know what we are talking about just fine if we just call it a context. Seth Russell
Received on Wednesday, 19 June 2002 09:43:24 UTC