From OWL
Jump to: navigation, search

See also: IRC log

Bijan Parsia, Rinke Hoekstra, Michael Smith, Markus Krötzsch, Martin Dzbor, Ian Horrocks, Uli Sattler, Alan Ruttenberg, Boris Motik, Sandro Hawke, Zhe Wu, Vit Novacek, Bernardo Cuenca Grau, Peter Patel-Schneider, Alan Ruttenberg, Carsten Lutz, Evan Wallace
James Hendler, Ivan Herman, Ratnesh Sahay, Joanne Luciano
Ian Horrocks
Rinke Hoekstra

(Scribe changed to Rinke Hoekstra)


Roll Call

Ian Horrocks: covered Roll call

Agenda Amendments

Ian Horrocks: any amendments?

Ian Horrocks: no amendments

(Previous) Previous Minutes

PROPOSED: Accept Previous Previous Minutes

Bijan Parsia: Are we going to cover more issues if we finish the one's listed
Jeremy Carroll: they were rather late
Ian Horrocks: previous *PREVIOUS* minutes [Scribe assist by Peter Patel-Schneider]

Evan Wallace: previous previous minutes list me as evan wallbace

Sandro Hawke: accept them pending the change

PROPOSED: Accept previous previous minutes modula fixing Evan's name

Michael Smith: +1 to accept previous previous minutes

Sandro Hawke: fixed them

RESOLVED: Accept previous previous minutes module fixing Evan's name

Bijan Parsia: I just updated the attendance list to add Uli
Bijan Parsia: Who was missing

PROPOSED: Accept Previous Minutes

Jeremy Carroll: SANDRO - please reply to private message
Alan Ruttenberg: I approve

Sandro Hawke: haven't been there long enough to be reviewed

Ian Horrocks: who has reviewed them?

Uli Sattler: i haven't
Bijan Parsia: I just did
Rinke Hoekstra: had a quick look

Ian Horrocks: leave them to next week

Peter Patel-Schneider: aren't minutes supposed to be ready in 48 hours or less?
Sandro Hawke: yes, PFPS, that's the normal convention. In this case the fault was mostly mine.  :-(
Alan Ruttenberg: Evan, are you willing to write up the steps to clean up the minutes? (on

Action Items

Ian Horrocks: action item status?

Ian Horrocks: Action 4

Sandro Hawke: still mulling it over

Ian Horrocks: move to next week

Alan Ruttenberg: did the syntax document (Action 15)

Ian Horrocks: Action 17 qname approval?

Michael Smith: email has been sent, asking about schema components status

Michael Smith: most of the issue has been addressed because peter found relevant parts
Michael Smith: action was done

Ian Horrocks: Action 18, brain dump?

Alan Ruttenberg: continue

Alan Ruttenberg: haven't dumped, postponed to next week

Agenda for 1st F2F Meeting

Ian Horrocks: f2f agenda

Ian Horrocks: have collected a list of items to be discussed at the f2f, please look at the agenda

Ian Horrocks: currently on day 1 an overview of language features, imports

Ian Horrocks: two other topics dl and full alignment

Bijan Parsia: Datatypes?

Ian Horrocks: if you have comments, topics, then you might want to suggest them

Ian Horrocks: the schedule is going to be quite tight!

Ian Horrocks: cannot guarantee that every topic will be added

Peter Patel-Schneider: suggest F2F topics how?

Alan Ruttenberg: where did you put the agenda?

Ian Horrocks: link from meetings page, in the irc as well

Alan Ruttenberg: if you feel that any knowledge needs to be made clear, we can put it in the tutorial

Bijan Parsia: What's the tutorial?
Bijan Parsia: When is it?

Ian Horrocks: over the course of the next week we will fix the agenda?

Evan Wallace: would like to discuss the Declaration

Evan Wallace: just the discussion of it

Bijan Parsia: what's the tutorial?

Alan Ruttenberg: orientation, looking who's coming, having a walkthrough of the specs, and doing a Q&A

Alan Ruttenberg: if you have ideas of what should be covered, let us know

Bijan parsia): is that the same as Overview of language features?

Alan Ruttenberg: yes

