W3C home > Mailing lists > Public > www-archive@w3.org > August 2001

RDFCore F2F IRC LOG 2/Aug/2001

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Sat, 04 Aug 2001 17:07:29 +0100
Message-ID: <3B6C1DC1.C7A7FC1B@hplb.hpl.hp.com>
To: www-archive@w3.org
00:00:26 <dajobe> phayes: publishing a doc that erfers to anon _:bob and really
want to do that
00:00:40 <dajobe> ... if I can't mean the same thing by the same name, that name
is no use of all
00:00:52 <dajobe> danc: nature is that there is no name in rdf/xml and can't
refer to it
00:01:03 <dajobe> phayes: then I shouldn't generate _:bob
00:01:22 <dajobe> danc: yes, but this is ntriples and _:bob can't be seen
00:01:41 <dajobe> fmanola: then this can't come up?
00:01:56 <dajobe> phayes: are you allowed to use _:bob
00:02:04 <dajobe> danc: no, you use "something"
00:02:14 <dajobe> phayes: then I cannot refer it to you directly
00:02:23 <dajobe> danc: yes, you have to use other mechanism
00:02:50 <dajobe> jang: there are transient docs on the web and fetch them,
_:bob etc. are transient identifers you want them to behave lie that
00:03:10 <danbri> * danbri scribes
00:04:03 <danbri> frank: it is one thing to talk about two '_bobs'... It is a
very different use case if I, perusing doc1 and getting a genid _bob, returns to
source and say "hey, you know that thing you called _bob"... 
00:04:16 <danbri> pat: thats the case i had in mind
00:04:35 <danbri> sergey: suggestion... Don't use N3 please. We've barely a grip
00:05:00 <danbri> dan: we didn't see these disagreements until we had ntriple to
make situation explicit
00:05:43 <danbri> emiller: <shows example with /2001/08/01-ex1 and -ex2.>
(@todo: link to doc from em)
00:05:50 <danbri> ...
00:06:03 <danbri> jan: theres a mechanism question w.r.t. what pat's sayinh
00:06:19 <danbri> "we have _bob from 2 docs... we want to go back and say more
stuff about 'it'"
00:06:40 <danbri> "you can use identifying properties about it
00:06:58 <danbri> * danbri disagrees (quietly)
00:07:20 <danbri> graham: the reason i showed example in ntriples was cos we've
decided to use this to describe what parsers do
00:07:36 <danbri> "the unfortunate part of the example was my writing _bob
instead of _243234234234324
00:07:45 <danbri> "parser needs to write some kind of labelling for the ntriple
00:08:00 <danbri> "now if two docs happen to parse to same ntriple form, incl.
00:08:19 <danbri> "are we going to make parsers responsible for making globally
unique genids
00:08:32 <danbri> "or do we couch this in terms of ids relative to a document
00:09:38 <danbri> frank: a query rather than an assertion: "let's pop the
stack... seems we've gone in a fairly complicated manner discussing a number of
relevant topics. But we started out here with some pretty straightforward
questions, ie. firstly whether we want generated identifiers, then whether we
want to distinguish them from URIs (either semantically or syntactically)
00:09:57 <danbri> "i don't know that we've done much to answer those questions,
or to answer their converse: if we don't like something is the result any
00:10:15 <danbri> "if we don't like generated identifiers, we have things that
aren't identified, what do we do
00:10:24 <danbri> brian: we've decided that
00:10:37 <danbri> dan: we didn't decide they were URI
00:10:52 <danbri> brian: i thought we had made progress
00:11:12 <danbri> ..."that we agreed we can distinguish these things 'in the
00:11:30 <danbri> frank: did we decide that they had the characteristics of URIs
00:11:37 <danbri> pat: decisions was...
00:11:54 <danbri> "we agreed there wouldbe a way of distinguishing the
'distinguished nodes' from 'undistinguished ones'
00:12:00 <danbri> dan: i didn't agree to new syntax for this
00:12:05 <danbri> pat: some way...
00:12:09 <danbri> brian: to tell them apart
00:12:16 <danbri> pat: ...syntactically...
00:12:30 <danbri> emiller: we have 3 interpretations on the overhead
00:13:10 <danbri> dan: make the first one a non-URI,
00:13:26 <danbri> emiller: some way of uniquely identifying it, that is or isn't
or looks like a uri
00:13:45 <danbri> dan: the wg has ruled out the 3rd situation
00:13:56 <danbri> ..."i heard that you could tell the difference in the output
00:14:15 <danbri> "since seeing http://blah in output couldn've been there in
the input
00:14:40 <danbri> pat: what's wrong with saying because it contains 'genid' in
00:14:44 <danbri> dan: not without talking to god
00:15:03 <danbri> ..."not in our charter"
00:15:42 <danbri> emiller: (to pat) a lot of us are coming to this from a web
architecture p.o.v....
00:15:50 <danbri> brian: dave has the words from previous decision
00:16:16 <danbri> frank: there's a reverse side of it... When you generated this
thing that's clearly distinguishable from a URI... Is it therefore _not_ a URI?
00:16:34 <danbri> ..."what are its characteristics?
00:16:38 <dajobe> question was:
00:16:39 <danbri> frank: yes, acc to the URI spec
00:16:48 <danbri> dave reads from logs:
00:18:02 <danbri> emiller: some people are thinking they can peek inside
syntactic substructure of uris
00:18:38 <dajobe> answer was:
00:19:33 <danbri> dan: the words he wrote rule out interpretation 3
00:19:40 <danbri> (someone pls post the 3rd example)
00:20:32 <danbri> pat: similar to one saying, i'll write an axiom in logic with
a relation name called 'Not'
00:20:50 <danbri> dan: the text he read says we can tell these apart
00:20:53 <danbri> * danbri now agrees
00:21:17 <danbri> dan: this info is not enough to tell us
00:21:28 <danbri> pat: why can't we say what the rules of the language are?
00:21:55 <danbri> dan: nowhere in rdf 1.0 does it say we can't have
http://purl.org/var/.... is not allowed...
00:22:03 <danbri> "now into the opacity argument for not inspecting URI
00:22:15 <danbri> graham: URIs are not our language (ie. IETF spec)
00:22:17 <danbri> ---
00:22:18 <danbri> break
00:22:19 <danbri> ---
00:33:31 <danbri> dan: some issues are kinda arbitrary, we owe to world to flip
00:33:42 <danbri> ...i feel this is a non-arbitrary decisions, needs doing
00:34:05 <danbri> (discussion of Vegemite-based incentives)
00:34:13 <danbri> dan: i'm happy to defer to another issue
00:34:23 <danbri> emiller: i'd like to end with something we can accomplish
00:34:32 <danbri> ...do you think we can do that in 30 mins
00:34:48 <danbri> pat: i voted no and caused a bunch of trouble
00:35:13 <danbri> ..."i'd be happy to change and say yes, so long as we ack that
we need to introduce notion of scoping, and be crystal clear
00:35:32 <danbri> "it'd be a  mistkae to say they have an existential
interpretation and have vagueness about their scope
00:35:48 <danbri> sergey: i want to support your (dan's) suggestion by proposing
another use case
00:36:05 <danbri> emiller: pat, dan, sergey agreeing...??!
00:36:23 <danbri> sergey: "the case i'm suggesting... trying to factor out all
the different concepts we have in our mind...
00:36:45 <danbri> "if we have something we think are anonymous nodes in the
document... is there a way to point to this thing in another document?
00:37:08 <danbri> dan: my answer is 'no'
00:37:25 <danbri> sergey: there's this axiom of the web, that rdf allows folk to
say anything about it
00:37:48 <danbri> graham: it doesn't, you can talk about the same entity
00:38:09 <danbri> jan: you _can_ providing you're talkikng about a
sub-document... ie. make an instantiation of the document... you know what the
anonymous resource is...
00:38:32 <danbri> ..."database analogy: run a query on a db, you can tell its
identity in the database. but i can't publish the private id as a uri
00:39:04 <danbri> pat: a realisation... i think jos said all along... "you can
publish a document... if someone can 
00:39:28 <danbri> pat: if the original document _is_ enough to pick it out,
(jos: by value) then yes you _can_ describe it further
00:39:48 <danbri> brian: my worry, we spent a whole bunch of time on anon
nodes... we set out questions...
00:40:12 <danbri> "once a node gets into the model, can i tell it apart, we had
that questoin... I want to make sure. Can we confirm we said "yes!"
00:40:30 <danbri> danc: we've only answered it if we rule out 3rd interpretation
(@todo: url overhead)
00:40:57 <danbri> brian: 
<rdf:Description><foo:bar>foobar</foo:bar></rdf:Description> ...->...   _
<foo.bar> "foobar"
00:41:32 <danbri> questoin: what goes here< after the '_'
00:41:32 <danbri> dan: ??? (missed)
00:41:32 <danbri> pat: nobody reading any document generated from the xml would
ever be able to get hold of the id
00:41:45 <danbri> pat: of course in ntriples it looks public
00:42:03 <danbri> pat: but if in the egs we use 'http:' it sure looks public
00:42:11 <danbri> brian: notion of public doesn't feel quite precise enough
00:42:20 <danbri> ..."same question as sergeys 3rd...
00:42:40 <danbri> brian: there are 3 things that could go in here...
00:42:49 <danbri> "___ <foo.bar> "foobar"
00:43:07 <danbri> brian: dan is asking that we don't allow URIs here
00:43:31 <danbri> strawpolll: can it be a uri
00:43:33 <danbri> most folk: no
00:43:36 <danbri> pat: don't care
00:43:44 <danbri> mike: i'd like it to be a uri and parse substructure
00:43:56 <danbri> sergey: we can have a special namespace
00:45:13 <danbri> danbri: dan persuade me. folk might write bad RDF/XML that
used our magic namespace for genids. therefore we can't gurnatee the distinction
00:45:15 <dajobe> danc also said - no, you can't lok inside URI
00:45:24 <danbri> * danbri nods
00:45:25 <dajobe> miked then said - want to parse fragment ids
00:45:34 <danbri> brian: so it can't be a uri
00:45:39 <danbri> Capturing this:
00:45:49 <danbri> we agree it can't be a URI.
00:46:12 <danbri> frank: generated identifiers have a distinguished
representation from URIs
00:46:46 <danbri> mike: i'd like to see us say 'we reserve any fragments
beginning with an underscore
00:46:59 <danbri> ...that way you might know eg what doc it came from
00:47:02 <danbri> ...in rdf:ID
00:47:14 <danbri> dan: then you lose expressive power; you lose ability to say
'there exists'
00:47:24 <danbri> marK: maybe you want several types of genids
00:47:31 <danbri> pat: please please don't use a variable as a name
00:47:52 <danbri> jan: this ... doesn't really work. you go to a source, get a
doc back; you do again, you get it back. these things are transient in the web.
00:48:08 <danbri> mike: there's nothing to keep the parser from providing an id
00:48:13 <danbri> dan: i suggest thats a bug
00:48:46 <danbri> brian: as i udnerstand the issue with the rdf:ID="_id43454"
solution... if i read it in twice, i'm going to geneate the same URI
00:48:53 <danbri> mike: if you use same tool
00:49:16 <danbri> brian:...but you have no way to know that that's about theS
same rsource
00:49:27 <danbri> ...you're parser is asserting identity when has no right to do
00:49:41 <danbri> mike: [...] can use daml:equiv...
00:49:55 <danbri> * danbri (didn't capture that)
00:50:02 <danbri> pat: that was what bothered me about _bob
00:50:07 <danbri> ...someone else might use it
00:50:18 <danbri> mike: i'd want them to use full URI for doc
00:50:20 <danbri> martin: yes
00:50:40 <danbri> dan: i use '_bob' here, i can't use that _thing_ in any other
00:51:00 <danbri> pat: if you were to write that in rdf/xml you'd not see '_bob'
00:51:14 <danbri> dan: in ntriples: an implicit backwards E in front of _:
00:51:35 <danbri> martin: these bobs can't be matched across documents
00:51:58 <DanC_> * DanC_ wonders when the meeting is scheduled to adjourn
00:52:02 <danbri> emiller: i'm a little confused about this convesation... 
00:52:45 <DanC_> on opacity, is Mike Dean or PatH here on IRC? the opacity axiom
is documented, in draft form, at
00:53:00 <danbri> ..."we've had compelling test cases / experiences in last few
years. W.r.t. serey's point. While we say anyone can say anything about
anything, here perhaps we can't. Possible, quite probably, that some things may
not have names. Those things without may be difficult to further describe
00:53:23 <danbri> "given our current focus, rdfcore, if you give something an
ID, you have good chance of merging data...
00:53:44 <danbri> "for those things that don't... not our business to
standardise stuff best done in privacy of own computer
00:54:00 <danbri> em: we might eg like sha1 digests, but not our business to
00:54:21 <danbri> pat: that's not the issue. Not about knowing 'the' name, but a
00:54:40 <danbri> pat: is the act of giving something a name that big a burden
that we can't ask them to do it
00:54:46 <danbri> dan: rdf 1.0 did not make that burden
00:54:58 <danbri> "question is, how do we interpret the doc in our 1.0 syntax
00:55:11 <danbri> pat: rdf m+s text is utterly unclear about notion of anon
00:55:29 <danbri> dan: but we DID tell people to write rdf/xml in this form
00:56:09 <danbri> emiller: the 1st intepretation is what we meant first time
round; "i feel terrible for setting community back 4 years, not beating the s**t
out of editors/WG 1st time round, but that's the situation
00:56:15 <danbri> ora: it's not all your fault!
00:56:29 <danbri> emiller: so, clean up our mess. That's where we're at...
00:56:34 <danbri> dan: problem is that the implementors have done 2nd/3rd thing
00:56:44 <danbri> frank: can someone clarify diff between 1st and 2nd?
00:56:55 <danbri> * danbri requests emiller's doc for the records. URL please!
00:57:38 <danbri> frank: "if point is to interpret the 1st one as an existential
qunatifier... what's the difference between my wanting to refer to that
something, that ?x, versus referring to some arbitrary named genid.  I think
there's a difference.
00:57:42 <barstow> * barstow is enjoying this discussion and would love to see
it continue but I'm wondering if we have to stop at the top of the hour because
the published schedule said the meeting would end at 6:00pm ...
00:58:00 <danbri> dan: pat made this crystal clear. In assertional case same
entailment; in query case, nontrivially different
00:58:09 <danbri> dan: we can't go into queries
00:58:11 <danbri> frank: yes...
00:58:21 <danbri> --
00:58:48 <danbri> pat: (attemptign to sum up)
00:59:07 <danbri> "suppose we have existntials, not generated names, there's no
real difference logically. what's thefunctional difference?
00:59:34 <danbri> "you lose a little functionality. if there's a handle provided
for every existential. if there's no handle, you lose a little functionality.
00:59:49 <danbri> dan: if we want a handle, make it a uri
00:59:53 <danbri> pat: yes, you could take that line
01:00:30 <danbri> ADJOURNED. 
01:00:32 <danbri> ---
01:00:48 <danbri> chat...
01:00:50 <barstow> barstow has left channel
01:00:57 <danbri> emiller: i feel progress from last few years...
01:01:03 <danbri> pat: issues are becoming clearer...
01:01:07 <danbri> dinner!
01:01:23 <GK-f2f> GK-f2f has left channel
01:01:31 <danbri> danbri has quit
01:04:29 <dajobe> dajobe has left channel
01:11:09 <DanC_> DanC_ has quit
04:58:16 <AaronSw> AaronSw has joined #rdfcore
14:48:45 <jhendler> jhendler has joined #rdfcore
14:49:26 <jhendler> * jhendler lurking (Invite as member of W3-SW-CG)
14:56:31 <DanC_> DanC_ has joined #rdfcore
14:57:46 <DanC_> * DanC_ wonders if the WG came to any conclusion on
anon-resource etc.
14:58:04 <AaronSw> Doesn't seem like it from the logs...
15:02:11 <DanC_> DanC_ has left channel
16:12:07 <barstow> barstow has joined #rdfcore
16:12:35 <barstow> Ora: Pat and I have been thinking and we agree
16:12:40 <barstow> barstow is now known as scribe
16:12:59 <scribe> ... we are concenred about the identity of anon nodes
16:13:10 <scribe> ... we do know the identity of the annonnodes
16:13:24 <scribe> ... the distictness is reserved.
16:13:40 <scribe> Node -a-> 1 
16:13:46 <scribe> Node -b->2
16:14:18 <scribe> Yes
16:14:37 <scribe> In the serialization syntax, we give no names to these nodes
16:15:14 <danbri> danbri has joined #rdfcore
16:15:50 <scribe> Pat: the realization that I have, if I do the MT as attached
to the graph, then issues like scope of exist quant go away becauset there are
no scopes in the graph
16:16:48 <scribe> ... ... In N-Trpiles, annonNodes have ttheir own syntax.  The
annonNode is unique.
16:17:52 <scribe> ACTION: Pat - I'll re-word the MT wrt my new insight.
16:18:37 <scribe> Pat: wrt entailment, if two nodes have same URI, they can be
merged; if they do not, they must not be merged.
16:18:47 <jhendler> (err, I mean what school do you attend)
16:19:19 <scribe> Pat: there is no way in [core] RDF to do the graph merging
that Eric showed yesterday.
16:19:37 <scribe> EricM: you are correct, it can be done with additional rules -
is not part of core RDF
16:20:20 <scribe> Pat: this resolves wether things are public or private
[Brian's issue]
16:20:35 <scribe> Pat: this resolves DanC's issue with existen quantifier
16:20:56 <scribe> Pat: the annonNodes do have ID but this has nothing to do with
the graph
16:22:24 <scribe> Frank: if you think of the model as being the graph, the nodes
in the ggraph have identify; if I merge the graph, the nodes still have
identity; the annonNodes just don't have URI.
16:23:21 <scribe> Frank: wrt serialization syntax, what characteristics do the
annonNodes have?
16:24:46 <scribe> Pat: with N-Triples, annonNode are identified by their unique
16:25:25 <scribe> Frank: if you try to merge multiple N-Triple docs, the app
must keep info about where the triples came from
16:25:57 <scribe> Steve: N-Trples therefore is not a good syntax
16:27:49 <ASwartz> ASwartz has joined #rdfcore
16:27:52 <AaronSw> AaronSw has quit
16:28:00 <scribe> Graham: 2 vars are distinct if they have diff tags or if they
appear in diff n-triples expressions
16:28:15 <ASwartz> ASwartz is now known as AaronSw
16:28:43 <scribe> ... when combining 2 ntriple expressions, all of the tag nodes
are assigned arbitrary tags such that distinct nodes always have disnt tags in
the resulting expression
16:28:47 <GK-f2f> GK-f2f has joined #rdfcore
16:28:57 <scribe> mike: I'm worried about exposing internal names
16:29:13 <GK-f2f> * GK-f2f I think words to cover this are in:
16:29:41 <scribe> Pa: must differentiate naming the node and giving a name to
the thing the node denotes
16:29:51 <scribe> s/Pa:/Pat:/
16:30:04 <scribe> Ora: this is NO change to the M&S spec!
16:30:11 <scribe> Pat: I agree!
16:30:52 <scribe> Mike: in the case where internal names need to be exposed, you
will loose the fact that it was anon?
16:30:55 <scribe> Pat: yes.
16:31:33 <scribe> Eric: what does this say about the issue - are these thing
16:31:54 <scribe> Pat: Yes.
16:32:34 <scribe> DaveB: I don't understand the need to add scoping N-Triples.
16:32:46 <scribe> Pat: if you merge on the graphs, there is no problem.
16:32:56 <scribe> DaveB: you merge graphs, not N-Triples.
16:33:51 <scribe> ... [not n-triples docs]
16:34:04 <scribe> Jan: we've said scope of N-Triples is the N-Triples doc.
16:34:04 <GK-f2f> * GK-f2f so I have a program that reads two different
N-triples documents, and spits out N-triples thayt bresult from merging their
graphs -- I'd describe that as merging the N-triples documents
16:34:22 <scribe> Steve: I think we still have to deal with the scoping issue.
16:34:36 <scribe> ... Ntriples are forcing us to do that.
16:35:13 <scribe> Arno: we ran into this issue at Adobe.
16:35:43 <scribe> ... We have diff docs and compound docs.  We solved it by
16:36:07 <scribe> ... first thinking not about annonNodes but implicitly named
[have a name, wwee dont know what it is]
16:36:25 <scribe> ... We have a mechanism to refer to them.
16:36:54 <scribe> ... What we've said is consistent with our design.
16:37:11 <scribe> Graham: Ntriples is a syntax.
16:37:59 <scribe> Brian: I think we have some agreement but need to test if we
are talking about the same thing.
16:38:25 <GK-f2f> * GK-f2f and a "document" is a character string that matches
poroductiions from the "distinguished symbol" of the N-truiples grammar ... i.e.
a "sentence" of the Np-triples syntax.
16:38:36 <scribe> ... I think Ora and Pat said:
16:38:48 <scribe> ... the fundamental model is the GRAPH MODEL!
16:39:06 <scribe> ... Ntriples is a syntax for a graph [a serialization foor a
16:39:30 <scribe> ... We can have more than one graph.
16:39:35 <scribe> Pat: yes!
16:40:27 <scribe> Brian: when I merge ntriples, the semantics is that I'm
merging the graphs.
16:41:28 <scribe> ... If we have the two graphs, we can't just concatentate the
corresponding n-triples; must first change some names
16:41:58 <scribe> Brian: does the MT theory, Pat?
16:42:21 <scribe> Pat: yes, the MT must be based on the graph, not on N-Triples.
16:42:40 <scribe> ... won't need the set of triples in a document.
16:43:09 <scribe> Brian: we have an RDF serialization
16:43:17 <scribe> ... we will also have a grammar
16:43:43 <scribe> ... we will define semantics by defining a mapping from
serialization to n-triples
16:43:58 <scribe> ... from n-triples, we have a MT
16:44:15 <scribe> ... Why do we have to change that?
16:45:03 <scribe> Pat: the arrow from ntriples to MT must now go through the
16:45:09 <scribe> ... the graph has a MT
16:45:25 <scribe> ... the advant: separates some issues 
16:46:01 <scribe> Graham: will we have a MT based on the graph [not the
16:46:52 <scribe> Ron: want the graph in the middle; put MT in an arc; put
n-triples as an arc, put RDF/XML as a arc
16:47:32 <scribe> Ron: if we split an ntriples doc, how to put it back together?
16:47:57 <scribe> Pat: we can break up graphs.
16:48:28 <scribe> ... In the graph, nodes are nodes.
16:50:14 <scribe> Ron: use case is controlled vocabularies
16:50:33 <scribe> ... a node may have lots of info
16:50:41 <scribe> ... may only want to send some of the info
16:50:52 <scribe> ... can send the identity of the node
16:51:39 <scribe> jan: if you need to talk about it, give it a URI!
16:54:07 <scribe> Sergey: I'm not convinced we're all talking about the same
16:55:37 <scribe> ... want to explore using annonNodes as existential
quantifiers, etc.
16:56:06 <scribe> ... By looking at these other approaches, we could get more.
16:57:23 <scribe> danbri: I would like to hear Sergey's view.
16:57:50 <scribe> ... I would be willing to give up some RDFS time.
16:58:32 <AaronSw> * AaronSw thinks you're going around in circles
16:59:00 <scribe> ---- Sergey -----
16:59:46 <scribe> [Sergey projects a document that contains his model.]
17:00:02 <scribe> ACTION: Sergey - send this document to the WG mail list
17:00:27 <scribe> Annon nodes as existential variables
17:00:46 <scribe> URI constants: c = {c1,...,cN,...}
17:00:53 <scribe> { exists, & }
17:01:04 <scribe> Variables: {x1,...,xN,...}
17:01:26 <scribe> graph/document = formula without free variab les (most general
17:01:51 <scribe> Applications exchange documents in intermediate format (BLOB),
but get formulae (graphs) in the end
17:02:28 <scribe> d1 = t(c1, c2, ce)
17:02:28 <scribe> d2 = exists x1 t(c1, c2, x1)
17:02:35 <scribe> d3 = exists x1 [ t(c1, c2, x1) & t(x1, c3, c4) ]
17:02:43 <scribe> Equivalence:
17:02:55 <scribe> Let -> be entailment
17:03:09 <scribe> d1 = d2 <=> d1 -> d2 and d1 -> d1
17:04:21 <scribe> ad 0): t(c1, c2, c3) -> exists x1 t(c1, c2, x1) [Inference
that DanC want]
17:04:36 <scribe> ad 1): d1 = exists x1 t(c1, c2, x1)
17:04:54 <scribe>     d2 = exists x2 t(c1, c2, x2)
17:05:21 <scribe>     d1 -> d2 and d2 -> d1 => d1 = d1 (fine)
17:06:03 <scribe> ad 2): d1 = exists x [ t(c1, c2, x) & t(x, c3, c4)]
17:06:16 <scribe>    How split?
17:06:43 <scribe> [ed note: ... d1=>d1=d2 above]
17:07:02 <scribe>    d1' : exists x1 t(c1, c2, x1)
17:07:26 <scribe>     d1'' : exists x2 t(x2, c3, c4)
17:08:03 <scribe>    Merge: d1''' = exists x1 t(c1, c2, x1) & exists x2 t(x2,
c3, c4)
17:08:34 <scribe>     d1 -> d1''', but d1''' -/-> d1 => d1 != d1'''
17:08:58 <scribe>     irrerversibel change when docs are split and merged (bad?)
17:09:21 <scribe> ad 3: impossible to refer to anon. node in another document
withing the model
17:09:40 <scribe>     d1 = exists x1 t(c1, c2, x1)
17:09:59 <scribe>     d2 = exists x2 t(c1, c2, x2)
17:10:15 <scribe>     no way to ask: is x1 in d1 same as x2 in d2?
17:10:28 <scribe> Anonymous nodes as local constants:
17:10:41 <scribe> (Implementaiton perspective)
17:10:57 <scribe> URI constants: C = {c1,...,cn,...}
17:11:57 <scribe> Local constatns: PRG1 = {l1_1,...l1_N,lll}, PRG2 =
17:12:11 <scribe> Rule: prg1 cannot see constants in document
17:12:41 <scribe> ad 0): t(c1,c2,c3) -/->, <-/- t(c1,c2,l1) [fine]
17:13:08 <scribe> ad 1): d1 = t(c1, c2, l1_1), second parse d2 = t(c1,c2,l1_2)
17:13:18 <scribe>     d1 != d2 [bad?]
17:14:13 <scribe> ...
17:14:35 <scribe> [ed. note: I give up - assume Sergey will post this his file
to the list ...]
17:16:06 <scribe> ...
17:16:17 <scribe> Observations:
17:17:38 <scribe> o A does not caont URI (disjoing) If A and C overlap, we
cannot distinguish anon. nodes from the others.  But: since the same procedure
for assigingin constants from A, this is irrelevant.  A can be viewed as subset
of C that is extremely unlikely to be used
17:18:25 <scribe> o Application that neeed not communicate may not local IDs. 
If communicate using syntax that contains "holes", fine.  No global
autogeneration algorithm required.
17:19:01 <scribe> o If no standard assignment algorithm is required, ad 1) is
still violated (parsing twice)
17:20:46 <scribe> ....
17:21:13 <scribe> Sergey: there can be a formal mechanism to help base arguments
about anon. nodes.
17:21:41 <scribe> ... point 2: there are multiple options for implementing anon.
nodes [they all have advantages and disadvantages]
17:22:45 <scribe> ... want to ground the decisoion.  This also helps define the
application semantics.
17:22:55 <scribe> Jan: this is very useful.  However, your existance proof is
17:23:28 <scribe> ... You have no way of knowing where things come from.
17:23:56 <scribe> ... The algorithm doesn't reflect that  a URI may return the
same thing through time.
17:25:14 <scribe> Pat: the question is what is the semantics.  Is is temporary
[the doc]?
17:25:26 <scribe> ... M&S is talking about graphs.
17:27:09 <scribe> Sergey: I think explicit genids would be useful.
17:27:34 <jhendler> jhendler has quit
17:28:03 <scribe> Brian: if you parse the same doc, should an anon description
have the same identity?
17:30:25 <scribe> Ron: if everyone generates the same identifier for an anon
node, it could be useful but it also could be dangerous.
17:30:37 <scribe> ... That's the choice: useful vs dangerous.
17:30:54 <scribe> danbri: it is very dangerous.
17:31:22 <scribe> Brian: can you do more things this way?
17:32:07 <scribe> Ron: you can do more things because then you can hang
additional stuff off of it.
17:32:19 <scribe> Jan: there are better ways to do this.
17:32:39 <scribe> Frank: what exactly is the question?
17:33:27 <scribe> Brian: do you need everyone to use the same algorithm?
17:33:49 <scribe> Ron: if folks agree on an algorithm, you can do additional
17:35:49 <scribe> Pat:  I don't think these examples are helpful.  They
introduces more confustion.  It doesn't talk about the graph.
17:36:21 <scribe> ... We don't need to introduce the variables.
17:37:32 <scribe> Eric: we need to put a stake in the ground and move on.  We
need to focus on the graph to agree on stuff.
17:38:38 <scribe> Pat: I'll update the MT based on the graph within a week.
17:58:11 <scribe> ======== Break Over =========
18:00:20 <GK-f2f> RDF Syntax -- Dave Beckett Leads
18:01:51 <GK-f2f>
18:02:57 <GK-f2f> slide 2
18:03:18 <GK-f2f> slide 3
18:03:24 <GK-f2f> (ntriplesreview)
18:03:27 <GK-f2f> GK-f2f has quit
18:03:31 <jang> jang has joined #rdfcore
18:04:34 <jang> (talks about benefits of ntrlpes as simple serialisation)
18:04:41 <jang> slide 4
18:04:50 <DanCon> DanCon has joined #rdfcore
18:05:21 <jang> dave'd been looking at reexpressing the grammer in terms of the
infoset, rather than '<' etc
18:05:39 <jang> grammar looks simpler, smaller
18:06:23 <jang> we o xml syntax -> ntriples -> graph -> MT
18:06:27 <jang> s/o/go
18:06:39 <jang> points at:
18:06:57 <jang> http://ilrt.org/discovery/2001/07/rdf-syntax-grammar/
18:07:16 <jang> dave points out, as an example, the 6.3 entry in the table
18:07:40 <jang> dve's had to invent a syntax for expressing XML infoset
18:07:57 <jang> slide 5
18:08:31 <jang> change to slide: <=> "the graph" in each case
18:08:50 <jang> dave mentions other formal proposals for syntax notations
18:08:55 <jang> slide 6
18:09:09 <jang> answer to "is ntriples sufficient?" DB: yes
18:09:15 <jang> (db = dave beckeytt)
18:09:36 <jang> still open on question 2: what formalisms should be used to
express grammar
18:09:45 <jang> => slide 8
18:09:47 <jang> and done
18:10:01 <jang> wy is BNF so bad?
18:10:27 <jang> we can use BNF, but sould be expressed in terms of infoset, not
<, & etc
18:11:04 <jang> PH: ntriples syntax may bem misleading
18:11:14 <jang> URIRef and anonnode should be changed
18:11:19 <jang> DB: I've already changed that
18:11:52 <jang> brian:
18:11:57 <jang> there are two questions
18:12:05 <jang> 1. how we repsent the grammar formally and precisely
18:12:12 <GK-f2f> GK-f2f has joined #rdfcore
18:12:17 <jang> 2. how do we define the transform from rdf/xml into core
18:12:27 <jang> (and is it mechanically executable)
18:12:46 <jang> closest bri has are attribute grammars
18:12:54 <jang> danbri: schematron is the closest I've seen
18:13:11 <AaronSw> * AaronSw (informally) proposes XSLT
18:13:14 <jang> db: uneasy about it's completeness
18:13:33 <jang> restating question about transformation:
18:13:44 <jang> rdfxml must be translated by a parser into some representation
of the graph
18:14:02 <jang> is there a way of describing this transformation mechanically
and executably?
18:14:13 <jang> SM: there's a new parser that uses javacc
18:14:25 <jang> javacc ives you the grammar definition
18:14:35 <jang> you can introduce bits of code into the grammar it uses
18:14:51 <jang> bri: that's basically an attribute grammar with java as the
18:15:05 <jang> danbri: we sould note xslt has been used for this
18:15:21 <jang> bri: tried it, it was very large, not a good way of descibing
the transformation to an implementor
18:15:30 <jang> danc has also got an xslt parser, danbri knows of another
18:15:35 <jang> (can't remember who by)
18:15:52 <jang> bri: wants a compact gramamr that can be transformed into xslt,
for instance
18:15:57 <jang> danbri: that's what schematron does.
18:16:06 <jang> bri: talks about jeremy's parser
18:16:25 <jang> he had the problems due to M+S talking about characters.
18:16:26 <danbri> the other rdf xslt parser was by jason diamond
18:16:33 <jang> so he did javacc with a grammar in terms of SAX events
18:16:48 <jang> this is pretty handy
18:17:05 <jang> dave's looking for suggestions; he's stil inthe investigation
18:17:15 <danbri> xslt parsers: see http://www.xmlhack.com/read.php?item=757
18:17:34 <jang> art: is the WG constrained to using w3c or other standard?
18:17:44 <jang> are we bound to standardised mechanisms?
18:18:12 <jang> em: i don't think so. We must be able to represent the grammar
in something that's as familiar as possible to the other xml techs
18:18:33 <jang> em: likes XDuce; but if it's one of equals he'd prefer sometng
18:18:39 <jang> dan: relaxng looks promising too
18:19:03 <jang> danri: if we want others to have a good look at our spec, we
should extend them the same courtesy
18:19:23 <jang> em: only a few people from, eg, DC will be interested in reading
the spec?
18:19:33 <danbri> (re politeness: specifically within the w3c xml family of
18:19:35 <jang> daveb: we want a single normative mechanism
18:19:46 <jang> em: ebnf, for example.
18:19:54 <jang> daveb: it's basically in terms of characters
18:20:06 <jang> sm: can xslt produce non-xml docuemnts?
18:20:08 <jang> all: yes
18:20:35 <jang> sm: asks for smple syntax
18:20:45 <jang> dave: we've got ntriples, that's what we've been using
18:21:03 <jang> sm: what about dealing with reification, literls, etc.? it's
going to keep growing
18:21:23 <jang> brian: is ntriple broken? do we anticipate it stopping working?
18:21:34 <jang> ph: the only possible problem is scoping, i think we've resolved
18:21:46 <jang> bri: then we stick with ntriple until it's demonstrated that
it's broken
18:22:12 <jang> jang volounteers to help dave with the investigation
18:22:19 <jang> dave asks: can we include jeremy?
18:22:25 <jang> art: also interested
18:22:32 <jang> brian: AP! ask jeremy about this
18:22:42 <jang> dan: suggests schematron to invesigate
18:22:59 <jang> AP: ang, dave, art to investigate and come back with a
18:23:16 <jang> Graham: let's be absolutely clear wat we consider the primary
18:23:40 <jang> graham: i ask because XSLT exists and may be very good, but it
is probably not very good at expressing the concepts to a human reader
18:23:48 <jang> is the human developer the primay audience?
18:23:50 <jang> bri: yes
18:24:02 <jang> sm: s ntriple going to be xmlised?
18:24:05 <jang> bri: no plans yet
18:24:12 <jang> sm: then we can't use xslt?
18:24:21 <jang> al: no, it can produce anything including text files
18:24:30 <jang> em: it can do tree transforms to text
18:24:40 <jang> steveP: what is the role of the ntriples syntax?
18:24:46 <jang> normative or for testing?
18:24:54 <jang> I'd be opposed (I think) to it being normative
18:25:13 <jang> bri: we need a way to represent the graph. we have to be able to
write down the graph transformation
18:25:20 <jang> bri: in mymind, ntriples is for that
18:25:24 <jang> steve: but it's not a graph
18:25:37 <jang> ph: we could draw pictures in the spec
18:25:54 <jang> we need ntriples for testing, not for the defintiion
18:26:11 <jang> brian: I need some way of writing down my test-cases
18:26:25 <jang> I'd rather use one representation of a gaph
18:26:30 <jang> graph, even
18:26:56 <jang> dave: we've got a mixture of text and formalisms at the moment
18:27:04 <jang> ph: software exists to construct and transmit graphs.
18:27:23 <jang> ph: wy don't we make the exposition in the definitive document
conform to the graph directly?
18:27:40 <jang> every time a graph is pictures, we can give the ntriples
18:28:02 <jang> danbri: i aree largely, but I'd be concerned if we say all sorts
of wooly non-normative thngs about ntriples
18:28:08 <jang> it's as normative as the rest of the spec
18:28:28 <jang> ph: I was responding to brian's desire that ntriples be the way
graphs are described
18:29:19 <jang> fm: one role ntriple could play in the exposition is to
illustrate some of th epotential misunderstandings they may experience
18:29:47 <jang> people have been sending ntriple-ish stuff back and forward for
disambiguation by email
18:29:57 <jang> so ntriples could be used as an example of a serialisation
18:30:02 <danbri> * danbri agrees
18:30:08 <jang> to make the point that the graph model is the central issue
18:30:32 <jang> brian: when I think of ntriple, i think it behaves exatly like a
18:30:46 <jang> ph: all the issues of name scoping have not been properly
18:31:09 <jang> graham: the advantage of using graphs directly: it'll prevent
opthers from falling into the same mental trap
18:31:32 <jang> em: we've been trynig to do this for 4 years, unsuccessfully:
saying "it's the graph stupid"
18:31:46 <jang> people understand the serialisation more than the abstract
18:31:53 <DanCon> DanCon has left channel
18:31:54 <jang> ora: I don't think that's true. 
18:32:19 <jang> people see the serialisation and don't understand it represents
a graph
18:32:28 <jang> em: eg,xml people see it as an xml document
18:32:50 <jang> graham: we should do everything twice in the document: once as a
graph and once as ntriples
18:33:17 <jang> ora: in some sense, choosing xml was a mistake. people see xml
and consider it to be just xml, not a graph
18:33:38 <jang> every time i speak about the graph, people get it though. I've
stopped talking about xml and people just get it
18:33:46 <jang> em: I've seen exacty the opposite
18:34:03 <jang> people ask, "but what does it look like?" meaning, where are the
18:34:41 <jang> em: people are deploying a lot of apps that just happen to be
rdf-friendly, eg, rss - most users just consider it to be an xml document
18:35:12 <jang> dan: what are we trying to achieve? we're not trying to write
the rdf tutorial or do modelling
18:35:57 <jang> we're not trying to write the tutorial here - in that context,
does anyone have anything else to add?
18:36:20 <jang> mike d: we've produced another serialisation for rdf. if we play
it up, won't people start using it?
18:36:36 <jang> how important is it to emphasise that the xml serialisation is
the preferred syntax
18:36:45 <jang> bri: we're not chartered to develop a new synta
18:37:00 <jang> mike: it's becoming bigger. it's for test cases basically
18:37:24 <jang> ph: it sends a good messge - there are at least two maybe more
serialisations of rdf
18:37:35 <jang> M+S doesn't hammer this home sufficiently
18:37:54 <jang> arno: this can create some confusion. eg, DC has multiple
18:38:14 <jang> documents that have different forms tend to be interpreted
18:38:36 <jang> em: let's not go there yet. it is non-trivial to convince people
to deploy multiple syntaxes
18:38:58 <jang> ph: we either say, there is one preferred syntax, and not
mention any others, or we shoud say
18:39:06 <jang> rdf is about graphs and there may be muktiple syntaxes
18:39:24 <jang> danbri: this has been very important to exaplin to people.
18:39:50 <jang> em: I want that, yes: we're building on the first M+S
18:40:16 <jang> this diagram (referring to the graph -> MT, ntriples,
serialisation diagram) is really importnat
18:40:35 <jang> e: priority should be to clarify the model (graph) and focus on
the rdf xml serialisation
18:41:12 <jang> ora: says "S-expressions" and gets lynched
18:41:12 <jang> brian: moving on to schema
18:41:12 <jang>  minute break, back in a tick...
18:55:51 <jang> back: rdf schema issues
18:56:00 <jang> danbri to lead, brian to timekeep + chair
18:56:15 <jang> eric has noes on laptop
18:56:21 <AaronSw>
18:56:30 <AaronSw>  - notes
18:56:32 <jang> ap: eric/danbri to ensure dan's document goes online
18:56:41 <scribe> ======== DanBri - RDFSchema ========
18:57:57 <jang> w3c think rdfsch is more or less done
18:58:06 <jang> we've had feedback... particularly from daml+oil
18:58:36 <jang> rdfschema work stopped waiting for xml schema - that's now done
18:58:49 <jang> we need to take the useful bits ( datatypes) into rdf schema
18:59:08 <shellac> shellac has joined #rdfcore
19:00:01 <jang> WG sucessor (web-ontology) is planned
19:00:55 <jang> dan points out: what we decide/do next doesn' have to be writen
in stone, so we make pragmatic ecisions on what the next WD looks like
19:01:55 <jang> domain + range is an open issue; dan proposes we skip over this
because there's a good answer
19:02:19 <jang> this is a no-brainer
19:02:47 <jang> ora gives a bit of background to rdfschema; we're after an OO
extensible type system to rdf
19:03:02 <jang> we're after very little.
19:03:54 <jang> ora: te properties of properties are global - no class-specific
19:03:59 <jang> we fixed this in daml
19:04:17 <jang> domain + range: this is the open issue
19:05:12 <jang> dan talks about daml work getting pushed into schema/web-ont -
we don't know or care yet what's going to ahappen about this
19:05:23 <jang> dan: ora - class-contextualised constraints may come later
19:05:50 <jang> dan: any dissent to conjunctive interpretation of range+domain?
19:07:04 <jang> art: is there any evidence that people are using current
19:07:07 <jang> jan: I've seen some
19:07:14 <jang> AP: jan to write up the fix/workaround for this
19:07:36 <jang> ron: possible to change the namespace to not break stuff for
19:07:55 <jang> dan: yes, it's possible, my preferred take:
19:08:15 <jang> there is a thing called rdf:domain which the rdfschema people
have previously made an erroneous statement about
19:08:36 <jang> ph: introducing a new namespace isn't always the most painful
19:08:53 <jang> AP: rdf schema editor to fold conjunctive decision into the raph
19:09:53 <jang> APPROVED: multiple domains, ranges, with conjunctive semantics
19:10:01 <jang> pretty much carried unanimously
19:11:21 <jang> approved by ora, brian, art, jos, dave b, martin, ph, ron d,
frank m, sergei, kwon, em, arno, stephen p, jan, raham, 
19:11:31 <jang> we record no objections: ron daniel abstained
19:11:44 <jang> (danbri also voted in favour)
19:12:26 <jang> rdfs:domain & rang constraingts or rdfs:domain were missing from
the schema - this is just a typo
19:12:33 <jang> proposal to fix this
19:13:17 <jang> ron: was the editorial oversight due to non-discussion/
non-decision or was a decision recorded
19:13:24 <jang> but didn't make it to the doc?
19:13:37 <jang> dan: not certain; but the pictures we had show these values
19:13:46 <jang> proposal: editor to fold these into the next WD
19:14:36 <jang> all in favour, no abstentions, no against
19:14:40 <jang> APPROVED
19:15:15 <jang> subclassing containers...
19:15:36 <jang> dan: a compelling case for this was not allowed
19:15:41 <jang> s/allowed/made
19:15:47 <jang> for the next wd, we say: future work
19:16:18 <jang> AP: jan to provide explanation of how we'd add this
19:17:35 <jang> proposal: no change on this issue in next draft of rdfs
19:17:50 <jang> we take as resolved on the issues list
19:18:13 <jang> (recording accurately the nature of the resolution)
19:19:50 <jang> all in favour: abstain frank, no against
19:19:55 <jang> APPROVED
19:20:34 <jang> datatyping....
19:21:56 <jang> ron: originally we discussed this and decided to wait for
19:22:12 <jang> proposal is to take in what DAML+OIL did, throw it in and then
argue abot ti later
19:22:19 <GK-f2f> * GK-f2f INFO: CC/PP uses XML schema datatypes -
19:22:41 <jang> this sin't for the next WD, just as the next step
19:23:11 <jang> proposal (refined)
19:23:25 <jang> we expect to work in this area, informed by the daml+oil work
19:25:41 <jang> AP: graham to send to working group how CCPP does datatypes
19:26:01 <jang> AP: ajn to do the same with the EASEL approach
19:26:20 <jang> ora: the daml+oil approach is clever because if you don't care,
you don't get hurt
19:26:49 <jang> proposal: to go away and investigate and report back to the
19:27:00 <jang> dan: taskforce to consider the adoption of...
19:27:43 <jang> adopt daml+oil/xml datatypes as initial foray into the issue
19:27:55 <jang> we don't consider closure on this issue a must-have for the next
19:28:18 <jang> drop the "adopt"
19:28:30 <jang> final proposal should come from EM's document, he's editing it
19:29:22 <jang> volounteers: danbri  graham, martin, jan
19:30:15 <jang> all in favour of the taskgroup 
19:32:10 <jang> brian leaves to order pizza
19:33:48 <jang> rdfs-primitive-properties
19:36:28 <jang> AP: pat to go into some more detail on why the know-tying at the
top of the hierarchy in rdfs is not a set-theoretical hole
19:37:14 <shellac> shellac has quit
19:37:20 <jang> s/know-tying/knot-tying
19:38:04 <jang> proposal: we don't think this is a problem
19:38:32 <jang> so we close the issue, with the expositional urden associated
19:39:52 <GK-f2f> * GK-f2f INFO: Horrocks, et al paper is at
19:40:20 <jang> dan explains how we go around answering this (process issues)
19:40:30 <jang> we're obliged to respond to feedback
19:40:57 <GK-f2f> * GK-f2f Last URI was wrong one ... still looking
19:41:42 <jang> all in favour. no abstain, no against (brian absent)
19:41:59 <jang> cycles in subclassof
19:42:02 <GK-f2f> * GK-f2f I think this is the right one:
19:42:36 <jang> daml+oil didn't like this
19:42:58 <jang> dan: personal bias towards what we've got is a bad usability
problem explaining it to people
19:43:25 <jang> graham: one reason to change is that this is one of those things
that can't be described within the schema framework
19:43:27 <jang> thus we drop it
19:43:46 <jang> ora: doesn'tcare
19:44:05 <jang> dave: biggest implementation in this area doing this already?
will we break something?
19:44:17 <jang> dan: opens floodgates
19:44:34 <jang> ron: recalls experience was that people wouldn't want cycles in
te subgraph relationship
19:45:00 <jang> this will break a lot of implementations if we use this. in
particular, stuff out there won't be doing cycle detection
19:45:12 <jang> danbri: the system is gullible if it's not checking this
19:45:33 <jang> ron: no, that's not fair - if the spec tells you there are no
cycles, then there is a performance optimisationto not bother checking
19:46:01 <jang> frank: that argument can be ade for any syntactic description.
this is absurd if taken to its extreme conclusion
19:46:20 <jang> dan: I was going to ask someone from DAML how strongly they care
19:46:36 <jang> graham: we need to make the change ASAP if we're going to hurt
as few people as possible
19:47:11 <jang> dave: rather than do nothing, I want to know now what we're
doing, are we gogin
19:47:17 <jang> to change it
19:47:51 <jang> PH recalls why daml people wanted this - it was fought hard over
19:48:01 <jang> ora: frank + ian do class equality doing this
19:48:01 <jhendler> jhendler has joined #rdfcore
19:48:10 <jang> which frees them from having another relationship
19:48:16 <jang> and that this is DL accepted practice
19:48:58 <jang> frank: I did circulate a paper sumarising the major arguments
for this change from DAML
19:49:11 <jang> people are going to write these; what do we want to happen?
19:49:56 <jang> do we barf, notice this, flag it up as a possible problem, etc?
19:50:11 <jang> frank: there are a number of large-scale ontologies with cycles.
19:50:52 <jang> PH: the critical case for DAML+OIL thinking was that subsetting
relationship might be made by multiple people
19:51:12 <jang> the logical conclusion is that the two classes are co-extensive
19:51:47 <jang> PH: the issue is, is subclassof lessthan or lessthanorequal
19:52:00 <jang> one has cycles, one doesn't; we really need both
19:52:34 <jang> EM: when merging large ontologies, we can't prohibit cycles from
19:52:40 <jang> the issue is, what does it mean? (PH)
19:53:09 <jang> this is the only place where two ontologies could contradict
each oter (in rdf + rdfs)
19:53:20 <jang> dan tries to close this
19:53:37 <jang> can we resolve that people who care about this go away and come
back with some advice?
19:53:56 <jang> ron would like a vote
19:54:14 <jang> brian returns at this point.
19:55:09 <jang> em: options: taskforce, or discuss now (useful)
19:55:18 <jang> ron: third option: strawpoll?
19:57:23 <jang> dave: programmers from OO languages dont like this
19:58:27 <jang> non-binding strawpoll
19:58:45 <jang> insufficient consensus on this
19:58:54 <jang> dan stresses we're only talking about the next WD
19:59:52 <jang> sergei says why he's against (because of dave's point)
20:00:58 <jang> ron: suggests we record this that we insert a question into the
next WD
20:01:04 <jang> asking for feedback
20:01:10 <jang> this now becomes the proposal....
20:01:23 <jang> ORA: AP - talk to ian +frank t get the background on this
20:02:55 <jang> proposal: we stick something in the WD saying "we're looking for
feedback - we're going to pull this - how badly does it hurt?"
20:03:11 <jang> PH: daml will invent daml:subclassof f you don't take this out
20:03:44 <jang> frank: the daml+OIL people gave us explicit feedback, which
strongly mentioned this
20:04:27 <jang> frank: also want explicitly recognised that frank sent the
feedback t the WG list
20:04:41 <jang> this shouldn't be news to us we HAVE feedback already!)
20:05:36 <jang> ron: by nserting this in the document then this becomes a
resonse to the DAML+OIL people
20:05:44 <jang> PH: that sounds perfectly fine
20:06:09 <jang> jos: we're discussing subpropertyof too
20:06:23 <jang> danbri: yes, we take this to be the case
20:06:45 <jang> can frank modify his document into something to put in the next
20:07:30 <jang> em: propose flaed in the next draft
20:07:48 <jang> also: someone (frank) to go back to the DAML+OIL people and ask
for moe convincing arguments
20:08:21 <jang> AP: pat to take this back to the DAML people at the next telecon
and bring the feedback to us
20:09:02 <jang> summary: OO programmers are confused, people are trying to
code-generate classes (java) for this
20:09:06 <jang> thus we have to go back
20:09:39 <jang> proposal: open the issue, take the stuff to DAML (PH) and
continue the discussion
20:10:03 <AaronSw> * AaronSw (informally) notes java doesn't even have multiple
inheritance, so it's not really a good example
20:10:08 <jang> frank to own this issue.
20:10:22 <jang> aaron: it has multiple inheritance of interfaces
20:10:30 <jang> (after a particular fashion)
20:10:38 <jang> not of implementations
20:10:56 <AaronSw> * AaronSw scrunches his face up...well, yeah
20:12:21 <GK-f2f> * GK-f2f Java no MI of classes, true, but it does have MI
20:12:22 <AaronSw> * AaronSw notes (informally) that python allows inheritance
20:12:30 <jang> propose: open issue (frank owns ) plus PH, ora to take back to
DAML any feedback from this
20:12:35 <jhendler> jhendler has left channel
20:21:49 <jimH-lurk> jimH-lurk has joined #rdfcore
20:42:20 <scribe> scribe has quit
20:44:10 <barstow_> barstow_ has joined #rdfcore
20:50:25 <jang> back after lunch
20:50:47 <jang> plan: finish schema, open mike
20:50:51 <jang> danbri...
20:51:25 <jang> spo semantics (inheritance)
20:51:35 <jang> inheritance of range+domanin
20:51:48 <jang> seem to have fixed a lot of this with range & domain
20:53:16 <jang> jan: subproperties should inherit conjunctively the range+domain
of their superproperties
20:53:24 <jang> ron: is there a clarification that's been asked for?
20:54:48 <jang> general agreement with jan's statement of this
20:55:24 <jang> AP: dan clarify prose to reflect this position accurately
20:56:03 <jang> then issue closes
20:56:30 <jang> subclass of a subproperty
20:56:40 <jang> (previous issue RESOLVED)
20:57:30 <jang> are rdfs:Class and rdfs:Property disjoint?
20:57:45 <jang> ora has seen an instanc of this
20:57:58 <jang> didn't see any reason why this shouldn't be permitted
20:58:28 <jang> dan talks about rss:image
20:58:47 <jang> PH: the real question is "what does this mean?"
20:59:15 <jang> em: finds it very confusing
20:59:41 <jang> dan: default thing is to do nothing; the spec's silent on this
20:59:56 <jang> dan's candidate meaning is "coincidence" - ph's MT does this
21:00:44 <jang> proposal: can we restate this as "are Property and Class
21:01:07 <jang> the proposal is to record this issue in this style
21:01:54 <jang> and to do nothing in the next WD
21:03:56 <jang> we move on
21:04:23 <barstow_> * barstow_ notes to GK that MIT [thus W3C] is experiencing
network problems ...
21:04:37 <jang> (this is our resolution)
21:04:52 <jang> onlie char encoding
21:05:12 <jang> proposal: editor to fix this
21:05:16 <jang> RESOLVED
21:05:25 <jang> (we don't want to rathole on this nobrainer)
21:05:30 <jang> versioning:
21:05:36 <jang> known and had problem
21:05:40 <jang> s/had/hard
21:05:59 <jang> this is very very difficult. Nobody really appears to know how
to do this. Open research issue
21:06:17 <AaronSw> * AaronSw doesn't think so
21:06:41 <jang> Proposal: note this is very hard, close the issue.
21:07:30 <jang> PH: proposal "wepropose to not answer this!"
21:07:57 <jang> in other words, we leave the spec as it is
21:08:11 <AaronSw> * AaronSw is vehemently opposed to that proposal
21:08:15 <jang> moving on
21:08:22 <jang> you're not here; take it to email
21:08:49 <jang> transitive subproperty
21:09:35 <GK-f2f> Jan: Counter-example sisterOf subproperty of siblingOf
21:09:50 <jang> proposal: the answer is "no" it's not transitive
21:10:13 <jang> AP on anyone who cares: find an explanatory piece of prose on
21:10:17 <jang> AP on JAN to do this
21:10:41 <jang> AP on editor: chase jan on this
21:12:32 <jang> movin on
21:12:46 <jang> (ron notes that he's not convinced in this case)
21:12:56 <jang> we make no changes to the next draft; this issue remains open
21:13:33 <jang> we do that. frank, steve P abstain
21:13:37 <jang> next
21:13:44 <jang> subclassof and instance clarification
21:16:03 <jang> frank: we must ensure that we consider the original email
messages, not a summary of the issues
21:17:08 <jang> that and the next two issues (isDefinedBy semantics and
21:17:28 <jang> no action on tehse before the next WD
21:17:44 <jang> carried; a couple of abstentions (jan, steve P)
21:19:08 <jang> we leave these until later
21:22:44 <jang> new WD in one month
21:22:44 <jang> new WD of rdfs due on september sixth
21:24:16 <jang> jan notes he has acounterexample to the transitive subproperty
of subproperty question
21:29:58 <jang> we go on to "where next"?
21:30:05 <jang> schema new WD by sept 6
21:30:17 <jang> syntax: we have a taskforce
21:30:27 <jang> model: pat has an action on him
21:30:45 <jang> also: second half - sergei's mechanisms for implication analysis
21:31:12 <danbri> danbri has quit
21:32:01 <jang> ron especialy points out that splitting is not a requirement,
merely something to consider
21:33:04 <jang> steve p asks : can we actually get a proposal out of this?
21:34:01 <jang> PH; two pieces of rdf are identical iff they map to the same
21:35:23 <jang> s/identical/equivalent
21:36:02 <jang> two rdf documents are equivalent iff they map to teh same RDF
21:37:41 <jang> two rdf graphs are the same when :
21:37:51 <jang> 1. they are graph isomorphic
21:38:03 <jang> 2. no two nodes are labelled with the same URI
21:42:18 <AaronSw> * AaronSw doesn't get point 2 at all
21:43:43 <GK-f2f> * GK-f2f stuff on graph theory at:
21:44:14 <jang> we can't specify this precisely
21:44:14 <jang> so we agree that this needs more thinking about
21:44:14 <jang> we HAVE agreed that the graph is the central idea to RDF
21:45:42 <GK-f2f> * GK-f2f see in particular 1st para of
21:45:46 <jang> ron: the graph is the central concept for RDF, there are
multiple graphs
21:46:15 <jang> ron reads out a whole bunch of statements that indicate we need
to think
21:46:22 <jang> AP: ron to send this to the list
21:47:01 <jang> frank: as a matter of exposition, the graph model is central and
the other representations are to be interpreted n that light
21:47:06 <shellac> shellac has joined #rdfcore
21:47:06 <AaronSw> * AaronSw knows what isomorphism is... not sure why RDF needs
a special requrement though
21:47:11 <jang> the current text doesn't really make this clear throughout
21:47:53 <jang> in the course of making these points, we have to be careful that
the message is carried throughout the whole document
21:48:26 <jang> brian: agrees; we're lookig fora  rewrite, not an editing job.
21:50:00 <jang> we look at te schedule
21:50:34 <jang> we're running a lttle behind :-)
21:51:10 <jang> are there better notions of what revised dates we should commit
21:51:30 <jang> em: we should discuss what our delivrables are
21:51:38 <jang> we know one:rdfs, we have a date
21:52:08 <jang> re: pat's attempts aove: jang greed they had the same logical
entailment, but that that was not where teh anon node issue lied
21:52:14 <jang> s/lied/lay
21:52:25 <danbri> danbri has joined #rdfcore
21:53:57 <jang> we ask how many people would be interested in focussing on a
21:54:23 <AaronSw> * AaronSw signals agreement
21:55:05 <jang> if we had to pick to each of:
21:55:11 <jang> primer, model, df/xml, schema
21:55:20 <jang> which would they be?
21:55:41 <jang> we add "test case repository" as a deliverable
21:56:48 <jang> interested in primer: 5
21:56:57 <jang> model: 8
21:57:07 <jang> syntaxL 4
21:57:13 <jang> schema: 4
21:57:17 <AaronSw> * AaronSw volunteers for primer
21:57:22 <jang> test cases: 2
21:57:45 <danbri> aaron/primer: :)
21:58:32 <jang> AP; (repeated) action item to get rdfs done
21:58:43 <jang> some of these depend on pats revised model
22:00:19 <jang> danri: we can get the telecon bridge available at other times
22:01:59 <jang> ora: are we issuing a version of the existing spec or a new
22:02:37 <jang> as comparison, there is a new XML spec.
22:03:24 <jang> ora notes that we tried to originally eparate model and syntax,
and it was too hard
22:03:49 <jang> pat: is the document primarily definitive or understandable?
22:04:57 <jang> em/ora: why we smushed the documents together originally
22:05:18 <jang> we were looking for primer and spec and al sort of things
22:05:32 <jang> dave: document format is to be left ntil much later, let's
produce the pieces first
22:07:13 <jang> ow many people are interested in being the editor/document
layout person
22:07:14 <jang> graham is
22:07:38 <danbri> danbri is
22:07:51 <jang> graham: i sense there's significant support for the idea that
model and syntax be separated
22:07:56 <AaronSw> * AaronSw is interested in nitpicking
22:08:06 <danbri> (danbri is...interested in being on any group working on
document partitioning)
22:08:21 <jang> good, but people are talking - I'm not going to butt in with
this one (to email, you'll not be left out)
22:08:56 <jang> dave:do we need coordination?
22:09:13 <jang> em: yes, really. I'm looking for where this can take place/be
22:09:23 <jang> s/centered/centred
22:09:58 <jang> ron: proposal to identify a team leader for each of the items,
including overall documen structure
22:10:06 <jang> this is har work, but I think that's what we need
22:10:57 <GK-f2f> brian M suggests pick a leader for the overall breakdown, and
defer selecting others
22:11:40 <jang> brian proposes to take the document leader job - it's the
chair's jo
22:11:44 <jang> hear, hears
22:12:02 <jang> that is document structure ONLY
22:12:21 <jang> AP: brian to take the list of sections and come back with
something more cocrete to look for volounteers
22:12:55 <jang> frank: could we consider structuring theseas web things instead
of PODs?
22:13:06 <jang> there, we close.
22:13:27 <GK-f2f> * GK-f2f I think the docs should be printable as PODs if
22:13:42 <jang> reopen: schedule rearrangement
22:13:42 <GK-f2f> * GK-f2f (POD = plain old document?)
22:13:45 <jang> yep
22:14:13 <jang> brian thinks that www11 would be a good place to annonce rec
22:14:14 <AaronSw> * AaronSw thinks web things == goodness
22:14:35 <jang> hard narrative stuff and hard to print out to read onthe plane
22:14:58 <jang> www11 is in may 2002
22:15:25 <AaronSw> * AaronSw thinks web things != no print version
22:16:15 <GK-f2f> * GK-f2f yes, but I woukld want it to be a single printable
doc, not lots of separate web "pages"
22:16:41 <AaronSw> * AaronSw thinks that this is what XML is for -- one XML
document can be distributed in multiple versions
22:16:58 <AaronSw> * AaronSw also likes one-document specs, FWIW
22:18:30 <jang> AGREED: to announce REC at www2002
22:18:35 <jang> (or aim for that)
22:19:23 <jang> kwon's presentations
22:19:23 <jang> AP: kwon to get this on the web
22:22:30 <danbri> (hmm... agreed: We would really really like to announce REC at
22:25:46 <jang> kwon's questions....
22:25:55 <jang> (from last side)
22:26:10 <jang> PH: rdf useful within machines for storing metadata
22:26:21 <jang> is this an "in" for getting RDF involved?
22:26:54 <jang> kwon's wg chair wants to go with rdf
22:27:00 <jang> but they're suffering from tool availablility
22:27:25 <jang> metametadata storage is still currently hard, esp. with rdfs in
its current state
22:27:39 <jang> em: lots of people are squeamish because rdfs is not a rec
22:28:05 <jang> em: thus I'd really like to get rdfs out the door asap
22:28:28 <jang> ph: it's startling that ean entire country waiting for us to
make up our minds
22:28:49 <jang> em: there are now 6 countries that have mandated DC metadata in
xml/rdf in all govt produced documents
22:29:12 <jang> so the frivolous question of pat's is actually very accurate
22:29:29 <jang> dan: people see us getting interested in AI/KR issues, theyr'e
worried by this
22:29:44 <jang> ron: "are we supporting the austrailian DC standard?"
22:29:50 <jang> we get these issues all the time
22:30:06 <jang> em: yes, a lot of tese people are simply waiting on a REC
22:30:52 <jang> (now dajobe scribe)
22:31:03 <jang> arnot - adobe
22:31:14 <jang> ... toolkit and specification now available
22:31:21 <jang> ... invite anyone interested to join program
22:31:45 <jang> ... c++ and source available under an open license, probably
open source
22:32:05 <jang> bwm: to kwan
22:32:12 <jang> s/kwan/kwon/
22:32:42 <jang> ... toolkits - redland, raptor by daveb, rdf api - sergey, jena
- bwm
22:32:52 <jang> ... cslisp - ora, kinda-perl - dan
22:33:00 <jang> ... help available, please ask
22:33:13 <jang> jang is now known as dajobe
22:33:39 <dajobe> rond: demo
22:33:56 <dajobe> ... presentation to time
22:34:47 <danbri> aside, danbri's perl rdf stuff:
22:34:50 <dajobe> ... visual maps 
22:35:01 <dajobe> ... tim bray's antarti.ca
22:35:27 <dajobe> ... demo contains interwoven-generated time info
22:35:37 <shellac> shellac has left channel
22:35:50 <II> II has joined #rdfcore
22:36:02 <dajobe> ... stories visualised in map form
22:36:17 <dajobe> ... number of articles is area
22:36:27 <dajobe> ... 'importance' by how titles are visualised
22:36:44 <dajobe> .... separate view on content using SIC codes
22:37:27 <dajobe> ... example of rdf 'stuff' sent off to a different company,
made into a demo
22:37:46 <dajobe> em: can you make this public?
22:37:48 <dajobe> rond: have to see
22:39:08 <dajobe> dajobe: maps.net taken rdf from dmoz too
22:39:17 <dajobe> em: short turnaround, fantastic story
22:39:41 <dajobe> ---
22:40:13 <dajobe> em: until I got tools that knew daml+oil, did it dawn to me
what daml+oil was up to
22:40:27 <dajobe> ... workflow for w3c was really interesting with model and
merging, equilvanentTo
22:40:29 <II> II has left channel
22:41:04 <dajobe> phayes: simple stuff in daml+oil has biggest bang-for-buck
22:41:18 <dajobe> ... which is what we find.  Nobody much uses the advanced
22:42:05 <dajobe> emiller giving w3 demo
22:42:45 <dajobe> wg chair visualising
22:43:00 <dajobe> ... object of type 'chair', make it a square ...
22:43:26 <dajobe> .. chairs really don't know the unique ID of WG and don't care
22:43:41 <dajobe> ... but know name and its email address etc
22:44:07 <dajobe> ... tere is no unique ID for wg
22:44:18 <dajobe> ... some may use homepage, email address or charter (danbri)
22:44:23 <dajobe> ... and all of those are OK
22:44:49 <dajobe> ... don't want to impose new requirements, but let them
describe as they see them
22:44:56 <dajobe> ... and ground in what they know
22:45:19 <dajobe> http://www.w3.org/Talks/2001/07/30-swws/slide36-1.html
22:45:30 <dajobe> (url typed by hand)
22:46:04 <dajobe> .. people waned to know announcements by activity eg..
everyting by XML activity 
22:46:04 <dajobe> ... and the WG chairs don't need to add this
22:46:19 <dajobe> ... people who describe activity structure have different
anmes than the chairs do for wgS
22:46:27 <dajobe> ... they can make their descriptions in a different way
22:46:48 <dajobe> ... so long as they agree on the id for the entity, they can
merge (e.g. mail addr)
22:47:08 <dajobe> ... so without the notion of the contact:mailbox as
daml:equilalent we couldn't merge
22:47:20 <dajobe> ... so need daml peroperties to do this
22:47:38 <dajobe> ... interesting to see how processing this info wtih different
levels of tools became a powerful thing
22:47:55 <dajobe> ... and these things can be incremenetly layered.  Int his
case I needed damil:equiv
22:48:00 <dajobe> ... but in other forms, I didn't
22:48:07 <dajobe> (slide 39-1.html)
22:48:35 <dajobe> ... some get merged because of unique ids, some from
daml:equivalent too
22:49:07 <dajobe> ... we can do this by graph merging mostly and sometimes need
22:49:21 <dajobe> ... incrementaly layering functionality
22:49:30 <dajobe> ... greate experience to get hands on the tools for this
22:49:43 <dajobe> ... and sometimes we realise we can weave into the workflow
assigning unique ids for these
22:50:00 <dajobe> ... lwo hanging fruit for daml is uniqueproperty,
damlequivalent, ... (lost 3rd)
22:50:13 <dajobe> ... very powerful
22:50:34 <dajobe> 3rd was daml:unambiguous
22:50:56 <dajobe> --
22:51:12 <dajobe> ora: was mandated in daml program for all participants to use
daml on their pages
22:51:31 <dajobe> ... if you looked at the feature usage, most people just used
rdf schema, very few daml bits
22:51:52 <dajobe> phayes: if you looka t daml+oil working at daml reseacher
22:51:53 <dajobe> ...
22:52:06 <dajobe>  ... they are running into limitations of daml+oil
22:52:17 <dajobe> ... and hence has divergent pulls to simplicity, complexity
22:52:26 <dajobe> danbri: I've run into those concernts, more of a spectrum
22:53:01 <dajobe> ... data merging is critical, before daml I had something
monoproperty.  daml properties don't license all the merging done in em's demo
22:53:10 <dajobe> monoproperty was 'same for all time'
22:53:18 <dajobe> em: rdf notion of layering
22:53:29 <dajobe> ... daml may require more layers, but if done in this way,
remains useful and power
22:53:38 <dajobe> danbri: sw-cg job is to get thesecharters layered
22:53:48 <dajobe> s/charters/components/
22:54:10 <dajobe> phayes: what this community needs is a combination of things
from KR ...
22:54:20 <dajobe> ... GOFK(???) ...
22:54:30 <dajobe> ... some features that are pathetical easy from 1956 or
22:54:39 <dajobe> ... and some things so hard we put them off ...
22:54:49 <dajobe> ... "full temporal sensitivity in changing worlds" ...
22:54:58 <dajobe> ... exciting ...
22:55:07 <dajobe> ... redirecting our attention to problems we put off
22:55:21 <dajobe> ... and can't put off to the next millenium.  Must do now, or
22:55:29 <dajobe> bwm: pat is excited!
22:55:34 <dajobe> ... wrap up
22:55:38 <dajobe> ... thanks to everyone
22:55:45 <dajobe> thanks to brian
22:55:47 <dajobe> * dajobe claps
22:55:54 <dajobe> thanks scribes
22:56:03 <dajobe> more free gifts...
22:56:11 <AaronSw> * AaronSw claps, grabs free gifts
22:56:14 <dajobe> XML schema f- the guide to w3c xml schema
22:56:20 <dajobe> MEETING CLOSED
22:56:25 <dajobe> DONM - months away :-)
22:56:30 <jimH-lurk> jimH-lurk has left channel
22:56:50 <dajobe> AaronSw: will try to grab one for you.  mostly xml.com
articles in a book
22:56:54 <GK-f2f> Yes, done!!!!
22:57:04 <AaronSw> thanks, dajobe
22:57:10 <AaronSw> Good work everyone!
22:57:35 <dajobe> logger here will be closing shortly... over to #rdfig
22:57:39 <GK-f2f> I think the acronym above was GOFAI
22:57:54 <GK-f2f> (Good Old Fashioned AI)
22:58:00 <AaronSw> GOFKR ;-)
22:58:13 <barstow_> barstow_ has left channel
Received on Saturday, 4 August 2001 12:10:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:31:37 UTC