<tomayac> bonjour monsieur!

<tomayac> "the conference is restricted at this time" => have the dial-in details changed? using rdfwg1# code

<FabGandon> should work but we haven't called yet and a number of participants are still missing in the room

<tomayac> 9:30 sharp-ish ;-)

<FabGandon> we will have to do an adhoc teleconf the teleconf chanel is not available for today

<FabGandon> trying again...

<PatH> Same message here

<tomayac> same here

<davidwood> We're working on it - please stand by

<davidwood> We'll announce a new dial in code shortly

<FabGandon> dial 26631

<davidwood> PLEASE USE CONFERENCE CODE 26631

<davidwood> Sorry for the confusion. Our bridge was not configured as we expected.

<NickH> Good Morning!

<OlivierCorby> Hi, phone is ok now

<PatH> Sound quality is rather poor today

<FabGandon> scribe: Fabien

<FabGandon> guus: identifying the 4 issues to be discussed

<Steven> 30, 31, 15

<FabGandon> ... 5 30 31 and 15

<FabGandon> cygri: 31 is a bit out of the list

<mischat> http://www.w3.org/2011/rdf-wg/track/issues/30

<FabGandon> davidwood: suggest we start with issue 30

<FabGandon> ISSUE-30: How does SPARQL's notion of RDF dataset relate our notion of multiple graphs?

<trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added

<mischat> http://www.w3.org/TR/rdf-sparql-query/#rdfDataset <-- sparql dataset as per rdf sparql query 1.0

<FabGandon> Cygri : SPARQL defines Dataset as data data model used in SPARQL query i.e. collection of graph = one default graph and a set of named graphs <IRI,Graph>

<tomayac> AZ: +1, sound is low quality :-(

<mischat> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal

<FabGandon> ... they use the term named graph and it is a g-snap in our terminology because immutable

<pchampin> http://www.w3.org/TR/2009/WD-sparql11-update-20091022/#sec_graphStore

<PatH> +q

<FabGandon> ... graph store :"unlike an RDF dataset, named graphs can be added to or deleted from a graph store"

<FabGandon> ivan: the mutability is on the store not on the graph

<FabGandon> ... are the graphs explicitly immutable ?

<PatH> sound quality is poor but usable

<FabGandon> cygri : the spec are not specific on this ; not really addressed

<FabGandon> ivan: IMO the dataset is a set of g-boxes

<FabGandon> cygri: the evaluation of a SPARQL query is defined against an immutable dataset

<FabGandon> PatH: we shouldn’t be agnostic we should say what the graph is e.g. we should say it is a g-box that has a name

<FabGandon> cygri: SPARQL uses the term named graph, the IRI is the name for the graph in SPARQL

<FabGandon> /me scribe lost

<mischat> PatH: there is no need to introduce confusion

<AZ> We can certainly see a SPARQL dataset as a snapshot of the graph store (the graph store is mutable but the snapshot is fixed to define what's the result of a query)

<FabGandon> PatH: RDF should specify the semantic of names if there is to be an interpretation of that name

<FabGandon> ... if we don't we leave the question open to endless discussions.

<davidwood> +1 to PatH, in that if we define what we mean we won't have misunderstandings as we do with "information resource" or "what *is* RDF".

<JFB> +1 to PatH: if there is some specifing meaning to names, it must be formalized in RDF Semantics

<FabGandon> PatH: we need to declare in a declarative text what the interpretation is for the IRI naming a graph.

<FabGandon> cygri: Can we use the name of doc as the name of graph.

<FabGandon> PatH: we can't prevent that

<Zakim> davidwood, you wanted to discuss graph store relationships to g-boxes and g-snaps.

<FabGandon> davidwood: several graph stores are maintainers of g-boxes implemented as multiple reader single writer

<FabGandon> ... when a query comes in they generate sets of g-snaps from the current state of the g-boxes.

<FabGandon> SteveH: yes that's what happens.

<PatH> we have yet to specify what a g-box is semantically. We will have to speak of states and g-snaps there.

<FabGandon> davidwood: SPARQL queries are dealing with a sub-set of our world.

<PatH> in otherr words, this box/snap issue will have to be dealt with there in any case.

<sandro> guus: When you do a SPARQL Query, you are querying at a point in time, so you are querying against the set of g-snaps which is the current contents of those g-boxes.

<FabGandon> Guus: at that point there is no conflict between our view and SPARQL

<davidwood> PatH: Yes

<davidwood> Yes, there is no conflict.

<PatH> who is speaking?

<PatH> ta

<sandro> pchampin: I want to be able to use my own arbitrary data as the "graph" name in SPARQL.

<FabGandon> pchampin: I feel uncomfortable with fixing the semantics of the relation name of graphs  and the store ; it depends on my use of the quadstore

<FabGandon> cygri: I don’t see this machinery as answering a large demand ; I don’t feel there is a huge demand on fixing that semantics

<PatH> +q

<FabGandon> ... what do we gain from defining the interpretation of named graphs ?

<pchampin> sometimes, I name a graph in my quad store with the URI of the g-box this graph comes from,

<pchampin> sometimes, I name it with the URI of the resource it is about

<FabGandon> danbri: are tou confortable with the level of interoperability that would set?

<sandro> +1 danbri we need more interop between datastores (there is breakage when people use different styles of URIs)

<pfps> I don't know how the RDF semantics is going to speak to things like timestamping downloads of RDF documents.

<FabGandon> PatH: defining the semantics will not have so much implication on the implementation that seems to be feared. The idea is not to interfere with the machinery.

<danbri> it's something like a lack of mechanism for saying how *my* sparql store is managed. One might use 'the URI I fetched = the graph URI', another uses a uuid: per-transaction, and a table-of-contents history graph. Sure I can send SPARQL queries across both at same time, but the results might be barely meaningful.

<FabGandon> sandro: the machinery will complain for instance if I use the URI of a graph to identify a person and these classes are disjoint.

<danbri> PatH, the triples could have semantics, but their bundling and tagging with graph URIs could lack semantics

<FabGandon> SteveH: there are many use cases where we don't want to do some logical inference on top of RDF.

<pchampin> +1 danbri: I write no *triple* stating that a person is a graph :-)

<sandro> Pat: It violates the semantics of the language to have the name of a graph also be the name of a person.

<FabGandon> cygri: How does the fact of using a URI for a graph and a person raises a problem in SPARQL?

<AZ> A name can name several things, like in OWL 2 DL, a name can name a class and a property

<pgroth> could we do both? a name and a tag?

<AZ> and classes are disjoint from properties in OWL 2 DL

<FabGandon> PatH: lets not call it the names then.

<sandro> +1 pat

<FabGandon> pfps: RDF is agnostic as to the use of the same IRI to name a graph or a person.

<Zakim> pchampin, you wanted to talk about named graphs in SPARQL endpoints

<sandro> pchampin: I'm using the "graph id" as merely a "tag"

<FabGandon> pchampin: ok to say it’s not really a name but merely a tag.

<sandro> +100000 the world here would be MUCH CLEARER if SPARQL forced you to only use graph IDs that you own!!

sandro -100000

<Zakim> sandro, you wanted to return to danbri's question

<pfps> sandro - so you think that you shouldn't use "anyone else's" IRIs in a named graph?

<FabGandon> sandro: I wish SPARQL restricted you to use only URIs that you own i.e. use graphs in a domain you control

<danbri> sandro, that feels to me like having the SQL spec specify that you can only store things that are true

<pchampin> I sure was not suggesting to restrict SPARQL... :-/

<pchampin> just pointing out that its flexibility allows for different practices... beyong "naming according to Pat"

<FabGandon> cygri: strong use case again that : when you crawl the web you want to use the URI from where you got the data.

<Zakim> cygri, you wanted to disagree with sandro -- web crawling use case

<FabGandon> sandro: it may be more efficient but you create interoperability problems.

<sandro> Utility is at odds with Interoperability.

<PatH> hard to hear..

<sandro> Local utility vs Global utility.

<yvesr> another use case is ACL on quad stores

<FabGandon> pchampin: not suggesting restricting what SPARQL allows to do ; just advocating flexibility.

<FabGandon> pgroth: I wonder if we don't need a typing mechanism.

<sandro> pgroth: There's "naming graph" and there's graph tags.

<Zakim> cygri, you wanted to talk about n3

<FabGandon> cygri: if you want a graph associated with a URI in N3 you need to put a predicate in-between.

<danbri> q: is this OK SPARQL? http://pastebin.com/raw.php?i=TaJVsste

<FabGandon> ... there is something in the middle that indicates the relation, don't restrict that because in SPARQL it is not restricted.

<yvesr> danbri, i guess it would - why wouldn't it?

<FabGandon> pfps: in RDF everything is a resources: a graph must be an resource or not ; how can we disconnect graph from that if we name them with IRI?

<FabGandon> Guus: we need to identify the things we do agree on.

<Zakim> danbri, you wanted to try http://pastebin.com/raw.php?i=TaJVsste

<PatH> sounds like a sparql RDF dataset is not a collection of named graphs. Which surprises me, but I can live with.

<FabGandon> danbri: I want to talk about this test case http://pastebin.com/raw.php?i=TaJVsste

<FabGandon> ... this is a SPARQL query querying different databases.

<FabGandon> ... can we name graphs with mailto:bla@bla.bla

<PatH> but see what pat just wrote.

<PatH> +q

<FabGandon> yes we can

<FabGandon> davidwood: some people say we should always use http://

<FabGandon> danbri: there is a drift from using http:// URIs

<FabGandon> SteveH: I don't see anything wrong with that.

<sandro> sandro: This is just neats vs scruffies --- the graph might be a (scruffy) tag, or might be a name of a proper RDF graph.

<FabGandon> danbri: what about the provenance perspective?

<pfps> well, a SPARQL RDF dataset is defined as potentially containing "named graphs" as this is the first (as far as I know) W3C mention of "named graph", then SPARQL wins and SPARQL RDF datasets have named graphs

<pfps> the upshot of this is that the RDF WG may need a new name for what we have been calling named graphs

<FabGandon> pgroth: we care about pointing at a resource or at a graph talking about a resource.

<FabGandon> ... we need to be able to point at the content.

<PatH> pfps, suggest rather we keep named graphs but allow datasets to be something else.

<danbri> so my example lets me represent the (likely derrived from other stuff) info that Pat says Guus is the name of the holder of his homepage

<pfps> then we need to quickly get SPARQL not to "use up" this name - oops too late, named graphs is already in SPARQL 1.0

<pgroth> i like the idea of a default interpretation

<FabGandon> pchampin: graphs are resources they need naming and not necessarily a named attached to a SPARQL endpoint.

<pgroth> that the iri is the name of the graph

<FabGandon> pfps: do RDF graphs have to be resources ?

<danbri> http://www.w3.org/TR/rdf-mt/#gloss ''Resource (n.)(as used in RDF)(i) An entity; anything in the universe. (ii) As a class name: the class of everything; the most inclusive category possible.''

<PatH> aaaargh. what are 'levels'????

<FabGandon> cygri: graphs are in the abstract syntax; resources are in the model theory

<FabGandon> pchampin: graphs are resources

<sandro> pfps: We have A and Not-A (where A=Graphs must be Resources)

<sandro> pat: Of COURSE graphs are resources. The model theory clearly says everything is a resource.

<JFB> +1 everything is a resource, if I am, why wouldn't a graph be ?

<FabGandon> PatH: there are no such notions of levels ; thats not the pb.

<pchampin> +1

<sandro> pat: We could say that SPARQL Datasets are about tagged graphs NOT naming.

<SteveH> +1

<sandro> +1 pat

<mischat> +1

<danbri> +1

<yvesr> +1

<FabGandon> ... if we say we tag graphs and not we name then we can stop arguing

<AZ> But then, how one talks about a graph in triples?

<FabGandon> davidwood: I need a clarification on the difference between the name and a tag.

<Zakim> SteveH, you wanted to talk about <uri> :relation <graph>

<FabGandon> PatH: the difference is in the relation, tag is neutral.

<danbri> 'bundles'

<pgroth> why can't we have a default interpretation

<pgroth> ?

<sandro> possible consensus: SPARQL "named graphs" are not "named" in the logical sense.

+1 ivan

<danbri> pgroth, because there are multiple equally respectable default db management habits

<gavinc> FROM NAMED

<sandro> :'(''

<FabGandon> ivan: we don't have much choice, the term "named graph" is already used in the whole SPARQL community.

<pgroth> danbri, but default doesn't mean you have to

<sandro> sandro: Can we at least tell people this is a misleading name?

<SteveH> +1

<PatH> potentially misleading

<danbri> From a SPARQL perspective, it is legitimate to (a) tag graph-bundles with URI the triples were dereferenced from (b) to tag graph-bundles with URI for the party who made the claim (c) or a trasaction ID, eg. uuid:

<sandro> More Consensus: SPARQL "named graphs" are not necessarily "named" in the logical sense, or RDF graphs.

<sandro> * FabGandon we have "tagged boxes" and we will call them "named graphs"

<Zakim> danbri, you wanted to suggest [eventual] best practice note on how *in practice* people are associating URIs with bundles-of-triples

<PatH> can we introduce the terminology of "sparql naming"

<FabGandon> danbri: may be we should first document the current uses of "named graphs"

<yvesr> +1

<sandro> +1 danbri: document the common practices for using sparql graphs names.

<PatH> I dont want to start policing sparql usage.

<FabGandon> ... I have three in mind but may be we should have a wiki page to collect them

<davidwood> No, we certainly don't

<danbri> path --- absolutely not policing, but documenting

<yvesr> PatH, not policing, surevying what's actually happening

<PatH> just keep terminology clean

<PatH> OK

<danbri> -- so we can send SPARQL queries that use GRAPH to services managed in a certain fashion

<FabGandon> pchampin: NQuads is used to dump a full store

<danbri> eg. see http://pastebin.com/TaJVsste ... maybe you have a DB I could usefully send that query to; but maybe Ivan's SPARQL db is managed with a different GRAPH/URI policy

<danbri> ...so naming those deployment patterns

<mischat> i do think that best practices for linked data re: graphs and named graphs

<Zakim> davidwood, you wanted to as about naming of RDF

<FabGandon> ivan: NQuad is juts syntax

<Zakim> pchampin, you wanted to raise some concern about the semantics of NQuads, then

<danbri> FDR!

<FabGandon> davidwood: concerned about redefining everything.

<FabGandon> sandro: SPARQL named graphs has little to do with named g-boxes.

<Zakim> mischat, you wanted to ask about the difference in FROM NAMED and the GRAPH URI

<FabGandon> Guss: SPARQL is agnostic about.

<FabGandon> mischat: It is nice that SPARQL doesn’t force you to use the URL of the doc for the named graph.

<sandro> steve: FROM NAMED pulls a graph from some undefined place and puts it in the set of named graphs, but... [lost]

<FabGandon> SteveH: the exact behavior of the default graph changes from store to store.

+1 mischat

<yvesr> +1

<danbri> yup

<FabGandon> mischat: the best practices could be in a note and not in rec.

<FabGandon> davidwood: we don't want to get in the way of LOD

<FabGandon> ivan: too early to phrase it as a resolution ?

<sandro> PROPOSED: Close ISSUE-30 saying that SPARQL Datasets and Named Graphs have no strict or formal connection to a logic of RDF "naming" of Graphs.

<pfps> PROPOSED the upcoming notion of multiple graphs is not necessarily the same as named graphs in SPARQL

<danbri> perhaps - SPARQL quads are not the kinds of thing that can be interpreted as True vs False; RDF WG quads might or might not add more...

<PatH> suggest that the key point is that just because sparql uses a uri to, um, identify a graph, it does not mean that the uri can be used to refer to the graph in an rdf triple.

<FabGandon> ivan: we currently have no formal connection between the name and the graph in RDF

<danbri> ie. we can ask if the triple "uri-for-guus :homepage http://www.cs.vu.nl/~guus/" is true or not; but we can't yet ask if the quad "{uri-for-graph} uri-for-guus :homepage http://www.cs.vu.nl/~guus/" is true or false

<AZ> PatH +1

<danbri> (path, +1 to what?)

<FabGandon> Guus: who agrees with PatH ?

<AZ> +1

<FabGandon> PatH: you can use the URI but there is no guaranty that it refers to the graph.

<sandro> sandro: Pat means "refer" in a model theory sense, not a computer science sense.

<gavinc> So what does: SELECT ?s WHERE {GRAPH ?s { ?s ?p ?o }} end up meaning in this case?

<FabGandon> yvesr: we don't know what a multiple graph is and therefore can we talk about it in a resolution?

<FabGandon> ivan: when we have clarified notions then we can come back to that question.

<yvesr> we can't resolve an issue where half of the question is still undefined

<PatH> i like 'thruth'

<FabGandon> ... the issue should be postponed.

<danbri> quadly thruthyness

<PatH> :-)