Ian Horrocks: are we done?

Ian Horrocks: alan and I will prepare a more concrete agenda

Bijan Parsia: Perhaps, ian should send an email to solicit agenda topics for f2f?

2nd F2F meeting

Ian Horrocks: 2nd F2F meeting

Ian Horrocks: quite a few have commented already

Ian Horrocks: any people on the phone who would like to add their response before we come to a decision?

Jeff Pan: Beijing
Alan Ruttenberg: q+ to go back to scribing for a second

Ian Horrocks: uli, boris, bernardo... you didn't respond yet?

Boris Motik: No preference
Uli Sattler: oups - i thought i had: preference for washington
Bernardo Cuenca Grau: beijing or DC

Ian Horrocks: any preference Washington, Bejing, Sydney

Jeff Pan: beijing

Martin Dzbor: prob. washington for me
Michael Smith: I prefer DC, at risk for Beijing, no to sydney
Carsten Lutz: I can probably neither come to Washington nor Beijing, but Sydney may be possible
Vit Novacek: no preference for me for F2F2

Alan Ruttenberg: will put the raw responses on the voting list

Ian Horrocks: it is overwhelming for Washington... two people Beijing, one Sydney, everybody else Washington

Ian Horrocks: it's a no brainer... almost unanimous for Washington

Ian Horrocks: peter can go ahead with the OWLED colocation thing? That's my proposal

PROPOSED: F2F2 will be in Washington DC

Ian Horrocks: lots of agreement, no disagreement

RESOLVED: F2F2 will be in Washington DC

Ian Horrocks: finished with the admin

Jeff Pan: q+ have we decided the dates on F2F2?
Bijan Parsia: +1 to DC
Alan Ruttenberg: ack alanr
Zakim: alanr, you wanted to go back to scribing for a second

Alan Ruttenberg: if Conrad could put his work on the cleanups on the wiki

Task Forces reports and/or Discussions

Ian Horrocks: task forces stuff

Ian Horrocks: it would be useful to get some feedback from them

Ian Horrocks: jeremy to say something about the UFDTF

Bijan Parsia: Yes he is :)

Jeremy Carroll: let me think

Jeremy Carroll: can I go second?

Rich Annotations

Ian Horrocks: Rich annotations? Bijan?

Bijan Parsia: I wrote up a proposal, some use cases, not finished

Bijan Parsia: I ran them by several people, e.g. Alan Rector

Bijan Parsia: somebody wanted to use them for patterns (value partitions)

Bijan Parsia: that's fine in my proposal, haven't written it up

Bijan Parsia: (Jeremy?) using reification for axiom annotations

Bijan Parsia: I guess in that exchange with Boris one option would be to ... the annotations

Alan Ruttenberg: +1 on importance of axiom annotations

Bijan Parsia: would remove a lot of the usefulness of annotations

Alan Ruttenberg: q+ to mention issue with rich annotations

Bijan Parsia: proposal is 90% done...

Bijan Parsia: would be nice to get some sense of what we're going to do with it

Ian Horrocks: there is a fairly wellformed proposal on the table

Ian Horrocks: please give some comments

Alan Ruttenberg: concerned about the multiple domains of interpretation/ multiple worlds/ multiple models aspect of it

Zakim: alanr, you wanted to mention issue with rich annotations

Alan Ruttenberg: part of the concern was that it's fairly new, and unexplored... want a warm fuzzy feeling that it's well understood

Alan Ruttenberg: second issue is that I don't know whether and how it would affect the RDF semantics

Alan Ruttenberg: could you comment on how it affects the OWL Full aspect of it, in the RDF sense

Bijan Parsia: I have not realised an RDF mapping

Bijan Parsia: one could use different extensions: multiple files with pointers analogous to owl:imports

Bijan Parsia: minimal mutilation of everything, and easy to understand

Bijan Parsia: other than that: is that enough to get you going?

Alan Ruttenberg: yes, just to say where I am on it: how much of the proposal is dependent on that

Alan Ruttenberg: is that the central part of the proposal? If it's left out, what will be left?

Bijan Parsia: it's a major part... another part is the idea to have blobs of annotations instead of nested or chained

