<sandro> http://www.w3.org/2011/rdf-wg/meeting/2011-10-12

<Guus> scribe?

<yvesr> scribe yvesr

<ivan> scribenick: yvesr

<ivan> scribe: yvesr

Guus: let's start with Pat's email

<tomayac> scribenick: tomayac

<ivan> scribe: tomayac

<Guus> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Oct/0210.html

Guus suggests to start with ISSUE-71

was originally ISSUE-12, but got closed and is now ISSUE-71

<sandro> issue-71

<sandro> issue-71?

<trackbot> ISSUE-71 -- Reconcile various forms of string literals (time permitting) -- open

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

we can either do nothing, or option 2d

<Guus> Proposal for Issue 12

people could live with that

any further discussion required?

got extensively discussed

marked as a feature at risk

<AndyS> and also let RDFa know

AndyS: makes the spec a little cleaner

Guus: objections?

<Guus> ISSUE-71: Reconcile various forms of string literals (time permitting) W.r.t the representation of language-typed literals I took an action to propose the following resolution: "Lexical form is "foo", datatype is rdf:TaggedLiteral. The abstract syntax has a lexical form and language tag (like in RDF 2004). The value is assigned directly (like in RDF 2004), bypassing the datatype. The datatype has an empty lexical space and empty L2V mapping. (Option 2d from t

<trackbot> ISSUE-71 Reconcile various forms of string literals (time permitting) notes added

<cygri> PROPOSAL: Resolve ISSUE-71 by adopting the phrasing in http://lists.w3.org/Archives/Public/public-rdf-wg/2011Sep/0083.html

<LeeF> Can someone paste the wiki page or email that had the various options in it? (the place at which this was option 2d)?

<ivan> PROPOSAL: Resolve ISSUE-71 by adopting the phrasing in http://lists.w3.org/Archives/Public/public-rdf-wg/2011Sep/0083.html

<davidwood> +1

<AndyS> +1

<iand> +0

<AZ_> +1

<cygri> +1

<LeeF> I'm happy with this

<yvesr> +1

Guus: please click on the link, too log to paste. marks a feature at risk.

<pfps> +epsilon

<AlexHall> +1

<NickH> +1

<ivan> is the poll result

Guus: Resolved.

<ivan> +1

<gavinc> +0

<ivan> RESOLVED: Resolve ISSUE-71 by adopting the phrasing in http://lists.w3.org/Archives/Public/public-rdf-wg/2011Sep/0083.html

<AndyS> ε > 0

<sandro> +1 it's good enough for 2011; someday maybe we can add more URIs for language tags

Guus: dave proposed to have a discussion on sandro's proposal.

<davidwood> PROPOSED: While it's desirable to have dataset tag IRIs denote their associated g-boxes, because of existing deployments we can't just rule that now. Instead, we can provide some way to flag the cases where it does, so the market can move in that direction. (Sandro)

<iand> what are dataset IRIs?

<pfps> I worry about "flying flags" in RDF, particularly if this means building a theory into the semantics of RDF.

<mischat> we would need to inform the RDF 1.1 people about the previous resolution re: manu's email http://lists.w3.org/Archives/Public/public-rdf-wg/2011Oct/0115.html

ivan: sandro, when you say provide some case to flag the cases, what do you mean?

<tlebo> I think http://www.w3.org/2011/prov/wiki/Using_named_graphs_to_model_Accounts#Via_SPARQL_1.1_.2B_RDF_1.1 is related

<AndyS> tag: denote g-box? Should that be g-snap?

<Souri_> Could you please put the proposal on IRC one more time?

<LeeF> I support this goal, but I worry that adopting it might mean that we are inventing like 4 new mechanisms for communicating this which don't currently exist

<LeeF> PROPOSED: While it's desirable to have dataset tag IRIs denote their associated g-boxes, because of existing deployments we can't just rule that now. Instead, we can provide some way to flag the cases where it does, so the market can move in that direction. (Sandro)

sandro: there are two different kinds of data sets

<AndyS> The word "tag" is confusing me somewhat.

<iand> sandro, when you say tag do you mean the names in named graphs

<gavinc> I think he does.

<sandro> "NameTag" Datasets vs "KeyTag" Datasets

<mischat> scribe mischat

<swh> scribenick: mischat

<ivan> scribenick: mischat

<tlebo> attempt to reconcile the "tag" with an actual, implied URI: http://www.w3.org/2011/prov/wiki/Using_named_graphs_to_model_Accounts#Via_SPARQL_1.1_.2B_RDF_1.1

sandro: is asking Andy what is the other word you use instead of name

?

<sandro> TimS, is "label" better than "tag"?

<gavinc> I'll just call it <http://www4.wiwiss.fu-berlin.de/bizer/trig/#graphname> ;)

tlebo: is trying to reconcile the graph insert in the graph* terminology ^^
... the example inserts the same triples into two graph containers
... the proposal is trying present what an insert does in terms on graph* terminology
... the proposal is different from sandro's as the global graph container is different

<tlebo> archived view: http://www.w3.org/2011/prov/wiki/index.php?title=Using_named_graphs_to_model_Accounts&oldid=3770#Via_SPARQL_1.1_.2B_RDF_1.1

<Zakim> davidwood, you wanted to suggest there is no reason to find that anything "denotes" anything else until we address Pat's CoU proposal. It may in fact be dangerous to do so.

davidwood: is concerned about the WG making a finding about how an IRI should be making a decision on what "denotes" when there is no Pat around

… and given Pat's email

davidwood: would like to move this issue out for the time being

sandro: is asking AndyS what is a better name than tag

<sandro> ReferingNameDatasets vs MerelyTaggingNameDatasets

<Souri_> Shall we refer to it as graph-IRI (to avoid "name" and all those ~4-letter words)? :-)

<tlebo> "name" might, but not http://www.w3.org/ns/sparql-service-description#name

<sandro> ReferingNameDatasets vs MerelyLabelingNameDatasets

sandro: is asking if there are two different ways about talking about a dataset

Guus: are you talking about "labelling"

" various people " tagging and labelling sound like the same thing

<gavinc> label == name == context == graph name == graph iri == graphName == graph tag ?

<iand> sandro, are you asking for the WG to explore a way for datasets to optionally declare that the labels for graphs denote those graphs?

sandro: thinks that in sparql it is merely an association

davidwood: where the tag is an identifier to what happens have an HTTP Get operation

sandro: the name in the, sense of REST, identifies the graph-container
... name identifies and refers to a graph-container ?

or s//?$//

Guus: sandro could you please formulate your proposal ?

