Re: Addressing ISSUE-64 and ISSUE-65

On 22 Aug 2011, at 22:07, Juan Sequeda wrote:
> If I understand correctly, your proposal is:
> 
> 1) Prefer to use relative IRIs (<People#fname>) instead of prefixes (ppl:fname)

Yes.

> 2) When it comes to generating an IRI for a foreign key, you prefer <ref/People#addr>.

Yes. (I like the <xxx/Table#column> pattern. I don't really mind what “xxx” is.)

> What is the IRI that you recommend for multi-attributes foreign keys?

xxx/Table#column1,column2.

This would address ISSUE-65 (FK properties are now distinct from data properties; no more need to suppress the data triple for single-column FK).

It does not address ISSUE-64. I don't mind what happens with ISSUE-64 as long as it doesn't make the common case more complicated. In other words, as long as there's just one FK defined over a column sequence, it should use a simple property IRI like <xxx/Table#column>.

I don't have a strong opinion on what should happen in the corner case (multiple FKs defined over the same column sequence). There are good arguments for just using the same property and accepting a clash, and there are good arguments for treating it as an exception that generates different IRIs.

Best,
Richard


> 
> Am I missing something? I just want to be clear on your position. 
> 
> 
> Juan Sequeda
> +1-575-SEQ-UEDA
> www.juansequeda.com
> 
> 
> On Fri, Aug 19, 2011 at 7:28 AM, Richard Cyganiak <richard@cyganiak.de> wrote:
> On 17 Aug 2011, at 23:48, Eric Prud'hommeaux wrote:
> >> You say that some proposals don't play well with namespace prefixes. You use this as an argument against these proposals. I think that's an invalid argument because namespaces are *already* entirely useless with the DM.
> >>
> >> 1. Each table requires its own namespace, leading to an abundance of namespaces
> >
> > In the use cases I've dealt with, this has been a feature rather than a bug. That is people:ID and addrs:ID are conveniently distinguished. Writing rules or queries is very intuitive with this partitioning:
> >
> >    PREFIX ppl: <People#>
> >    PREFIX adr: <Addresses#>
> >    SELECT ?city WHERE { ?who ppl:fname "Bob" ;
> >                              ppl:addr ?addr .
> >                        ?addr adr:city ?city }
> 
> Most databases don't have neat and intuitive table names like that. They have "OBX_MODEL_PPL2" and "OBX_SHP_ADR_MAIN". Once you look beyond the MySQL webapp market and look at enterprisey stuff, many database schemas aren't even hand-designed, but look like they dropped out of some CASE tool or other monstrosity. Actually coming up with a neat intuitive three-letter abbreviation for each of these tables is *hard*. It is extra work. Most users won't bother, because they can get the job done without inventing prefixes, and for fear that their neat prefix doesn't quite capture the meaning of the table (which they probably didn't design themselves and only half-understand).
> 
> >> 2. The DM is not written by humans but by machines. The machine has to generate the namespace prefix. The only thing it can really do is either use the table name, or use the (unreadable) ns0, ns1, ns2 pattern.
> >
> > The DM will be queried by humans. It will also be transformed to common ontologies by rules written by humans.
> 
> So you assume that the prefixes will be written by humans?
> 
> I don't believe that.
> 
> No one wants to enter several lines of boilerplate before they can run a query. Either the processor will pre-configure the prefixes (which again raises the problem of machine-generated prefixes), or users will just make do without prefixes.
> 
> Writing the prefixes manually, on the other hand, requires an understanding of the URI scheme used by the DM. Once one has acquired that understanding, one can just as well forget about prefixes and use the URIs straight.
> 
> >> 3. Generating prefixes automatically from the table name leads to all sort of Fun with special characters. Basically, it is impossible because there are no escape mechanisms inside the *prefix*.
> >
> > Most databases have only unary foreign keys.
> 
> I doubt that. Many databases don't have any foreign keys at all. And many non-toy databases *do have* foreign keys with multiple columns.
> 
> > Most of these can be tranformed to common vocabularies with rules which don't mention node identifiers, e.g.
> >
> >    PREFIX ppl: <People#>
> >    PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> >    CONSTRUCT {
> >        ?who a foaf:Person ; foaf:givenName ?fname
> >    } WHERE { ?who ppl:fname ?fname }
> 
> Have you tried a non-toy example? How did that go?
> 
> >> 4. The DM already produces many IRIs that cannot be abbreviated into prefixed names because they contain commas or equal signs in the local part.
> >
> > Many queries and rules don't include specific node identifiers.
> 
> It is very common for queries to ask for a specific identifier.
> 
> > For databases with only unary foreign keys, these queries can be tersely and conveniently expressed with the current algorithm.
> 
> Bullshit. Using namespaces in DM queries makes them more verbose, not more terse. Rewriting any of your examples here with relative URIs makes the queries more compact.
> 
> >> 5. Even if that's not the case, special characters in table and column names will often prevent abbreviation.
> >
> > But again, most column names are BORING UPPER-CASE STRINGS (which fit the PN_LOCAL lexical pattern which SPARQL and Turtle use).
> 
> Sure, BORING_UPPER_CASE_STRING works in 80% of all cases. Nevertheless, *every* user who does any real work with the DM will be confronted with situations where prefixed names don't work, so they will:
> 
> - have to understand the relative URI approach anyway
> - be confused about why sometimes the one and sometimes the other is used
> - be confronted with unexpected errors when they try to use prefixed names but it doesn't work because there's some weird character in a column name
> - have to learn which characters are allowed in local names, so that they know whether to use prefixed name or relative URI when writing their queries
> 
> And this is *in addition* to dealing with percent-encoding, which is confusing enough!
> 
> I repeat this for you: When working with any non-toy database, you'll have to use the relative URI approach *anyway* in at least a few instances, so users have to learn that approach *anyway*, and have to learn what the heck the difference is, and when to use which.
> 
> The relative URI approach works *always*, is *more terse*, and removes an entire layer of complexity.
> 
> >> 6. All RDF syntaxes that support prefixes, also support relative IRIs. Using the table name as a prefix is just as long as using a relative URI: People:addr vs. <People#addr>.
> >
> > Perhaps it's a fault of the educators,
> 
> Perhaps.
> 
> > but I've seen a surprisingly small number of SPARQL queries using base (like < 3%).
> 
> Well, the DM is quite different from your average RDF graph, so it's not surprising that queries against the DM will look different.
> 
> BASE isn't even necessary. The processor can specify a default base.
> 
> >> 7. *All* URIs that can possibly occur in a DM graph can be nicely abbreviated with a single base URI.
> >>
> >> My conclusion is that using prefixes with the DM is impossible to implement in any way that works and makes sense. Implementations that are interested in producing readable RDF should just use relative IRIs.
> >>
> >> Therefore, I think you have not presented any valid arguments against using property IRIs such as these:
> >>
> >>  <People,Addresses#addr,ID>
> >>  <People#addr,Addresses,ID>
> >>  <ref/People#addr>
> >>
> >> Personally, I like the last option.
> >
> > So worse than each table having its own namespace, each foreign key has again a novel namespace.
> 
> Eh. My point is that *none* of them has a namespace declaration. You know, there is no law that states you can't use <IRIs> as property names in SPARQL.
> 
> > 1 and 3 ensure that no foreign key will be in the same namespace as the other properties of the table. 2 renders many common queries like
> >    PREFIX ppl: <People#>
> >    PREFIX adr: <Addresses#>
> >    SELECT ?city WHERE { ?who ppl:fname "Bob" ;
> >                              ppl:addr ?addr .
> >                        ?addr adr:city ?city }
> > harder to write.
> 
> How is the above harder to write than this?
> 
>   SELECT ?city WHERE { ?who <People#fname> "Bob" ;
>                             <People#addr> ?addr .
>                       ?addr <Addresses#city> ?city }
> 
> > What is the justification for complicating these common cases?
> 
> I think of it as simplifying them. One less layer of complexity. More predictability. Less to learn.
> 
> > If it's just 'cause there's an exception in the spec, I don't see the trade-off justified at all. If it's to save an arc traversal { ?who ppl:addr ?addr . ?addr adr:ID ?id }, most graph patterns won't even touch db-encoding artifacts like the ID. If it's to save a SQL join, the relational schema already provides the DM processor already with sufficient info to not do the join (i.e. FOREIGN KEY (addr) REFRENCES Addresses (ID) ).
> 
> None of the above.
> 
> It's to make the DM more predictable, easier to use, easier to teach and easier to read for real-world applications.
> 
> Your entire argument hinges on the use of namespace prefixes, and since I believe that use of namespace prefixes with the DM is a bad idea, I simply don't find your argument compelling at all.
> 
> You're optimizing for the “hello, world” case at the expense of real-world usability. You're pretending that funky characters in identifiers are a rare corner case that doesn't really happen and that you don't need to worry about. I'm sorry but that doesn't work. Believe me, I've tried that approach in D2RQ and it doesn't work. Our second-most frequent class of bugs over the years has been the result of me assuming, “oh no one would ever be so stupid to put *that* character into a column name, right?”
> 
> Best,
> Richard
>

Received on Tuesday, 23 August 2011 09:01:00 UTC