Bijan Parsia: in the current annotations have to booted in the axiom

Bijan Parsia: a lot of people I talked to want to be able to associate fairly elaborate structures to an entity or axiom

Jeremy Carroll: q+ to comment

Ian Horrocks: until more people have had a chance to have a look at that... we might as well leave that

Alan Ruttenberg: we do have it on f2f

Bijan Parsia: suggest that it becomes an official agenda item

Ian Horrocks: action item to go and read it?

Bijan Parsia: if I know its' going to be on the agenda I could (re)start an email discussion about this

Sandro Hawke: no need to do an action item

Bijan Parsia: if its on the agenda, I will start a discussion

(it was on the agenda for today)

Ian Horrocks: why don't you start a discussion, and if there's a significant response to that we can put it on the agenda

Alan Ruttenberg: who are the stakeholders on this?

Alan Ruttenberg: and have an action item to review this?

Alan Ruttenberg: for them (that holds for me)

Michael Smith: I'm a stakeholder and will review

Ian Horrocks: anyone else?

Peter Patel-Schneider: I'll stick my hand up
Boris Motik: I will read it by next week. Does this count as a review?

Alan Ruttenberg: more strongly, if you think it's important and you might object, you're a stakeholder

Zakim: jeremy, you wanted to comment

Ian Horrocks: why not let jeremy speak, and let people mull over whether they are stakeholders

Jeremy Carroll: by having the OWL Full semantics in multiple documents is very complicated

Jeremy Carroll: far away from owl 1.0

Alan Ruttenberg: q+ to see if I understand bijan's idea
Evan Wallace: could we ask for a decision on this next week

Jeremy Carroll: out of court. More about 'lets' put some wacky stuff in' instead of a conservative improvement over 1.0

Boris Motik: If I've understood things correctly, the idea is not to have one semantics distributed over different documents (Bijan, please correct me if I'm wrong).

Ian Horrocks: you're talking yourself into being a stakeholder

Uli Sattler: jeremy, as usual, I can't understand what you are saying -- could you please talk louder?

Jeremy Carroll: just articulating how a large part of the OWL community would feel about this move away from 1.0

Boris Motik: The idea is that you just have different, independent documents. They have nothing to do with each other. You can, however, query them together using, say, SPARQL.

Jeremy Carroll: this seems a big change from 1.0 in terms of the OWL Full semantics

Jeremy Carroll: sounds like a non starter (?)

Zakim: alanr, you wanted to see if I understand bijan's idea

Alan Ruttenberg: by putting it into different files, we are just making things independently and unconnected

Alan Ruttenberg: each separately is an OWL Full document

Alan Ruttenberg: that correct bijan?

Bijan Parsia: that's fine
Bijan Parsia: That's one reasonable way to go yes

Jeremy Carroll: strikes me as a 'big' change (in the eye of the beholder)

Jeremy Carroll: mouses and elephants

Ian Horrocks: clearly needs to be discussed in some more detail

Boris Motik: But this is really no change: each document is still interpreted as it was interpreted in OWL 1.0. You can use either Full or DL semantics, moreover.

Ian Horrocks: perhaps jeremy and bijan could exchange some emails on this topic?

Ian Horrocks: then the rest of us can eavesdrop

Ian Horrocks: how would that be?

Alan Ruttenberg: +1 to draft Jeremy as stakeholder :)
Alan Ruttenberg: I can be on call too...
Alan Ruttenberg: if desired

Jeremy Carroll: not very enthusiastic, at least I get payed for it

Ian Horrocks: I'll take that as a yes


Ian Horrocks: move on to datatypes..

Bijan Parsia: There was a telecon!

Ian Horrocks: a lot of email traffic, no taskforce...

Bijan Parsia: There is!

Alan Ruttenberg: summarise where we came to in the first meeting

Alan Ruttenberg: Mike smith

Michael Smith: two types of external datatypes... those that include ID's which can be externally referenced, and those that can't

Michael Smith: on the second we are waiting on the XML Schema WG

Michael Smith: to modify structural specification to require the approach described in when referencing external XML Schema definitions with id attributes

