See also: IRC log
<trackbot> Date: 13 September 2011
<mhausenblas> scribenick: mhausenblas
PROPOSAL: Accept the minutes of last meeting http://www.w3.org/2011/09/06-RDB2RDF-minutes.html
<nunolopes> +1
<juansequeda> +1
<ivan> 1
RESOLUTION: Accept the minutes of last meeting http://www.w3.org/2011/09/06-RDB2RDF-minutes.html
ISSUE-48?
<trackbot> ISSUE-48 -- Mapping SQL datatypes to RDF -- pending review
<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/issues/48
http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011Sep/0007.html
Michael: David, are we fine with it now?
David: yes
PROPOSAL: Close ISSUE-48 as it is addressed in http://www.w3.org/2001/sw/rdb2rdf/r2rml/#datatype-conversions
<MacTed> +1 proposal
<nunolopes> +1
<dmcneil> +1
<ivan> +1
RESOLUTION: Close ISSUE-48 as it is addressed in http://www.w3.org/2001/sw/rdb2rdf/r2rml/#datatype-conversions
<ivan> ISSUE-66?
<trackbot> ISSUE-66 -- Translation Scheme as proposed seems too complicated for the simple task of mapping <DB value(s), RDF term> -- open
<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/issues/66
<ivan> ISSUE-61?
<trackbot> ISSUE-61 -- Re-using public entity identifiers - look-up table -- pending review
<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/issues/61
Michael: propose to first address ISSUE-66 and the we can also close ISSUE-61
Souri:: the translation
scheme is difficult
... we came up with a
solution that is simpler
... there are several
issues that come up
... we came with a
simplification
... one is many to one we are thinking of reducing it to one to
one
... unless the user really asks for it we should not complicate
our lives
... one to one suffices in our view
Souri: the other aspect you
currently associate one or more tranlsation scheme
... but if you do that with the predicate map, we believe it is
becoming difficult to figure it out
... if you are not materialize it but you take the query it
becomes difficult
... we did make that restriction
Souri: if last call comment come
back to us
... these are the two restrictions we wanted to put into it to
reduce the complexity of implementation to the minimum
... other than that we tried to avoid skos, just called it a
simle translation map
... there is an rdf term that is associated to at term
map
... the translation scheme if present then it maps an rdf term
to another one
... the translation scheme is just a description of such
pairs
... it took us quite some time to find out the implementation
difficulties
mhausenblas: i would be happy
moving on
... there was one comment from ted regarding skos
<Souri> Here is the URL for translation scheme: http://www.w3.org/2001/sw/rdb2rdf/r2rml/#translation-schemes
mhausenblas: this is something
where I would prefer to cut certain features to move on
... ted came up with a solution
... that would support the skos use case, but would keep it
also simple like souri suggested
MacTed: my suggestion to stick
with richard's suggestion
... the new set of pairs seems to be equivalent to
broadMatch
... if we say: use that, if you do not know any better
... and others can do more, we do not close the door
mhausenblas: i am bit unsure...
there 4 ways
... 1 richard
... 2 souri and seema
... 3 drop section 9
... 4 factor it out into a different, non rec-track
document
Souri: my main concern is that we
try to such broad things
... but the rdb2rdf does not need that type of
relationships
... that can be done separately as another document
... the mapping of, say, /Boston, should be done in a separate
document
... anything that mapping should be done in a separate mapping
portion
MacTed: this is where this separate document lives!
mhausenblas: the idea is to cut
down section 9 to minimum, where it is just defined
... and then putting the translation is in a separate
document
MacTed: what souri said was to
split r2rml into separate document
... that makes it more complicated
Souri: all I am thinking about is
you have a database, you map a particular column, the column
'R'
... I want to show that as column 'Red'
... I can then define a mapping R->Red
... R can also be in the visible light class
... but that aspect should be in a separate document
... that I may or may not want to include
... document is a separate rdf graph or owl, not a document as
a note or something similar
mhausenblas: so section 9 should only have some sort of an 'interface' and that is it
MacTed: it is a way to do it but it does not really simplify it
mhausenblas: who would oppose to totally drop section 9
Souri: before, I want to discuss
something
... if you look at the example
... it this example we are saying code/1 that we can generate
templates is not very good,
... we want code/indian
... we just want to get to that well known meaningful
uris
... but we might want to say that that both can be mapped to
/indian and /thai are all /asian
... that aspect is not in the mapping
... the rest is some sort of ontology
... that you express in owl or other
... but that is not for r2rml
MacTed: after that you have only
/indian or also /1?
... I think that the many to one is really valuable, and that
has been removed
... having the original iri is also valuable
... there was a move towards more powerful options
... by removing the many to one says nobody need the more
complex one
Souri: the idea of the spec is to
keep it as simple as possible
... making it elegant also requires lot of work
MacTed: simplification for its
own purpose is not valuable
... if you do not know skos, use broadmatch, it allows many to
many,
... but lets people who understand to use skos fully
mhausenblas: main question is if
you can merge the skos version of richard and yours, souri,
which is simpler?
... if you want to leverage skos then you can do it
Souri: you can do it outside, put it into a separate graph, and then merge them
mhausenblas: but you need to preserve the original uris
Souri: if you want to prefer /1
you can include that all
... we have a disagreement
... I definitely feel positively to our position
... there is a strong support for the other side
... I would say let us drop it
mhausenblas: I would feel comfortable if the terms you use here to use the same terms
Souri: translation map was not
there
... the syntax and the vocabulary use ws different
mhausenblas: we are free to have
things in there
... if we can agree to drop section 9
... and have a separate, non-rec track document describing
things
... but I am fine dropping it
<mhausenblas> PROPOSAL: Drop section 9 and close ISSUE-61 and ISSUE-66 with it (maybe reuse text in a non-REC track document)
+1
<Souri> +1
<Seema> +1
<MacTed> -1 dropping the section
<nunolopes> +1
MacTed: it is problematic to me
the way these things happened
... there were several examples side by side
<Souri> please see the old version
MacTed: it is no longer possible to compare these because they are not there
mhausenblas: we have spent just time...
MacTed: the other thing has already been removed
Souri: we kept both versions in the last 2-3 versions
<dmcneil> is there a link to the older version?
MacTed: my proposal was the
previous version of the section
... rather than creating that new set of terms
... and say using skos terms
mhausenblas: that is a full
circle
... richard wording was for issue 61
... and souri objected to it
<Souri> -1 to the previous version (involving SKOS)
MacTed: but the complication was that you ahve to know skos
mhausenblas: I personally support skos, but souri still says that the previous section would not work
souri: it is not the matter of
knowing skos
... we do not feel that it is not to be part of r2ml
... what we need to put there is the minimum
... you already have all the other possibilities outside of
r2rml
MacTed: the minimum functionality is dm
MacTed: we wanted to make
something more complex that would map to other
vocabularies
... dm cannot do this mapping
... which is correct
... for the person who does not know skos
Souri: the implementation nhas to support the full spectrum
dmcneil: the point souri is
making is a very good point
... I need to think through to see the implications
... so I think that at this point I agree dropping it
mhausenblas: I do not see anything that will resolve this
<mhausenblas> PROPOSAL: Drop section 9 and close ISSUE-61 and ISSUE-66 with it (maybe reuse text in a non-REC track document)
MacTed: fine, drop the section, but I want the previous iteration to be visible somewhere
<MacTed> +0
RESOLUTION: Drop section 9 and close ISSUE-61 and ISSUE-66 with it (maybe reuse text in a non-REC track document)
ISSUE-59?
<trackbot> ISSUE-59 -- Syntactic sugar for triples maps that only have a single predicate-object map -- pending review
<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/issues/59
<mhausenblas> ISSUE-59?
<trackbot> ISSUE-59 -- Syntactic sugar for triples maps that only have a single predicate-object map -- pending review
<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/issues/59
mhausenblas: it is a syntactic sugar
Souri: it is only a
shortcut
... when there is a single predicate object map
... typically a map will have several
... so this short cut does not really make sense
<dmcneil> richard was specifically targetting the case of a many-to-many join table
Souri: our proposal was not to have it
<dmcneil> he argued that it was common/useful in this case
<mhausenblas> Michael: which would mean to remove http://www.w3.org/2001/sw/rdb2rdf/r2rml/#dfn-implicit-predicate-object-map
dmcneil: richard's response it is
common in the many-to-many join table case
... he specifically targeted this on that case
juansequeda: i asked that
question
... m-t-m was very complex to me
... but the way it could be done this
... if we do not have this as a sugar
... then I would like to see an example how to see it in the
document
mhausenblas: in the document
richard has captured the description of the issue
... it would make sense to get this example there
Souri: we added the example richard had and added an example on how to it
<mhausenblas> http://www.w3.org/2001/sw/rdb2rdf/r2rml/#example-m2m
juansequeda: if it is already done, then forget my comments
Souri: if you look at it if it is
o.k.
... the second example was the one the sugar was meant to
juansequeda: I will take a look
<mhausenblas> PROPOSAL: Remove section http://www.w3.org/2001/sw/rdb2rdf/r2rml/#dfn-implicit-predicate-object-map that contains syntactic sugar for single predicate-object map and close ISSUE-59
juansequeda: it looks good!
+1
<Souri> +1
<nunolopes> +1
<MacTed> +1
juansequeda: is there a tracked in as an r2rml version 2?
<Souri> v 1.1 :-)
<mhausenblas> PROPOSAL: Remove section http://www.w3.org/2001/sw/rdb2rdf/r2rml/#dfn-implicit-predicate-object-map that contains syntactic sugar for single predicate-object map and postpone ISSUE-59
<Souri> +1
+1
<nunolopes> +1
<Seema> +1
<MacTed> even better +1
<juansequeda> +1
<Marcelo> +1
RESOLUTION: Remove section http://www.w3.org/2001/sw/rdb2rdf/r2rml/#dfn-implicit-predicate-object-map that contains syntactic sugar for single predicate-object map and postpone ISSUE-59
<mhausenblas> ISSUE-65?
<trackbot> ISSUE-65 -- For uniformity and performance, "literal" triples must be always generated for each child table column in a foreign key -- open
<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/issues/65
ISSUE-65?
<trackbot> ISSUE-65 -- For uniformity and performance, "literal" triples must be always generated for each child table column in a foreign key -- open
<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/issues/65
<mhausenblas> ISSUE-67?
<trackbot> ISSUE-67 -- Separationn characters for reference IRIs and row IRIs -- raised
<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/issues/67
mhausenblas: i would like to
close issue 65, we had an agreement on that
... modulo the separator characters
... which is issue 67
<mhausenblas> PROPOSAL: Close ISSUE-65 based on last weeks discussion with general agreement
+1
<juansequeda> +1
<Marcelo> +1
<MacTed> +1
<nunolopes> +1
RESOLUTION: Close ISSUE-65 based on last weeks discussion with general agreement
mhausenblas: eric, summarize
ericP: so basically we have a
bunch of choices with all being sort of attractive
... we build up the refernce and row iris
<ericP> ① attr¹-val¹.attrⁿ-valⁿ ref-attr¹.attrⁿ
<ericP> ② attr¹.val¹-attrⁿ.valⁿ ref-attr¹-attrⁿ
<ericP> ③ attr¹-val¹.attrⁿ-valⁿ ref-attr¹-attrⁿ
<ericP> ④ attr¹=val¹,attrⁿ=valⁿ ref-attr¹-attrⁿ
<ericP> ⑤ attr¹.val¹.attrⁿ.valⁿ ref.attr¹.attrⁿ
ericP: some of those let you do
better in turtle
... and sparql
... some others comform to the guidlines of the rfc-s
... having looked around motivations on the iri document
... for '..' there is some
... otherwise there is no real motivation
... there is also a question of aesthetics
... those are not expressible as qnames (using '=')
... so my proposal is, based on my draft of the direct mapping,
to go to last call with the text as it is
... and make the community on notice that the punctuation
character might change
mhausenblas: we write a spec, we
should say 'this is what we agree'
... i am happy to write put there something that say there is a
choice
... we should choose one
... here are the options that this is what we chose' is
something we should do
<ericP> http://www.w3.org/2001/sw/rdb2rdf/directMapping/explicitFK#defn-percent-encode
mhausenblas: we have to have a current stand
<mhausenblas> Should say 67 and not 76
eric: my proposal would be to go to last call with what we have
<dmcneil> i haven't followed the full details of the discussion about the delimiters, but it does seem suprising to me that none of the options use the main URI delimiter: /
<ericP> PROPOSAL: public http://www.w3.org/2001/sw/rdb2rdf/directMapping/explicitFK#defn-percent-encode as a Last Call of the Direct Mapping
<mhausenblas> PROPOSAL: Close ISSUE-67 with going for option [1] and make a note about alternative options
<mhausenblas> http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011Sep/0009.html
PROPOSAL: Close ISSUE-67 with going for option [1] and make a note in the document referring to : http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011Sep/0009.html
+1
<ericP> +1
<MacTed> +1
<juansequeda> +1
<Marcelo> +1
RESOLUTION: Close ISSUE-67 with going for option [1] and make a note in the document referring to : http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011Sep/0009.html
mhausenblas: thank you
... it seems that we are through
... we have closed all the issues for last call
... as soon as the editors have implemented the resolution
Souri: just to comfirm: I remove to translation scheme and the sugar, right?
mhausenblas: yes
<mhausenblas> Michael: Can the Editors implement the resolutions ASAP?
Souri: I will get it done soon
<Souri> what is the CVS command to fetch a prev version?
<mhausenblas> PROPOSAL: The WG has closed all pending issues and decides to go LC with both R2RML and DM
+1
<mhausenblas> PROPOSAL: The WG has closed all pending issues and decides to go LC with both R2RML and DM once the Editors have implemented the resolutions of 2011-09-13 telecon
<Souri> +1
<nunolopes> +1
+1
<juansequeda> +1`
<Seema> +1
<ericP> http://www.w3.org/2001/sw/rdb2rdf/directMapping/explicitFK#defn-percent-encode
<Marcelo> +1
<ericP> +1
<MacTed> +1
<mhausenblas> Michael: +1
RESOLUTION: The WG has closed all pending issues and decides to go LC with both R2RML and DM once the Editors have implemented the resolutions of 2011-09-13 telecon
adjourned
<mhausenblas> [meeting adjourned]
<mhausenblas> ericP?
<mhausenblas> you know that you still have a reference to ISSUE-48 in the DM doc, right?
<mhausenblas> as it is resolved, can you update this section as well pls?
<ericP> mhausenblas, will do
<mhausenblas> thanks
<mhausenblas> trackbot, end telecon