See also: IRC log
<trackbot> Date: 22 August 2012
<ivan> Scribe: Tom Baker
<ivan> scribenick: tbaker
<SteveH> thanks AndyS
<ivan> last meeting's minutes
<PatH> I'll be on the call in a few mins
RESOLVED - minutes accepted
Ivan: See one action from Pat - discussion of Provenance - he's not yet on call. Propose to postpone - he needs resolution on draft identification issue before we can proceed.
<ivan> Overdue actions
Ivan: Bunch of overdue
actions:
... Some are a few months old... Sandro: one from Sept 2011 -
still open?
... ACTION-82 and ACTION-98 still pending.
... ACTION-100: ask editors of SPARQL...
Sandro: never quite understood that.
<sandro> close action-100
<trackbot> ACTION-100 Ask editors of SPARQL Entailment Regimes what they'd suggest RDF specs says about their work. closed
Ivan: Pat, action on your for past year to modify RDF semantics... (ACTION-120)
<sandro> action-120?
<trackbot> ACTION-120 -- Patrick Hayes to modify RDF Semantics appropriately to hard-code the class extension of rdf:langString to the set of all pairs of strings and language tags -- due 2011-11-16 -- OPEN
<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/120
<sandro> action-140?
<trackbot> ACTION-140 -- Patrick Hayes to review XSD in RDF and OWL from semantics perspective -- due 2012-02-08 -- OPEN
<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/140
Ivan: Propose to close ACTION-140.
<gavinc> close action-140
<trackbot> ACTION-140 Review XSD in RDF and OWL from semantics perspective closed
Ivan: Pat, ACTION-166
Pat: Leave ACTION-166 and ACTION-170 open.
Ivan: ACTION-179 for Sandro - what was that?
Sandro: We included test cases in namespace. Waiting for Ian to return from vacation.
Ivan: Do we want to leave it open until inverse-property sugar issue is closed?
<ivan> close action-180
<trackbot> ACTION-180 Create a proposal for inverse property syntax in Turtle closed
<ivan> close action-181
<trackbot> ACTION-181 Start wiki page for F2F closed
<ivan> Wiki page for f2f
Ivan: Urge you to sign up for right category - whether you intend to come, or come in remotely.
<gavinc> https://www.w3.org/2011/rdf-wg/track/issues/95
Ivan: Sandro, do we have way to handle remote participation?
<gavinc> Open ISSUE-95
Ivan: We will have a phone, hardware, and line?
<gavinc> I guess that doesn't work from IRC.
Sandro: I think so, but haven't confirmed.
Ivan: Five people already want to come in remotely.
<scribe> ACTION: Sandro to check on hardware for meeting. [recorded in http://www.w3.org/2012/08/22-rdf-wg-minutes.html#action01]
<trackbot> Created ACTION-182 - Check on hardware for meeting. [on Sandro Hawke - due 2012-08-29].
Ivan: Starting next week,
vacations are over.
... I mean two weeks - 5 September.
<PatH> sudo zakim?
Ivan: We got through the admin actions!
Ivan: Just for the record...
<ivan> proposal document
Ivan: you all got this mail.
Probably nobody is completely happy. We try to find consensus
at some level and move out of current deadlock.
... Three major areas. David tried to get agreement on
fundamentals. If accepted, a bunch of details. Gives us
guidelines.
... Proposal to focus on 3 issues first: 1) terminology around
NGs that would end up in Concepts,
... 2) What we do with Semantics. Some discussion with Antoine,
Sandro, etc.
... 3) General guideline for TRIX syntax for NGs.
... Do you all agree, or propose something radically
different?
... Take silence as agreement.
<PatH> q
<PatH> q
Ivan: Start with things that will end up in Concepts.
<alanr> +1
Pat: Would not start with terminology, then semantics - would reverse the order.
<MacTed> +1 overall to that doc
Sandro: It was that we would decide to decide terminology.
Ivan: Not the specific terms to use. We try to identify the missing bit of terminology. Most of the things are coming from SPARQL documents.
<alanr> can there be a summary of the points of contention?
Ivan: In that document, we coined
RDF Spaces, or GBox (coined ages ago) - by trying to find the
right term for that - don't want to go there now - we have some
sort of symmetry of concepts that could go into Concepts.
... Comments on that issue?
<alanr> 1+
Alan: Coming in to see if I can help. Could someone summarize history of points of contention?
Ivan: "Short" overview of past 18 months would be complicated...
<gavinc> Everyone disagrees, but ends up not disagreeing and we end up talking about g-boxes a lot.
Ivan: Volunteers for 2-minute overview?
Pat: I'll give it a shot...
SPARQL has provided constructions - graphs with URIs attached -
and we have been debating what this means in RDF terms.
... Basic issues: whether graph names really name the graph, or
name something else.
... If they do name something, what do they name?
... A flavor of the issues...
... This bundle of issues got mixed up with notion that people
think of graphs, often, as something that is mutable.
... [Pat lists the over 4-5 alternative suggestions for what a
graph URI could denote]
Richard: ONe of the reasons why this graph discussion is difficult: we don't really have agreement on the big-picture goal of this effort.
<PatH> +1 to richard
Richard: At the end of the day,
we don't _have_ to do anything. SPARQL has already standardized
solutions to the problems we are trying to solve - pretty good.
So why is RDFWG dealing with this? Yes, in charter, but what
does it mean for us to be successful in this work? Do we create
point of reference for multigraph work? Use cases we want to
address?
... Different opinions on this. Difficult to know what we need
to do to be successful.
Sandro: Think - second of
Richard's options - should define things such that more use
cases become tractable. In Use Case document, federated phone
book. Many people want to express "change over time"
... Someone could come along and define that vocabulary.
Terminology and model for how to work with multiple graphs in
interoperable way. Easy to come up with stand-alone solution.
Challenge: exchange with others.
Richard: What is missing from what SPARQL already standardizes?
Sandro: The metadata - a way to hook URIs - this thing has this property - currently not clear what you are talking about.
<alanr> Classes have extensions. RDF Graphs have things that look at lot like extensions. Classes can be closed. RDF Graphs sees to want to be either open or closed. I wonder whether a) an extension to the ref semantics that adds a graph extension in addition to a property and class extension. b) Any of the use cases for using the graph name to mean other than the extension can not be handled by (a) and the fact that the domain of discourse of RDF is ref:Resource = any
Richard: So even semantics to use [] in default graph.
Ivan: Also think - agree with
Richard that most things we need have been defined by SPARQL.
That said, need place clearly referenceable for this, and only
this, topic, that is not bounced to the query language.
... Will not be clear to people what this means.
<ivan> \
Ivan: Reason why SPARQL terminology would be taken into Concept document - to be in line with SPARQL, but also to extract and put somewhere that people can cite.
Pat: Disagree. Don't think SPARQL has indeed defined these constructions.
<ericP> alan, one issue is whether our not my graph <foo> corresponds to your graph <foo>
Pat: To amplify what Sandro says: Difficult to come up with framework that can be extended for notions of time, etc.
<alanr> it does, by the approach I propose. That would be consistent with use of all other URIs
<alanr> consistency is good
<Zakim> alanr, you wanted to discuss my comment
Pat: People using RDF at edges - BBC, etc - important to clarify this big issue to help these people.
<alanr> tbaker: time needs to be its own project - very involved
<SteveH> FWIW, I've not seen this being discussed in the real world
<MacTed> +1 PatH
Alan: So shouldn't be a
competition, but ability to cover cases - want to re-use as
much as possible. In semantic extensions for RDF - class
extensions in RDFS - a URI can have several different
"attachments". One of these should be for RDF graph. Has this
been discussed?
... Need basics: "mutable" sets, document-like thinks.
Something like class extension - "semantic extension"?
<PatH> graphs can be in the rdf universe, so there can be classes of them.
Alan: If you have an RDF resource that can mean essentially anything - if it has a graph extension - this would give you possibility of extending graphs to additional, more restrictive things.
<PatH> is that enough for you?
<MacTed> :-)
Antoine: Agree with Pat when he says lots of things not defined by SPARQL. Doesn't explain what conclusions you can draw from dataset. We know what to draw from one graph, but not from a pair of Name-Graph. This is needed (in answer to Richard).
<alanr> I don't see the need for "pair" any more than we need "pair" for describing the URI, resource it refers to
<alanr> there's a name, and then there's a thing that it names
<alanr> that's the basis of RDF
<PatH> +1 alanr
Ted: What Alan said re: basics - agree. We need mutable container and immutable set which might be held in a container - those basics are in the proposed document. Why do we have to re-hash instead of focusing on proposed document?
<PatH> lets do that, indeed.
<alanr> pat: does the idea of a semantic extension that gives a resource a graph extension work?
Ivan: Lost Richard?
... Agree with Ted. Feel that document contains what we can
agree upon now. Fills in one hole - the mutable Something.
<PatH> alanr: maybe but it seems like semantic overkill.
<alanr> document will do as a name - that's what is used in other contexts
Ivan: Would appreciate agreement that this is the right direction?
<alanr> compared to the semantic onslaught on graphs it seems relatively easy ;-)
<ivan> Proposed: The WG agrees to close the loop on RDF terminology, reflecting the mutability/non mutability issue as also raised by the SPARQL 1.1. What we mean by "closing" is reflected in the symmetry of Figure 1 in the RDF Graph Identification proposal document.
Ivan: Will put in what David wrote...
<alanr> re: terminology, there are objectional uses, e.g. "dataset"
<alanr> which means a lot of things
Ivan: Emphasizing that the terminology used in that section is not final.
Sandro: So we will find a way to talk about GBox and GSnap.
<davidwood> Right, should remember our consensus where it exists :)
<alanr> sets are not mutable
<alanr> that's that
<PatH> I think we all agree on this diagram when the labels are erased :-)
<alanr> mathematics defines this
<gavinc> It's just semantics!
<alanr> (I don't like the "pair" business)
<LeeF> hi!
<alanr> that shouldn't bet there imo
<davidwood> Alanr, we have discussed this to death and is why we have the current understanding of mutable and immutable terms.
Ivan: Straw poll on the proposal?
<ivan> +1
<MacTed> +1
<AndyS> +1
<alanr> david, discussed what?
+1
<davidwood> +1
<cgreer> +1
<sandro> +1 Sure, why not
<PatH> +?
<gkellogg> +1
<Souri> +1
<AZ> +1 to section Concepts at least
<gavinc> +1 to uh, whatever the proposal is
<davidwood> alanr, we all know that math sets are immutable.
<SteveH> +1
Proposed: The WG agrees to close the loop on RDF terminology, reflecting the mutability/non mutability issue as also raised by the SPARQL 1.1. What we mean by "closing" is reflected in the symmetry of Figure 1 in the RDF Graph Identification proposal document.
<PatH> +1
<LeeF> +1
<AlexHall> +1
<pchampin_> +1
<cygri> -0.5
Ivan: Guideline on what we discuss.
Richard: Back now. I don't understand the proposal.
<alanr> not sure why datasets are just not classes of rdf graph
Richard: What is being proposed?
<MacTed> this is more straw poll than proposal, is it not?
Sandro: We will use GBox and GSnap for now. Reaffirming.
<davidwood> PatH, I'm glad to hear that we all agree on the diagram modulo the terms.
<alanr> eric: for an outsider, completely confusing
Pat: Could Sandro number nodes in that document? We could cite by number...
<sandro> sandro: that's what gbox/gsnap are.
<sandro> pat: fair enough
Ivan: More to that, to be fair. One year ago, we invented new terms only when they did not clearly exist in SPARQL. That document: 90% SPARQL + only one term not defined and used by SPARQL. If we could find a proper English term for what we are calling RDF Spaces, we could close this and move on.
<alanr> gavinc +1
Sandro: No. Two problems: the term we agree on. But also the problem that the world uses terminology inconsistently. E.g., "RDF Graph".
<PatH> lets not go there now.
<alanr> odd to be writing a standard for people who won't read standards to figure out what technical terms mean
Ivan: But we can't go back and tell SPARQL they need to re-write.
macted: No way to dodge ongoing confusing because terms used in ambiguous ways by alot of people. So that group uses terminology in an obsolete fashion.
Ivan: So you want to come up with terms different from those used for a long time?
<AndyS> It's not the SPARQL-WG - it's the community. SPARQL 1.0 followed community. It will continue. As PatH said "be loose about it" (can't remember the exact phrase)
Ted: Only terms we have used consistently: GBox and GSnap. Every term we come up with that incorporates the word graph maintains confusing because it has so many meanings. Leads to interoperability failure.
<AZ> I don't agree: can you point to a place where "RDF Graph" is misused in the last 6 months in our WG?
<PatH> Im beginning to understand why Moses had a bad temper.
<ericP> the gbox /gsnap terms are hard to improve upon
<davidwood> "RDF Graph" is defined in RDF Concepts. We could change that, but I don't see the point. Someone will object to any term. At some point, we just need to adopt a set of terms and use them consistently.
Andy: My point: think we're using SPARQL WG as symbol for "general community". Even SPARQL 1.0 was reacting to the community. "Graph" will be used loosely - will not change.
<gavinc> SO?
Y: Except RDF graph is used inconsistency too.
<ericP> just need the 3rd term for the grsph label
<Zakim> alanr, you wanted to proposed minting URIs, then creating definitions, then assigning terms.
<davidwood> We should *not* borrow trouble by pretending that we know who in reader space might find a consistent term confusing.
Alan: In order to not get stuck
on names, Gavin has suggesting giving [] - seems
sensible.
... I agree that in the way we try to build ontologies, we are
all types. We assign URIs then work hard on definitions. Then
when we're done we can worrry about names.
<AZ> The concept of "Graph" is not part of the RDF concepts, it's normal that it can be misused in the RDF community
Alan: If you look at this as six types.
<MacTed> so rather than "mint URIs" you mean "mint opaque URIs"
Ivan: They are not necessarily types.
<PatH> fwiw, my recent prposal was to bless the sloppiness of the general usage. Think of it as RDF Unitarianism.
<Zakim> cygri, you wanted to ask whether fixing use of terminology is a goal of this WG
Alan: Why not? Each term refers to something that has properties. That is what a type is.
Richard: Lots of terms that we use and that needed to be agreed, and do not correspond to types - e.g., subject, predicate....
<alanr> a type is precisely a bunch of things that share properties
<alanr> pat: hate to disagree, but really, do you think that will help interoperability?
Richard: Am I hearing from some that they have the ambition to fix the misuse of terminology in the community? Do we want to come up with a terminology that my include, or deviate from, existing terminology? Is this a requirement for WG to succeed.
Sandro Btw goal and requirement. Hard to succeed if we don't get the terminology.
<sandro> sandro: I think good terminology will help us a lot.
<davidwood> The goal is, IMO, to align our new documents with terms that are used in other W3 documents and extend as needed (but only as needed).
Y: Trying to get new set not prone to misuse.
<PatH> alanr, i dont think terminology is relevant to interoperation much at all.
Ivan: That train may be gone. I
would now be happy if we could document exactly the way
terminology used out there, and only add terminology where
needed to make things clear.
... Turn around Richard's question: What would you like to see
there?
Richard: Would like to see, eventually, the bits of SPARQL - RDF datasets definition - the upper half of [this circle in the diagram - URL please!].
<alanr> pat: I interpreted "sloppiness of general usage" to mean no distinct set of names, each of which means a specific sort of thing. Did you mean something different?
<sandro> Diagram appears here: http://www.w3.org/2012/08/RDFNG.html#concepts
Richard: in the lower half of the document, mutable RDF dataset, then slot that binds [x]. Both not particularly happy with terms there now and not 100% convinced why we need them all. Hence: what are we trying to achieve? Do we want to...
<alanr> you need a glossary and translation guide.
Richard: SPARQL Update defines
Graph Store - do we want to cover that? If we want to cover all
relevant concepts from RDF specs, then we need. But if goal is
to cover use cases, then unclear whether needed.
... The GBox thing: we need to define something. The rest: not
sure we need.
<alanr> tbaker: according to the diagram "mutable rdf dataset" is a contradiction in terms
<PatH> alanr, not exactly. See http://lists.w3.org/Archives/Public/public-rdf-wg/2012Aug/0075.html
Richard: Will need something for GBox - explain how this concept relates to real world where things change.
<davidwood> PatH, +1
<davidwood> Please note that this WG never changes :)
<alanr> pat: concur in general, and note FixedResource in web document language. Ability to subclass is essential, which is why I'm surprised these aren't considered types. Then they could be organized
<alanr> so immutable ref graph (according to document) is analogous to FixedResource
<PatH> davidwood, lol.
Y: Things which change over time
- exists in nature. If you have to express this concept, must
be able to discuss State A and State B - name them. I'd like to
think these are Datasets (in current). Prefer to call GSnap.
Temporal snapshot of a thing which changes over time (usefully
called GBox). If we didn't need, we wouldn't have come up with
them and used them so consistently. We...
... have demonstrated that we need these.
<davidwood> Perhaps we should add the terms g-box, g-box and g-snap to the diagram, if only temporarily.
Richard: I said GBox - we will need. So we're not disagreeing about that.
<alanr> pat: also note that in web arch, we don't sanction just *any* change. We say that "cool uris don't change"
Richard: Not sure we need Slots and Graph Store, or equivalents. Lower-right part.
Y: Hear what you are saying. I think those things make the picture clearer.
<PatH> But when they do, we dont say that a definition has been violated.
<alanr> This person who hasn't been part,will be rather shocked at this diagram
<davidwood> To me, the symmetry of the diagram proves that all the concepts should be represented. That helps comprehension.
Ivan: Agree with Pat. When we came up with this diagram, things became clearer - i.e., concepts that are already out there. I personally think the lower half of the doc is necessary.
<alanr> you have a perfectly good set of tools to define and relate terms (RDF/OWL) and instead you decide to use ad-hoc stuff. Eat your own dogwood?
<TedH> dogwood?
Ivan: Not sure about changing existing terms, where we might create more harm by changing than by using terms that are sloppily used.
<alanr> dogfood :)
<alanr> damn fingers
<PatH> pat has been muted for a while now, guys.
<gavinc> I agree with cygri, I am confused that my website has become a graph store
<alanr> unambiguity can never be resolved by "terms". URIs do better, I hear ;)
Richard: Sounds okay - makes
sense. One thing: Graph Store - I am unsure - unlike other
terms, this is only in SPARQL Update - not used widely in
community. To change that would not be as disruptive. As for
named GBoxes - I can sort of see "Collection of Named GBoxes"
but Web is simply not a Graph Store. Makes sense for SPARQL
update, but too specific to that use case to be
generally...
... applicable. So have reservations.
<davidwood> The point is, we need a term for g-box, which the document calls a space. The term is not important, but the concept is critical. All other terms exist elsewhere. Why argue about terms? Terminology is even less important than syntax, as long as they are used consistently.
Sandro: Guess I wonder if - one
issue unresolved: whether we stick - for RDF Graph and Dataset
- to SPARQL, or consider changing because the community uses
with other definitions.
... Rather than us sharing perceptions - could we do a
survey?
<PatH> ivan, do you see why i suggested putting the terminology discussion second?
Sandro: Ask what people mean by "graph". How would you interpret...? We would find perhaps that we ourselves do not use consistently.
<Zakim> MacTed, you wanted to say reason for new terms is for unambiguous discussion. ambiguity can be resolved by using the unambiguous term. ambiguous terms cannot be used to resolve
Ted: Reason for new terms - not
to replace old. But to have unambiguous term where you mean
unambiguous things. "Do you mean X" We have been doing with
GBox and GSnap. We need for all the points on diagram.
... Serializations, etc, come from concepts.
<sandro> +1 ted: it makes sense to define precise terms for the terms that are often ambiguous
<PatH> ted, there is a strategy which is widfely used. Foo is ambiguous, so we define an A-Foo and a B-Foo, and still let peop;le be sloppy using Foo when it doesnt matter. Relling them to say Baz some of the time forces them to think in a new way, and they resist this.
<sandro> cf: backronym
Richard: Agree with Ted - makes
sense to define new terms that is really unambiguous, but not
intend that people use everyday. As for survey? Unsure. Even
terms like "set" and "table" - mutable or immutable? Can be
used either way. My preference: acknowledge that certain
concepts exist and probably need to be defined in Concepts and
will need to be defined, but work with placeholders
for...
... now. As Pat said earily, stuff will become clearer when we
work out semantics.
<alanr> +1 to PatH, and note we can defined foo as the disjoint union of foo-a and foo-b (assuming we are using the tools available to us) and make this "sloppy" usage precise.
Ivan: Need proposal: the diagram itself is something that will end up in the Concept document plus exact English terms.
Ted: So this proposal makes the right distinctions but does not provide the terms?
Ivan: Do we agree?
<PatH> +1 agree on that
<alanr> why isn't a proposal being written to the IRC and then voted on if you are seeking agreement.
Richard: Comfortable using diagram as basis for discussion, acknowledging that it is reasonable to use these concepts. Would like to see how - as an editor, would not want to decide that this diagram should be in final spec. Seems premature to decide that.
<davidwood> +1 to include the diagram. It is clear from this discussion that we need to help readers relate the terms.
Richard: Would be happy to see it there as working document, as placeholder.
<PatH> All our decisions are working :-)
<sandro> PROPOSAL: The WG thinks a diagram like http://www.w3.org/2012/08/rdf-spaces-relationships.svg is very helpful, and we should probably have something like that (with different terms) in RDF Concepts
Ivan: Put that as proposal we can refer to?
<MacTed> + PROPOSAL: The WG thinks a diagram like http://www.w3.org/2012/08/rdf-spaces-relationships.svg is very helpful, and we should probably have something like that (possibly with different terms) in RDF Concepts
<davidwood> +1 to MacTed version
<PatH> +1 to whatever wording we decideo on here.
<alanr> I don't vote, but I would think that that resolution would be very hard to follow up on without disagreement
<sandro> PROPOSAL: The WG thinks a diagram like http://www.w3.org/2012/08/rdf-spaces-relationships.svg is very helpful, and we should probably have something like that (probably with different terms) in RDF Concepts
<cygri> +1
<ivan> +1
ted: This diagram is pretty clear.
<GavinH> +0
<davidwood> +1 to final version
<gkellogg> +1
+1 - to final
<AZ> +1
<pchampin> +1
<sandro> +1
<sandro> RESOLVED: The WG thinks a diagram like http://www.w3.org/2012/08/rdf-spaces-relationships.svg is very helpful, and we should probably have something like that (probably with different terms) in RDF Concepts
<PatH> Sorry i have to run..
<sandro> ciao, PatH
<PatH> +1
<alanr> i was on q
RESOLUTION: The WG thinks a diagram like http://www.w3.org/2012/08/rdf-spaces-relationships.svg is very helpful, and we should probably have something like that (probably with different terms) in RDF Concepts
<alanr> on previous issue
Ivan: At beginning of WG life, resolution to issue 1 that Turtle syntax should be as close as possible to SPARQL. Same resolution applies to what we do in TRIG? Or not?
<cygri> ISSUE-1?
<trackbot> ISSUE-1 -- Is TURTLE the same as SPARQL 1.1 triple syntax? -- closed
<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/1
Ivan: Two grammars: one reproducing TRIG, another taking into account SPARQL influence.
<LeeF> Yes
Ivan: Do we consider ISSUE-1 to be a guideline for TRIG as well?
<sandro> -1
<ivan> +1
<gavinc> +1 from Editor
<davidwood> +1
0
<davidwood> Sandro, why?
<LeeF> I took it the 2nd way :)
<sandro> I think TriG is a decent starting point, but when it conflicts with SPARQL and other deployed things, TriG shouldn't have a lot of weight.
AndyS: That can be taken two ways: Keep existing TRIG and align with SPARQL?
<LeeF> Why doesn't TriG (a deployed thing) have a lot of weight against "other deployed things" ? :)
<davidwood> Please note that my proposal in the agenda had the words, "where possible" and ensured backward compatibility.
Ivan: When I said "align with SPARQL" = in a way that keeps compatibility with existing TRIG data. Main issue: biggest difference between two: in TRIG, default graph must be enclosed in curly brackets. In SPARQL, not.
<gavinc> TriG is less deployed than SPARQL or Turtle
<gavinc> Yes, totally possible!
Sandro: Which is more important? TriG or SPARQL compatibility?
<LeeF> Agree
<sandro> +1 making GRAPH and { } around default graph optional.
Ivan: Putting default graph in curly brackets is optional. And SPARQL is valid TriG.
<davidwood> I trust Andy on all things parser related
<SteveH> I have big concerns about possible Turtle documents that are also valid TriG
<gavinc> Would like = to go away, but that's about it ;)
<pchampin> +1
<gkellogg> +1
<alanr> by all
<gavinc> N3 compatibility is not a feature
<AZ> +1 in general but not with the "=" sign
<gavinc> There are implementations in the wild that do not support it today
Richard: TriG does not allow equals sign. First versions did not support.
Ivan: Abbrevs for equals and sameas.
<sandro> sandro: = would be bad -- conflicts with N3, given likely semantics
<gavinc> PROPOSAL: As Turtle has been brought together with SPARQL as a result of WG the resolution of ISSUE-1, similar argument can hold for TriG grammar: try to ensure, as much as possible, compatibility with SPARQL
<ivan> PROPOSED: the guideline for the definition of TriG would be the second grammar in http://www.w3.org/2012/08/RDFNG.html#trig
Sandro: confused about "two grammars".
<SteveH> -1 - I will object to any text along that line
Ted?: The grammar is specific. The resolution should be language introducing that grammar.
Steve: From my quick reading, looks like a Turtle doc would be a legal TriG doc.
Ivan: Grammar-wise, true, but we say media-type must be different from TriG and Turtle.
Sandro: If someone serves with wrong media type, worse case: errors.
[Exchange between Sandro and Gavin re: resolving to default graph].
<cygri> take sparql compatibility to the max and require INSERT DATA { ... } in TriG?
<davidwood> File extensions, media types, common syntax, common semantics. I don't see a practical problem.
<sandro> SteveH: some systems (our system) will behave differently with a turtle document vs a trig document with just the default graph, and we are not willing to trust the media type or the filename to guide our systems in this -- the syntax must also be disjoint.
Ivan: Single biggest issue: in SPARQL, query with graph is same as query without a graph (?).
<davidwood> Probably also common parser, in many cass
Ivan: Biggest issue aligning TriG with SPARQL - what to do about the default graph. Steve's biggest problem.
Steve: One of several.
<davidwood> s/cass/cases/
Ivan: Steve, I was hoping this would be solved by media type.
Sandro: If people give you incorrect data, their problem. Their giving you incorrect filetype is comparable.
<davidwood> File extensions are the most often used mechanism to cover in absence of media types.
Ivan: We must close. Steve, if you think it can be resolved, write it up.
<sandro> steve: My preference is to have the error of an incorrect media type result in a failed parse, instead of invoking the wrong behavior.
<cygri> sandro, incorrect media types are incredibly common, especially for new file formats. lots of good content served with bad content-type.
Steve: I don't think this is the biggest issue.
<SteveH> tbaker, that wasn't me speking
<pchampin> what about keeping enclosing brackets around the whold TRIG file?
<pchampin> s/whold/whole/
<pchampin> that would make it SPARQLish, and not compatible with Turtle
Ivan: closing meeting. We didn't kill each other! A result!
<davidwood> Thanks, Ivan
<SteveH> requiring INSERT DATA is quite interesting
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/+1 AndyS/+1 PatH/ Succeeded: s/ref/rdf/ Succeeded: s/number that/number nodes in that/ Succeeded: s/[]/macted/ Succeeded: s/X/Andy/ Succeeded: s/Andy/X/ Succeeded: s/X/Ted/ Succeeded: s/ref/rdf/ Succeeded: s/Pat/Ted/ Succeeded: s/X/ted/ Succeeded: s/X/Ted/ Succeeded: s/Gavin/AndyS/ Succeeded: s/Ted?/X/ FAILED: s/cass/cases/ Succeeded: s/Steve/Gavin/ FAILED: s/whold/whole/ Found Scribe: Tom Baker Found ScribeNick: tbaker WARNING: No "Present: ... " found! Possibly Present: AZ Alan Alan_Ruttenberg AlexHall Andy AndyS Antoine GavinH Ivan LeeF MacTed OpenLink P0 P2 P26 P28 P4 P8 P9 PROPOSAL PROPOSED PatH Richard Souri Steve SteveH SteveH_ Ted TedH aaaa aabb aacc alanr ambiguity cf cgreer cygri cygri_ davidwood dwood eric ericP gavinc gkellogg https joined pat pchampin pchampin_ rdf-wg sandro scribenick tbaker trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Regrets: Arnaud Yves Scott Zhe Found Date: 22 Aug 2012 Guessing minutes URL: http://www.w3.org/2012/08/22-rdf-wg-minutes.html People with action items: sandro[End of scribe.perl diagnostic output]