<FabGandon> Guus: we can close that issue and open and more precise one.

<zwu2> Sandro, I got "conference restricted at this time" from zakim

<JFB> +1 for semantics of a predicate that would capture SPARQL's behaviour, but we're not ready yet for that

<yvesr> issue-30 might be dependent on issue-15

<zwu2> thanks

<sandro> sorry, zwu2 we had to use a different code.

<FabGandon> pchampin: this question is linked to issue 15 http://www.w3.org/2011/rdf-wg/track/issues/15

<sandro> issue-15?

<trackbot> ISSUE-15 -- What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc -- open

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/15

<mischat> again, you could have a best practices document stating how you can use named graphs in a quad store in a truthy way, but neither rdf nor sparql mandates this, but it would be a good thing for quad store/linked data interoperability -- would be a good note for a primer

<FabGandon> Guus: 30 is about alignment with SPARQL and 15 is about our internal changes to RDF.

<FabGandon> ... in solving issue 15 we should not conflict with SPARQL.

<PatH> yes, fine

<PatH> yes,

<PatH> sorry cant unmute but agree with what you are saying

<FabGandon> Guus: we should remove dataset from issue 15 this is addressed in issue 30

<sandro> PROPOSED: ISSUE-15 is about our internal notions of multiple graphs, while ISSUE-30 is about how that related to SPARQL's notion. We do not expect the association of IRIs and graphs in SPARQL datasets to be RDF's identification/reference relationship.

<FabGandon> davidwood: etc. is not precise enough , issue 15 should be rephrased properly

<danbri> proposed: "While it is attractive to seek more clarity on relationship between some graph of triples and URIs they're tagged with, ... we note that SPARQL deployments have assigned URIs in a variety of ways, each of which being useful and compliant. There may be value in documenting these deployment styles (e.g. URIs for docs, abstract graphs, human sources or transaction IDs) so that SPARQL stores and serializations of URI-tagged triples can b

<danbri> e made more richly interoperable."

<FabGandon> Guus: we should start with defining our own terminology before aligning with SPARQL.

proposed: "Named Graphs in SPARQL “loosely associate” IRIs and graphs. They do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."

<FabGandon> ISSUE-30: cygri proposes "Named Graphs in SPARQL “loosely associate” IRIs and graphs. They do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."

<trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added

<danbri> i tried ' each of which being useful and compliant' instead of 'loosly' (above)

<sandro> "are simple associations"

<AZ> Maybe: "Named Graphs in SPARQL associate IRIs and graphs *but* they do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."

<FabGandon> PatH: don't like the word "loosely" prefer : temporary

<sandro> PROPOSED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not necessarily establish graphs as referents of IRIs

<AZ> I would not put the necessarily there

<mischat> SteveH: sparql uses the verb "graph" to talk about arbitrary graphs and the "named graphs" for graphs which which can be fetched via http, or is that just my pov?

<sandro> PROPOSED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily "name" graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs

<sandro> +1

<pfps> +1

+1 sandro

<AZ> +1

<mbrunati> +1

<pchampin> +1

<davidwood> +1

<cmatheus> +1

<yvesr> +1

<danbri> +1

<zwu2> +0

<NickH> +1

<SteveH> +1

<mischat> +1

<mischat> any objections for this being added as a note to issue-30 ?

<FabGandon> ISSUE-30: Proposed WG position : Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs.

<trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added

<sandro> RESOLVED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily "name" graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs (relevant to ISSUE-30)

ISSUE-15?

<trackbot> ISSUE-15 -- What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc -- open

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/15

<PatH> +1 also my vote

<FabGandon> davidwood: moving to ISSUE 15 ; let's try to rephrase it.

<AZ> AZ: isn't it implicitly asking "how" one can associate a URI to a g-* ?

<PatH> propose, uri always refers to g-box, but some boxes are immutable.

<pgroth> agree with pat

<FabGandon> sandro: g-boxes, g-snap, g-text could be named

<PatH> because a snap is always a state (of a box) rather than a resource uin its own right.

<FabGandon> ivan: can we have a predicate to say this IRI identifies this g-box ?

<pgroth> although i need to refer to a g-snap

<pchampin> PatH: can't a number have a URI ??

<FabGandon> pgroth: would that prevent you to refer to a particular state of a box ?

<PatH> dont think it can be done just using a predicate unless we endow that predicate with spoecial semantic force.

