Re: Proposal for ISSUE-65

On 29 Aug 2011, at 15:26, Juan Sequeda wrote:

> That was Eric's suggestion. If I understand correctly, '-' is a valid character in qnames while ',' is not. 

Ah, I see.

> So all ',' should be substituted with '-'

“=” isn't a valid character either, so I think it makes sense for record identifiers to remain the way they are.

“.” is also valid in prefixed names. So for FK properties, the candidates are:

  <MY_TABLE#ref-MY_COL1-MY_COL2>
  <MY_TABLE#ref.MY_COL1.MY_COL2>

I have a slight preference for the latter, because “.” reads more like a separator and is less likely to occur in column names. (There is some risk of confusion because “.” is usually used as a separator between table name and column name, so it might be surprising to see it used to separate columns. I still prefer it as it reads better than the dash.)

Best,
Richard


> 
> Juan Sequeda
> www.juansequeda.com
> 
> On Aug 29, 2011, at 10:10 AM, Richard Cyganiak <richard@cyganiak.de> wrote:
> 
>> Juan,
>> 
>> On 28 Aug 2011, at 21:45, Juan Sequeda wrote:
>>> After discussion with Eric, we came up with the following proposal:
>>> 
>>> [[
>>> PROPOSAL: For a foreign key of any arity, the reference property IRI is of the form <Table#ref-attr1-attr2-...-attrn>. This will address ISSUE-65
>>> ]]
>> 
>> I see this uses dashes instead of the commas.
>> 
>> Are record IDs still <Table#attr1=value1,attr2=value2> or do you plan to replace the commas there too?
>> 
>> If not, what's the motivation for using different punctuation in these cases?
>> 
>> Thanks,
>> Richard
>> 
>> 
>> 
>>> 
>>> Juan Sequeda
>>> +1-575-SEQ-UEDA
>>> www.juansequeda.com
>>> 
>>> 
>>> On Sun, Aug 28, 2011 at 10:21 AM, Richard Cyganiak <richard@cyganiak.de> wrote:
>>> Hi Eric,
>>> 
>>> On 27 Aug 2011, at 23:52, Eric Prud'hommeaux wrote:
>>>>> The case for Uniformity is stronger than that: All columns, always, are mapped in the same predictable way; with the single exception of unary foreign keys.
>>>> 
>>>> Given that all values are currently extractable, I think this needs to be cast as a use case that by includes a user and a learning curve:
>>>> 
>>>> User Joe has understands the pattern of querying database columns, doesn't know the unary foreign key exception.
>>> […]
>>> 
>>> I'm more concerned about the case where Joe builds his application, and then Bob the DBA, who knows nothing of Joe's work, makes an implicit foreign key constraint explicit, and Joe's application breaks.
>>> 
>>> I'm more concerned about the case where Joe uses some off-the-shelf front-end on top of the DM (such as Pubby or Linked Data Pages or some generic Linked Data browser), and that front-end just shows the directly attached properties when displaying a resource, and therefore the LOINC code of a disease outcome is not shown.
>>> 
>>> I'm more concerned about the case where Joe *thinks* that performance suffers because his SPARQL query requires an extra triple pattern to access the LOINC code, which in his mind translate to an extra join (whatever the implementation *actually* does under the hood).
>>> 
>>> I'm more concerned about Joe adding a dummy second column to his FKs just to avoid these problems, once he figures out that they only apply to single-column FKs.
>>> 
>>>> An approach which syntactically distinguishes all predicates, while leaving them in the same namespace, would address this:
>>>> 
>>>> SELECT ?name ?city WHERE {
>>>>    ?person <PERSON#LNAME> ?name .
>>>>    ?person <PERSON#LADDRESS> ?aid .
>>>>    ?address <ADDRESS#LCITYNAME> ?city .
>>>>    ?address <ADDRESS#LID> ?aid .
>>>> }
>>>> (Note the 'L's preceding the column names.)
>>>> This is sort of ugly and unpleasant. Maybe we'll find something more attractive, but ultimately, if we'll have to sacrifice some simplicity if we want to eliminate the unary foreign key exception.
>>> 
>>> You mean like the one I proposed?
>>> 
>>> http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011Aug/0140.html
>>> 
>>>> The DM is definitely supposed to be usable. The queries and rules we've used as examples were just as intuitive as the analogous SQL queries. Further, the DM is quite reasonably described in a small bit of RDFS and OWL, which is likely to be the languages that informs query builders and user-facing interactive browsers.
>>> 
>>> I don't know what you mean to say here. The DM has not been described in RDFS or OWL anywhere as far as I can tell.
>>> 
>>>> Any approach which requires a table with N foreign keys to have N+1 schema documents appears to be poor Semantic Web practice.
>>> 
>>> 1. The DM turns a DB into an RDF graph. It doesn't speak about schema documents at all.
>>> 2. You've never presented a use case that requires schema documents.
>>> 3. The proposal would require *1 or 2* schema documents per table, not N+1.
>>> 4. Why is minimizing the number of schema documents a design goal?
>>> 5. If a DB has 50 tables, then you're ok with a design that increases the number of schema documents from 1 to 50 (a factor of 50), but you're not ok with a design that takes it from 50 to somewhere around 100 (a factor of 2)?
>>> 
>>>> The proposals for the many-to-many tables broke every query on those tables if something as innocuous as a timestamp were added to the table.
>>> 
>>> So, it's ok that queries break when an implicit FK constraint is made explicit, but it's not ok if queries break when a column is added? By what general principle do you decide what kinds of changes are allowed to break queries?
>>> 
>>> Also, with the proposed many-to-many design it would have been *possible* to write conservative queries that don't break, because it would have just added *additional* convenience triples while retaining the standard DM representation of the many-to-many table. Not so with the FK design.
>>> 
>> 
>

Received on Monday, 29 August 2011 15:01:16 UTC