<sandro> STRAWPOLL: There is a kind of dataset (a "type-2 dataset) where the "name" IRI both refers to and awww:identifies the "graph", really a GraphContainer. These are in contrast with "type 1" datasets, where the "name" iri has an undeclared association with the "graph". We like type-2 datasets, but people are using type-1 datasets and we can't just rule them out. So we should provide a standard way for people to indicate when they are using type-2 dat

<sandro> asets.

<Zakim> pchampin, you wanted to propose an analogy

pchampin: thinks he like the proposal.
... there is an analogy: in a school you would ask to have a label on every coat. But you wouldn't be labelling the coat
... like the proposal

AndyS: thinks type2 is restrictive

<sandro> STRAWPOLL: There is a kind of dataset (type-2) where the "name" IRI both refers to and awww:identifies the "graph", really a GraphContainer. These are in contrast with type-1 datasets, where the "name" iri has an undeclared association with the "graph". We like type-2 datasets, but people are using type-1 datasets and we can't just rule them out. So we should provide a standard way for people to indicate when they are using type-2 datasets.

… and there is another proposal where the IRI - is a label for a g-snap is the more general case

<gavinc> +q to ask how we are identifying the dataset so that we can type it?

sandro: agrees with sandro

<tlebo> we should also propose the convention for how anyone can awww:identify "type-1 datasets" as "type-2 datasets" given the "type-1 dataset"'s "name" (the convention would derive from http://www.w3.org/TR/sparql11-http-rdf-update/#indirect-graph-identification)

AndyS: understands that the proposal fits in with sandro's Web Semantic proposals

sandro: isn't sparql today a type 1
... how about a type-3 being an IRI referring to a gsnap
... how about a type-3 being an IRI referring to a g-snap

AndyS: would like to see a world while there are different Contexts, as per Pat's suggestion. AndyS doesn't like the current proposal

…. seems to give privilege to type 1, and AndyS thinks that this is not the right thing.

<AlexHall> +1 LeeF

<swh> +1

LeeF: this seems to suggest that we will be prescribe a handle of various ways to annotate RDF to specify which type of dataset you're using, and this is not the best thing to do …

<sandro> STRAWPOLL-3: There is a kind of dataset (type-2) where the "name" IRI both refers to and awww:identifies the "graph", really a GraphContainer. These are in contrast with type-1 datasets, where the "name" iri has an undeclared association with the "graph". Some people want to use type-2 datasets, but people are using type-1 datasets and we can't just mandate type-2. We should provide a standard way for people to indicate when they are using type-2 data

<sandro> sets.

<tlebo> @AndyS, while others can have different contexts, anyone should still be able to awww:identify others' contextualized forms.

<Zakim> cygri, you wanted to say that it's not “types” of datasets but patterns of use

cygri: thinks it is mistake phrasing this as a type of dataset

<iand> Alternate STRAWPOLL phrasing: We should provide a standard way for people to indicate when their the "name" IRIs in their dataset both refers to and awww:identifies the "graph", really a GraphContainer.

<sandro> But I need *interop* of them,

cygri: thinks that sandro's approach is not ideal, there is lots of talk about different ways which you can make use of a dataset

<AndyS> "There is a usage of dataset where the "name" IRI both refers to and awww:identifies the "graph", really a GraphContainer. " but ...

cygri: but thinks that the current setup allows for sandro's type 2 dataset, and doesn't think that we should give a privileged status to a given way of using a dataset

<tlebo> but how does a third party uniformly refer to a SPARQL endpoint's GraphContainer?

<AndyS> ... then is there behind that a work item for the WG for this form, not others? Is the recognition of this work item the reason for the proposal?

<sandro> +1 Ian's rephrasing

<AndyS> (see Pat's email)

<yvesr> scribe: yvesr

scribenick yvesr

<ivan> scribenick: yvesr

<sandro> (scribenick is unnecessary with commonscribe, fwiw.)

<AndyS> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Oct/0195.html

<davidwood> +1 to Ian's rephrasing

<Souri_> +1 to David's thoughts that Ian's rephrasing is compatible with Pat's CoU suggestion

Guus: would cygri be more happy with iand's rephrasing?

+1

<Zakim> gavinc, you wanted to ask how we are identifying the dataset so that we can type it?

<tlebo> But how does a third party awww:identify graphs within SPARQL endpoints that do NOT provide @iand's indication?

gavinc: only worry about sandro's proposal - how are we supposed to refer to the dataset?
... we're on our way to create 'named datasets'

<AndyS> Maybe SPARQL service description helps here.

gavinc: how are we supposed to make assertions about a dataset atm?

<AndyS> ... which is "service" not dataset but that's the visible useable thing.

gavinc: sparql descriptions help for sparql end points - how do i move it around a trig dataset?

<pchampin> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Quadless-Proposal#Link_with_named_graphs_and_datasets

<Zakim> pchampin, you wanted to solve gavin's problem

<sandro> +1 pchampin and graph literals!!!

pchampin: coming back to the proposal i made a while ago - it would be improved by ivan's proposal to work with a datatype
... if we had graph literals and a vocabulary to express these relationships, then we could be unambiguous

<sandro> +999999

pchampin: not saying it should be how dataset should be implemented, but at least that's a unifying vocabulary to describe this

+99999 too

<Zakim> cygri, you wanted to answer gavinc

cygri: making statements about dataset is easy - just give it a URI
... the SPARQL service description gives us a mechanism to do that
... the URI of the Trig file is a good URI to make statements about the dataset

<iand> we already have draft text in RDF Concepts defining an RDF Dataset: http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-multigraph

cygri: the problem sandro's trying to solve is to know when a dataset is using a particular convention

<danbri> so we don't lose it in the scrollback, -->

<danbri> [13:08] <iand> Alternate STRAWPOLL phrasing: We should provide a standard way for people to indicate when their the "name" IRIs in their dataset both refers to and awww:identifies the "graph", really a GraphContainer.

cygri: having a statement asserting it doesn't solve that problem

<tlebo> Regarding "how does the GraphContainer description travel with TRIG, etc, non-SPARQL" - use service description's sd:NamedGraph/sd:GraphCollection, and replace sd:Service/sd:availableGraphDescriptions (https://github.com/timrdf/csv2rdf4lod-automation/blob/master/doc/ontology-diagrams/sparql-service-description-2010-10-31.pdf?raw=true)

<sandro> can I respond?

cygri: people lie on the Web - these statements could be false
... ... except if you trust the provider of the statement and the dataset to do the right thijng
... people are also wrong with mimetypes

<AndyS> "This WG will write a practice and experience note about using NG IRIs to both refers to and awww:identifies the "graph(g-box)", really a GraphContainer. "

<Zakim> danbri, you wanted to ask if it's the dataset that's typed, or the entry in it...?

<sandro> sandro: It's kjust like mime types --- sometimes they are wrong, sometimes people lie -- but they are still useful.

<davidwood> gavinc should respond, too. I'm curious whether describing data out-of-band with triples is acceptable to him.

cygri, i think it is still *much* more useful than *asumming* something tha tmay be wrong or controversial

<cygri> sandro, you're wrong on that. in sindice we do large-scale RDF processing and we have to ignore mime types.

<sandro> danbri: I'd like smaller granularity, like Ian's strawpoll, instead of Sandro's

danbri: ian's reformulation is more concrete
... in my store, i can have URIs of FOAF files, RSS feeds... I'd love to have descriptions to explain how my data is managed

<sandro> I'm okay with DanBri's, but I thikn it might be harder.

swh: another concern: type-1 includes some things that are undesirable - includign using people URIs as graph identifiers

<gavinc> Out of band triples are totally fine, I'm just confused as to how "just name things with URIs is easy" and the last months of conversations about what exactly naming graphs means are reconcilable?

<AndyS> +1 to "there are bad ways of doing 'associates'" (bad = wrong)

<sandro> NamedGraphs is either: LabeledGraphs and ReferedToGraphs

<sandro> (or Identified Graphs?)

<cygri> LabeledGraphs would be more accurate for what we have in SPARQL. that ship has sailed though :-(

swh: my concern is mainly that enumariting all possibilities is going to be very difficult, and chances of getting it wrong are high

<danbri> e.g. my store might have one graph (for latest version) <http://example.com/sandro.foaf> and also the transactions stashed using <uuid:12341234>. A manifest / table of contents / sitemap for the database should let me express that I've done this. But *also* it should let me express mappings from technical entities (servers, accounts, crypto) to social entities (people, orgs, ...).

swh: the chances that someone actually use it are infinitely small

<sandro> cygri, I agree that ship has sailed -- but we can launch another ship.

<sandro> "IdentifiedGraphs"

<Zakim> sandro, you wanted to talk about TriG metadata

sandro: trig bizarelly has no way to specify metadata
... no way to assert who is the author or a trig file

<AndyS> <> dc:creator "me" .

<tlebo> +1 AndyS

sandro: you can put the metadata in the default graph

<pchampin> ... but some people argued that the default graph is not more assertive than named graphs

<AndyS> (no different from situation for an RDF graph as far as I can see)

sandro: it would be nice to have a standard place - and what about metadata about metadata? who is the author of the author of the trig annotation?

<cygri> AndyS++

sandro: which graph has the metadata in it?

<pchampin> @Andy: well, if you chose to believe an RDF file, you have to believe what it says about itself

<mischat> shouldn't this sit in a Linked Data primer or similar

<gavinc> +q to respond

sandro: it seems like it would fail when you're carrying someone else's metadata

<AlexHall> (MIT discussion re metadata graphs described with special rdf:types...)

<swh> <G#meta> { <> dc:subject <G> ; a :MetadataGraph } … or something

<LeeF> LeeF: In Anzo, we have "metadata graphs" that give metadata about the graphs. We can also use it to give metadata about datasets, which are first-class objects (i.e. with URIs, etc.) in Anzo

AndyS: about ian's phrasing, i'd change the word 'standard'
... we'll write a 'practice and experience' note - non-normative

<mischat> +1 to AndyS

<zwu2> +1 AndyS

<LeeF> swh, yes, that's very much what we do

<sandro> If it's not a standard, then ... how does it work?

<swh> LeeF, ditto

danbri: convention?

<tlebo> awww:identifying a GraphContainer in a TRiG file using fragment identifiers? e.g. http://dvcs.w3.org/hg/prov/raw-file/666e284870cc/ontology/components/NamedGraph/named-graph-topics.trig#http%3A//www.w3.org/People/Berners-Lee/card

AndyS: best practice would work for me

<ivan> (what was also said) maybe defining Classes so that rdf:type could be used

<davidwood> In Callimachus, we assign a URI to each data "file" when loaded, thus making a named graph from it. Anyone can upload metadata about a named graph by referring to its URI. Therefore, our approach is similar conceptually to LeeF's.

<iand> i think we could define a class for this type of dataset. that's all we need

danbri: named graphs give you technical partition of your data - not social partition - you need out of band information

<ivan> iand, or a class for this type of (n,G) association, not the whole dataset

danbri: i hope this best practice note tackles that

<LeeF> davidwood, do you do anything different do if you're loading a trig file that defines multiple graphs?

<davidwood> yes

<davidwood> We make multiple graphs

danbri: we haven't shown the way on how to make the most of sparql, including this social use-case

<danbri> sandro, yes, we can do.

<Zakim> danbri, you wanted to argue for the social use case too (swh mentioned...)

<Zakim> gavinc, you wanted to respond

<pchampin> @danbri: but then, whouldn't it be nice to have this "out of band" information in RDF?

<danbri> (...just arguing that the use case is at least as important as the 'what url i got it from' use case which we've spent hours talking about in various forms)

<danbri> (possibly more important, ultimately)

gavinc: about AndyS's proposal of just adding a triple to a trig file - which graph does that go in?

<danbri> (since so much data will be acquired transactionally, e.g. oauth'd)

<iand> in http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-multigraph we define RDF Dataset and we could also define an RDF Denoting Dataset to be an RDF Dataset where the graph names denote the graphs

gavinc: maybe that is enough
... but if we're all doing it, there should be common practices

<Guus> wonder whether we can get a straw polln a revised phrasing

<sandro> +1 iands, not sure about the name "Denoting", but yes.

gavinc: right now, i have no idea how that works

<cygri> iand, that would rather have to go into RDF Semantics i think

AndyS: i don't care how the triple goes - it is an assertion, it could go in many different places

<gavinc> thanks AndyS

<Zakim> sandro, you wanted to say danbri, can't you build that with a vocabulary on top of IdentifiedGraphs ?

Guus: are we nearing a point where we can put a modified strawpoll?

sandro: AndyS, I don't think that works - we need an assertive metadata format
... TriG files carry stuff they're not asserting

cygri: where does this come from?

<iand> cygri: we use denotes in RDF Concepts

cygri: i wrote that spec, and it doesn't say anything in that respect

<AndyS> sandro - can you point to concrete text that lead you to that conclusion?

<tlebo> what happened to <> ?

<AlexHall> 3 options for describing a dataset: (1) conventions for special naming or typing of metadata graphs, (2) add a fifth column, (3) reify the dataset

sandro: danbri,: i agree this is a useful use case

<sandro> STRAWPOLL: We should write some text about for people to indicate when their the "name" IRIs in their dataset both refers to and awww:identifies the "graph", really a GraphContainer.

<danbri> standards-based; ...

sandro: perhaps we could phrase it by saying 'somebody' should

<danbri> ... sparql-queriable, rdf-describable, ... conventions/ best practice, ...

<danbri> swh 'because there are so many, and there are so incredibly complex, it takes us a lot to describe and ... ... this one is a weird special case'

<NickH> +1 to swh

<sandro> AndyS, that s/// will alter the scribe record --- changing my proposed strawpoll !

<ivan> STRAWPOLL: We should provide a standard way for people to indicate how their 'name' IRIs in their dataset both behave, such as when it awww:indentifies the graph, really a container

<tlebo> any third party should be able to refer to another's GraphContainer, regardless of what the GraphContainer 'owner' offers.

sandro: i am ok with that

Guus: it opens for conventions we document, and conventions we don't document

<ivan> STRAWPOLL: We should provide a standard way for people to indicate how the 'name' IRIs in their dataset behave, such as when it aww:identifies the graph (really a container)

cygri: i think this idea of indicating how they do it in their dataset is a waste of time
... it just doesn't work

<danbri> e.g. suggest something like: "Should provide RDF-based mechanisms and best practice documentation techniques, to share additional meta-information about collections of RDF graphs, including but not limited to a) info about how IRIs relate to the content they're associated with; b) data grouping technqiues that are more social than technical (eg. 'information from colleagues').'

cygri: there's nothing that encourages people to get that triple right
... nothing bad happens when you get it wrong

<sandro> cygri: This is a waste of time -- it just doesn't work. There is nothing that encourages people to get the triple right. Unless there is some Sandro-best-practice person running around....

<AndyS> +1 to danbri suggestion. /me concerned about "standard" ==> else it's not a dataset.

<cygri> yvesr, yes that's what pedantic web did, and it doesn't scale

<iand> i disagree that it is a waste of time, lots of data is wrong but that doesn't mean we should prevent people from writing data

<sandro> sandro: Yeah, my main point is that it's beneficial

cygri, agreed, but trying to standardise the relationship won't work as well

<ivan> +1 to iand

cygri, we'll never get it right

<gavinc> +1 to iand

<swh> danbri's suggestion seems more plausible

<cygri> yvesr, i think it's useful to document this convention as a good practice. that's all

<swh> I strongly don't feel it's good practice

cygri, but what is the convention? i am not even sure we agree on that

<swh> its one possible way to hold data, but it's not even the best one

swh, +1

<cygri> yvesr, the convention is what sandro said

<sandro> STRAWPOLL: It would be useful to have data-providers using "Referring-IRI" datasets, and for data-consumers to get an indication of whether the data-provider claims to be doing so.

swh, or at least not the only way

<danbri> -1

<cygri> -1

<swh> -1

<iand> -1

<danbri> Lots of things are useful to some people. but this has an advocacy feel.

<iand> (13:34:42) ivan: STRAWPOLL: We should provide a standard way for people to indicate how their 'name' IRIs in their dataset both behave, such as when it awww:indentifies the graph, really a container

<tlebo> The fact is, these things already implicitly eswhist - it's not a special case. It's universal!

<danbri> for me the issue is granularity ---

<tlebo> The (myriad, nuanced) relationships among anybody's GraphContainers should be described in RDF - and they should choose the vocabulary they want to describe those associations.

<sandro> STRAWPOLL: It would be useful to have data-providers using type-2 datasets, and for data-consumers to get an indication of whether the data-provider claims to be doing so.

<AndyS> alt -- "the WG writes up several usage scenarios " (so can say when to use and when not to)

<tlebo> so, all we need is A WAY to reference anybody's GraphContainers.

<danbri> in my stores some named graphs are referring IRIs, some are transactional, and there are RDF-describable links (derrivation, pipelines, etc) between them

<danbri> (inference even, on occasion)

danbri, +1

<ivan> STRAWPOLL: It would be useful to provide a standard way for people to indicate how their 'name' IRIs behave, such as when it awww:indentifies the graph, really a container

<cygri> -1

<pchampin> +1

<iand> +1

<sandro> +1

<danbri> 'behave' is a little anthroporphic, but sure +1

<gavinc> +1

<pfps> -epsilon

cygri: we should document patterns and conventions, *not* find a standard way

<davidwood> +0

<danbri> thought i think there is too much bias towards this specific use case, so i'll repeat

<danbri> [13:36] <danbri> e.g. suggest something like: "Should provide RDF-based mechanisms and best practice documentation techniques, to share additional meta-information about collections of RDF graphs, including but not limited to a) info about how IRIs relate to the content they're associated with; b) data grouping technqiues that are more social than technical (eg. 'information from colleagues').'

<tlebo> ALL WE NEED is a way to reference anybody else's GraphContainer. Leave the rest to RDF.

<LeeF> 0

cygri: we don't have any interest at all documenting all others

<davidwood> +1 to cygri

Guus: it would be useful to document best practice conventions to document how their named IRIs behave

<iand> i think we have no consensus on even whether this is useful :(

cygri: it would be useful to document this one particular convention for using names

<danbri> cygri, I want to be able to sparql a store for subset of its content that is (per some notion of) 'stuff from/by Richard ...'

<sandro> I just want to know what <t> { <t> <p> <o> } means. :-/

<davidwood> +1 to danbri's proposal

swh: i like danbri's suggestion from earlier

danbri: i want to go to my store, and get all the stuff from cygri

<tlebo> This isn't an opt-in thing, it ALREADY is. We just need a way to reference other's GraphContainers.

<iand> so we are saying we don't agree that it's useful for people to be able to describe the purpose of their named graph identifiers

<AndyS> sandro - Pat's proposal/idea?

<MacTed> maybe maybe maybe...

<MacTed> STRAWPOLL: It would be useful to have a standard way for people to indicate how the 'name' IRIs in their dataset behave, e.g., whether they awww:indentifies the graph (really a container), or when they only "refer to" the graph, or both

<danbri> i'm ok with guus's "behaves"; it addresses my use case

<sandro> AndyS, I haven't read the whole thread, but probably.

<tlebo> RDF handle the "zillion" cases - just give me a URI!

<cygri> -1 to "best practice"

<zwu2> how about good practice?

<cygri> zwu2, just "practice"?

<gavinc> okay, webarch conforming practice?

sandro: we don't have a consensus on any compromise
... it makes no sense to have a uri denote multiple things

<pfps> yes, but what do URIs name/denote?

<sandro> resources.

<pfps> sure, but we've had that since 2004

<danbri> sandro: "it was a small step in the right direction" [...] [...] [...] [...]

<tlebo> sd:name rdfs:subPropertyOf dcterm:identifier ---- handles the "oops, we aren't using URIs properly"

Guus: sandro, you started to say it's a small step in the rght direction

danbri: would you object to such a small step?

swh: i don't understand sandro's logical leap

<sandro> sandro: (big rant a minute ago) It's kind of absurd to use IRIs as merely labels.

<gavinc> huh?

swh: there's no relation between having a uri denote a graph or a thing

<AndyS> Is this not what RDF does? Describe things?

sandro: an IRI should both identify and refer

<danbri> sandro, they're being used properly, just that there is a missing column for relationship type

<cygri> STRAWPOLL: The WG will non-normatively document a particular convention for using datasets, where in <u,G> the URI is denotes a graph container and G is the state of the container.

sandro: in SPARQL, graph URIs are not used that way - i think that's a problem

<iand> Ivan's strawpoll had the most votes. i propose we re-vote on that strawpoll and move on

sandro: i don't want to standardise new things that build on that problem

<tlebo> INSERT { GRAPH ?s {} } ===> :my_s sd:name ?s; !owl:sameAs ?s .

sandro: if you want another relationship, it's not an IRI

<tlebo> INSERT { GRAPH ?s {} } ===> :my_s sd:name ?s; !owl: sameAs ?s .

<tlebo> Zakim: Sorry, danbri, I don't recognize "america".

<danbri> call us back when you've stopped chatting

<gavinc> geee, I think it's break time?

gavinc, +1 :)

pchampin: i wanted to answer to cygri's concerns - i think the idea is to providing a framework enabling to specify those practices
... not to define a fixed set of practices

<AndyS> Does "document good practices" work for people?

pchampin: danbri's use case fit perfectly into that

<davidwood> I propose to discuss Pat's Context of Use suggestion, which is a better way (IMO) to address these concerns.

pchampin: this proposal is to connect the dots - being able to write the right query for scoping all graphs written by X

<sandro> +1 graph literals are at least understandable and well-defined.

<tlebo> INSERT { GRAPH ?s {} } ===> :my_s sd:name ?s; skos:broader ?s; dcterms:identifier ?s . (SOME SPARQL endpoints may pretend ?s owl:sameAs :my_s )

<Zakim> danbri, you wanted to suggest thinking of this as a missing 5th column

<Souri> +1 to discussing Pat's CoU suggestion

<mischat> this seems similar to the discussion about how a "<> a foaf:Person . " is not the right thing™ - but RDF doesn't forbid it.

<pfps> the 64bit question is just what "properly" means here.

danbri: we introduced a 4th column to specify a graph, we should have had a 5th column to explain how we use the 4th one

<tlebo> +1 to fifth column == context

<swh> sandro, can you explain [possibly offline] what you think awww:identifies means? Because my understanding is like davidwood's

<iand> what about the context of the context?

<Zakim> cygri, you wanted to propose new wording

danbri: we're not doing anything wrong - we're just missing information - a manifest file, a sitemap, anything...

<danbri> yvesr s/should/could/

<tlebo> (but not actually *having* the fifth column)

<sandro> +1 danbri we're missing some information about the fourth column relates

<cygri> STRAWPOLL: The WG will non-normatively document one particular convention for using datasets, where in <u,G> the URI is denotes a graph container and G is the state of the container.

sandro: i agree with danbri

<sandro> +0.5 I'm fine with us documenting, but that doesn't solve my problem

<iand> cygri: that is the opposite to Pat's email where he suggested URIs identify graph containers and denote graphs

danbri, well, we have a framework for asserting things about the 4th column :)

danbri, RDF :)

<danbri> s/document one/document at least one/

<zwu2> +1 bettern than no convention

cygri: i mean it in the sense that you can expect to dereference u and get the grah

<sandro> +1 yes, it's a decent step in the right direction.

danbri: cygri, what's the granularity of your proposal?

cygri: datasets

<cygri> STRAWPOLL: The WG will non-normatively document one particular convention for using datasets, where in <u,G> the URI denotes+awww:identifies a graph container and G is the state of the container.

<tlebo> Everyone else can go beyond "this particular case", iif you give them URIs to reference others' GraphContainers.

<ericP> +1

<iand> +1

<danbri> +1

<ivan> +1

<Guus> +1

<swh> +0.1

<zwu2> +1

<MacTed> +1

<pchampin> +1

<LeeF> 0

+1, but we should strill provide a framework to document other cases

<sandro> +1 it's a step in the right driections . we still need graph literals or good semantics for TriG.

<davidwood> +1

<mischat> 0

<AlexHall> +0.5

s/strill/still

<pfps> =0 because of "denotes"

<NickH> 0

<AndyS> +1

<pfps> 0 because of smilies

<Souri> 0 (state => snapshot?)

<gavinc> +1

<pfps> 0 because of "denotes"

<cygri> s/The WG/sandro/?

<danbri> it's a good thing to do

<pfps> WG activities are not a zero-sum game, so adding work may positively affect other work.

<danbri> ( and s'ing 'sandro' back to 'the wg' won't fix things )

<cygri> sandro, good point. sorry

<danbri> er *scribe

<Souri> we probably should still consider discussing Pat's CoU suggestion sometime

<gavinc> Yes

<tlebo> BTW, I'm begging for http://www.w3.org/2011/prov/wiki/Using_named_graphs_to_model_Accounts#Just_give_me_a_URI

<Guus> let's reconvene

<mischat> can you guys at MIT hear us OK ?

<tlebo> Are we talking about http://lists.w3.org/Archives/Public/public-rdf-wg/2011Oct/0228.html ?

<tlebo> This one http://lists.w3.org/Archives/Public/public-rdf-wg/2011Oct/0195.html ?

<ivan> Pat's email

<tlebo> scribe: tlebo

<ivan> scribenick: tlebo

<cygri> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Oct/0212.html

cygri: given an RDF graph, there is a "context" in which the statements are made and are true.

e.g. "the age of Alice is 29 years"

obviously not true forever.

scribe: time is not the only situation. Different people can be the "contexts"
...: age 30 in a different graph; merging the two graphs causes some conflict.
... merging consolidates the contexts
... named graphs keeps contexts separate
... we need to decide case-by-case when to merge the graphs we want.

<mischat> 1. RDF Semantics defines an entailment relationship between sets of triples, a.k.a. RDF graphs

@cygri reading points from his email

<mischat> 2. This entailment relationship is only valid if all triples share the same context

<mischat> 3. Therefore, placing triples with incompatible context into a single graph is not seen as as something useful, and we understand RDF graphs as only containing triples of compatible context

<mischat> 4. It follows that merging two graphs with incompatible contexts is not a valid operation

<mischat> 5. Whether two contexts are compatible or not is outside of the scope of RDF Semantics

<sandro> I do :-)

cygri: not sure on response to Pat (aka wrong)
... current semantics is not designed for contexts and time; not extendable to handle it either
... keep it context free

(I agree with @cygri; we can keep RDF context-free and "compile" what we want from different named graphs/ contexts into the acontextual)

sandro: people are using RDF in different contexts; we should recognize that.
... Pat's claim that we need to be explicit about contexts is worthwhile.
... Pat says not to put :age into a context - b/c you have to decontextualize it.

<pfps> but everything has a context!

sandro: inferencing across different graphs - we need to decontextualize it into the "universal" context.

<Zakim> davidwood, you wanted to ask cygri what he thinks of Pat's proposal

sandro: sandro tried to represent Pat's position.

<Souri> I thought Graph-IRI gives us a hook to a context (which could itself comprise of many triples describing why/when/where/how/etc.)

<pchampin> I agree with Sandro's interpretation of Pat's answer (for what it's worth ;)

<ivan> pat's response to richard

<mischat> http://www.w3.org/mid/38CB85A6-F664-4A30-BCA5-985E49B7DC46@ihmc.us

<mischat> ^^ pat's response

davidwood: we aren't agreeing on "context"; suggests @cygri reread Pat's to see the different interpretations of "context"

<pfps> everything depends on what you mean - http://...age could mean "age on 11/11/11" and http://...born could mean "born how long ago"

<sandro> sandro: I think there's a huge opportunity for a joint solution here, between Richard and Pat -- where have multiple context, but a special "Web" context where thinks can be merged.

(beyond "web context", it's also any context we choose to create by merging some graphs and decontexutalizing them)

danbri: example - tried to decontextualize (date of birth, not age)
... foaf, color of cars

<sandro> danbri: we added foaf:age because myspace needed it. we can't make them decontextualize

danbri: foaf people wanted age, e.g. myspace spits it out every day
... we shouldn't be putting it into standards b/c research project

<sandro> danbri: there will be volatile properties; this should be a W3C CG dogin the research.

danbri: volitatile and non-volitile properties

<davidwood> Avoiding context makes sense, iff you can be sure you are actually doing it. It is trivial with events, but what about universally true statements made in RDF that are then taken *into* a particular context?

<pchampin> s/volitatile/volatile/

<pchampin> s/volitile/volatile/

souri: @cygri's proposition, can associate dimensions of the Graph IRI - why was it created, etc? These are dimensions on the context.

<gavinc> Channeling PatH via email: "No, that is not why named graphs were invented. They were invented so that one could say things about graphs in RDF. Things like who is asserting them, where they came from, etc..,: but not to supply a 'context' for the truth of the triples in them. That would be data, not metadata."

cygri: practice of decontextualizing and modeling decontextulized or not. But can merge without worrying? No, we'll still have to worry about it.
... most rdf published is context dependent.
... may contradict

<Zakim> cygri, you wanted to say that decontextualizing everything looks like a pipe dream

<sandro> cygri: it would be great if everyone was modeling in a way that would be true forever and could just be merged, but that's not the world we're living in , and I don't see it happening any time sooon. Most info published is context dependent. Not true forever, has errors, and we have to deal with that.

cygri: we need to deal with it.

<sandro> cygri: "just decontextualize" doesnt seem very practical.

<danbri> (specifically, if you describe everything as events, you are perfectly decontextual but borderline un-unformative, if you want the state of the world at some specific time...)

(can't we apply decontextualized semantics to contextualized data that we "choose" to decontextualize it?)

[]: disagreement is centered on SPARQL (?)

<gavinc> the named graph paper is a rather clear input to named graphs in SPARQL isn't it?

<pchampin> pchampin: I think the disagreement btw Richard and Pad concerning named graphs is that Pat is refering to the "Named Graph" paper, while Richard is refering to named graphs in SPARQL

s/[]/pchampin/

<sandro> agreed -- Pat's proposal was about contexts for just the 4th column

<Souri> +1 to AndyS about Pat's attempt being less ambitious than what Richard's trying to propose

(the SPARQL endpoint named graph is a specific case of contextualized RDF)

<gavinc> +1 AndyS

<sandro> AndyS: Pat's "Context of Use" email was just about the fourth column.

general consensus that @cygri's context is different from Pat's

Pat wants "web context"

sandro: we have multiple contexts and need to deal with it.

cygri: yes

<pfps> this is starting to look like the discussions with tbl on common meaning in the Semantic Web

cygri: not hard to store/query/vis contextualized data - problem is when we approach semantics.

<Souri> event-based formulation (as DanBri said above?) is another way of specifying the context ino

<Souri> s/context ino/context info/

sandro: cygri gave up on reasoning with RDF graphs b/c they are in different contexts.

cygri: collecting from wires, will need to post-process to check appropriate, clean, remodeling, etc.

<AlexHall> s/wires/the wild/

<pchampin> s/from wires/from the wild/

cygri: when reasoning over web data, those that do it say "of course we clean it up first"

sandro: we could construct ecosystems and feedback loops that increases quality.
... more rigid consumers (e.g. schema.org)

<mischat> i guess the question next is how does this relate to trig and/or graph serialisations, and whether we wish to be able to reason on top of data given to you in a trig file

sandro: will give pressure to increase quality - we need to make these systems possible.

[]: not "contextualizing web" but "contextualizing web at a point in time"

s/[]/AndyS/

<sandro> (I'm thinking about Cassandra's "eventual consistency" as a parallel to the way the Web Context might be consistent in the face of errors, lag, etc)

davidwood: re Pat's emails, happy with g-box ... (others disagree) david agrees. (LINK to thread?)

gavinc: straw poll on agreeing to the email

<gavinc> IRI----HTTP/"identifies" ---- g-box

<gavinc> IRI----denotes/names-----g-snap

sandro: what does this mean?

davidwood: Pat's trying to formally define context.

sandro: URIs can denote g-boxes.
... and you can't stop him.
... you can't identify g-snaps.

<davidwood> Start of thread: http://lists.w3.org/Archives/Public/public-rdf-wg/2011Oct/0194.html

(tlebo disagrees, you can identify g-snaps - in the words of @sandro - you can't stop me.)

<sandro> s/you can't identify g-snaps/identifying g-snaps might be a problem/

<sandro> http://www.w3.org/TR/webarch/uri-res-rep.png

x: need clear definition of "identifies"

<AndyS> <tag:1234> owl:sameAs { <s> <p> <o> }

sandro: identifies" means it like REST means it. The relationship between a URL and the thing the URL is conceptually associated with in an identifying matter.

<AndyS> That is naming so IRI----HTTP/"names" ---- g-box which is true of HTTP URLs.

sandro: heart of REST and WWW. you put a URL in, you get a representation back.

<AndyS> just don't use a #frag

sandro: REST - imagine thing over there. URL represents it and you get a representation of it when you request it.
... tag URIs say "there is no representation" - you still get identifying, but david may disagree.

<davidwood> I don't understand "there is no representation", so don't know whether I agree

guus: there is no requirement that a representation exists.

<davidwood> ah

swh: now has sense of "identifies" w.r.t. REST's URL and representation.

<swh> … actually re this conversation, I'm not sure it's a universal def'n

guus: where does that get us with identifying g-boxes and g-snaps

<davidwood> In that case, I agree with Sandro if he means that TAG URIs *identify* resources even if they cannot be resolved in a manner that returns a representation.

cygri: decontextualization - relationships are to hold "forever" - what about the g-box "can changing."
... URI for a g-box (that can change b/c the representation cna change tomorrow)

<AlexHall> taking a g-snap decontextualizes the g-box

cygri: you get different g-snaps when requesting the g-box

sandro and @cygri have concerns with proposal.

<AndyS> :x a :Car does not stop the car changing color

sandro: def b-boxes are representations of g-snaps (?)

(that sounds backwards to me)

gavinc: Pat's point: 2 parallel words, a semantic rule when one works, the other has to work.

<sandro> sandro: g-boxes are resources, their representations are g-texts, conveying the contained g-snap

sandro: let's cut this off, Pat is not here.
... where are we with not being able to inference across multiple contexts?

davidwood: the point is that you don't know what contexts there are (in RDF)
... encoding a context in the graph, and another context in another graph. Third party merges them (can do in RDF) - find logical inconsistency, but above level of merge.
... assuming apriori out of band contexts to know it SHOULD NOT be combined.

sandro: not knowing context - can assume are different, or same,

davidwood: or don't care about the contexts.

sandro: regardless, they are either the same or different (and you're implicitly deciding)\

davidwood: merging two graphs does not entail "I have made a decision about contexts"

+1 to sandro

(you've implicitly made a choice about context)

souri: removing graph names and merging - :age 31 and 32. Can go to event based organization - everything in this event is true (merging can't, because different events).

<AlexHall> propose to give different terms to richard's "context" vs. pat's "context" -- i understand this discussion to be relevant to richard's context

davidwood: have a graph not event-encoded - can have metadata true in a date. (alice graph 1 and 2)

souri: :g1 graph happened, :g2 graph happened, merging into :g3 eliminates contexts of first two graphs.

<cygri> souri++

<gavinc> PatH channeling ... " So for example if you write "it is raining' then thats not going to stay true, and if you write "it is raining now' that might be true but we have no way to know since we don't know when 'now' was, but if you write 'it is raining on 08/09/2011' then this stays true while time passes. Which is obviously better for communciation across times. So putting the "context' (or as much of it as necessary to fix the truth of what you are saying)

<gavinc> into the assertion itself is a basic good rule for data which is supposed to last for a while and still be true."

<Zakim> cygri, you wanted to talk about "compatibe/incompatible" contexts

<sandro> +1 gavinc

cygri: merging two graphs - same contexts? need notion of contexts are compatible or not (and depends on use case).

<Guus> [ivan is leaving]

cygri: depends on what you want to do with it, the modeling.

<sandro> bye Ivan!

<gavinc> but as danbri said, people may just say "it's raining"

(why can't we just leave RDF a-contextual and let us mix contexts when we want to, think we can?)

<gavinc> and the process of changing that to it's raining on ISODATETIME is a nice research project

<AlexHall> +1 tlebo

<pchampin> @gavinc: and *where* is it raining, exactly? :->

guus: YYY is out of context

<gavinc> pchampin, yes that too

guus: naming is main mechanism we have, and dereferencing. that's it. can't go any further.
... perhaps over-pragmatic, but.

cygri: use cases require holding data in incompatible contexts in same dataset. semantics has to work regardless.

<AlexHall> use prov info to record the context in which a graph is asserted, use the prov info to decide which data to include in the dataset that you want to apply inference to.

<gavinc> We are not meeting those use cases, yeah I'm okay with that ;)

(but since semantics only applies to a-contextual RDF, it's fine)

cygri: keep scope of semantics to individual graphs, since they should be within some context

(+1 cygri)

<Zakim> pchampin, you wanted to suggest that contexts are not a property of the graph, but a property of their use

<cygri> guus: so you don't want to touch semantics at all?

TTT: context of a graph, talking about it is a mistake. the context is in the use of the graph (consuming it)

s/TTT/pchampin/

<cygri> cygri: well, that would be one way of ensuring no bad entailments from putting incompatible contexts into the same dataset

<Souri> event-centric formulation of triples is good, but verbose, which leads people to not use it. Use of named graphs and associating context info with graph is easier (less verbose), but requires applications or people doing the merge to first check the contexts of the graphs being merged are compatible or not. We can provide some non-normative examples to illustrate this.

<Guus> Guus: "mnmed graphs" is the mechanism to indicate triples are in a particular context, not other ways to characterize/type/formalize context

pchampin: the context is not a property of the graph, but it's use. so the semantics is not cross-context. Semantics tells nothing about XYZ.

<cygri> souri +100

<Guus> Guus: you're on you own to interpret, for example, a merge

(so, contexts matter, but the semantics does not address it?)

<pchampin> s/XYZ/contexts, it just means that it that contexts do not exist outisde the semantics/

guus: the way people use RDF, and in OWL. We should not (address contexts?).

<pchampin> @tlebo: contexts matter on a pragmatic level

<mischat> similar to the "<> a foaf:Person ." issue which one finds in the wild, we can't say that it is wrong RDF.

sandro: retreat to syntax? what would help? Simplest is a variation of TRiG - a 5th column to name the context.
... TRiG-R - b/c relationship is added.

<sandro> <label> <relation> { ... graph .... }

(but <> already IS the context)

<yvesr> looks like n3!

sandro: manifests? to not break SPARQL.

guus: OWL used the ontology itself as the manifest.

<sandro> sandro: Maybe the service description could have a manifest of how each label is related.

souri: a primer? non-normative. an example of how to specify the context.

(<> already provides context... along with how you got <>)

should we discuss manifests?

<danbri> danbri: it just needs to be possible, we don't need to do *all* the work (re manifest formats / aka 'table of contents' for a datastore)

dawg discussed manifests

Manifests

<AndyS> It's one style amongst several/many/open ended ... it's just RDF.

sandro: labels are "..." or <...>?

how is manifest different from sparql service description?

<danbri> (quotes being uri-as-string stuff?)

<danbri> i forgot my homepage b/g graphic has a picture of this from another meeting: http://danbri.org/ (colours = graph types, volatile, version, composite etc)

cygri: VoID - RDF datasets vocab.
... not quite a manifest, but related.
... when pub RDF, also publich VoID file that describes the dataset.
... "here is a dataset, here is a SPARQL endpoint where you can query, here is a dump to put into your own store"

<Zakim> danbri, you wanted to ask andys and dawg folk how much manifest-style work has happened in sparql community

cygri: wanted outside of a SPARQL store, since can access different ways.

<Zakim> sandro, you wanted to sketch Service Description names the Dataset Manifest Graph M, in the service's dataset; M contains triples like { <G1> eg:relatedBy owl:SameAs. <G2>

<sandro> vs { [ inDataset <d>; label "G1"; relation owl:SameAs ] }

<mischat> have we won if we are in a position to describe things that people may want to describe, but not limiting people to how they have to describe things?

sandro: sketching a service description - two proposals

+1 not following

guus: please no sameAs

<AndyS> sandro - please explain log:semantics as people are unclear about it (or maybe they know and do not like it)

(are we tryign to model contexts still?)

context: where it is and where it came from.

<mischat> +1

<mischat> to tlebo

<sandro> { <G1> eg:relatedBy eg:labeling-a-snap. <G2> eg:relatedBy eg:label-is-url-source }

<gavinc> +q

<sandro> { <G1> eg:relatedBy eg:labeling-a-snap. <G2> eg:relatedBy eg:label-is-url-i-fetched-it-from }

(what is going on?)

<yvesr> { ... } a eg:Snap

<cygri> swh++

swh: 10s millions of named graphs.

<danbri> I anticipate manifest graphs could use http://www.w3.org/TR/HTTP-in-RDF10/ to describe where date was gotten

<danbri> (if we have 10s of millions of named graphs, all the more reason to be able to navigate that jungle...)

gavinc: name of graph is distinct from subjects in the graph, o/w you run into the "OWL problem" b/c the graph name is the subject of the graph - it gets odd.

<sandro> for swh: { <endpoint> eg:uses-dataset-relation eg:labeling-a-snap }

davidwood: "owl problem" is bad name for it.

<swh> sandro, or { <dataset> eg:uses … }

(none of this matters as if you give URIs for the GraphContainers; let people describe what they want in RDF)

<AlexHall> the "graph/resource conflation" problem?

s/as if/if/

review

<sandro> breajk for an hour in ten minutes

<sandro> guus: after break, go through issues list

guus: let's list issues
... what about manifest to discuss?

<Souri> s/breajk/break/

sandro: TRiGers, do you like something at top state relation, or add fifth column.

(this is already handled by <>)

<swh> -∞ to a 5th column

@cygri, either <> or <URI_to_endpoint>

<sandro> PROPOSED: We add to TriG an optional 5 column relationship-indiciator, which defaults to "loose association" as now.

<AndyS> <> :namingStyle rdf:GBoxIdentifies .

<cygri> tlebo, my question was about the relationship

<iand> wikipedia says "A fifth column is a group of people who clandestinely undermine a larger group such as a nation from within."

gavinc: 5th column does NOT mean fifth column.

context is already handled by where it is and where it came from - this is already represented.

s/represented/representable/

sandro: could read the manifest as triples if you'd like.

still manifests

<gavinc> TriG <G1> <eg:labeling-a-snap> {<s> <p> <o> }?

<> prov:wasDerivedFrom :process_of_dumping_SPARQL_endpoint .

<> prov:wasDerivedFrom : process_of_dumping_SPARQL_endpoint .

cygri: many will get confused and will just put garbage into it to "fill the field"

+100 @cygri

scribe: people dont' care.

<sandro> I think you're right cygri, and I dont know what to do about it.

guus: fine, but what are the benefits?

UUU: it just needs a vocab.

<cygri> s/UUU/AndyS/

<AlexHall> it needs a vocab and a reasonable abstract syntax/semantics for RDF datasets that doesn't preclude reasonable things people want to do with that vocab

<Zakim> cygri, you wanted to ask what we would put in when dumping a sparql store

OOO: worried about the "one style" without being sure it's the right one. we already have a system to describe it (RDF)

<swh> +1 to AndyS

<sandro> +1 AndyS we can just tag the style in the TriG metadata

BBC: what do people gain? what is motivation to use it? use cases.

<gavinc> s/OOO/AndyS/

<mischat> surely when this becomes a real world problem, a WG could look at how people are tackling it in the wild

maybeAndyS: incentive is need for knowledge, but no vocab to get it. Do not completely agree with cygri that can't be useful.

<yvesr> s/BBC/yvesr

(do we need to review what <> means, and that we can describe it with RDF?)

<yvesr> s/maybeAndyS/pchampin

<cygri> s/maybeAndyS/pchampin/

guus: will revisit issues list

<AZ> bye

<zwu2> I am leaving

<Souri> I need to leave ... meeting at office

<Guus> reconvene in 5

<Guus> 5/4

<Guus> Boston: ready to reconvene?

<cygri> danbri, thanks for http://www.w3.org/mid/CAFNgM+YE1Ld6iZdjYVQCGEuDw-L44PB1PAjt=e4XYJ389vORkQ@mail.gmail.com … well put!

<cygri> ACTION: cygri to update rdf-concepts re ISSUE-71 [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action01]

<trackbot> Created ACTION-97 - Update rdf-concepts re ISSUE-71 [on Richard Cyganiak - due 2011-10-20].

<iand> example of my use of graph literals: http://schemapedia.com/examples/cf314c8dab338aa1edaa93df2b54ad7b.rdf

<iand> no datatype though

<iand> schemapedia.com/examples/cf314c8dab338aa1edaa93df2b54ad7b.ttl is turtle version

<iand> http://schemapedia.com/examples/cf314c8dab338aa1edaa93df2b54ad7b.ttl

<iand> my use case is to embed examples of usage (i.e. to mention a set of triples without asserting them)

Raised Issues

<gavinc> http://www.w3.org/2011/rdf-wg/track/issues/raised

<NickH> scribe NickH

<NickH> scribe: NickH

<davidwood> scribe: NickH

davidwood: there are 8 issues marked as raised
... think we want to open all of these
... ISSUE-63 is the only one that is a black hole

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

<LeeF> ISSUE-50?

<trackbot> ISSUE-50 -- Revisit "Request to allow b-nodes as property labels" -- raised

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

<LeeF> ISSUE-63?

<trackbot> ISSUE-63 -- Introduce an HTML5 datatype -- raised

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

davidwood: issue-50 is left over. We should mark it as declined because it isn't part of our charter

<sandro> http://www.w3.org/2011/rdf-wg/track/issues/raised

<davidwood> Propose to close ISSUE-50 stating that this WG will not revisit this issue because it is not chartered to do so.

<iand> +1

<gavinc> +1

<AndyS1> +1

+1

<pchampin> +1

<cygri> +2

<AlexHall> +1

<yvesr> +1

<sandro> +1 bnodes as predicate identifiers? kinda late for that in RDF.

RESOLVED

RESOLVED close ISSUE-50 stating that this WG will not revisit this issue because it is not chartered to do so.

<sandro> RESOLVED: close ISSUE-50 stating that this WG will not revisit this issue because it is not chartered to do so.

<sandro> (need the colon)

<sandro> +1 open the RAISED issues

davidwood: 7 remaining issues marked as 'raised'
... any disscussion about these issues?

<gavinc> +1

<gavinc> http://www.w3.org/2000/03/rdf-tracking/#rdf-fragids-in-embedded-rdf

cygri: ISSUE-37 I am struggling to remember it
... left over from the previous group
... it is reasonable to open it and think about if we should do anything about

Guus: unlikely to result in spec change
... but might lead to some extra documentation

<cygri> +1 to opening all other raised issues

davidwood: chairs can open the remaining issues but didn't want to open things that didn't need opening
... lets move on to open issues
... lets focus on the open graph issues

Open Issues

<davidwood> http://www.w3.org/2011/rdf-wg/track/issues/open?sort=product

cygri: the products that we have at the moment are cleanup tasks, then each of the task forces

<sandro> +1 products = specs, if possible

cygri: might be good the have products for each of the specs

Guus: isn't a product for the primer

davidwood: can easily create new projects for primer
... created one for primer
... created one for concepts

<iand> s/projects/products/

<cygri> ISSUE-76?

<trackbot> ISSUE-76 -- RDF Semantics and RDF Concepts disagree on definition of datatypes -- open

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

davidwood: ISSUE-76 - which does it belong
... putting it into concecpts

cygri: it should go under semantics

<LeeF> ISSUE-75?

<trackbot> ISSUE-75 -- Valid plain literals containing #x0 are ill-typed in RDF 1.1 -- open

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

davidwood: where would you put ISSUE-75?

cygri: concepts

davidwood: last uncategorised on is ISSUE-39

<scribe> ACTION: sandro to rdf: and rdfs: namespace should resolve to something that meets best practices [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action02]

<trackbot> Created ACTION-98 - Rdf: and rdfs: namespace should resolve to something that meets best practices [on Sandro Hawke - due 2011-10-20].

<davidwood> CLOSED: ISSUE-39

CLOSE: ISSUE-39

davidwood: everything is categorised correctly more or less
... starting with cleanup tasks

ISSUE-6?

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

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

<gavinc> Better view: http://www.w3.org/2011/rdf-wg/track/products/5

davidwood: asks cygri is this is done for Concepts

cygri: either been addressed or there are open issues for it

ISSUE-7?

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

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

davidwood: we have closed a number of these - can either close or open a other issue
... propose closing ISSUE-7
... spent time on this in several telecons in June
... confident that we can close this

<davidwood> Closed ISSUE-7 because all leftover issues have either resulted in new open issues or closed issues due to compliance with our charter.

ISSUE-9?

<trackbot> ISSUE-9 -- Inference rules are incomplete in the RDF Semantics -- open

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

<AlexHall> fyi, issues 42-62 cover the postponed issues from last wg

<davidwood> http://www.w3.org/2011/rdf-wg/track/issues/9

davidwood: what does pfps want to do with ISSUE-9?

pfps: we should deal with it

Guus: added a product 'RDF Semantics' and moved it there

ISSUE-10?

<trackbot> ISSUE-10 -- Look if there are RDF(S) notions that are to be deprecated -- open

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

<danbri> cygri, re Sindice etc ... how much rss1 is still usefully out there?

davidwood: going to leave gavinc to do some work on ISSUE-10

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

davidwood: ... we leave ISSUE-11 open until our documents are closer to being ready

<gavinc> ISSUE-24?

<trackbot> ISSUE-24 -- Should we deprecate RDF containers (Alt, Bag, Seq)? -- open

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

<gavinc> ISSUE-25?

<trackbot> ISSUE-25 -- Should we deprecate (RDF 2004) reification of statements? -- open

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

<gavinc> Can close ISSUE-10

davidwood: would you like to look at ISSUE-11 in relation to SPARQL 1.1

AndyS: would rather not

ACTION sandro to look at ISSUE-11 in relation to SPARQL 1.1

<trackbot> Created ACTION-99 - Look at ISSUE-11 in relation to SPARQL 1.1 [on Sandro Hawke - due 2011-10-20].

<AlexHall> deprecated/archaic features: http://www.w3.org/2011/rdf-wg/wiki/ArchaicFeatures (needs clean-up)

<sandro> ACTION: sandro to ask editors of SPARQL Entailment Regimes what they'd suggest RDF specs says about their work. [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action03]

<trackbot> Created ACTION-100 - Ask editors of SPARQL Entailment Regimes what they'd suggest RDF specs says about their work. [on Sandro Hawke - due 2011-10-20].

<gavinc> Really? RDF XML Literals got lucky 13?

Guus: leave ISSUE-13 open for now

davidwood: if you think we are ready to close ISSUEs-24 and ISSUE-25, then go for it now

<sandro> STRAWPOLL: we'll suggest people stop using RDF containers (Alt, Bag, Seq) in new work.

+1

<sandro> STRAWPOLL: we'll suggest people stop using RDF containers (Alt, Bag, Seq) in new work. (and close ISSUE-24)

<sandro> +1

+1

<davidwood> +1

<LeeF> +1

<iand> -1

<AlexHall> +1

<danbri> Propose: "WG resolves that representing 'ordering' in any open world binary-relation logic language is intrinsically rather annoying; practitioners are notified that RDF containers are annoying, but so are the linked list thingies, and each may be differingly annoying in different situations."

<Zakim> cygri, you wanted to ask if we can get products in the tracker for all specs and to ask what they should use instead

<danbri> -0.12

cygri: what is the alternative? Can we put some test in describing what people should do?

davidwood: we should promote RDF Lists

<sandro> s/davidwood/sandro/

iand: I don't agree that we should tell people to stop using them

<AndyS> -X unless we propose an alternative (not sure on X yet)

<danbri> proposed: "Bag and Alt are mostly harmless, mostly useless."

davidwood: can I suggest that we have a proposal that we vote on, to jsut depricate Alt and Bag

s/jsut/just/

<davidwood> Propose to deprecate ALT with the language proposed at http://www.w3.org/2011/rdf-wg/wiki/ArchaicFeatures

sandro: is anyone going to object to deprecating Bag and Alt?

iand: yes

danbri: yes

<danbri> ' This is an archaic feature of RDF. It was included in the RDF specifications published in 1999 and 2004, but we no longer recommend it be used in new deployments. Some existing software uses it, however, and it will be present in some archival data, so general purpose software must handle it correctly. See @@@ for a more information.'

<pfps> +1

davidwood: deprecate does not mean remove

<iand> +1 to archaic

danbri: I don't like deprecate and rdf:Seq has its uses
... language will be 'This is an archaic feature of RDF'

<cygri> +1 to the text in wiki/ArchaicFeatures for alt, bag and seq

s/danbri/davidwood/

<sandro> PROPOSED: Mark rdf:Alt as an archaic features of RDF

danbri: I don't object

iand: I don't object

<MacTed> +1 proposal

<danbri> Ian agrees with me

<swh> +1

<iand> i agree with dan

iand: I agree with danbri

<sandro> PROPOSED: Mark rdf:Alt as an archaic features of RDF

<gavinc> +1

+1

<sandro> +1

<iand> +1

<davidwood> +1

<pfps> +1

<swh> +1

<Guus> =1

<mischat> PROPOSED: Mark rdf:Alt and rdf:Bag as an archaic features of RDF ?

<pchampin> +1

<danbri> stop calling it 'deprecated' please, that's too harsh terminology. I do not want to tell people that their data is bad; just that it is unfashionable.

<mischat> s/PROPOSED: Mark rdf:Alt and rdf:Bag as an archaic features of RDF \?//

<sandro> RESOLVED: Mark rdf:Alt as an archaic features of RDF

davidwood: we won't use the term 'deprecated' anymore

<davidwood> RESOLVED: Mark rdf:Alt as an archaic features of RDF

<davidwood> PROPOSED: Mark rdf:Bag as an archaic features of RDF

<sandro> +1

+1

<iand> +1

<MacTed> +1

<pfps> +1

<danbri> +1

<swh> +1

<davidwood> +1

<mischat> +1

<pchampin> +1

ericP: what is the alternative?

<yvesr> +1

<sandro> eric: I don't know what to tell people to use instead. Maybe x hasFlagColor :red, :blue, :green

ericP: I am not really sure what to tell people
... is the answer to tell people to use a repeated property?

<iand> people can use custom sequence properties, ex:sequence "1"

<sandro> davidwood: I use a repeated property, possibly off another node.

<pchampin> @ericP: that would be my answer

<gavinc> +1

davidwood: are you going to formally object?

ericP: no, no

<davidwood> RESOLVED: Mark rdf:Bag as an archaic features of RDF

sandro: is anyone objecting?

danbri: yes
... going to close ISSUE-24

<sandro> s/?/ to doing this with Seq?/

s/danbri/davidwood/

davidwood: closing ISSUE-24

<sandro> ISSUE: Should we mark rdf:Seq as archaic (cf ISSUE-24)

<trackbot> Created ISSUE-77 - Should we mark rdf:Seq as archaic (cf ISSUE-24) ; please complete additional details at http://www.w3.org/2011/rdf-wg/track/issues/77/edit .

danbri leaves

Guus is packing up

Guus: my plane is in 2 hours

davidwood: I missed you Guus

ISSUE-25?

<trackbot> ISSUE-25 -- Should we deprecate (RDF 2004) reification of statements? -- open

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

<tlebo> owl 2 annotations don't carry any truthfulness in them.

pfps: sparql annotations and RDF Reification are completely different

<tlebo> RDF's intent was to be "truthiness"

<yvesr> s/sparql/OWL

<tlebo> "owl annotations are just data sitting on the side; do with it what you will"

pfps: when you talk about the truthiness of the Reification, you get the truthiness of the RDF

<AndyS> statings

davidwood: when you make a statement about another statement - you are saying something about it
... I could say that it is false
... I think what pfps is saying is, the ability for you saying that statement is true is by expessing a fact about another triple
... I am not saying I agree with it, I am saying I understand what he is saying

<tlebo> RDF had more "truthiness" of the triple cited; while OWL 2 is completely agnostic to the truth of the triple being cited.

<tlebo> Then let's deprecate RDF reification and use OWL 2 if we still want it.

davidwood: there is no explicit truthiness tie, just making a statement

<pfps> owl 2 annotations aren't about statements at all, of course, they are "about" classes (or ....)

<tlebo> the rdfs:range of owl:annotatedSource is owl:Class ?

sandro: happy to mark Reification as archaic as long as we can provide something to replace it with

<tlebo> (@pfps)

<pfps> saying Bird creationdate 11/11/11 isn't saying something about a logical construct, but is instead might be saying something about an object

davidwood: I didn't hear pfps respone to my paraphrasing of him
... not concened about OWL annotations - interested in the deprecation of RDF Reification

<davidwood> Straw poll: Should we mark rdf 2004 reification as archaic?

<ericP> -0

<gavin_> -0 to wait until something can replace it exists

iand: want to make a distinction between reification mechanics and the language used for reification
... happy to make reification mechanics as archaic
... as long as the language remains
... the Talis changespec uses RDF reification

<yvesr> -0 until we understand what we're going to do about graphs and whether we can describe how users can replace one by the other

<sandro> sandro: so let's postpone issue-25 until we have a better solution, then we can mark RDF reificaton as archaic.

<sandro> ian: The reification mechanics (the vocab) are different from the concept of reification in general

<sandro> maybe I got that wrong...

<sandro> ian: I need the reif spec.

<sandro> s/spev/vocab/

<tlebo> (sorry, @iand - I think i was using @iand to reference Ivan earlier...)

pchampin: we are depreicating the non existant reification mechanics

davidwood: is there something better?

<cygri> +1 to the archaification of reification

iand: I can't think of anyting better at the moment

swh: archaic just means that you shouldn't do anything new with it, not that you can't use it for old things

<LeeF> ISSUE-37?

<trackbot> ISSUE-37 -- Handling of fragment identifiers in RDF embedded in other document formats -- open

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

<LeeF> ISSUE-46?

<trackbot> ISSUE-46 -- Revisit "Should RDF have a mechanism for declaring two uri's to be equivalent?" -- open

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

iand: might be a long time before I can change, don't like that idea of my customers using something marked as archaic

<cygri> ACTION: cygri to propose resolution for ISSUE-37 and ISSUE-69 [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action04]

<trackbot> Created ACTION-101 - Propose resolution for ISSUE-37 and ISSUE-69 [on Richard Cyganiak - due 2011-10-20].

pchampin: my memory of it was that I was the only one who wanted to discuss it
... I had a feeling that people were strongly opposed to it

<gavin_> +0.5 to include sameAssness in RDF (would defer to JJC for a full +1)

pchampin: I can live without it

<AlexHall> http://www.w3.org/2011/rdf-wg/meeting/2011-05-04#ISSUE__2d_46__3f_

<iand> for clarity on ISSUE-25: reification mechanics is http://www.w3.org/TR/REC-rdf-syntax/#section-Reification and reification vocabulary is http://www.w3.org/TR/rdf-schema/#ch_reificationvocab

<AndyS> rdf:sameAs owl:sameAs owl:sameAs

<gavin_> Yes, that ;)

<iand> rdf:sameAs owl:equivalentProperty owl:sameAs

<davidwood> Propose to close ISSUE-46 because owl:sameAs is already widely used and accepted. This WG has no better answer.

<pchampin> rdf:sameAs rdf:sameAs owl:sameAs

<pfps> +1

+1

<cygri> +!

<gavin_> -0.5 as it adds little bits of OWL when you really don

<cygri> +1

<gavin_> 't need it

<iand> -0

<sandro> +1

<MacTed> +1

<pchampin> +0

<AlexHall> +1

<AndyS> +0.5

<tlebo> OWL is just another vocabulary.

<iand> +1

<AndyS> (other useful owl-isms?)

<davidwood> RESOLVED: Close ISSUE-46 with no action.

<gavin_> Yeah, basiclly RDFS Plus

<pchampin> @Andy: InverseFunctionalProperty ?

<gavin_> owl:sameAs and owl:import

<iand> wasn't owl:imports a bug? :)

<pchampin> owl:imports owl:sameAs rdf:subject

<AndyS> IFP, FP, symmetric,...

ISSUE-62?

<trackbot> ISSUE-62 -- Revisit "The test cases manifest format has a semantic error" -- open

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

davidwood: had anyone looked at test cases recently?
... would anyone like to volenteer to take over the RDF test cases?

<silence>

davidwood: will have to rope ericP into it later

ISSUE-1?

<trackbot> ISSUE-1 -- Is TURTLE the same as SPARQL 1.1 triple syntax? -- open

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

<tlebo> @iand, "URI reference event r" from http://www.w3.org/TR/REC-rdf-syntax/#section-Reification; huh?

<AndyS> http://lists.w3.org/Archives/Public/www-rdf-comments/2003OctDec/0174.html Test case semantic error

<sandro> gavin_: "Yes, But...."

gavin_: escaoping...
... they could be the same apart from some well motivated exceptions

<sandro> PROPOSED: Close issue-1 saying they should be the same except for well-motivated (and small) exceptions.

davidwood: not sure we have resolved this issue

<cygri> +1

<sandro> +1

sandro: I think we can close this issue

<gavin_> +1

<davidwood> +1

<AndyS> suggest one SPARQL and one RDF person catelogue differences

<MacTed> +1

<gavin_> Hi Andy ;)

+1

<sandro> RESOLVED: Close issue-1 saying they should be the same except for well-motivated (and small) exceptions.

gavin_: until Turtle gets closer to being final, hope that the differences will go away

AndyS: no point if you have resolved it
... we should have a definativce cataglogue of what the differences are

<pchampin> s/definativce/definitive/

AndyS: and then work out if it makes sense or not
... I volenteer to do the work from the SPARQL side

<AndyS> For now, on the wiki.

davidwood: who shall do the work from the Turtle side?

gavin_: me

<AndyS> NB This applies to TriG as well. e.g. trailing DOT

<davidwood> Andy and Gavin will create a list of issues between SPARQL and Turtle. The list will be maintained on the RDF WG wiki and may become an appendix to the Turtle spec.

AndyS: yes, that is fine

gavin_: yup

<tlebo> +1

<tlebo> (we have issues)

<yvesr> no

davidwood: we resolve to put N-Triples into the Turtle document

gavin_: no resolution on what to do with old N-Triples that doesn't have a media type and new n-Triples that does have a media type

<AndyS> As long as there is a NT language and mime type (and its suggested to use UTF-8) somewhere

<AndyS> Ditto NQ

ISSUE-19?

<trackbot> ISSUE-19 -- Should TURTLE allow triples like "[ :p 123 ]." as SPARQL does ? -- open

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

gavin_: this can be resolved closed as a duplicate of ISSUE-1
... I have just closed ISSUE-1

ISSUE-73?

<trackbot> ISSUE-73 -- IRI_REF vs. IRIref -- open

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

gavin_: I need to resolve this with AndyS

davidwood: do you need help from the working group?

gavin_: I need help from AndyS
... they are subtly different
... they shouldn't be combined, they should be renamed

ISSUE-74?

<trackbot> ISSUE-74 -- Prefixed names and slashes -- open

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

gavin_: this is actually a working group issue

both are agreed and people think both are right

davidwood: end of the Turtle Issues
... lets go to RDF General

ISSUE-3?

<trackbot> ISSUE-3 -- Between us, we need to study the feedback we got via http://lists.w3.org/Archives/Public/www-rdf-comments/ on the previous round of specs (and errata) -- open

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

davidwood: certainly have to do that, certainly havn't done it
... lets move on

sandro: if it doesn't require a working group decision, better to put an action on somebody

davidwood: I think we should put an action on Ivan
... I can't imageine who else could do this well

sandro: I think cygri would do a good job

<tlebo> also not hearing things.

cygri: I am not going to volenteer for this because I think it is going to be a lot of work

davidwood: wondering if one of Guus's students might want to do this

work for someone young, keen and wanting to prove himself

<sandro> ACTION: davidwood ask Guus to find a student to do the work of ISSUE-3 [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action05]

<trackbot> Created ACTION-102 - Ask Guus to find a student to do the work of ISSUE-3 [on David Wood - due 2011-10-20].

<Scott_Bauer> scribe: scott

<sandro> scribe: scott

<Scott_Bauer> davidwood: issue 65 where do these exist?

<LeeF> ISSUE-65?

<trackbot> ISSUE-65 -- Update XSD 1.0 references to XSD 1.1 -- open

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

<Scott_Bauer> davidwood: we have rdf concepts written when rdf was xml. We ought to push xsd to serializations.

<Scott_Bauer> … need to change wording in concepts.

<Scott_Bauer> cygri: a broader point. Can't have a literal anymore in 1.1. need something more in rdf concepts

<Scott_Bauer> … datatypes only get into rdf when you get into semantics. needs to change.

<gavin_> s/literal/plain literal/

<Scott_Bauer> … needs to somehow include xsd: string

<Scott_Bauer> davidwood: we have clean up to do in rdf concepts

<Scott_Bauer> … section 5 datatypes.

<cygri> ACTION: cygri to mention ISSUE-65 in RDF Concepts ED (Section 5) [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action06]

<trackbot> Created ACTION-103 - Mention ISSUE-65 in RDF Concepts ED (Section 5) [on Richard Cyganiak - due 2011-10-20].

<Scott_Bauer> ACTION: cygri to add issue 65 as an issue on the rdf concepts section 5 datatypes [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action07]

<trackbot> Created ACTION-104 - Add issue 65 as an issue on the rdf concepts section 5 datatypes [on Richard Cyganiak - due 2011-10-20].

<Scott_Bauer> davidwood: alex does that address your issue on issue 65

<Scott_Bauer> … richard I propose to take your action and close action 65.

<Scott_Bauer> sandro: at this point its in CR

<Scott_Bauer> davidwood: we can raise an new issue if it stalls

<Scott_Bauer> … closing issue 65 moving to an editorial action.

<Scott_Bauer> … on rdf concepts

issue 66

<Scott_Bauer> davidwood: this needs to be a semantics issue

<Scott_Bauer> alexwood: owl2 and rid add some not referenced in semantics

<davidwood> s/alexwood/alexhall/

<Scott_Bauer> cygrid: the concepts in rdf semantics are practical and should be in semantics

<Scott_Bauer> s/cygrid/cygri

<pchampin> s/concepts/list of XSD datatypes/

<iand> he said the datatype list should be in concepts (as well as semantics)

<gavin_> +1

<pchampin> s/be in semantics/be in RDF concepts/

<Scott_Bauer> cygri: list of datatypes that are in recommended for use in semantics should be in concepts

<mischat> +1

<iand> +1

<pchampin> +1

<Scott_Bauer> davidwood: i concur

<yvesr> +1

<davidwood> +1

<Scott_Bauer> ACTION: cygri contact pat and peter and make sure they are ok with this [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action08]

<trackbot> Created ACTION-105 - Contact pat and peter and make sure they are ok with this [on Richard Cyganiak - due 2011-10-20].

<Scott_Bauer> davidwood: lets leave graphs alone

<gavin_> ACTION: gavinc add link from Turtle datatypes section to recommended list in concepts [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action09]

<trackbot> Created ACTION-106 - Add link from Turtle datatypes section to recommended list in concepts [on Gavin Carothers - due 2011-10-20].

<Scott_Bauer> davidwood: topic issue 16

issue 16

<cygri> ISSUE-16?

<trackbot> ISSUE-16 -- What is the normative serialization of the JSON grammar? -- open

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

<Scott_Bauer> davidwood: should this be an issue at all?

<Scott_Bauer> … this should remain open and we move on

issue 69

<Scott_Bauer> davidwood: richard gave himself an action for 34 and 69. will propose something

issue 70

<Scott_Bauer> davidwood: close as an editorial issue

<Scott_Bauer> … ?

<Scott_Bauer> cygri: I'd like to keep it open

<gavin_> issue-75?

<trackbot> ISSUE-75 -- Valid plain literals containing #x0 are ill-typed in RDF 1.1 -- open

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

issue 75

<Scott_Bauer> cygri: unicode not allowed in xml version. all sorts of formerly valid rdf plain literals are no longer valid

<Scott_Bauer> … unicode .0

<Scott_Bauer> davidwood: what should the resolution be?

<Scott_Bauer> cygri: we should have all the changes rdf 1.0 and 1.1 in same place.

<Scott_Bauer> sandro: put it in use cases and requirements?

<Scott_Bauer> cygri: do we have such a document?

<Scott_Bauer> sandro: no

<iand> we should notify community early to see if it breaks any implementations

<Scott_Bauer> davidwood: will create a note -- not an action item.

<Scott_Bauer> …

<Scott_Bauer> sandro: we put it in rdf concepts now?

<AlexHall> how many implementors validate xsd:strings right now?

<iand> we could write a negative test case: :x :y "\u0000" .

<iand> ask implementors to try that test and see if they handle it

<Scott_Bauer> letting cygri create the action item?

<cygri> ACTION: cygri to add a note to RDF Concepts re ISSUE-75 [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action10]

<trackbot> Created ACTION-107 - Add a note to RDF Concepts re ISSUE-75 [on Richard Cyganiak - due 2011-10-20].

<sandro> gavin_: This wasn't a problem pre-turtle because no syntax could express it.

<Scott_Bauer> davidwood: Ian's says it should be a test case

<Scott_Bauer> gavinc: it can't be expressed in n-triples

<Scott_Bauer> sandro: it's a syntax error -- you expect it to fail

<iand> it can be expressed in ntriples (as above) but it is just datatype invalid

issue 76

<cygri> sandro++

<Scott_Bauer> sandro: close issue 75 first

<iand> If i can write "x"^^xsd:int then I can write "\u0000"^^xsd:string

<Scott_Bauer> davidwood: closing issue 75

<Scott_Bauer> … issue 76 overcome by events if datatypes move from semantics to concepts

<Scott_Bauer> cygri: it's a bug and needs to stay open.

<Scott_Bauer> davidwood: we resolved this at an earlier date but we forgot to close it

<Scott_Bauer> davidwood: pat closed it

ACTION-76?

<trackbot> ACTION-76 -- Patrick Hayes to summarize the options -- due 2011-08-24 -- CLOSED

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/76

<Scott_Bauer> this was action 76

<gavin_> iand, I agree (sort of) but I don't think you could write Recomended RDF that used #x0 at all.

<gavin_> by a strict reading of the specifications

<Scott_Bauer> davidwood: ACTION: check with pat hayes to see if issue 76 can be closed

<Scott_Bauer> ACTION: check with pat hayes to see if issue 76 can be closed [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action11]

<trackbot> Sorry, couldn't find user - check

<davidwood> ACTION: davidwood to check with pat hayes to see if issue 76 can be closed [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action12]

<trackbot> Created ACTION-108 - Check with pat hayes to see if issue 76 can be closed [on David Wood - due 2011-10-20].

<Scott_Bauer> davidwood: only other issues are with graphs

<Scott_Bauer> … we can do issues for graphs or we can talk about the primer

<cygri> "Review of all outstanding Documents that the WG is updating."

<Scott_Bauer> sandro: issue 21 re node sharing is a possibilities

<Scott_Bauer> cygri: let's not look at graphs now

<gavin_> +1 no more talking about graphs

<iand> no issues were raised from our f2f discussions on named graphs. pity we couldn't get concrete issues from them

<iand> gavin_: we can't talk about graphs anyway

<Zakim> cygri, you wanted to suggest "Review of all outstanding Documents that the WG is updating."

<sandro> indeed, iand.... :-(

<Scott_Bauer> … review outstanding documents

<Scott_Bauer> … need editors drafts for other documents

<Scott_Bauer> … check up on prospective editors for these

<Scott_Bauer> davidwood: we should look into the editors list

<Scott_Bauer> sandro: we need to do one issue per week before last call

<Scott_Bauer> davidwood: let's go through the editors list

<Scott_Bauer> … we'll do the primer if we have time.

<sandro> s/do one/close one (on average)/

<Scott_Bauer> … vocabulary. we had dan brickley. Do we need a co-editor

<Scott_Bauer> … anyone interested

<pchampin> and if he does, I volunteer

<Scott_Bauer> ACTION: davidwood ask danbri if he would like a co-editor on vocabulary [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action13]

<trackbot> Created ACTION-109 - Ask danbri if he would like a co-editor on vocabulary [on David Wood - due 2011-10-20].

<Scott_Bauer> davidwood: n-triples two oracle editors on one documents.

<Scott_Bauer> gavinc: they raised objections and were made editors as a result.

<Scott_Bauer> davidwood: a fait accompli n-triples will be a part of the turtle doc

<iand> thanks sandro - i work better through the medium of text :)

<Scott_Bauer> … sour and she will work with gavin on the document

<Scott_Bauer> s/sour/souri

<gavin_> s/she/zhe/

<Guus> [from Heathrow]

<gavin_> This is the Linked Data API stuff yes?

<Scott_Bauer> davidwood: yves could you describe any progress on the JSON recipes note

<Scott_Bauer> yvesr: have not started on it yet.

<Scott_Bauer> ACTION: davidwood ping fabian re rdf syntax spec revised [recorded in http://www.w3.org/2011/10/13-rdf-wg-minutes.html#action14]

<trackbot> Created ACTION-110 - Ping fabian re rdf syntax spec revised [on David Wood - due 2011-10-20].

<Scott_Bauer> davidwood: richard the n-quad syntax?

<Scott_Bauer> cygri: we don't know what's going to have until abstract syntax is better developed

<Scott_Bauer> … might be part of the turtle work for eric or gavin?

<Scott_Bauer> davidwood: I disagree. we agreed that turtle would not deal with named graphs.

<Scott_Bauer> gavinc: I'm willing to work with someone on the the trig syntax.

<Scott_Bauer> … I'd like someone else to co-edit

<Scott_Bauer> cygri: trig and n-quads I've worked with but syntax is a lot of detailed syntax gavin is better at.

<Scott_Bauer> … grammar is 95% the same

<Scott_Bauer> gavin: I need some else but I agree

<Scott_Bauer> … the grammar will not be repeated.

<Scott_Bauer> cygri: Once we know abstract syntax we should revisit.

<Scott_Bauer> … concepts work is unknown. Work may go well

<Scott_Bauer> … I might consider in the future but not now.

<Scott_Bauer> davidwood: process question for sandro.

<sandro> change the shortname "rdf-syntax-grammar" to "rdf-xml"

<sandro> seems fine to me.

<Scott_Bauer> davidwood: should we do anything with our last 30 minutes

<Scott_Bauer> sandro: I have much of the scribe cleanup done but you are free to clean them up as necessary.

<Scott_Bauer> … (referring to the minutes)

<Scott_Bauer> davidwood: rdf primer is scheduled what do people want?

<Scott_Bauer> sandro: will it be a multi syntax document

<Guus> should come back on a telecon

<Scott_Bauer> davidwood: that would be great

<Guus> 1st version turtle/trig, add others later

<Scott_Bauer> … good for the community if all the serializations are represented in the primer.

<Guus> sure

<Scott_Bauer> gavinc: only one will have named graphs or can deal with it.

<Scott_Bauer> sandro: convenient in trig doable in others

<Scott_Bauer> … near a clear model use trig

<sandro> sandro: Once we have a clear enough model, I think it will be easy enough to define a useable way to do it in pure triples.

<Scott_Bauer> s/near a clear mode/need a clear model/

<sandro> PROPOSED: The primer should have examples in each of our syntaxes

<gavin_> +1

<pchampin> +1

<MacTed> +1

<sandro> +1

<davidwood> +1

<Scott_Bauer> +1

<Guus> +1

<sandro> RESOLVED: The primer should have examples in each of our syntaxes

<sandro> PROPOSED: The primer should have a section on each of our syntaxes

<davidwood> +1

<gavin_> +1

<MacTed> +1

<sandro> +1

<pchampin> +1

<Scott_Bauer> +1

<sandro> RESOLVED: The primer should have a section on each of our syntaxes

<sandro> PROPOSED: The primer should be 500 bytes long.

<Guus> this section may be an appendix

<sandro> PROPOSED: The section on RDF/XML should not be first

<pchampin> +1000

<Guus> good to limit main text length

<sandro> Guus? I thought you left...

<Guus> [anybody hearing me?]

<davidwood> PROPOSED: The section on RDF/XML should be the last syntactical section. Turtle should be first.

<cygri> PROPOSED: The full text for the RDF/XML section should be: “Don't.”

<davidwood> Guus: We don't hear you

<davidwood> Please vote on:

<davidwood> PROPOSED: The section on RDF/XML should be the last syntactical section.  Turtle should be first.

<MacTed> +1

<cygri> +1

<pchampin> +1

<AlexHall> +1

<gavin_> +1 given that we resolve name graphs in turtle ;)

<Guus> i think this is going in tto much detail, just formulate reqs, not structure

<sandro> +0 I think that's a little much

<gavin_> hehe

<gavin_> You think? ;)

<gavin_> AlexHall: What font should we use?

<sandro> PROPOSED: Adjourn

<Guus> +1

<Scott_Bauer> +1

<gavin_> +1

<sandro> ADJOURNED

<cygri> +1

<MacTed> +1

<LeeF> thanks very much to davidwood and Guus!

<gavin_> trackbot, end meeting

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Andy/Tim/
Succeeded: s/given cygri's email/given Pat's email/
Succeeded: s/to do RDF/to annotate RDF to specify which type of dataset you're using/
Succeeded: s/makign /making /
Succeeded: s/danbri/sandro: danbri,/
Succeeded: s/provide a standard way/write some text about/
Succeeded: s/their 'name'/the 'name'/
Succeeded: s/describe their named graphs/describe the purpose of their named graph/
FAILED: s/document one/document at least one/
FAILED: s/strill/still/
WARNING: Bad s/// command: s/The WG/sandro/?
FAILED: s/volitatile/volatile/
FAILED: s/volitile/volatile/
FAILED: s/[]/pchampin/
FAILED: s/context ino/context info/
FAILED: s/wires/the wild/
FAILED: s/from wires/from the wild/
FAILED: s/[]/AndyS/
FAILED: s/you can't identify g-snaps/identifying g-snaps might be a problem/
Succeeded: s/x/swh/
FAILED: s/TTT/pchampin/
FAILED: s/XYZ/contexts, it just means that it that contexts do not exist outisde the semantics/
FAILED: s/as if/if/
FAILED: s/breajk/break/
FAILED: s/represented/representable/
FAILED: s/UUU/AndyS/
FAILED: s/OOO/AndyS/
FAILED: s/BBC/yvesr/
FAILED: s/maybeAndyS/pchampin/
FAILED: s/maybeAndyS/pchampin/
FAILED: s/projects/products/
FAILED: s/davidwood/sandro/
FAILED: s/jsut/just/
FAILED: s/danbri/davidwood/
FAILED: s/PROPOSED: Mark rdf:Alt and rdf:Bag as an archaic features of RDF \?//
FAILED: s/?/ to doing this with Seq?/
FAILED: s/danbri/davidwood/
FAILED: s/sparql/OWL/
FAILED: s/spev/vocab/
FAILED: s/definativce/definitive/
FAILED: s/literal/plain literal/
FAILED: s/alexwood/alexhall/
FAILED: s/cygrid/cygri/
FAILED: s/concepts/list of XSD datatypes/
FAILED: s/be in semantics/be in RDF concepts/
FAILED: s/do one/close one (on average)/
FAILED: s/sour/souri/
FAILED: s/she/zhe/
FAILED: s/near a clear mode/need a clear model/
Found ScribeNick: yvesr
Found Scribe: yvesr
Inferring ScribeNick: yvesr
Found ScribeNick: tomayac
Found Scribe: tomayac
Inferring ScribeNick: tomayac
Found ScribeNick: mischat
Found ScribeNick: mischat
Found Scribe: yvesr
Found ScribeNick: yvesr
Found Scribe: tlebo
Found ScribeNick: tlebo
Found Scribe: NickH
Found Scribe: NickH
Inferring ScribeNick: NickH
Found Scribe: scott

WARNING: "Scribe: scott" command found, 
but no lines found matching "<scott> . . . "
Continuing with ScribeNick: <NickH>
Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname.

Found Scribe: scott

WARNING: "Scribe: scott" command found, 
but no lines found matching "<scott> . . . "
Continuing with ScribeNick: <NickH>
Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname.

Scribes: yvesr, tomayac, tlebo, NickH, scott
ScribeNicks: yvesr, tomayac, mischat, tlebo, NickH
Default Present: Peter_Patel-Schneider, MIT_Meeting_Room, AZ, Guus, thomas, danbri, steve, ivan, richard, andy, ian, pchamplin, yves, nicholas, micha, TedT, BBC, cygri, mischat, NickH, yvesr, iand, swh
Present: Peter_Patel-Schneider MIT_Meeting_Room AZ Guus thomas danbri steve ivan richard andy ian pchamplin yves nicholas micha TedT BBC cygri mischat NickH yvesr iand swh

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: 13 Oct 2011
Guessing minutes URL: http://www.w3.org/2011/10/13-rdf-wg-minutes.html
People with action items: add ask cygri datatypes davidwood from gavinc guus link sandro section turtle