Michael Smith: moving forward on the approach outlined in the best practices document for the case where we do have IDs

Ian Horrocks: what kinds of things wouldn't we be able to do without ID's

Jeremy Carroll: referencing external datatypes defined by someone else
Alan Ruttenberg: big file of anonymous datatypes
Alan Ruttenberg: external

Michael Smith: perfectly valid xml schema exists without IDs... if you want to reuse such schema types you have a problem

Michael Smith: on the semantic web

Bijan Parsia: So one would have to cut and paste that datatype definition into a different file

Michael Smith: if the author does have the semweb in mind, we have a solution.

Michael Smith: from the best practices

Ian Horrocks: we won't lose expressivity, just some rework

Alan Ruttenberg: literal inclusion of the file within the OWL file

Michael Smith: yes, about reusing existing XML schema definitions

Ian Horrocks: unary datatypes?

Michael Smith: yes, the external datatypes only discussed about unary datatypes

Michael Smith: one other thing, that we discussed

Michael Smith: don't know if we want to put that in to a proposal first or

Ian Horrocks: try us with the other item first

Jeremy Carroll: (at the telecon - some e-mail traffic on n-ary)

Michael Smith: inline xml as opposed to what is in the member submission

Michael Smith: I think it hit some kind of completion point

Michael Smith: we understand what could be done,

Michael Smith: if we want to use xml schema types inline, ...

Michael Smith: we need feedback from people about this

Bijan Parsia: I got negative feedback from OWL API/Protege4 author Matthew Horridge
Jeremy Carroll: I'll ask HP implementors

Ian Horrocks: another case where people need to have a look and get feedback

Jeff Pan: q+ unary datatype
Bijan Parsia: I would expect negative feedback from TopQuadrent (Holger)
Bijan Parsia: Oh, xml schema syntax inline

Ian Horrocks: negative with respect to which option?

Alan Ruttenberg: I was advocating taking this as our first point strictly from a simplicity point of view

Bijan Parsia: q+ to talk about schema syntax

Alan Ruttenberg: doesn't require any vocabulary, might reduce the load at the expense of annoying but sufferable software adaptations

Peter Patel-Schneider: well, what about all the corner cases in having inline XML Schema content?

Ian Horrocks: first bijan, then jeffP

Zakim: bijan, you wanted to talk about schema syntax

Bijan Parsia: I originally was thinking that using the XML schema syntax would be useful even with its limitations

Bijan Parsia: main argument against it: if we use XSD it restricts us in how we...

Bijan Parsia: would be apply new datatypes such as rational

Bijan Parsia: we could change it, but XSD guys might not like that

Bijan Parsia: unary datatypes with definitions, and totally different for n-ary: two different syntaxes

Bijan Parsia: if we do it ourselves

Jeremy Carroll: how about noting the issue and coming back to it in a few months?

Bijan Parsia: some advantages if we do it ourselves, otherwise we have to take the XSD WG into account

Bijan Parsia: if we make our home-made one it would probably be more uniform and more under control

Ian Horrocks: sounds like a convincing argument

Alan Ruttenberg: q+ to ask whether we *at least* need to support XML syntax
Jeremy Carroll: agree with ian no premature decision

Jeff Pan: question for mike... can we see the unions as well?

Michael Smith: there hasn't been a proposal to include unions no

Jeff Pan: if we don't have unions for datatypes. Won't we have too complicated datatypes

Bijan Parsia: With external datatypes they could use union,a faict

Jeff Pan: users might really want to reuse existing datatypes that they have

Ian Horrocks: if people don't use unions, then ...

(sorry missed that)

Uli Sattler: but we had counter-examples for this, Jeff!
Zakim: alanr, you wanted to ask whether we *at least* need to support XML syntax
Peter Patel-Schneider: -1 to requiring XML syntax

Alan Ruttenberg: might at least support the XML syntax. At least vs. might

Jeff Pan: uli, could you send a pointer?
Uli Sattler: Jeff, no - somewhere in the list of emails flying past

Ian Horrocks: if people don't use unions, then the kinds of datatypes they would be defining would be very simple, then not referencing