<danbri> (around foaf/webid/foaf+ssl and so on, we'll start seeing people identifying concrete sets of well known triples by hash of their encoding, eg. the triples W3C served for the RDF ns for the last 5 years)

<FabGandon> ivan: the snap vs. box is exactly about mutability

<pchampin> PatH??: <someuri> owl:sameas 42

<PatH> sure, that is ok, but states are transient.

<FabGandon> davidwood: if a g-box is a resource than we can talk about it.

<FabGandon> pgroth: so what is a snap then if not an immutable box ?

<FabGandon> sandro: another difference is equality.

<gavinc> The NAME is not part of the g-snap

<danbri> sandro, does that work ok w/ bnodes? do we have samegraphness defined adequately for graphs w/ bnodes?

<FabGandon> davidwood: two g-snaps may have the same content and still be different snaps.

<FabGandon> ... we haven't decided on that yet.

<sandro> danbri, yes, but you also have to allow bnodes to be shared between graphs.

<FabGandon> ... it depends on how we resolve issue 15

<gavinc> ... I don't think g-snaps had names?

<PatH> stephen, two anythings cannot be equal.

<Zakim> sandro, you wanted to say the difference

<danbri> (sandro, eg. if there is an rdf/xml file bundled with Jena that is packaged old version of DC schema; and the similar-but-different triples we get from a DCMI namespace URI fetch ... )

<FabGandon> PatH: The guiding abstraction should be the REST model

<FabGandon> davidwood: reprensentations are not resources by default

<sandro> it's the g-text that's the representation, not the g-snap.

<FabGandon> sandro: the representation is the g-text, a string

<danbri> PatH, does "is not a resource" there mean "not a Web/http resource" rather than "is not a resource-considered-as-synonym-for-thing"?

<danbri> (if you can channel for timbl...)

<FabGandon> pchampin: the g-snap is the state of the resource

<yvesr> g-box - resource ; g-snap - state ; g-text : representation

<pgroth> g-box = resource, g-snap = content negotiation, g-text = state serlization

<PatH> sorry, sandro is right. but the snap is an abstraction/parsing of the text.

<mischat> g-snap is information resource at time T ?

<PatH> and so is similarly unidentifiable.

<JFB> g-snap: state of the resource or state of the representation ?

<PatH> yes, sandro is right.

<yvesr> pgroth, i don't agree - g-snap != content-negotiation

<pchampin> @JFB: state of the resource

<FabGandon> cygri: you can't talk about the representation.

<PatH> danbri, i want those to be the same sense of resource

<FabGandon> davidwood: a representation is not a resource but with an additional step you can choose to make an identifier for that representation and talk about it.

<pchampin> data: URIs ?

<pchampin> I mean "data colon URIs"

<Zakim> SteveH, you wanted to ask Sandro about why two g-boxes can't be equal [unless I got the wrong end of the stick]

<PatH> pat is drinking tea at 4.25 am

<sandro> sandro: Two g-boxes remain distinct even though their contents/state might happen to be the same at some point in time.

<PatH> sandro, sorry to introduce extra confusion.

<PatH> +1 to pfps

<FabGandon> pfps: We could say we don’t change the semantics, Quads are syntax

<mischat> i like the idea that RDF semantics not changing, and using quads as syntax, +1 to pfps

<PatH> i think there are now also quints, sexts, etc..

<danbri> I can't understand how the same meeting can, 30 mins ago, accept resources=all things in the universe, yet 5 mins ago, deny that the stuff you get back from an HTTP request is a resource. Ug.

<sandro> pchampin, you're right, I think, that data: URIs give us identifiers for representations / g-texts.

<danbri> (even without handy URIs they're still things and thearfore Resources in rdfsemantics sense)

<FabGandon> ... RDF semantics defines the meaning of the underlying data structure but not augmented with a semantics for datasets.

<pchampin> a+

<sandro> danbri, we didn't agree with that -- it was just claimed and ignored. :-)

<pfps> so, after all the stuff that I said, I still remain agnostic as to which direction to go

<FabGandon> ivan: if we have predicates to link IRI and g-* we need to define them in the RDF semantics

<PatH> yes, we do. so the semantics will have to deal with the *-ideas.

<PatH> yes: exactly.

<FabGandon> pfps: if you want to talk about this inside the RDF voc you have to define it in the RDF semantics indeed.

<PatH> +1

<pfps> from an OWL perspective, the "don't change the semantics view" is very seductive

<SteveH> also from the DB implementors view

<PatH> extend does not imply change, hoever.

<sandro> ISSUE: Should there be an rdf:Graph construct, or something like that?

<trackbot> Created ISSUE-35 - Should there be an rdf:Graph construct, or something like that? ; please complete additional details at http://www.w3.org/2011/rdf-wg/track/issues/35/edit .

<FabGandon> Guus: should there be an rdf:Graph primitive ?

<sandro> (from Guus and David -- I don't understand the question.)

<PatH> +q

<Zakim> sandro, you wanted to talk about use cases

<FabGandon> pfps: if g-boxes just want to have fun they need to be in the semantics.

<FabGandon> sandro: one of the scenarios is "annotating graphs" e.g. be able to select a part of graph state things about it.

<davidwood> THE QUEUE IS CLOSED FOR THIS SESSION

<FabGandon> pchampin: we need a vocabulary for the g-* e.g. just to be about to talk about them when we load them.

<FabGandon> PatH: if the notion of g-box is important then the semantics has to clarify that notion it does need to be a revolution.

<pfps> perhaps, but by this same argument, the semantics should specify what happens when you go an HTTP get on a URL

<mischat> i am not sure about the adoption rate of '<> rdf:type rdf:Statement.' , do people even ever use them ...

<PatH> not that bad, peter...

<sandro> PROPOSED: We aligned g-* with REST, where g-box=information resource, g-snap=state of the resource, g-text=representation of the state of the resource

<FabGandon> cygri: documenting the alignment with REST may be useful for us but not in the deliverables ; it is too complex and time-consuming.

<pchampin> PatH: re what Fabien scribed, shouldn't it be "does NOT need" ?

<PatH> disagree with fabgandon

<FabGandon> ivan: would lead to endless discussions.

<sandro> PROPOSED: We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource, g-text=representation of the state of the resource

<pchampin> NB: a predicate would not state the relation between a URI and a graph, but between a resource (identified by a URI) and a graph

<FabGandon> my mistake s/ clarify that notion it does need to be a revolution/ clarify that notion it does not need to be a revolution/

<PatH> i think wewill be doing the world a disservice if we leave ambiguity and confusion. That is what the last RDF WG did, but there is a decade of practice now to guide us.

<mischat> sandro, perhaps s/state of the resource/state of the resource at time t/

<pfps> do we have a failrly coherent document that describes REST?

<sandro> PROPOSED: We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource (at time t), g-text=representation of the state of the resource (at time t)

<sandro> +1

<pfps> NB: I do understand that coherency is rather absent in the REST universe.

<davidwood> +1

<SteveH> +1

<gavinc> +1

<PatH> +1

<zwu2> +1

<danbri> -1

<AZ> +1

<JFB> +1

<AZ> zakim voted against me!

<mbrunati> +1

<ivan> 0

<sandro> (clarify -- this is only for the subset of IRs that can be respresented in RDF.)

<pfps> +.5 as I'm not exactly sure just what REST is

<JFB> @AZ yes, found that surprising

<PatH> az, that will teach you to make lumpy custard.

<NickH> +1 (but agree that REST isn't very well specified)

<yvesr> +1

<FabGandon> danbri: some environments don’t have a notion of REST.

<pchampin> -1

<FabGandon> Guus: we are only considering the notions behind REST.

<danbri> REST is good, but it doesn't seem a 1:1 relationship to me

<sandro> pchampin, my concern is that we might be missing some more complicated resources whose state is not represented by a graph, because it's not just time.

<SteveH> +1 to danbri, but I don't think it detracts from the analogy

<PatH> seems to me that if its not related to restthen I dont know why we even have these distinctions ourselves.

<pchampin> e.g. authentication, etc

<SteveH> pchampin, right, or cookies for e.g.

good point pchampin. language negotiation etc

<danbri> maybe i'm pulling Web-derrived data from a local Lucene store; from Mahout clustering, or prolog, doing stuff in code and stuffing bits into graphs with URI tags. REST is in the environment but the data flow is much more complex than fetch'n'store

<pchampin> yes, this too

<sandro> guus: two groups; (1) json, (2) skolemization

<tomayac> json += tomayac

<PatH> will skolem have a phone link?

<FabGandon> ISSUE-15: Text to be further discussed : "We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource (at time t), g-text=representation of the state of the resource (at time t)"

<trackbot> ISSUE-15 What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc notes added

<danbri> SteveH, sure, considered as an analogy it can be instructive (and in fact I'm trying to extend REST concepts a bit more into XMPP message types)

<AZ> if there is a phone link then I'll join the skolem

<pfps> skolem will be here - same phone - restart in 15 min

<PatH> skolem for me if possible.

<PatH> OK.

<JFB> @AZ same room for DSkolem, so same phone should work

<FabGandon> PatH, yes skolem stays in this room

skolemization (whatever that is!)

<tomayac> is there a dial-in no. for json?

<pfps> no dialin for json yet

<pfps> and there won't be one

<sandro> no dialin for json ever, sorry.

<mischat> tomayac: do you want to be dialled in ?

<yvesr> scribe: yvesr

<danbri> so - what are we skolemising and why?

<mischat> do JSON people want to call in

Skolemization Breakout

<pgroth> the skolemization has taken over this chat room

<pfps> The problem, as I see it, is that RDF stores hold blank nodes, but they have problems sending identifiers for these blank nodes out in response to queries and getting them back.

<mischat> yeah we are about to set up a voice thing

<mischat> i sec

SteveH: long-standing issue in the way bnodes are defined
... close-enough to existential variables in rdf
... most implementations turn it into an internal identifier

<sandro> SteveH: I have a longstanding issue who how bnodes are defined, as existential variables. But the reality is that all the triplestores turn it into an internal identifier.

SteveH: turning them into 'skolems'

<cygri> (JSON breakout is happening over in the #rdf-json channel)

<sandro> pfps: So far, they havent' done anything wrong.

SteveH: 2 problems - 1) bnodes in the wild (when there shouldn't be) and 2) people deliberately writing them (i.e. FOAF)

<PatH> there is also a strong deprtecation of bnode use in the linked data community.

<sandro> SteveH: But sometimes you encounter bnodes in the wild, where it would be nice to have URIs, as in foaf. In practice it's annoying.

SteveH: in FOAF, you end up using inverse functional properties to identify individuals
... People are missing a feature from relational databases (not assigning an explicit primary key)
... some triple stores have internal uri schems to talk about bnodes

<sandro> SteveH: Folks also have internal URI schemes for talking about bnodes. People really want this for SPARQL round-tripping.

<Zakim> danbri, you wanted to account for the foaf case

SteveH: those can surface in query results - and can be used in queries

danbri: There's a reason for the FOAF choice - leading to anonymous resources
... no owl:sameAs, not clear what to do with resources
... identifying people with properties was a pragmatic decision

davidwood: how would you do it today?

danbri: if you were in a position to assign uris for other people, then FOAF would have gone for URIs
... bnodes are a pain to deal with...

<Zakim> sandro, you wanted to present proposal

<sandro> steve: The assigned URIs leak out of query interface, which is what makes them useful.

<danbri> original statement of the foafy smushing stuff: http://lists.xml.org/archives/xml-dev/200012/msg00597.html

sandro: Long discussion on the semantic-web list a couple of weeks ago - a proposal was done that adress everyone's requeirements
... pick one of two uri pattern choices to skolemize bnodes
... http://... if you want to dereference, or tag:...
... if you encounter one of those uris, it's machine generated
... those uris can be considered as disposable

<danbri> so the first dozen or so FOAF files used genid: as a URI scheme, eg. http://svn.foaf-project.org/foaftown/2010/allfactoids/copies/danbri/danbri-foaf.rdf ... about="genid:poulter" etc

<FabGandon> yvesr: how do you know they are machine generated?

<PatH> it is always valid to 'deskolemize', so we dont need to say anything about that.

<FabGandon> StevenH: because they have genid

danbri: reserved uri pattern - genid in the uri means that it is machine generated

<sandro> 1. If you're going to Skolemize, use a URI like this:

<sandro> - http://example.org/.well-known/genid/[whatever]

<sandro> - tag:example.org,2011/.well-known/genid/[whatever]

<sandro> 2. If you encounter one of these URIs:

<sandro> - you know it's machine generated

<sandro> - consider it more disposable, more mergeable

<PatH> +1 to speaker. genid is better.

<gavinc> eg: generate-id() in XPath/XSLT

<sandro> We mean LITERALLY the string "genid".

SteveH: Prefers genid over bnodes

<PatH> s/speaker/stevenh

SteveH: you might want to use "genids" to identify graphs

<davidwood> ?

sandro: Use "genid" or "gensym"?

<Zakim> pfps, you wanted to say that such RDF stores aren't really doing anything 'wrong'

JFB: bnodes are stronger - they can never be used in another graph

SteveH: this is already dropped in sparql-update

pfps: Technically, it is not a valid entailment

<danbri> related prev discussion: sergey melnik tried to create a canonical URIs for bnode/anon resources - http://lists.w3.org/Archives/Public/www-rdf-interest/1999Dec/0046.html

<sandro> pfps: As long as these are fresh, you wont get any incorrect inferences.

pfps: SPARQL-update validates the leaky bnodes, what this proposal says is that graph stores are able to make that transformation

<sandro> pfps: This says an RDF store is entitled to change bnodes like this.

<sandro> pfps: "RDF graphs stores can, on their own recognisance, do this transformation"

PatH: the fact that such uris can leak out is a good thing
... We don't have to worry about leakage

<zwu2> cannot hear much

<PatH> sound is very patchy.

<PatH> better

<Zakim> davidwood, you wanted to mention the use of made-up ids as a pattern to replace bnodes

yvesr: RDFa creates lots of bnodes in the wild
... and sometimes there are things that you can't identify, or don't want to mint a URI for (e.g. transient things)

<danbri> ivan, in your homepage you have <div id="container" about="http://www.ivan-herman.net/foaf#me" typeof="foaf:Person dc:Agent"> .... that's the verbose aspect. But maybe you could use a relative URI at least?

davidwood: I don't think there is soemthing wrong with bnodes, and it's fine to skolemize them

s/soemthing/something/

davidwood: Machines should do the job, transparently

SteveH: what you want is a bnode syntax, not a bnode semantics

ivan: I can understand that a number of people would want to derefence these things

<PatH> sandro, type it.

ivan: what happens when you derefence them?

<sandro> PROPOSAL: It's okay for systems to Skolemize bnodes, replacing them with IRIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. Must be reg'd with IETF.

ivan: what advice do you give, and how are people to set it up?
... the first uri pattern is an http:// uri, and needs to be dereferencable - what does it do?

<PatH> should be fine for these to give 404s.

<davidwood> SteveH: Yes, I want the usefulness of bnode semantics with a simple, automated bnode syntax assistance.

ivan: do we want to get this reflected in various syntaxes?

SteveH: what we would do in 4store would be to generate bnode skolems based on a prefix
... prefix is defined in configuration
... accessible as any other identifier in the store

ivan: you're using your SPARQL engine as a tool - the W3C needs to provide a global mechanism for what happens when you derefence a http://...genid... uri

<PatH> sandro, if these are supposed to refer to non-information resources, then according to http-range-14, they ought to give a 303 redirect. Can they have a # ending to remove this requirement?

ivan: Linked Data people don't want to have bnodes in their graph

pfps: there's no way to make them happy

ivan: there is a way to set up a simple service somewhere that would do the job

<sandro> PatH, how about if it's http[s]://[domain]/.well-known/genid/[locally-uniq-id]#

<PatH> fine with me, as long as doesnt require a 303 mechanism

SteveH: if you dereference a bnode, one thing you could do is to just say 'this is a bnode'

<Zakim> sandro, you wanted to draft proposal

<sandro> PROPOSAL: It's okay for systems to Skolemize bnodes, replacing them with IRIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id]# or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. Must be reg'd with IETF.

sandro: the hash is to stay clear of httpRange-14

<gavinc> Annoyed but not strong/formal objection to using tag: --0?

sandro:

<PatH> +1 danbri, should not presume a service of any kind.

SteveH: i can think of lots of reasons not to do that

<sandro> gavinc, why does the tag bother you? what would you prefer?

davidwood: uri lookups cost time and money

<gavinc> tag was designed specificly for HUMAN generated uniqueness

<danbri> (re bit.ly / tinyurl analogy, ... it's taking us a month of HTTP requests to bit.ly to expand otherwise mysterious shortlinks from a twitter crawl, ... they only allow 2 lookups / second ... single points of control worrying)

<pchampin> shouldn't we add "fresh IRI" in Sandro's proposal?

<sandro> yvesr: I don't like Skolem ids leaking out.

<danbri> LOD community have established the convention than any party can invent HTTP URIs freely, for anything and anyone; so why not just generate LOD URIs or uuid: URIs? I don't see this proposal adding value to those options

<FabGandon> WRT the service approach, beyond the risk of single point of failure it is a point of centralization in the model and in general centralization is not good for web arch IMHO

<PatH> all specifically RDF uses dont require dereferencing. Seems like main purpose of these being recognizable is to AVOID dereferencing them.

<sandro> sandro: Maybe "*if* you're going to skolemize, you SHOULD use one of these two forms"

<PatH> disagree. should be free to skolemize any way you like, as long as it is 'frtesh'

gavinc: seems very wrong to use tag uris

<PatH> fresh

gavinc: is UUID terrible?

SteveH: minting a new UUID for all bnodes is not very affordable

gavinc: we got rid of all bnodes at o'reilly because of that

<davidwood> Sandro thinks yes, UUIDs doesn't allow you to use genie

<davidwood> s/genie/genid/

ivan: is it true that the tag: scheme says 'it is for humans'?

gavinc: the generation mechanism needs to happen by humans

<Zakim> davidwood, you wanted to discuss broadness of skolemization (stores, validation, services, etc)

davidwood: There is opportunity to use skolemisation in quite a lot of places, not only in stores
... input, output, validation process, skolemization services

<sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they SHOULD use URIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id]# or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.

davidwood: if you're doing skolemization, you SHOULD do it in the way we're defining

<Zakim> danbri, you wanted to express risk of single point of failure / keeping a bnode-description-service secure is nontrivial, costly work

<PatH> prposal. it is permissible to replace bnodes by URIs provided that the URIs are 'fresh', ie not used in any other rdf graph. It is recommended to include a string /genid/. one way is sandro's prposal.

ivan: Would that effect any of the syntaxes, and how?

SteveH: it wouldn't

<danbri> I defer; question withdrawn

SteveH: it wouldn't be the parser's job to do it
... it doesn't have enough information

ivan: for RDFa, it would make sense - and it might make sense for Turtle files too
... many people use the square brackets - lazyness

<danbri> ( I assume args for the skolem function is not just the textual input, but also the base URI...)

ivan: i should be able to tell the parser to mint me some URIs for those

<sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they SHOULD use fresh URIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.

<davidwood> +1 to PatH's proposal

SteveH: reverse transformation - output documents *with* bnodes

<mischat_> Webr3 about?

zwu2: if you have one triple in a store, :john :friendOf _:a

<PatH> steveh, it is always valid to 'deskolemize' with bnodes.

zwu2: you would get back a skolemized bnode

<mischat_> webr3, if you are about join #rdf-json

zwu2: if we're using that skolemized bnode as a query

are we supposed to return :john or not?

zwu2: are we supposed to return :john or not?

SteveH: yes

<PatH> yes. once it is a uri, you can do this.

davidwood: if identifiers leak out to the outside world, it maintains validity

ivan: if i use the bnode filter operation in a SPARQL query, what happens?
... does it match the skolemized bnode?

SteveH: that's an issue for us
... we need to define if they count as bnodes or not

ivan: as a user, who doesn't understand this stuff, i would expect the bnode function to work

SteveH: in 4store, it would answer true
... it only gets skolemized on the export
... internal consistency

<Zakim> pchampin, you wanted to talk about the fresh URIs and them leaking from the store

pchampin: We shoudl specify what is ok for the system to do

<PatH> az, no problem

pchampin: We should specify what the system would return

<SteveH> AZ, that wouldn't be legal RDF syntax, though you could write it by hand

<davidwood> PatH, can you please resend your proposal?

pfps: Troubles finding the SPARQL bnode definition

<danbri> pat hayes

<SteveH> http://www.w3.org/TR/rdf-sparql-query/#func-isBlank

<SteveH> ...the BNODE() function actually mints bNodes

PatH: genid SHOULD be in the URI but not absolutely required

<SteveH> but I think it was understood what was being discussed

PatH: it should be possible for people to invent URIs and use them
... they could use software to do that automatically
... We should not allow skolems that are specific to a single query

<sandro> PatH: Note that Skolemization is not valid in an antecedent (eg query).

<sandro> SteveH: that's fine.

<PatH> prposal. it is permissible to replace bnodes by URIs provided that the URIs are 'fresh', ie not used in any other rdf graph. It is recommended to include a string /genid/. one way is sandro's prposal.

SteveH: the skolemization process has to be stable

davidwood: Can we get consensus around this proposal?
... are there concerns around sandro's mandated use?
... if you're going to skolemize, you need to use a globally unique URI

<sandro> freshness is iffy -- since you want stability....

davidwood: and we encourage you to do it in a way

<danbri> -1 where did 'allowed' enter the rdf universe?

<zwu2> as long as generated uri is fresh to the triple store, it is good enough

-1 as well

<danbri> -> say what it means, not what people can/can't do

<PatH> must be fresh, should include /genid/

sandro: MAY is you're allowed to

pfps: SHOULD is you should do it, unless there's a very good reason not to

<PatH> sandro, why is freshness "iffy"

<danbri> propose: "A graph transformed such that each bnode is replaced with a fresh bnode [meeting some constraints], ... then that new graph is true under the same conditions of the original."

<danbri> we are not the SPARQL WG

davidwood: if systems are going to leak bnodes, they must use fresh uris

SteveH: consistent mapping between internal representation and external id

<zwu2> so we can reuse "fresh" uris

<sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.

danbri: we're not the SPARQL working group - so I think this language inappropriate
... we should instead say something about graph structures

ivan: current RDF documents already talk about skolemization
... the only thing we're saying here is that if it is used, you should use this pattern

<danbri> http://www.w3.org/TR/rdf-mt/#prf

pfps: RDF Semantics talk about skolemization

sandro: you need a web service to do the skolemization

<PatH> wha?

???

<danbri> madness!!!

SteveH: you can't guarantee uniqueness

<danbri> (that's a technical term, no disrespect intended)

<PatH> call it 'bnode purging' and people will love it.

sandro: tag: skolemized bnode are more horrible than bnode

<danbri> PatH, can it be couched more declaratively? this 'should' stuff worries me

<JFB> RDF Semantics talks about Skolemization in Appendix A. Its notion of freshness is "fresh in the current graph"

ivan: the R2RML folks are fighting with the same problem

<PatH> danbri, yes.

ivan: what happens when the DB doesn't have a (publicly exposable) primary key

<PatH> jfb, no, that is not what was intended.

<pchampin> s/the DB/a table in the DB/

<sandro> PatH, in "you need a web service to do the skolemization" , I mean to be particularly useful, and make people happy you did the Skolemization....

<danbri> sandro, what are you seeing as the args to the skolemisation function? not just a document + base_uri?

ivan: if we come up with this note, we need to send it to the R2RML group - potential first users

<sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.

<sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use a fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.

<sandro> objections from danbri and yves.

<PatH> unhappy with 'disposable'

danbri: very short URIs are important to me
... don't force me to use this long pattern

<sandro> danbri: short URIs are important to me. don't force me to do it this way.

SteveH: uri pattern is quite verbose

<PatH> and would prefer to just say 'SHOULD include string /genid/'

<danbri> sorry - am sounding grumpier than I am. This could be a useful pattern for some.

<sandro> SteveH: for the non-deref form I prefer something smaller.

<zwu2> how about genid:local_unique_id

danbri: if we cut the proposal to the first MUST, any objections?

<PatH> and sandro's particular form offered as an offtheshelf solution.

all: what does disposable mean?

pfps: all pragmatics from here

<PatH> +1

sandro: you can skolemize, at some cost

<danbri> when you said "You're changing the data", that's in the right direction pfps

<PatH> you always can skolemize. It is not valid, but it preserves satisfiability.

sandro: proposition restrcited to MUST is actually stronger - want to expose the fact that it has been skolemized
... genid:... would be good, but needs to be pushed through the IETF

ivan: this is a pain

sandro: don't want to be stuck in the IETF

<zwu2> you guys are not hungry, are you?

<danbri> the crux seems to be 'is it still in some appropriate equivalence class of graphs from the original? or has it been inappropriately interfered with..."

<PatH> why do we need to involve the IETF???

<gavinc> scheme registration :(

PatH, for a potential new uri scheme for those skolems

<pchampin> PatH: if we want a genid: URI scheme

<pfps> if we want to use URIs of the form genid:... we need to get approval

<PatH> screw a new scheme. they are just uris.

SteveH: are the two graphs the same? the skolemized and the original one?

<ivan> Pat, the issue is that the proposed URI-s are ugly and long...

<PatH> we need pertmission to include some text inside a URI??

<sandro> we need permission to say that all URIs containing certain text have a certain meaning, Pat.

<PatH> ivan, that is another issue.

you can't project from skolemized to original, but you can the other way around

FabGandon: you can't project from skolemized to original, but you can the other way around

<PatH> we artent saying anything about meaning, sandro.

<PatH> we are just making them recognizable.

<PatH> dawn is breaking here.

davidwood: if we're close to a solution, let's keep on on that

<sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, without doing damage to the graph, they MUST use a fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id] (or, someday, genid:...). Such IRIs are considered more disposable. "genid" to be reg'd with IETF.

<FabGandon> yvesr: still not happy with the SHOULD part

<PatH> -1 to that. way too restricting. overkill.

<FabGandon> ... not confortable with specifying a URI parttern.

<pchampin> still uncomfortable with the "disposable" part; I don't know what that means

<zwu2> +0

<FabGandon> ivan: happier with IETF pattern

<PatH> agree with fabgandon

<FabGandon> Fabien happier with genid:

<PatH> we do not need to get IETF involved.

<pchampin> PatH: if we want genid: URIs, we do

<PatH> have a good lunch, guys.

<AZ> enjoy your meal

<PatH> pahmpin: I do not neeed he IETF t put 'gnid' into a URI name.

<PatH> Anyway, back to email :-)

<gavinc> about:, irc:, javascript:, jar:, rsync:, ssh:, ... need the IETF is a nice idea, the world doesn't exactly agree ;)

<gavinc> heck, if WHATWG has its way with the IETF ... no comment

<ivan> -> http://www.w3.org/mid/4DA6A6AD.70205@deri.org -> Antoine's objection to yesterday's resolution

<ivan> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0307.html instead

<danbri> 404

<danbri> ah

<ivan> Lee's reply

<mischat> can people here the room ?

Debrief Breakouts

<sandro> subtopic: JSON Breakout Debrief

<cmatheus> crgri: talked about note to enumerate problem JSON space

<cmatheus> three examples; linked data, BBC, NYT

<cmatheus> part of problem: data always connected to some api

<cmatheus> linked data approach provides tools but its complicated

<cmatheus> talked about focusing on simple actions a json developer might want to take: enumerate instances, describe instance

<cmatheus> mischat: will also enlist help form rdfa TF

<ivan> ack

<cmatheus> ivan: discussion with Sandro about rdf web app working group (rdfa wg)

<cmatheus> ivan: their intention is for low level things to be hidden from JS user

<cmatheus> whatever comes out of that group should be coordinated

<cmatheus> need to keep groups in sync

<cmatheus> guus: does this mean our use case numbver one is being done by rdfs wg?

<cmatheus> ivan: it's in the bin

<danbri> 'in the bin?' = trash?

<webr3> next week..

<cmatheus> according to plan rdfa api will be published next week

<cmatheus> this group should look at that document

<cmatheus> guus: reporting of second breakout?

<sandro> subtopic: Report of Skolemization Breakout

<cmatheus> steveh: problem is if you have bnodes and you want to run a query to get them out there's no way to do that.

<cmatheus> plan is to provide a standard skolemize method to let you get them out

<cmatheus> everyone agreed this was good

<sandro> SteveH: If you query a sparql store and get bnodes out, there's no way to ask about them. We'd like to stdize a way to allow those bnodes to be given lables (be IRI nodes) so you can ask more. The sticky part is about indicating which nodes started out live as bnodes.

<cmatheus> sticky part whether it's desirable to have a way to tell that these started out as bnodes.

<cmatheus> guus: is there consensus that you should be able to tell that they were blank nodes?

<Steven> Minutes of JSON breakout

<cmatheus> davidwood: core issue: how are people external to the skolem process able to tell they were bnodes.

<danbri> (@cygri, I made a twitter list with rdfwg members, from your post - https://twitter.com/#!/danbri/rdfwg )

<cmatheus> question to peter: do you object to there being a way to be able to tell that these are bnodes?

<sandro> davidwood: Peter, do you object to there being a mechanism for indicating skolem nodes?

<sandro> Peter: I object to it being mandated.

<cmatheus> peter: against it being manditory

<cmatheus> as a consum I don't need to know whether someone skolemized.

<sandro> peter: As a consumer, I don't need to know, in all cases, whether Skolemization was done. It would be nice to know, but it's not even a should.

<gavinc> +q to ask if isBlank() behavior should stay the same with skolemized or non skolemized?

<cmatheus> it's nice if we all did it or all agreed on doing it.

<danbri> so was this skolemised? http://data.linkedmdb.org/page/film/2014 ... who cares!

<sandro> SteveH: I want to be able to mint URIs that are skolem constants for bnodes such that when I get them back I can tell they were bnodes?

<cmatheus> steveh: if the producer gets the bnodes back should they be able to tell if they were created as bnodes? different from having any user being able to tell.

<cmatheus> davidwood: in short, we were not able to get consensus

<gavinc> -q

<cmatheus> guus: will leave it open for the moment

<sandro> danbri, there are several practical situations when I would care, yes.

<cmatheus> guus: turning to clean up

<SteveH> danbri, if someone does INSERT DATA { <http://data.linkedmdb.org/page/film/2014> ... } and it's ont of my bNodes, I really need to be able to tell

<SteveH> otherwise it will screw up the data

<cmatheus> sandro: yesterday issue 10: deprecated, will use archaic

<cmatheus> issues on xs:string, containers

<cmatheus> next item for today: reification

<cmatheus> this is issue-25

<cmatheus> propse that we leave this until after we have a replacement for it

<cmatheus> issue-26: trivial, rdfxml syntax has two ways to state subject: rdf:about and rdf:id

<trackbot> ISSUE-26 Should we deprecate rdf:ID on RDF/XML node elements? (use rdf:about instead) notes added

<cmatheus> proposal to mark idea as archaic

<cmatheus> Steveh: it can be usefull to use rdf:id to ensure you don't reuse an id

<sandro> SteveH: rdf:ID can be useful to find times when you accidentally use it twice....

<cmatheus> (since rdf:id's must be unique)

<AlexHall> do most rdf/xml parsers enforce the uniqueness of rdf:ID?

<cmatheus> guus: no objection to marking archaic

<cmatheus> cygri: I would argue against it. it's a minor issue. fixes a minor problem among the many rdf has.

<cmatheus> if this is the only change let's not go there

<gavinc> Googling for rdf:ID lists documents which give conflicting advice on using it vs. rdf:about

<cmatheus> sandro: wouldn't suggest that we go to much lenght to fix, but would recommend author's not to suggest using rdf:id

<danbri> http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-ID-xml-base

<cmatheus> guus: there is a cost involved to learning to use rdf:id vs. rdf:about

<danbri> "So for example if rdf:ID="name", that would be equivalent to rdf:about="#name". rdf:ID provides an additional check since the same name can only appear once in the scope of an xml:base value (or document, if none is given), so is useful for defining a set of distinct, related terms relative to the same RDF URI reference."

<cmatheus> danbri: rdf:node_id are for bnodes

<cmatheus> sandro: no body advocating rdf:id is a good thing just that it's not worth doing much about it

<sandro> PROPOSED: We don't think people should be using rdf:ID, but maybe it's not worth expressing this sentiment in any documents.

<webr3> so why not just deprecate it?

<cmatheus> guus: no one arguing for keeping it

<sandro> webr3, lots of people just gave their reasons.

<cmatheus> ivan: I would not touch rdf/xml

<pchampin> @web3: we deprecated the term 'deprecate' yesterday :)

<SteveH> http://www.google.com/search?q=%22rdf%3AID%22 suggests we should keep it

<cmatheus> if we begin to do something with it we will have to do a serious job

<cmatheus> danbri: rdf spec grammar, rdf:id can be used to check name reuse

<sandro> danbri: By saying anything, we complicated the RDF environment.

<cmatheus> if we say anything at all we add complexity to rdf environment.

<cmatheus> guus: propose we do not change

<sandro> PROPOSED: Close ISSUE-26 doing nothing.

<cmatheus> pfps: because it is being used we should do something about it

<LeeF> ISSUE-26?

<trackbot> ISSUE-26 -- Should we deprecate rdf:ID on RDF/XML node elements? (use rdf:about instead) -- open

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/26

<gavinc> I think my objection to rdf:ID is what happens if your xml:base ends with a / ;)

<gavinc> the issue is "appending the attribute value to the result of appending "#""

<NickH> Why is getting rid of rdf:ID more effort than getting rid of XMLLiteral / xsd:String etc?

<cmatheus> davidwood: why if it caused confusion and we agree we should use it why should continue to accept it?

<cmatheus> marking it archaic is not removing it

<sandro> PROPOSED: Close ISSUE-26 doing nothing.

<NickH> cmatheus: sorry for the inaccuracy

<ivan> +1

<cygri> +1

<SteveH> +1

<danbri> +1

<pfps> +0

<AZ> +1

<pchampin> +1

<mbrunati> 1

<gavinc> -0

<cmatheus> +1

<sandro> +0 (I understand)

<webr3> +0

<JFB> +1/3

<davidwood> +0

<mischat> +1

<NickH> Why is marking rdf:ID as archaic more effort than marking XMLLiteral / xsd:String etc archaic?

<FabGandon> +2/3

<sandro> RESOLVED: Close ISSUE-26 doing nothing.

<davidwood> NickH: Because marking rdf:ID as archaic would require a change to the RDF/XML document.

<cmatheus> sandro: rdf:value

<cmatheus> all I can say, mark it as archaic

<danbri> NickH - because those are *vocabulary* constructs which affect the entire ecosystem - rdfa, turtle, json, sparql, owl...

<sandro> SteveH: I like rdf:value

<sandro> Guus: I like it too!

<cmatheus> FabGandon: it's in a best practice note

<LeeF> SCOVO uses rdf:value (for better or for worse)

<NickH> danbri / davidwood thanks

<webr3> I like rdf:value just wish it was defined more clearly

<LeeF> (http://sw.joanneum.at/scovo/schema.html)

<sandro> Guus: In representation of museum data, we annotate with a bnode structure and then use a rdf:value for what's really pointed to.

<cmatheus> guus: example of its use: have things about values such as its dimension

<gavinc> +q Dublin Core also uses it

<danbri> rdf:value was partly from reification, and partly for n-ary -> http://lists.w3.org/Archives/Public/semantic-web/2010Jul/0252.html

<gavinc> +q to talk mention that Dublin Core also uses it

<sandro> guus: Lots of people use this pattern, effectively.

<danbri> it's a bit like toString()

<FabGandon> Note 3 in SWBPWG http://www.w3.org/TR/swbp-n-aryRelations/#sec-notes

<cmatheus> guus: this is a property that points to the value

<cmatheus> it's highly deployed in some communities

<LeeF> Even if it was the most hated thing in the spec, I don't think we ought to deprecate it if it's as widely in use as it appears.

<danbri> re weights-and-measures, http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ uses it for exactly that -- search for <n:units rdf:resource="http://www.nist.gov/units/Pounds"/>

<cmatheus> Steveh: done work with numeric data, want to be able to lterals as subjects in a sense

SteveH, was it signal processign related stuff?

SteveH, had to do the same for this kind of things

<cmatheus> ivan: when you need to add a unit to a value this is perhaps the best way to do it

<sandro> PROPOSED: Close ISSUE-27 doing nothing (not marking rdf:value as archaic).

<gavinc> -q

<pfps> -1

<webr3> +1

<SteveH> yvesr, no, demographics

<cmatheus> danbri: was in the original recommendation for that purpose

<LeeF> +1

<ivan> +1

<gavinc> +1

<AZ> +0

<SteveH> yvesr, but I think it might also be used in LV2

<gavinc> +q to talk mention that Dublin Core also uses it

<davidwood> +1

<cmatheus> cygri: would like evidence on its deployment

<mbrunati> +1

<SteveH> yvesr, for presets and defaults

<FabGandon> +1/2

<cmatheus> pspf: I've seen it. always badly.

<sandro> pfps: Every single case where I've seen it used, it's used badly.

<cmatheus> danbri: how could you tell?

<cmatheus> pfps: there's always a back handed agreement for how it is used

<sandro> pfps: ... where there is a backhanded agreement about what it really means, and where the meaning is really different in every case.

<cmatheus> ivan: this can be done because it is an open ended property

<cmatheus> pfps: destroys the utility of rdf

<cmatheus> rdf: value is used as a local property

<webr3> +1 pfps

<cmatheus> cygri: where used should have defined a local property

<cmatheus> guus: that's not tru

<webr3> it's centered on out of band knowledge about the data

<AZ> +1 cygri

<sandro> cygri: I would argue that every time it's used, a local property should be defined for that.

<cmatheus> rdf:value is for something where we don't have a solution

<cmatheus> steveh: like rdfs:label -- it's a handy thing to have around

<webr3> rdfs:label is a typed link, rdf:value is untyped

<sandro> issue-27

<sandro> issue-27?

<trackbot> ISSUE-27 -- Should we deprecate rdf:value? -- open

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/27

<sandro> http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue

<cmatheus> guus: rdf:label points to string instead of name and rdf:value points to the value

<cmatheus> same kind of function as rdf:label

<mischat> ?q

<danbri> ±0

<danbri> http://www.w3.org/TR/rdf-schema/#ch_value "rdf:value has no meaning on its own. It is provided as a piece of vocabulary that may be used in idioms such as illustrated in example 16 of the RDF primer [RDF-PRIMER]. Despite the lack of formal specification of the meaning of this property, there is value in defining it to encourage the use of a common idiom in examples of this kind."

<cmatheus> pfps: don't mark it as archaic but realize you're making a bad mistake

<LeeF> Can we put an action to address this in the updated primer?

<danbri> ie. RDFS current encourages its use

<cmatheus> sandro: do you want document to same something about it?

<gavinc> Does Dublin Core do it wrong? http://dublincore.org/documents/dc-rdf-notes/

<cmatheus> pfps: no. every time it's been used its been used badly.

<webr3> pfps +1

<sandro> pfps: Every time I've seen rdf:value it's been bad practice, destroying the "beauty" of RDF.

<webr3> it's like <a href="boo">, untyped

<pchampin> @sandro the example in the RDF primer is a bad one :-( (weight)

<cmatheus> pfps: rdf:value is the same as rdf:thispropertydoesn'tmeana*?/thing

<cmatheus> sandro: is this resolved?

<sandro> pfps: I'm not formally objecting to this proposal.

<webr3> should it a couple of new properties be defined for common uses of rdf:value ..

<gavinc> ah

<gavinc> and there goes the phone

<cmatheus> cygri: is there some text on good use of rdf:value?

<sandro> Guus: I disagree with Peter's characterization

<sandro> davidwood: As do I.

<cmatheus> I would disagree with some of the things in the Primer

<sandro> cygri: The use for units of measure is extremely questionable.

<cmatheus> there's a lot of work on how to measure units of measure, they come up with different solutions

<gavinc> No, I can not hear.

<cmatheus> Sandor: meeting room got hung up on

<sandro> s/Sandor/Sandro/

<cmatheus> cygri: if you just use rdf:value and have addition properties hanging of value telling you what the value means that's bad

:fft rdf:value "..."

<cmatheus> the Primer leads people into bad modeling and we should do something about it

<sandro> cygri: The primer gives bad modeling advice, and I don't like that.

<pchampin> +1 cygri

:fft :derived_from :signal .

all good practice, imho

<cmatheus> guus: we can close this and open a new issue about the Primer

<NickH> yvesr: so avoid repeating very large literal values?

<cmatheus> cygri: okay

NickH, yep

<gavinc> -q

s/yvesr:/yvesr,/

<sandro> PROPOSED: Close ISSUE-27, not marking rdf:value as archaic, but with the understand that the modeling advice in RDF Primer will be revisited.

+1

<ivan> +1

<Zakim> danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.

<gavinc> +1

<danbri> ahh, i forgot already

<cygri> -0

<davidwood> Dublin Core uses rdf:value in the same manner as the examples in the RDF spec. I think it is therefore compliant.

<AZ> +0

<danbri> action danbri danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.

<trackbot> Created ACTION-33 - Danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value. [on Dan Brickley - due 2011-04-21].

<pchampin> +1

<cmatheus> sandro: can put an Action on Richard to review primer

<cmatheus> cygri: I think there is a technical issue about a bug in the rdf Primer about advice on us eof rdf:value

<cmatheus> guus: could result in Primer ignoring rdf:value

<sandro> RESOLVED: Close ISSUE-27, not marking rdf:value as archaic, but with the understand that the modeling advice in RDF Primer will be revisited.

<cmatheus> sandro: plan to spend another 35 minutes here

<cmatheus> those were all the ones marked as Archic

<cmatheus> s/Archic/Archaic/

<FabGandon> issue-6?

<trackbot> ISSUE-6 -- Handling RDF Errata -- open

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/6

<FabGandon> issue-7?

<trackbot> ISSUE-7 -- Leftover issues from the RDF Core WG -- open

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/7

<cmatheus> ivan: issue 6: handling of Errata

<mischat> http://www.w3.org/2001/sw/RDFCore/errata

<cmatheus> we have to have a mechanism not to forget these

<mischat> this related to danbri's suggestion of going through the archives

<mischat> s/related/relates/

<cmatheus> nothing earthshakingly major

<cmatheus> issue-7: some issues left open from previous working group

<trackbot> ISSUE-7 Leftover issues from the RDF Core WG notes added

<mischat> http://www.w3.org/2000/03/rdf-tracking/#/%23futures

<cmatheus> danbri: brief comment on list

<cmatheus> some were engineering hacks, left for next group

<webr3> +1

<cmatheus> ivan: we still need to go through them

<cmatheus> davidwood: propose a telecom to discuss these

http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects :)

<cmatheus> pfps: someone should go through them ahead of time

<cmatheus> davidwood: I volunteer to do that

<cmatheus> ivan: IRI versus URI story

<sandro> ACTION: wood prepare resolutions to dispose of each of the leftover items, http://www.w3.org/2000/03/rdf-tracking/#/%23futures [recorded in http://www.w3.org/2011/04/14-rdf-wg-minutes.html#action01]

<trackbot> Created ACTION-34 - Prepare resolutions to dispose of each of the leftover items, http://www.w3.org/2000/03/rdf-tracking/#/%23futures [on David Wood - due 2011-04-21].

<cmatheus> frankly I am lost with the details

<gavinc> Jeremy had something on what needed to be updated with the IRIs, but I seem to have miss placed it.

<cmatheus> Andy and Eric know a lot about that

<FabGandon> issue-8?

<trackbot> ISSUE-8 -- Incorporate IRI-s into the RDF documents -- open

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/8

<cmatheus> sandro: we want to take out every we say about URI and replace with IRI

<ivan> The IRI Spec[1] is from 2005, and it may be necessary to retrofit it to RDF. Eg, what is the relationship between "http://xn--rsum-bpad.example.org/" and "http://xn--rsum-bpad.example.org/"? Are they the same resource or not? Note that SPARQL has something on that[2]...

<gavinc> Jeremy thought there were a few when we spoke about it. But again, I've missplaced the record of that conversation

<sandro> "http://résumé.example.org" and "http://xn--rsum-bpad.example.org"?

<cmatheus> ivan: (issue with url's in irc)

<cmatheus> are the displayed iri's refereing to same resource or not

<cmatheus> cycri: two iri's are identifcal if the characters are the same, except in a number of cases...

<cmatheus> s/identifcal/identical/

<cmatheus> the one uri can be normalized into the other

<cmatheus> guus: if it's a problem we can flag it but's it's not in the realm of where we should go

<mischat> http://www.w3.org/TR/sparql11-query/#syntaxTerms

<cmatheus> mischat: if we go this way we will need to have best practise note on this

<cmatheus> sandro: example?

<sandro> mischat: back-tick is valid in URI-References but not IRIs.

<cmatheus> mischat: a back tick. caused out app to go down.

<cmatheus> davidwood: I've seen issues with that, I think it was with back tick.

<gavinc> for reference, IRI spec: http://www.ietf.org/rfc/rfc3987

<cmatheus> guus: objet to description of issues -- it's outside of scope

<pchampin> from the charter (required section): Clarify the usage of IRI references for RDF resources

<cmatheus> mischat: rdf group was guessing at what iris would look like

<cmatheus> davidwood: issue from implementation standdpoint

<cmatheus> when trying to index rdf, if you have to do a lot of checking, implementers will screem, Talis for one.

<cmatheus> if we said an iri and uri were equivalent that would cause serious practical problems

<cmatheus> steve: I understand what you're saying but don't understand the technical problem

<gavinc> +q

<cmatheus> davidwood: when ingesting rdf must say whether this uri ir equivalent to some other uri's in your system

<sandro> SteveH: Every triplestore I know just uses utf-8, so the question is which chars are allowed.

<cmatheus> steveh: it just changes your grammar

<cmatheus> davidwood: you may be right

<cmatheus> SteveH: I'm pretty sure I am

<sandro> SteveH: SPARQL says they have to be the same normalized utf-8 byte string.

<cmatheus> davidwood: I'm talking about in SPARQL

<cmatheus> the specs say different things

<cmatheus> cygri: I don't think they do

<cmatheus> in RDF world things are conistent

<cmatheus> s/sconistent/consistent/

<mischat> i don't think they are consistent, you can a SPARQL INSERT triples which you cant CONSTRUCT as valid RDF/XML

<cmatheus> there's no way you can align this with the rest of the web architecture

<SteveH> mischat, no you cant

<cmatheus> but can give recommendations.

<SteveH> mischat, oh, wait, not maybe that's right

<sandro> cygri: We can (and should) give recommendations to publishers about how to mint URIs to avoid these problems, like don't say :80 and dont use uppercase URI scheme or host names.

<mischat> it is right SteveH

<cmatheus> if you avoid certain things then you will get same result

<davidwood> correction: I was *not* talking about SPARQL, but Turtle or other forms of ingesting into a store, and then only in the case where we decided that a given IRI was equivalent to a different character string URI.

<cmatheus> worth writing up as an aid to users of rdf

<cmatheus> ivan: this discussion went beyond what I intended

<cmatheus> but look what happend when we just but the same iri's through two different systems and got very different results

<cmatheus> this is something we need to address

<gavinc> I think the section in question is: http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref

<cmatheus> guus: this is not something we're going to solve

<mischat> this is the IRI RFC http://www.ietf.org/rfc/rfc3987.txt

<gavinc> The RFC lists a set of normalization methods http://www.ietf.org/rfc/rfc3987

<cmatheus> ivan: why? there is a document that says how to implement a system that will do the right thing

<cmatheus> davidwood: what is the sate of iri's in the standard (RC)

<cmatheus> cygri: it's implemented in all browsers

<cmatheus> davidwood: that's different from the state of the standard

<cmatheus> gavinc: we went through this a month ago but I can't find the work we did -- not sure if it got lost in the shuffle

<cmatheus> we didn't think the spec was as brioken as some of the people are saying

<cmatheus> sorry, I don't remember the details

<sandro> davidwood, it's a PROPOSED STANDARD, per http://www.rfc-editor.org/rfcxx00.html#STDbySTD

<sandro> (like almost everything)

<cmatheus> mischat: the issue I have is I can issert certain triples, with content with a back tick, and then retrive it I get something different.

<cmatheus> ivan: there are cetrtain charcters that you cannot put into a xml doc, but in turtle it would be a problem

<sandro> (although URI RFC-3986 is actually a "STANDARD" STD-66 )

<cmatheus> pfps: turtle currently stuck at uri's

<cmatheus> gavinc: I don't think turtle is cemented to uris

<davidwood> IRIs seem to be an IETF standards-track (but not standard) RFC (3987), which does not expire. There is a newer proposal, which will expire in Sep 2011 (https://datatracker.ietf.org/doc/draft-ietf-iri-3987bis/)

<cmatheus> gramar refers to iris

<cmatheus> sandor: revisit when Eric and Andy (perhaps Jeremy) are around

<cmatheus> ivan: issue 9

<sandro> s/sandor/sandro/

<cmatheus> small thing for Pat and Peter from der Horst

<cygri> davidwood: that's the same as the URI RFC

<cmatheus> an obvious thing that the editor has to take care of

<cmatheus> issue 11, more complicated

<cmatheus> docs published by other wg's that extended the rdf semantics or contained element related to rdf semantics

<cmatheus> implementors focusing on rdf have to visit all docs

<cmatheus> rdf plain literal added vocabulary

<cmatheus> POWDER likewise

<FabGandon> issue-11?

<trackbot> ISSUE-11 -- Reconciliation of various, semantics-oriented documents with the core RDF ones -- open

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/11

<cmatheus> SPARQL 1.1 has Entailment Regimes

<cmatheus> something we should look at

<cmatheus> guus: is there anything we need to do now

<danbri> ( @davidwood, i made a first cut at suggesting closure of the old RDFCore issues: http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0317.html )

<cmatheus> ivan: probably not

<cmatheus> guus: let's leave this open but ensure it gets resolved

<cmatheus> ivan: string literals handled

<cmatheus> xml literals discussed and still open

<cmatheus> that's all

<cmatheus> ivan: (discuss about POWDER extension to rdf schema...)

<cmatheus> guus: bad idea that there are many different groups dealing with these issues

<cmatheus> ivan: not proposing to do any extra work -- need to make references to the other sources of relevant information

<cmatheus> guus: if we need to do more than references than this needs to be handled at a higher level

<cmatheus> guus: suggest 20 minute break

<cmatheus> in final session. short planning round for next F2F

<cmatheus> discuss document set

<cmatheus> and candidate docs

<davidwood> danbri: Thanks. That list is very helpful. I'll start with your list and see if I have any different ideas. I plan to add that discussion to the agenda for next Wed.

<gavinc> ?

<gavinc> I heard my name?

<gavinc> or not ;)

<mischat> this is the excerpt from the IRI rfc which highlights my issue with roundtripping RDF

<mischat> http://pastebin.com/ZiQHQ2ab

<FabGandon> I wonder if it wouldn't be an easyer position to consider that every IRI loaded in a triple store is first turned into its ASCII version and then treated as the URI before including the character by character comparison.

<gavinc> No, the spec is already clear that URIs are unicode

<gavinc> "A URI reference within an RDF graph (an RDF URI reference) is a Unicode string"

<cygri> scribe: cygri

<scribe> scribenick: cygri

<FabGandon> still we could have the transformation before and always work on the transformed version, no?

Next F2F

<LeeF> I'd recommend considering the sort of 2-site w/ video conference F2F that has been successful for SPARQL WG.

guus: there's pressure towards balance between european and north american locations

<LeeF> The problem is that for time zones that only really works for US East Coast + UK (or so)

ivan: W3C will have technical plenary week

<danbri> http://www.w3.org/2011/11/TPAC/

ivan: where several WGs meet

<danbri> Santa Clara Marriott, Santa Clara, California, (Silicon Valley) USA 31 October to 4 November 2011

ivan: I try to convince the RDF apps WG to have their F2F there
... downside is that it's the week after ISWC

davidwood: we might want to have the F2F meetings earlier rather than later

ivan: july/august not a good time for europeans

guus: suppose we would do it at TPAC, for whom would that be an obstacle?

<Souri> I am getting "The conference is restricted at this time" message when trying to connect to the telcon using 617-761-6200 + 733941#

SteveH: time difference is a problem

<gavinc> Sigh.

davidwood: I question whether we should have a west coast f2f

<zwu2> CA in US sounds great

sandro: how about right before ISWC?

ivan: other WGs: sparql, rdb2rdf, provenance, government linked data

steveh: east coast much easier than west coast

sandro: i'm happy to host at W3C, if i can find a room

s/W3C/MIT/

pfps: happy to host at bell labs

guus: so, east coast location, 1st half of october?

pfps: better earlier, end of september (more distance to tpac)

guus: week of 26th september?

SteveH: clash with SemTech London

FabGandon: week of 12th of september?

SteveH: we could host at Garlik

pfps: find someone at oxford?

<gavinc> MIT sounds better then Europe

guus: week of 3rd october, boston?

<gavinc> TPAC sounds the best still

<danbri> (I don't know what I can attend nor where, but prefer east coast as most plausible)

<sandro> October 3-4 in Eastern US....

gavinc: I can travel if it's in the US; europe less likely

<LeeF> Yes

<Souri> East Coast is the best for me. Europe is doubtful.

<LeeF> both

<LeeF> correct

<sandro> zwu2_, press 60#

<LeeF> Possibly if it were scheduled with our input :)

<LeeF> The challenge this time was the date being picked without input, and hving existingcommitments

davidwood: to the remote americans: would you be able to come to a f2f in europe in the future?

<zwu2_> CA is fine. East coast will do too

<gavinc> Europe is unlikely

<AlexHall> No, I don't anticipate being able to travel to Europe

souri: east cost is best, europe problematic

<AZ> I don't know if will be able to come to the US

<AZ> May situation after August is quite unclear

<AZ> s/May/My

davidwood: this tells me we should alternate meetings between europe and US

ivan: tpac still best

guus: i'll set up a poll

<gavinc> TPAC: 31 October to 4 November 2011

<Souri> We had a very good setup for SPARQL f2f last time using video connections between Cambridge/MIT and Oxford.

<scribe> ACTION: guus to set up poll regarding F2F date [recorded in http://www.w3.org/2011/04/14-rdf-wg-minutes.html#action02]

<trackbot> Created ACTION-35 - Set up poll regarding F2F date [on Guus Schreiber - due 2011-04-21].

<gavinc> 2 video remote sites would also be excellent

guus: options will be: US east cost: Boston or Murray Hill
... and TPAC

<zwu2_> is CA a choice at all?

Scribing

<gavinc> TPAC is CA

<gavinc> well

sandro: would be helpful if scribes could use topics and subtopics

<gavinc> CA, US ... not CA Canada

<mischat> http://www.w3.org/2011/rdf-wg/meeting/2011-04-13 and http://www.w3.org/2011/rdf-wg/meeting/2011-04-14

<zwu2_> yes CA, US

RDF document set

guus: this was on telecon agenda for a long time
... strong preference for not creating completely new set of docs
... but update the existing RDF Core documents
... have new editors and update these documents

sandro: seems to depend on how big the changes are

guus: for instance RDF Concepts would have to add sections on terminology and other things
... hopefully not too many changes to RDF Semantics
... primer should be completely new rewritten version
... test cases we have to see

ivan: test cases were REC in 2004. i don't see why they should be
... formally, would that mean we re-use the same short names?
... so would they formally be new versions of the same documents?

cygri: we should use the same short names to avoid having multiple REC documents floating around

ivan: what does SPARQL do?

steveh: (scribe got lost. not yet decided?)

guus: good guideline: substantial changes => new short name

steveh: in SPARQL isn't decided yet

sandro: OWL rewrote everything and new short names

davidwood: that was not a good idea

guus: i don't hear objections, so let's work on that assumption

<sandro> sandro: sounds like we're just talking about 2nd editions of Recs, not new Recs.

thanks sandro

guus: these are lots of documents
... RDF Concepts. main change will be graph terminology

ivan: and archaization? and XMLLiteral?

cygri: i can be editor on that one

davidwood: me too

<sandro> guus: eds, Richard and David

guus: RDF Semantics
... ideal would be pfps and PatH

pfps: ok

<sandro> ACTION: guus to ask Pat to be an editor of RDF Semantics [recorded in http://www.w3.org/2011/04/14-rdf-wg-minutes.html#action03]

<trackbot> Created ACTION-36 - Ask Pat to be an editor of RDF Semantics [on Guus Schreiber - due 2011-04-21].

guus: RDF Schema

<sandro> Guus: DanBri, will you edit RDF Vocab?

danbri: ok

<pfps> what is the preferred mechanism for editing a W3C document these days?

sandro: can we change the name to "RDF Schema"?

<sandro> ISSUE: Should we change the title of rdf-schema to use the word "Schema" ?

<trackbot> Created ISSUE-36 - Should we change the title of rdf-schema to use the word "Schema" ? ; please complete additional details at http://www.w3.org/2011/rdf-wg/track/issues/36/edit .

guus: Turtle

ivan: EricP has volunteered to do that

<sandro> ericP?

mischat: i'm willing to help but might not be able to help much with syntax/grammar

ivan: amount of work on turtle might not be much

<gavinc> I'd be happy to provide test cases?

<danbri> I guess the concept we're going for is "2nd Edition" for most of these? sandro/ivan - is that defined in http://www.w3.org/2005/07/pubrules somewhere?

<sandro> danbri, yes.

<sandro> danbri, I've never done it myself, but I've seen it.

mischat: i'll take it into consideration. if andy wants do do it, i won't feel bad

guus: we need to publish FPWDs soon. turtle obvious candidate
... mid-june should be doable
... possible other documents: n-triples

sandro: n-triples might be appendix of turtle, or appendix of test cases

guus: might be a separate piece of work anyways
... spread out the responsibilities

<mischat> AndyS's page http://www.w3.org/2011/rdf-wg/wiki/N-Triples-Format

cygri: andy did a wiki page on n-triples

<sandro> zwu2_ ?

<zwu2_> yes

sandro: zwu2, can you be ed of n-triples to make sure nothing bad happens to it?

zwu2: i can do that

<sandro> sandro: does it matter to you, Zhe, whether you are credited as an editor for that work?

guus: json

<sandro> Zhe: I'm okay either way there.

<danbri> (asking informally, I'm told that "Second Editions" typically get their own short-name in /TR/ --- but to check with the webmaster team)

<Souri> I can help on the n-triples -- my org (Oracle) has heavy investment on n-triples

davidwood: i'll take an action to ask talis about a possible editor for the json rdf-to-rdf thing

cygri: souri just volunteered to help on n-triples

guus: anyone else for rdf/json?

ivan: only other person i can think of is tomayac

<sandro> ACTION: wood to ask Talis to provide an editor for JSON [recorded in http://www.w3.org/2011/04/14-rdf-wg-minutes.html#action04]

<trackbot> Created ACTION-37 - Ask Talis to provide an editor for JSON [on David Wood - due 2011-04-21].

ivan: asking him would be a good idea

<scribe> ACTION: ivan to ask thomas about RDF/JSON editorship [recorded in http://www.w3.org/2011/04/14-rdf-wg-minutes.html#action05]

<trackbot> Created ACTION-38 - Ask thomas about RDF/JSON editorship [on Ivan Herman - due 2011-04-21].

guus: JSON recipes note
... we had some volunteers: mishat, NickH, mbrunati
... and i'll volunteer one of my postdocs

yvesr: i want to contribute to that note as well

s/mishat/mischat/

<mischat> thanks

guus: rdf primer
... i volunteer

<LeeF> I would like to devote time to the rdf primer, though not necessarily as an editor.

FabGandon: me

pchampin: me

cmatheus: me

ivan: we need one, max two people to lead it, and perhaps a larger number of contributors

<mischat> :)

<davidwood> Guus and Fabian to edit the Primer, with many contributors expected.

cygri: so primer will have guus, FabGandon as lead editors, with possibly many contributors
... on TriG/N-Quads, probably not a new doc but part of turtle ... i can help there

ivan: RDF/XML ... we may not touch it at all, but might want to check with henry

<zwu2_> I don't hate rdf/xml at all

mischat, zwu2, sandro: freaks!

<zwu2_> I just don't write manually in rdf/xml much

<mischat> i am a bit of a fan, it has the most robust tooling

mischat that's true

<mischat> i dont like writing any rdf by hand

<sandro> I happily misread that, mischat, as the most robust trolling.

sandro: henry made clear that he won't do the RDF/XML work himself

<AlexHall> the problem with rdf/xml is when newcomers confuse the xml syntax with the rdf semantics

<danbri> (btw re Turtle, http://www.w3.org/DesignIssues/N3Alternatives might be interesting)

sandro: are there errata against RDF/XML?

someone: yes

FabGandon: i'm happy to apply the errata

<mischat> :)

mischat: are you volunteering?

<yvesr> AlexHall, and people using xpath on rdf/xml

<yvesr> caused us so much problems at the BBC

<yvesr> you change serialiser, and you end up breaking applications

<zwu2_> tricky to use xpath I guess

danbri: practicalities around CVS access? use mercurial?

<yvesr> maybe an xpath-able version of rdf/xml would be in order? don't know though...

<gavinc> zwu, tricky is an understatement

<zwu2_> :)

<danbri> http://dev.w3.org/2009/dap/ReSpec.js/documentation.html

sandro: four options: 1. edit xhtml in cvs; 2. use xmlspec

<danbri> w3c mercurial repo: https://dvcs.w3.org/hg/

<AlexHall> yvesr, it's in the charter as a time-permitting feature

sandro: 3. respec (an html5 and js thing)

Souri, ok

ivan: respec works well for me
... only downside: we have to transform old docs into respec. initial price.

<pchampin> the Media Annotation WG uses respec

<pchampin> for the API document

<pchampin> http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html

sandro: 4th option: use the wiki. there's a script to put stuff from xhtml into the wiki, and another for the way back

<danbri> I was thinking more about the testcases repository (as a consensus documentation tool / decision record) -> should that be w3c cvs datespace again, or mercurial?

ivan: (more respec advocacy)

sandro: if we don't use my code, i won't do the pubs

FabGandon: upside of using the wiki: no cvs

ivan: downside is that ppl hate wiki markup

sandro: i should look at respec and look at how it handles [something]

<sandro> ACTION: sandro look at respec's handling of references [recorded in http://www.w3.org/2011/04/14-rdf-wg-minutes.html#action06]

<trackbot> Created ACTION-39 - Look at respec's handling of references [on Sandro Hawke - due 2011-04-21].

SteveH: don't use xmlspec

<danbri> so should RDFS spec be in HTML/RDFa? if so, which vocabulary terms should it include RDF claims about? rdf+rdfs?

SteveH: especially if only small changes, just do them in xhtml

<mischat> votes for a distributed version control system instead of a centralised one

<danbri> +1 cygri

<Souri> based upon my R2RML editing experience: +1 for option 1 (edit xhtml in cvs); +0.5 for option 4 (wiki)

<danbri> http://www.w3.org/blog/systeam/2010/06/16/why_we_chose_mercurial_as_our_dvcs/

<sandro> (discussion of whether emacs can reify skolemized bnodes....)

<yvesr> (in rdf/xml...)

+1 guus

<sandro> Bye remote folks!

<zwu2_> bye and have a safe trip home!

<manu> Have a safe trip back home to everyone there - :)

guus: adjourned

trackbot, generate minutes

<trackbot> Sorry, cygri, I don't understand 'trackbot, generate minutes'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/sugest/suggest/
Succeeded: s/MUST/MUCH/
Succeeded: s/are/must be/
Succeeded: s/NAMES/NAMED/
Succeeded: s/Guss/Guus/
Succeeded: s/pgroth:/pgroth,/
Succeeded: s/,/:/
FAILED: s/speaker/stevenh/
FAILED: s/soemthing/something/
FAILED: s/genie/genid/
FAILED: s/the DB/a table in the DB/
Succeeded: s/here/hear/
FAILED: s/Sandor/Sandro/
FAILED: s/yvesr:/yvesr,/
FAILED: s/Archic/Archaic/
FAILED: s/related/relates/
FAILED: s/identifcal/identical/
FAILED: s/sconistent/consistent/
FAILED: s/sandor/sandro/
FAILED: s/W3C/MIT/
FAILED: s/May/My/
FAILED: s/mishat/mischat/
Found Scribe: Fabien
Found Scribe: yvesr
Inferring ScribeNick: yvesr
Found Scribe: cygri
Inferring ScribeNick: cygri
Found ScribeNick: cygri
Scribes: Fabien, yvesr, cygri
ScribeNicks: cygri, yvesr

WARNING: No "Present: ... " found!
Possibly Present: AZ AlexHall FabGandon Guss ISSUE ISSUE-15 ISSUE-30 JFB LeeF MacTed Maybe Meeting_Room NB NickH OlivierCorby P18 PROPOSAL PROPOSED PatH Peter RDFWG1 SW_RDFWG Souri Steveh Steven StevenH Steven_ TPAC Zhe aa aaa aaaa aabb aacc aadd about active all cmatheus correction crgri cycri cygri danbri data davidwood eg g-snap gavinc guus issue-26 issue-7 ivan manu mbrunati minutes mischat mischat_ mischat__ next others pahmpin pat pchampin pfps pgroth pgroth_ propose pspf raphael rdf rdfs sandor sandro scheduled scribenick someone start steve subtopic to tomayac tomlurge trackbot webr3 yvesr zwu2 zwu2_
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 14 Apr 2011
Guessing minutes URL: http://www.w3.org/2011/04/14-rdf-wg-minutes.html
People with action items: guus ivan prepare resolutions sandro wood