See also: IRC log
<ChrisWelty> Meeting: RIF Telecon May 6, 2008
<csma> list agenda
<ChrisWelty> Scribe: mdean
<ChrisWelty> http://lists.w3.org/Archives/Public/public-rif-wg/2008Apr/att-0199/rif-minutes-29-april-2008.html
minutes approved
csma: 2 comments from Dan Connolly on comment list
<csma> http://lists.w3.org/Archives/Public/public-rif-comments/2008May/0000.html
Sandro: discuss process in meeting - likely to get more comments soon
Chris: probably assign someone for response, rather than just on Wiki page
csma: IRI comment pretty close to
email list discussion
... second comment is question for Michael
Chris: add to end of agenda
<sandro> http://www.w3.org/2002/09/wbs/38457/f2f10/results
15 people have answered, 12 are coming
closest hotel is full
bed and breakfast has space
Axel only on IRC today due to conflicting meeting
please fill out form
<Harold> About Sandro's ACTION: http://www.w3.org/2005/rules/wiki/FLD#XML_Serialization_Framework
<csma> all actions continued except 471, which is closed
<csma> ACTION-459: closed
<AdrianP> we might discuss it together with the UCR review
<csma> ACTION-437: closed
<csma> ACTION-253: closed
<AdrianP> nothing specific. there is currently a XBRL conference
<AdrianP> http://conference.xbrl.org/
no news from OWL
<ChrisWelty> http://www.w3.org/2005/rules/wiki/ToDo_before_BLD_last_call
3 editor's notes in SWC
Axel: a proposal on table
Jos: takes care of 52 and 53
Jos to redial due to noise
thanks
Jos: notion of context comes from BLD document - this specifies specific contexts
Sandro: email thread from last
night - open issues
... prefer "language" over "context"
... or "format"
<sandro> or "formalism"
Jos: agree - took "context" from BLD - second argument to import statement
<Harold> Import ::= 'Import' '(' IRI CONTEXT? ')'
<josb> http://www.w3.org/2005/rules/wiki/BLD#Formulas
Jos: definition of import directives
<Harold> "The context specifies what kind of entity is being imported and under what semantics (for instance, the various RDF entailment regimes)."
<sandro> Sandro: So I'm proposing that this parameter, "language", be understood to be a default language identifier to use in case the language is not sufficiently self-identifying.
<sandro> Jos: I'm okay with that
Chris: consistency with current OWL WG?
Sandro: too early to say
<sandro> Chris: I am too -- how does it relate to what OWL-WG uses?
Michael: OWL uses profile
<sandro> mkifer: OWL uses "Profile"
<sandro> Sandro,Jos,Harold: Okay
consensus on "profile"
resolution not needed
Sandro: could call it default profile, to indicate that it doesn't override
Michael: other cases: semantics, data types, etc.
<Harold> Re Import(t c): "The constant t indicates the address of another rule set to be imported and c is called the context of import."
<sandro> defaultProfile
<Harold> http://www.w3.org/2005/rules/wiki/BLD#Formulas
Chris: document takes precedence
if it specifies a profile
... but could imagine various precedence strategies
mkifer: should be an error
Sandro: ok with error
... now OK with profile given discussion
<sandro> ACTION: Harold to change "context" to "profile" in BLD and propose an XML syntax [recorded in http://www.w3.org/2008/05/06-rif-minutes.html#action01]
<trackbot-ng> Created ACTION-472 - Change \"context\" to \"profile\" in BLD and propose an XML syntax [on Harold Boley - due 2008-05-13].
<sandro> (and in FLD)
Sandro: next issue - URIs for
profiles
... probably makes sense to create new URIs linked to spec
Jos: agree
<sandro> Sandro: let's make up new IRIs, like http://www.w3.org/2008/rif-import-profile/Foo
<sandro> Sandro: let's make up new IRIs, like http://www.w3.org/2008/rif-import-profile#Foo
<sandro> Chris: just for the ones mentioned in this document
<sandro> Sandro: right.
mkifer: is profile a
constant?
... why do we need to specify this?
Sandro: about 7 enumerated in Jos' document
Chris: will these be dereferenceable?
<sandro> Chris: this is just for Jos' document -- we don't need to talk about these in general.
Sandro: in principle yes
... great if someone is motivated to put statements there
<sandro> Chris: Just special IRIs that some implementations know. When you see this IRI, use this form of interpretation.
<sandro> Sandro: Yes.
<sandro> ACTION: jdebruij2 to pick IRIs for profiles [recorded in http://www.w3.org/2008/05/06-rif-minutes.html#action03]
<trackbot-ng> Created ACTION-473 - Pick IRIs for profiles [on Jos de Bruijn - due 2008-05-13].
Jos: what about RDF graphs with different profiles - pick highest?
Sandro: what about transitive imports?
Jos: pick highest, but haven't thought about transitivity - not feasible to use multiple profiles
Sandro: could make it an error or
undefined
... would like open issue on importing things with different
profiles
... OK with last call draft as is
<sandro> ACTION: jdebruij2 to open a non-CP issue on importing with mixed profiles [recorded in http://www.w3.org/2008/05/06-rif-minutes.html#action04]
<trackbot-ng> Created ACTION-474 - Open a non-CP issue on importing with mixed profiles [on Jos de Bruijn - due 2008-05-13].
Jos: generic profiles: RDF vs
OWL
... could be combined - no formal distinction
... don't require specification of a profile
... imports currently defaults to RIF ruleset
Sandro: can distinguish based on
RIF MIME type
... also need to work on that
<sandro> ACTION: Sandro to look into mime type registration for RIF [recorded in http://www.w3.org/2008/05/06-rif-minutes.html#action05]
<trackbot-ng> Created ACTION-475 - Look into mime type registration for RIF [on Sandro Hawke - due 2008-05-13].
<sandro> Sandro: How about make Profile optional, and if omitted use mime-type.
Jos: this is a BLD issue
<sandro> Chris: So -- no generics, profile is optional, and up to spec how to handle this if document isn't self-identified.
<sandro> Jos: Michael, harold?
mdean: file: IRI doesn't have a MIME type
Sandro: can live with second
argument of "RDF" but this seems silly
... file: IRI library may have file extension mappings to MIME
types
<sandro> Sandro: I can live with second-parameter-required for non-RIF imports.
<sandro> Sandro: I think that works for XML, OO style and not.
resolution not required since things stay the same
wait until next week to close Issue 52
<sandro> postponing closing issue-52 until we can check over the documents with these edits.
josb: issue 53 is resolved
Sandro: would like review by Bijan, who's thinking about annotations in OWL
Chris: seems to account for where OWL is going as well as providing backward compatibility
<sandro> PROPOSED: close ISSUE-53 as in current rdf-owl text
<csma> RESOLVED: close ISSUE-53 as in current rdf-owl text
<sandro> PROPOSED: close ISSUE-53 as in current http://www.w3.org/2005/rules/wiki/SWC
<sandro> RESOLVED: close ISSUE-53 as in current http://www.w3.org/2005/rules/wiki/SWC
issue 54
Jos: contact OWL DL people as
soon as possible
... syntactic restriction on use of variables in RIF rules
<Harold> I guess we are talking about a subdialect of BLD, which fulfills Safeness Restrictions?
<sandro> ACTION: jdebruij2 to propose solution to ISSUE-54 that he's happy with and OWL-RIF TF is happy with [recorded in http://www.w3.org/2008/05/06-rif-minutes.html#action06]
<trackbot-ng> Created ACTION-476 - Propose solution to ISSUE-54 that he's happy with and OWL-RIF TF is happy with [on Jos de Bruijn - due 2008-05-13].
<sandro> http://lists.w3.org/Archives/Public/public-rif-wg/2008Apr/0185.html
Sandro: leaning toward option 4
<csma> no
Chris: first option corresponds to "out-of-band agreement"
<csma> What I have in mind when I say "out-of-band agreement, I mean that the requirement must be mentioned in the RIF doc
Chris: shouldn't require ignoring of datatypes not in spec
<sandro> kifer: how about something between 1 and 2 ---- two systems may agree on some extra datatypes, if they see an unrecognized datatype, then they issue an error.
mkifer: combination of 1 and 2?
Sandro: might work
<sandro> jos: I prefer option 2 -- you reject if you cannot deal with the datatypes that are there.
<sandro> kifer: I think that's the same as I'm saying. You assume systems can support official types plus some extra types, and you reject only if it's in neither.
mkifer: agree - reject datatypes that you don't support
csma: option 1 is not quite out-of-band agreement
<sandro> csma: allow a doc to make ref to non-std datatypes; an impl should be able to use the dt's they know.
<sandro> csma: they should be required to throw an error/warning if they don't recognize the datatype, and use it if they do. only issue is how to make sure no ambiguity. maybe RIF docs have to list their non-std datatypes.
<sandro> csma: all the datatypes in RIF document must be either std or unambiguously named; and any implement that knows the DT can use it, and if you don't you must warn/error.
<sandro> jos: yes
<sandro> mkifer: yes
<josb> OWL says: "If an input document uses datatypes that are not supported by the datatype map of an OWL consistency checker then it MAY report a warning. "
Harold: option 4 subsumes 1 and 2
<sandro> Harold: I would hope we could go for option 4, it subsumes 1 and 2 -- the xform could be identify, or refine error, etc. It's nice an general. It's at the heart of what RIF is about.
<josb> http://www.w3.org/TR/owl-test/#consistencyChecker
Harold: heart of RIF as interoperability mechanism
Chris: how much work needs to be done to include this?
<sandro> Harold: it could be left open, in the sense of our externals.
<Zakim> sandro, you wanted to talk about use case where a big publisher wants to include a new data type
Sandro: compelling use case for 4
is big web publishers - can't introduce new datatype until
consumers all implement - chicken and egg precludes
evolution
... but don't see a solution by the end of May
... prefer to leave the door open for programmable fallback
mkifer: which document(s) will specify this?
<Harold> Sandro, is XTAN at all related to GRDDL?
<sandro> Sandro: I wish XTAN were done ahead of time, but it's not, so the question is how to leave the door open for them.
Sandro: XTAN in separate
REC-track document used by RIF but separate
... need to finish enough for people to build against BLD -
shouldn't require major changes to implementations
<Harold> I think XTAN can also be used for transformations that return a normal form.
<josb> well, people do use xsd:date in OWL, I think
<Harold> (XTAN could thus allow users to work with non-normal-form information.)
mkifer: need to say something about compliance, beyond data types
<josb> uses xsd:float: http://protege.cim3.net/file/pub/ontologies/camera/camera.owl
mkifer: strawman compliance statements that can later be changed
<sandro> Chris: let's leave compliance clause until after we have implementaiton experience
<Harold> What about at least an Editor's note about compliance?
Chris: no way to know what compliance means for BLD
<sandro> kifer: let's provide some straw man, at least.
<csma> you mean, later than LC?
Sandro: can procedurally wait until CR
mkifer: discussion a year ago
<Harold> What will happen regarding answering public comments, gathering errata, etc. between RIF phase 1 and phase 2?
mkifer: should take up seriously or not, not just for datatypes
<csma> +1 to michael
Chris: much clearer idea of what BLD is than we had a year ago, but experience still limited
<sandro> ACTION: kifer to draft some text on compliance [recorded in http://www.w3.org/2008/05/06-rif-minutes.html#action07]
<trackbot-ng> Created ACTION-477 - Draft some text on compliance [on Michael Kifer - due 2008-05-13].
<Harold> What will happen with the OWL-RIF Task Force after May 31?
adjourned
<csma> rssagent, make log public