Re: Proposal for ISSUE-65

So I guess we are down to choosing between '.' and '-'

Can we just vote on this tomorrow and close this issue?

Juan Sequeda
+1-575-SEQ-UEDA
www.juansequeda.com


On Mon, Aug 29, 2011 at 12:12 PM, Richard Cyganiak <richard@cyganiak.de>wrote:

> On 29 Aug 2011, at 16:07, Eric Prud'hommeaux wrote:
> >> If I understand correctly, '-' is a valid character in qnames while ','
> is not.
> >
> > That, and '-' is an operator in SQL so it needs to be protected with ``s,
> discouraging it's use in identifiers.
>
> “.” needs to be escaped too, so that's no difference.
>
> > In my observation, there are more '.'s in SQL names than there are '-'s
> (in fact, I've never seen the latter).
>
> I've seen both. I don't know what's more common.
>
> I prefer “.” for readability, but will go along with “-” if that's the
> majority preference.
>
> Progress! ;-)
>
> Best,
> Richard
>
>
>
> >
> >
> >> So all ',' should be substituted with '-'
> >>
> >> 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.
> >>>>
> >>>
> >
> > --
> > -ericP
> >
>
>