Ian Horrocks: external datatypes using wouldn't be so much of an issue

Ian Horrocks: Mike was saying something about a proposal

Jeff Pan: uli, which email in the mailing list?
Michael Smith: to modify structural specification to require the approach described in when referencing external XML Schema definitions with id attributes

Michael Smith: proposal for modifying structural specification

Bijan Parsia: +1 to this proposal
Jeremy Carroll: (look jeremy and bijan agree!)
Jeff Pan: :-)

Ian Horrocks: that must mean everyone else is on board as well

Martin Dzbor: sounds reasonable :-)

Ian Horrocks: this would need to be formed into a proposal that we might resolve

Jeremy Carroll: q+ to note normativity (lack of)

Alan Ruttenberg: is there a section that we could read, a section that says everything about it?

Michael Smith: the alternative would be to insert text into the structural document

Alan Ruttenberg: I like this
Bijan Parsia: +1 to doing the edit
Peter Patel-Schneider: -1 to this proposal, as OWL 1.1 already has an adequate solution
Alan Ruttenberg: that, ians suggestion
Jeremy Carroll: I prefer inserting text

Ian Horrocks: add it to the document, and then come back with a proposal to accept the edit in the document

Alan Ruttenberg: please comment in sandro's format

Ian Horrocks: peter objects? but I guess that when you come back with the proposal to accept your editing...

Peter Patel-Schneider: the message stands for itself

Peter Patel-Schneider: owl 1.1 already has its own syntax solution which eliminates the need for hacked-up xml schema documents

Alan Ruttenberg: there is our own syntax for defining datatypes?

Alan Ruttenberg: a requirement is to be able to reuse other people's documents

Jeremy Carroll: q+ to respond to peter

Peter Patel-Schneider: there's a vanishingly small number of xsd documents in that form

Alan Ruttenberg: bijan?

Bijan Parsia: not so much about reusing... I would be perfectly reasonable to define my own datatypes in xml schema.

Bijan Parsia: I have reasons for doing them inline sometimes, and for doing them outline in some cases

Zakim: jeremy, you wanted to respond to peter

Jeremy Carroll: the data may well be useful for an owl or webservice application

Jeremy Carroll: since the rest of the world reads xml datatypes already, we might as well do it ourselves as well

Jeremy Carroll: yes, it's awful, but that's life

Boris Motik: XML Schema is a really complex specification, though.
Jeff Pan: +1 for reuse xml schema datatypes
Boris Motik: I don't understand quite what exactly is mean with "reusing XML Schema datatypes".

Ian Horrocks: bijan and jeremy are saying that there isn't actually a huge cost to it?

Ian Horrocks: we just need to add id's

Alan Ruttenberg: the documents need to be understood by the reasoners that support them

Carsten Lutz: and by the user
Bijan Parsia: Boris, I currently can create a set of XML Schema datatypes using XML Schema
Bijan Parsia: Why not?
Bijan Parsia: Why not use that?

Ian Horrocks: the added overhead for implementers is that they need to add support for xml datatypes

Peter Patel-Schneider: you are going to require them to do that

Michael Smith: if you do reference them, you do it in the required way

Boris Motik: But are these only the elementary data types (string etc.), or are we including the complex datatypes as well (elements, complexType, etc.)?
Jeremy Carroll: there may be an issue with some facets

Alan Ruttenberg: add a delimited specific set of datatypes... but implementers could hook into the syntax to support more complex datatypes

Bijan Parsia: bmotik, yes, the imported datatype must be legal in OWL 1.1
Jeremy Carroll: simple types only
Jeff Pan: boris, I think we mean simple types only

Michael Smith: owl 1.0 docs are a little bit inconsistent (integer + string, another doc has a longer list)

Michael Smith: we are not really clear on what's required for implementers and what's not

Michael Smith: maybe clarifying that is important

Bijan Parsia: But if an implemented handled something more expressive, e.g., union, it seems harmless to let them address it by Id
Boris Motik: Referencing an external .xsd document from OWL parsers might be a pain for implementors.

Ian Horrocks: a side chat between boris and jeff, trying to clarify whether we are only talking SimpleTypes

