Re: rdfms-graph: Food for thought

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