- From: Graham Klyne <Graham.Klyne@baltimore.com>
- Date: Mon, 16 Jul 2001 13:01:17 +0100
- To: pat hayes <phayes@ai.uwf.edu>
- Cc: w3c-rdfcore-wg@w3.org
At 02:15 PM 7/12/01 -0700, pat hayes wrote: >>At 01:01 PM 7/11/01 -0500, Aaron Swartz wrote: >>>Here's some questions (with proposed answers) to get us thinking about >>>rdfms-graph. I'm also curious whether there are other questions that >>>should be considered part of the resolution -- the issue description >>>isn't really enough for me to tell. >>> >>>1) Does an RDF graph have a URI? >>> >>>It is a Resource, and it can. M&S does not define a specific one. >> >>I agree. I'm not sure anything more needs to be said. Any such URI is >>not part of the abstract syntax/model. > >I agree except with the last sentence. The abstract syntax does not >exclude URIs that may happen to denote an RDF graph, so we need to say >that it means when they do occur. I think we can simply be agnostic about it. I think I was a bit sloppy there -- I meant to say they don't have a distinguished or required place in the abstract syntax -- which I think is consistent with what you say. >>>2) Is an RDF graph a set or a bag? >>> >>>A set, as it has conjunctive assertion semantics, or whatever they're >>>called: >>> (A && A) => (A) >> >>Again, I agree. I'm not sure anything more needs to be said. > >The fact that it has this semantics doesn't mean that it is a set. Logical >expressions are not sets, but (and A A ) still implies A and vice versa. >The issue is whether we want to say that an RDF graph cannot contain two >copies of the same triple, not what we interpret those triples to be >saying. I would urge that it would be harmless to let them be bags, and >insisting that they are sets places an unnecessary burden on a parser >(which would need to remove all duplications whenever it merged two >graphs), so let them be bags. Hmmm... I think this is a design choice that could go either way, each of which puts some kind of constraint on the parser: Bag - requires that the parser accurately create a separate copy of each triple defined by the input; this might be a burden for some implementations -- e.g. a relational database that uses the 3 triple components as the primary key in a table. Set - requires that the parser detects duplicates, as you say. In defining the abstract syntax, I think we are trying to capture something of the *intent* (read "meaning") of the RDF language used, rather than to prescribe a particular implementation. Calling an RDF graph a "set" seems to more closely reflect the intent. One might say it doesn't matter which it is (set or bag), and in a sense that would be true. But then we lose a small practical benefit of the approach this group has been followings, viz. to prescribe a collection of triples that correspond to any RDF graph. In defining and formalizing N-triples, I think the Bag approach of not forbidding duplicates is right, because that means the semantics is explicitly defined by the formalism. In defining the mapping from RDF/XML to N-triples, the choice is less clear (to me). So I'll offer a test case: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http//example.org/#"> <rdf:Description about="http://example.org/#Subject" > <ex:property>Value</ex:property> </rdf:Description> <rdf:Description about="http://example.org/#Subject" > <ex:property>Value</ex:property> </rdf:Description> </rdf:RDF> For which, SiRPAC says the triples are: <http://example.org/#Subject> <http//example.org/#property> "Value" . <http://example.org/#Subject> <http//example.org/#property> "Value" . Similarly, the graph displayed has two identical arcs. This seems to be at odds with RDFM&S, section 5, (P162) which says "There is a set called Statements, each element of which is a triple of the form ...": http://lists.w3.org/Archives/Public/www-archive/2001Jun/att-0021/00-part#162 >>>3) Can a node exist in a graph without any properties? >>> >>>Yes. This is indicated in the current XML syntax with an empty >>>Description element. >> >>Here, I disagree: there is no obvious way to represent an isolated node >>in an abstract syntax/model based on triples. I think an empty >><Description> adds nothing to the semantics so should not appear in the >>abstract syntax/model. > >As a matter of general methodology, the question to ask is whether >allowing it would cause any harm. I can't see any harm, so would opt for >not forbidding it. The "harm" I see is that (a) not forbidding would seem to suggest a requirement to represent it, and (b) it's not clear to me how one would represent (in N-triples) a node on its own. Also, I think a node not part of a property has no "meaning", so allowing this would seem to introduce spurious alternatives for the same semantics. It seems simpler to just ignore isolated nodes at the abstract syntax level. #g ------------------------------------------------------------ Graham Klyne Baltimore Technologies Strategic Research Content Security Group <Graham.Klyne@Baltimore.com> <http://www.mimesweeper.com> <http://www.baltimore.com> ------------------------------------------------------------ ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses.
Received on Monday, 16 July 2001 10:51:43 UTC