Ian Horrocks: I was presuming we're talking about more complex types, not unions, but facets

Michael Smith: when I was responding to Jeff, I was talking about inline... now we're talking about external datatypes

Boris Motik: What is "external"?
Bijan Parsia: I.e., defined in an XML Schema file

Michael Smith: I don't think there was a proposal to restrict what kinds of external xsd datatypes are allowed

Bijan Parsia: q+ to say "no to complex stuff"
Bijan Parsia: +1 to jeremy's point about complex types
Boris Motik: What exactly could you write in this external document? Could you do much more than just apply facets?
Bijan Parsia: I could define a type hierachy
Bijan Parsia: I could define complex types, but they wouldn't be usable in OWL

Ian Horrocks: reuse the external xsd in your owl file

Jeremy Carroll: complextype and simpletype are technical terms

Jeremy Carroll: a simpletype can in fact be very complicated

Bijan Parsia: I could define a type hierachy

Ian Horrocks: complicated rather than complex them

Ian Horrocks: does this answer boris' questions?

Boris Motik: More or less.

Ian Horrocks: perhaps Boris could say whether he understands everything now?

Boris Motik: What is a type hierachy?
Bijan Parsia: Boris, I can define a string type that is a subclass of xsd:string
Bijan Parsia: And subclasses of that
Zakim: bijan, you wanted to say "no to complex stuff"

Bijan Parsia: we need to be a little bit careful wrt the types you are about to reference are types that are 'allowed'

Bijan Parsia: presumably no current reasoner can do anything with it

Bijan Parsia: the type that you reference must be definable in the inline syntax as well

Bijan Parsia: qnames wouldn't be types you can use and dereference from

Ian Horrocks: clarified a lot for me

Ian Horrocks: action on Mike

Ian Horrocks: to make a change that encapsulates his proposal


Boris Motik: Wiki question: can we approve changes out-of-order?
Boris Motik: For example, if two people make changes in one order, but we want to approve them in different order (or even roll-back one change), is this possible, and if so, how?

Ian Horrocks: skipped over the user facing documents

Jeremy Carroll: three telecons so far

Jeremy Carroll: quite a lot of disagreement, the main point of the telecons was sharing and exchanging views

Unidentified-Speaker=Re): numerics, I've been working on an explantion document in support of datatypes and n-ary predicates: [Scribe assist by Bijan Parsia]

Jeremy Carroll: agreement on different users prefer docs in terms of their domain and use cases

Jeremy Carroll: risk that we like to produce more docs than we could

Jeremy Carroll: some members are keen on docs that represent user communities

Jeremy Carroll: another opinion is that we should produce very little

Bijan Parsia: Well, part of that view (which is mine) is there is other venues which are, perhaps, more appropriate

Jeremy Carroll: another point of disagreement is to do with what the overview should look like

Jeremy Carroll: input is owl 1.0: brief summary + list of constructs

Jeremy Carroll: owl 1.1 summary which is much briefer

Jeremy Carroll: not anywhere near resolving anytime soon

Jeremy Carroll: a further issue is that non-wg members have interesting work that they would like to contribute to the group

Jeremy Carroll: how much can we interact with people not on the wg?

Ian Horrocks: not really a constraint on interaction, but if the documents reflect a lot of their input, then their names could not be on the docs

Alan Ruttenberg: I thought it was Jeremy that was following up...

Vipul Kashyap: sent an email to michel and ... as to what their expectations are

Jeremy Carroll: i asked sandro

Ian Horrocks: fair to say, ongoing, progress is made, but significant issues?

Alan Ruttenberg: also there are action items for UFDTF

Jeremy Carroll: for the overall taskforce, yes, I think we're making disappointingly small progress so far

Alan Ruttenberg: Alan is more optimistic than Jeremy, but that may expose a flaw ...
Alan Ruttenberg: in Alan's optimism

Vipul Kashyap: one thing we did agree on is to identify the set of users that would

Vipul Kashyap: be targeted by these docs

Vipul Kashyap: CIO's Enterprise Architects, developers: list on an external website

Alan Ruttenberg: Also started page trying to define who the targets of the documentation are

