Re: Comments on Eric's Section 2

On 9 Nov 2010, at 12:12, Eric Prud'hommeaux wrote:
> I propose to get consensus on your FPWD proposal first, then address
> the #_ issue in all of the examples. An alternative viewpoint came
> from DanC in his review:
> [[
> 2010-10-29T17:43:19Z <DanC> yay for #_
> ]]

Can you please state why you put the #_ there. You keep refusing to  
provide a rationale for the inclusion of this. If you're not prepared  
to provide rationale, then it should go. “Yay” does not count as  
rationale.

>> 4. Inconsistency: Section 2.2 states that predicate IRIs have
>> hashes, while all the examples have slashes.
>
> fixed (if we're speaking of the same place)

I see this in the current version:

[[
IRIs in the predicate position are composed by concatenating:
	• the stem
	• '/'
	• the url-encoded (per WSDL urlEncoded [WSDL]) table name
	• '/'
	• the url-encoded column names, separated by a '_'
For example, a table called People with a foreign key with the column  
names fname, lname would produce the IRI <http://foo.example/DB/People#fname_lname 
 >
]]

The rule would produce a different result from the example.

>> 8. In order to have an improved narrative in the section titles, I
>> propose splitting 2.2 into one section “Identifiers for rows and
>> columns” and one section “Row mapping rules”. (Not essential for
>> FPWD)
>
> I believe the current version has more structure and bolding than what
> you reviwed. Has this addressed your comment?

It's improved.

-1 to the subsubsections like 2.2.1. This is not a long document; you  
should be able to do this with just two levels of headings.

>> 9. Section 2.5: “Hierarchies” can refer to many things in an SQL
>> context, so it's a bit hard to figure out what the section refers
>> to. The first sentence should perhaps talk about “hierarchies of
>> tables that represent specializations of the same concept” or
>> something similar.
>
> Is
> [[
> It is common to express specializations of some concept as mutiple
> tables sharing a common primkary key.
> ]]
> sufficient?

Yes, thanks.

> [[
> As a counter example, a Wedding table may
> have exactly two spouses but it's still not a many-to-many relation in
> most places.
> ]]

I don't understand why this is a counter-example. The question whether  
a row in a marriage table is represented as one triple or as one  
resource with two triples is completely independent from the question  
whether the relationship is many-to-many or not. These are independent  
questions. In fact, the whole issue shouldn't be named “many-to-many”  
because it has nothing to do with questions of cardinality. It's about  
the question what to do with tables that represent relationships and  
not entities.

You state there that detecting these tables is hard. That is not true.  
You have already provided a test in an earlier mail.

>> 11. See my comments to Juan and Marcelo asking for inclusion of
>> table IRIs and of a triple that associates each row to its table.
>> I'd really like to see a proposal for this in the FPWD, but at least
>> an issue box would be essential. I note that the directGraph/alt
>> version already has this.
>
> The foreign-key-is-candidate-key situation *appears* to imply that the
> same node is defined across multiple tables; saying that it's an
> Address or an Office won't give you the critical information which is
> what predicates came from what table.

I don't have a requirement for knowing which columns come from what  
table.

> I propose instead:
>
> <Offices#building> rdb2rdf:inTable <#Offices> .
> and maybe
> <Offices> rdb2rdf:inDatabase <> .

These don't address what I asked for. I want to be able to query for  
all resources generated from a single table in an obvious way.

> That way you can separate which triples came from which tables.

I want to know this for resources, not for triples. Hierarchical  
tables are a rare corner case and I don't particularly care how that  
edge case is handled as long as the common case remains simple.

> You
> can get the type effect where you want it by asserting
> <Offices#building> rdfs:domain <#Offices_row> .

What do you mean here? Do you suggest to make that triple part of the  
direct mapping and state that implementations MUST query the RDFS  
inference closure of the graph? That would address my requirement.  
Otherwise I don't know how I would “assert that triple”.

Best,
Richard

Received on Tuesday, 9 November 2010 06:51:52 UTC