See also: IRC log
<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2008Jul/att-0037/20080701-RIF-minutes.html
<ChrisW> PROPOSED: accept Minutes from July 1 telecon
ChrisW: Any objections to accepting the minutes from last week?
<ChrisW> RESOLVED: accept Minutes from July 1 telecon
ChrisW: Any agenda ammendments?
ChrisW: None of the liaison people are here
ChrisW: Next F2F is Sept 26-27 in NY. I would like to know whether people prefer to have it at Hawthorne or at an IBM facility in Manhattan. Manhattan is more fun but more expensive. The default will be Hawthorne, so please let me know if you have a preference.
<josb> +1 Manhattan
<AxelPolleres> I prefer the lower cost options to some extent.
<AxelPolleres> yes, I did
ChrisW: All documents are frozen except for FLD?
Harold: Yes
job: RDF/OWL is not frozen. I'm waiting for BLD freeze, and wiki was broken today. So, RDF/OWL will be ready for freeze tomorrow.
<AxelPolleres> I will also send some more comments to you by tonite, jos.
Harold: FLD is promised by this Friday, but will try for earlier
ChrisW: Action review
action-538 completed
action-537 completed
action-534 continued
action-530 will be complete by Friday, July 11
JosB: Review of FLD by next Tuesday, July 15
ChrisW: Document freeze and review schedule:
.... DTB is frozen and will be reviewed by Chris
.... BLD is frozen and will be reviewed by Leora and Jos by Friday, July 11
.... UCR is frozen and will be reviewed by Stella by Friday, July 11
.... FLD will be frozen by Friday, July 11 and reviewed by Chris and Jos by Tuesday, July 15
.... RDF/OWL will be frozen by Wednesday, July 9 and reviewed by Axel
.... PRD has been reviewed and is ready for publication
ChrisW: AdrianP, is there a person assigned to review UCR?
AdrianP: No, not yet
ChrisW: Volunteer to review UCR?
I can review UCR
<ChrisW> ACTION: Stella to review UCR for next WD [recorded in http://www.w3.org/2008/07/08-rif-minutes.html#action01]
<trackbot> Created ACTION-539 - Review UCR for next WD [on Stella Mitchell - due 2008-07-15].
<ChrisW> ACTION: Axel to review BLD for LC [recorded in http://www.w3.org/2008/07/08-rif-minutes.html#action02]
<trackbot> Created ACTION-540 - Review BLD for LC [on Axel Polleres - due 2008-07-15].
<ChrisW> ACTION: jdebruij2 to review bld [recorded in http://www.w3.org/2008/07/08-rif-minutes.html#action04]
<trackbot> Created ACTION-541 - Review bld [on Jos de Bruijn - due 2008-07-15].
ChrisW: Sandro put the mime types text in BLD. Has anyone reviewed?
Harold: Yes, it looks good
ChrisW: Do you need any changes?
Harold: No, it's fine. Security is an open ended topic - I think it's a little unbalanced because he talks specifically about the danger of documents that are imported by dereferencing, but not about other things such as computation that doesn't end. He talks about one particular example, but doesn't mention other cases.
<DaveReynolds> Surely the current wording addresses both?
ChrisW: Are you talking about problems caused by implementations or by specific rule sets?
Harold: Rule sets, for example the text doesn't mention rule sets that will cause computation that doesn't end
<Harold> Sandro mentions: "Through the use of "import", it may
<Harold> also require arbitrary URI dereferencing, which may consume
<Harold> all available network resources on the consuming system or
<Harold> other systems."
DaveR: I think the current text covers that case
ChrisW: Yes, I also think it does
Harold: Ok
ChrisW: Any other comments on mime type?
ChrisW: Axel, can you summarize this issue?
AxelP: In the DTB document,
section 4.3, cast and conversion functions
... casts from and to rif:iri - the question is do we want these casts, and if so how
should we design them
... and there was also a question about the cast from rif:text to
string. First, I will describe the rif:text issue.
... note that we have to wait until we resolve rif:text with OWL
working group
... the question is: should the conversion take only the string part, or the string with
the language tag
... both would be fine, currently only the string part is preserved in the cast
... Next issue is rif:iri (sections 4.3.5 and 4.3.6). A function style cast is possible in
one direction if we define axiomatic equalities (4.3.5)
... but this is not possible in the other direction, because
the axioms would cause inconsistencies
... I prefer functions wherever possible, and predicates only
where function can't be used
... (as opposed to making from and to rif:iri both
predicates)
... MichaelK and JosB said the predicate will cover both directions of
casting
JosB: Yes, the function is redundant, and another argument against 4.3.5 is that it is not actually a function (one return value for a given argument) in the way that the other casting functions are, because rif:iri is not a data type
AxelP: I agree that what you say is true, but still want to leave it the way it is
JosB: It's simpler and more understandable to have the one predicate
ChrisW: Are you arguing to use this method for all cases?
JosB: No, just rif:iri
ChrisW: What about doing it for all?
JosB: It's possible, but maybe not natural because we are following XQuery, and also because they are actually functions. But I still wouldn't be completely against using predicate for all casts
AxelP: Predicates makes writing things more complicated
ChrisW: Any other opinions?
<MichaelKifer> I agree with Jos.
<ChrisW> Straw Poll: Axel +1, Jos -1
<josb> -1
<DaveReynolds> -0.1
<AxelPolleres> Strawpoll: Keep 4.3.5: +1 drop: -1
<Harold> 0
<MichaelKifer> -1
<AxelPolleres> +1
<LeoraMorgenstern> -1
-1
<AdrianP> 0
ChrisW: I will put this in the form of a proposed resolution (Jos's proposal) and let people know that we'll be voting on it at next week's telecon
JosB: What about between rif:text and strings? The issue is when casting from rif:text to string. In the current spec, you lose the language when casting from rif:text to string. But the other direction is only defined for strings that have language id embedded (with the @ notation). So, roundtripping is not possible
<AxelPolleres> casting from string to numbers is also not round-drippable... "0001"
DaveR: Casting from text to string using only the string part makes sense to me -- as long as there is also a two argument constructor to create a string, and also an extractor to get the language from the string
JosB: I think we don't have the two argument constructor
AxelP: I don't agree with the roundtripping argument because (?)..... and also then it would be complicated to get out the string part
<AdrianPa> sorry, dropped out. I'm currently travelling and do not have a stable line
JosB: I agree with DaveR's idea that we change the cast in 4.3.4 to take two arguments: the first a literal string, and the second a language tag
ChrisW: I agree that current cast doesn't really make sense
AxelP: It comes from the
presentation syntax, it would be easy to implement for the
presentation syntax
... yes, I agree to change 4.3.4 to 2 argument
version
<ChrisW> ACTION: axel to change 4.3.4 to a two arg function (string,lang) [recorded in http://www.w3.org/2008/07/08-rif-minutes.html#action06]
<trackbot> Created ACTION-542 - Change 4.3.4 to a two arg function (string,lang) [on Axel Polleres - due 2008-07-15].
AxelP: I think we should add a shortcut for rif:text then, in the presentation syntax
JosB: That was discussed at length at F2F10, with no agreement
JosB: Also, in section 4.7.1, Axel and I disagree over the name of the extraction function. It is inconsistent with the rest. I think it should be called lang-from-text
AxelP: The others come from XQuery, this one comes from SPARQL. But I could live with JosB's naming
JosB: It's all caps in SPARQL
AxelP, ChrisW: SPARQL is not case sensitive
<ChrisW> Straw Poll +1 prefer func:lang, -1 prefer func:lang-from-text
<DaveReynolds> +0.1
<LeoraMorgenstern> -1
<josb> -1
<MichaelKifer> 0
<AxelPolleres> strawpoll: +1 lang -1 lang-from-XYZtext
<Harold> -0.1
<AxelPolleres> +1
<AdrianPa> +1
ChrisW: Default is leaving it as is
AxelP: Jos and I agreed to put editor's note on items we don't agree on, and get comments from external reviewers
ChrisW: Other issues on casting?
JosB: In the above DTB section, there is an inconsistency in names. Which is intended?
AxelP: Typo. Can I fix this even though wiki says the document should not be changed?
JosB: It's just a simple editorial change
ChrisW: Yes, you can make an editorial change
JosB: Just to confirm: the one in the schema is the correct name, right?
AxelP: Yes
MichaelK: Are grammar changes also ok?
ChrisW: Yes
<AxelPolleres> -1 to adding double-negations
ChrisW: Any other discjussion on DTB?
AxelP: I would like all the access phone numbers in the agenda emails
<ChrisW> ACTION: chris to update access numbers in agenda [recorded in http://www.w3.org/2008/07/08-rif-minutes.html#action07]
<trackbot> Created ACTION-543 - Update access numbers in agenda [on Christopher Welty - due 2008-07-15].
ChrisW: Any other business?
ChrisW: The meeting is adjourned