Ian Horrocks: we'll be discussing this more on the F2F... hopefully more progress on these issues then


Issue 14

Ian Horrocks: issues ... first is Issue 14: CURIES

Sandro Hawke: CURIES as in Marie Curie

Alan Ruttenberg: peter and I had a brief discussion about our original decision to use SPARQL

Bijan Parsia: Nasty in the RDF/XML yes?
Jeremy Carroll: Did sparql not use CURIE because it wasn't reaching REC any time soon?

Alan Ruttenberg: peter thought it was limited, suggested to go for full CURIES instead

Alan Ruttenberg: no problem: a dependency as they're not a standard yet

Alan Ruttenberg: if others think that CURIES are good, then I'm happy too

Ian Horrocks: are we in a position that we could resolve

Sandro Hawke: the state of CURIES, we don't know they're ever going to be a rec

Bijan Parsia: q+ to ask where would we use these

Peter Patel-Schneider: we could pull the stuff out of the CURIE spec

Peter Patel-Schneider: we could copy/paste CURIE text if they do not reach REVC [Scribe assist by Jeremy Carroll]

Alan Ruttenberg: someone from the group suggested we might monitor this

Alan Ruttenberg: and do a fallback when it turns out to not become a rec

Jeremy Carroll: I'll Dave tomorrow
Zakim: bijan, you wanted to ask where would we use these

Sandro Hawke: in RIF there was some discussion, in the end decided not to... maybe because it turned out to be not relevant... (don't remember exactly)?

Bijan Parsia: if CURIES are not legal element names, then how would this effect the RDF serialisation

Bijan Parsia: probably would require additional processing

Sandro Hawke: right -- CURIE in AS, or in some of the serializations?
Bijan Parsia: That doesn't always work

Alan Ruttenberg: In my application(s), if the local part is not a valid part of a qname then it's expanded to an escaped uri

Bijan Parsia: no that doesn't make sense

Alan Ruttenberg: I don't create extra namespaces, I fully quote them (in angle brackets)

Bijan Parsia: Yes, i.e., properties

Jeremy Carroll: certain uris that might occur as property uris can not be serialised as RDF uris

Unidentified-Speaker=Metaquestion): do we expect people to use the functional-style syntax directly? If not (i.e., if this syntax is used just in the spec), do we care about abbreviating URIs? [Scribe assist by Boris Motik]
Bijan Parsia: q+ to reply

Jeremy Carroll: in alan's cases we're talking about subject/object uris, in that case no problem

Alan Ruttenberg: can always use description/about

Jeremy Carroll: in predicate position some curies cannot be serialised in RDF/XML

Jeremy Carroll: this a known limitation in RDF/XML, and we should ignore it

Zakim: bijan, you wanted to reply

Bijan Parsia: that's fine jeremy, that's what I wanted to know

Bijan Parsia: if that's ok with you, then I'm fine with it

Jeremy Carroll: RDF/XML went to REC with this as a known bug

Sandro Hawke: q+ to repeat the AS vs CS quest

PROPOSED: to base abbreviated URIs on CURIES not QNAMES

Alan Ruttenberg: you can already use an arbitrary URI already in OWL 1.1 which cannot be serialised as RDf

Jeremy Carroll: not an OWL problem, an RDF problem

Bijan Parsia: But curies don't help in RDF/XML *at all*

Sandro Hawke: is this just about the abstract syntax?

Alan Ruttenberg: only effect the functional syntax

Jeremy Carroll: I would perhaps change my position after discussion with colleagues (dave and andy)
Boris Motik: functional syntax
Boris Motik: structural specification

Ian Horrocks: structural syntax

Alan Ruttenberg: functional style syntax

PROPOSED: to base functional style syntax abbreviated URIs on CURIES not QNAMES

Alan Ruttenberg: "Structural Specification and Functional-Style Syntax"

Jeremy Carroll: have you seen my notes? I might change my vote tomorrow by email

Alan Ruttenberg: put it on agenda for next week

Ian Horrocks: what's the best way forward? Resolve this now, backtrack? Push it to next week?

Ian Horrocks: put it on the agenda for next week. You'll be in a position to give a definitive yay or nay

Ian Horrocks: we resolved that we will resolve something

Issue 12

Ian Horrocks: Issue 2 is the final thing on the agenda

Ian Horrocks: we already resolved that we fix up this problem for alldisjoint wrt the RDF mapping

Ian Horrocks: the question arose as to whether we make the language symmetrical and add constructs for things in the structural syntax that use lists

Ian Horrocks: boris what are the other ones

Boris Motik: differentindividual
Boris Motik: sameindividual

Peter Patel-Schneider: union, intersection

Boris Motik: Union and intersection are already OK
Bijan Parsia: Doesn't union and intersection allready nary
Alan Ruttenberg: +1 to differentindividual

Ian Horrocks: really correct peter?

Ian Horrocks: in RDF they are mapped to multiple pairwise..

Boris Motik: It is equivalentClasses, equaivalentProperties, disjointClasses, disjointProperties

Alan Ruttenberg: alldifferent was already in the first version?

Peter Patel-Schneider: if you want to go for a same-sized translation, there are only two that are lists

Boris Motik: sameIndividaul, differentIndividuals
Alan Ruttenberg: <owl:AllDifferent>
Alan Ruttenberg: <owl:distinctMembers rdf:parseType="Collection">
Alan Ruttenberg: <Opera rdf:about="#Don_Giovanni"/>
Alan Ruttenberg: <Opera rdf:about="#Nozze_di_Figaro"/>
Alan Ruttenberg: <Opera rdf:about="#Cosi_fan_tutte"/>
Alan Ruttenberg: <Opera rdf:about="#Tosca"/>
Alan Ruttenberg: <Opera rdf:about="#Turandot"/>
Alan Ruttenberg: <Opera rdf:about="#Salome"/>
Alan Ruttenberg: </owl:distinctMembers>
Alan Ruttenberg: </owl:AllDifferent>
Jeremy Carroll: differentIndividuals(iID1 … iIDn)
Jeremy Carroll: _:x rdf:type owl:AllDifferent .
Jeremy Carroll: _:x owl:distinctMembers T(SEQ iID1 … iIDn) .
Boris Motik: It does not enable roundtripping.
Alan Ruttenberg: so differentindividuals already handled

Ian Horrocks: not a direct syntax as we have for alldisjoint

Peter Patel-Schneider: the only rationale for having a direct syntax for some of them is

Peter Patel-Schneider: that the obvious translation is n^2 and the non-obvious translation needs a trick

Ian Horrocks: boris says that it makes the problem for roundtripping

Alan Ruttenberg: do we have specification of what roundtripping means? Is it an agreed upon requirement?
Uli Sattler: how big is this problem?
Boris Motik: For backwards-compatibility we might translate things as usual only if n =2
Boris Motik: If n != 2, we might use the new mapping

Peter Patel-Schneider: we always have a roundtrip from functional to RDF and back, but if we already have a document in RDF then we cannot do roundtripping unless we have a direct mapping

Boris Motik: Sure, but if you have an OWL 1.1 RDF document (with new vocabulary), then things should be round-trippable.

Peter Patel-Schneider: quantitative vs. qualitative improvement

Peter Patel-Schneider: reason is bloat

Jeremy Carroll: +1 to pfps
Alan Ruttenberg: +1 to pfps too
Alan Ruttenberg: roundtripping not possible given backwards compatibility

Boris Motik: I understand the point regarding the bloat

Boris Motik: if we now extend the language with this new construct... new ontology, serialise as RDF then we can do roundtrip

Boris Motik: if you use owl 1.1 RDF and owl 1.1 AS then things should be round-trippable

Alan Ruttenberg: I don't know if it matters

Ian Horrocks: this wasn't the simple discussion I was anticipating

Ian Horrocks: are not going to get through this in the remaining 3 minutes of this telecon

Ian Horrocks: aim for email exchange to clarify the matter

Any other Business

Ian Horrocks: last item.... aob?

Ian Horrocks: any of it?

Jeff Pan: +1 bye
Uli Sattler: doe and dusted

Ian Horrocks: declare us finished for this week

Uli Sattler: bye bye
Zhe Wu: bye