RDF Next Step Workshop

<pfps> Where are my tomatoes?

<FabGandon> #rdfn tag for twitter, etc. ?

<pfps> scribenick pfps

<pfps> what do I need to do to be the scribe

<sandro> I made a short URL for the agenda: http://bit.ly/rdfnsw

<pfps> official agenda URL http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop

<AndyS> scribenick: pfps

<AndyS> Scribe: Peter F. Patel-Schneider

Introduction of all participants

<dajobe> and search for lost participants

Today will be presentation of many of the submissions

Tomorrow will be breakout sessions

Also today, initial setup of breakout sessions

Presentation from Richard Cyganiak

Richard Cyganiak: Four Boundary Conditions for RDF Next Steps

cygri: Four Boundary Conditions for RDF Next Steps

<Jeremy> http://richard.cyganiak.de/2010/06/rdf-next-steps.pdf

Above is a version of Richard's slides

cygri: I want to set up boundary conditions on what we can do and what we can't do.

Some information from the slides will not be minuted

<sandro> cygri: #1: Standards are a tool for achieving interoperability

cygri: Boundary Condition 1: Standards are a tool for achieving interoperability.
... Boundary Condition 2: Change can disrupt the network effect.
... Boundary Condition 3: W3C is not good at R&D.
... Boundary Condition 4: Focus on areas where RDF has proven useful.
... What does this mean?
... Optimality can never be achieved.
... W3C can turn existing practice (quasi-standards) into recommendations.
... We can align the stack.
... Currently the stack is rather messy.
... Even within RDF - e.g., containers vs lists
... A messy stack causes problems for new people.
... There are ways to align the stack, including deprecation, notes,
... My preferences - put common practice into Rec, explain the messiness

sandro: What are consequences of only looking at where RDF is useful?

jeremy: Remember the forced compatability between RDF and OWL.

<sandro> sandro: whar are the things that are NOT areas where RDF has proven useful ?

<sandro> andy: RDF for encoding OWL ontologies vs OWL for defining RDF properties

cygri: Don't come up with a new semantics for RDF here (e.g., to make it work with blogic).

<sandro> cygri: As a foundation for KR languages, RDF has not proven itself. Let's not spend a lot of time with the RDF Semantics to make that happen.

<sandro> david: Be careful of tyranny of the majority; don't kill something just because it's not popular (yet)

david: Let's not preclude the future.

<sandro> david: On the spectrum between Change Nothing and All-Powerful-WG, where are you?

<AndyS> TBL: http://www.w3.org/DesignIssues/RDF-Future.html (June 2010)

cygri: Any WG should turn practice into REC, anything else can be dangerous.

<sandro> cygri: Yes change quasi-standards into Recs. Be very careful about scope-creep on WG fixing stuff.

<sandro> ivan: cygri, be a guard dog at this workshop, please, pointing out if people violate your principals.

Jeremy Carroll: Towards a minor revision of RDF

Jeremy Carroll: Towards a minor revision of RDF

http://lists.w3.org/Archives/Public/www-archive/2010Jun/att-0057/SmallSteps.pdf

jeremy: Small Steps Please!
... "If it ain't brokce, don't fix it"
... No bugs in RDF spec (contrast with HTML).
... The parts that aren't being used don't matter.
... Let's also consider the costs of doing something (HP spent 0.8M on RDF Rec)

david; HERESY!

jeremy: There are also implementation and training costs, ....
... Semantic Web has yet to really prove itself, too much change at this point can be detrimental.
... We should instead be linking data, building apps, ....
... We could make a few small steps, e.g., deprecate containers, but for any thing someone wants it.

cygri: Deprecating something doesn't mean that the feature has to go away, as users can do it themselves.

<sandro> cygri: Are those folks using these maybe-deprecate features using them in an interoperable way?

<sandro> jjc: "Not to be used for new vocabularies" WEAKLY DEPRECATE.

<sandro> +1

<dajobe> +1

<ivan> +1

jeremy: Let's use weak deprecation - "Don't use this in future work - new vocabularies"

<sandro> jjc: "SHOULD not use"

<sandro> sandro: RDF parsers MUST still parse it

ivan: Real deprecation has this pragmatics that the feature *will* go away.

<sandro> dbooth: Encourage authors of older vocabs to migrate.

<sandro> jjc: a MAY

<sandro> li: maybe will improve computaton complexity

jeremy: "I hate it" is a good enough reason to deprecate something :-)
... If enough hate it, there is something wrong with it

?: What about backwards compatabilitymikeu

jeremy: weakly deprecated features shouldn't be used by other recs

<dajobe> we should have a 'weakly deprecate' column on the whiteboard

<sandro> david: weakdepr puts a stake in the ground in the direction to go.

<iand> we can use things like the linked data patterns book to help with deprecating things, e.g. http://patterns.dataincubator.org/book/repeated-property.html

cygri: foaf uses "archaic" for this purpose

<sandro> cygri: Danbri says "archaic" not "deprecated".

jeremy: OK do to turtle and named graphs, maybe "follow your nose"

<AndyS> Better, not "deprecation" but "best practices"

<AxelPolleres> core/deprecating/best practices seem to revolve around the same issue ... discouraging some less used features, 2 questions are: which features are these, how doe we "brand" that?

jeremy: need to do a cost/benefit analysis

<pgearon> I'd like to note the regular questions on mailing lists about "I've heard that Containers are bad, but I can't find out why"

jeremy: throwing out RDF semantics could be good, but it would be costly

<sandro> jjc: Maybe throw our RDF Semantics, but DONT THROW OUT THE BATHWATER WITH THE BABY. Lots of good bathwater there.

<AxelPolleres> paul, good point...

andys: maybe use "best practices" instead of "weak deprecation" - its cheaper

<sandro> andy: Always point to a good practice instead, next to anything deprecated

axel: want to discourage some stuff, but we need to come up with a tag for that

<sandro> paul: for things like rdf:value, say what you should do instead

pgearon: if we are going to "wd" we should also say what *to do*

Dave Beckett: RDF syntaxes 2.0

dajobe: RDF syntaxes 2.0

http://www.dajobe.org/talks/201006-rdf-next-steps/

<Jeremy> Dave is not representing his employer

dajobe: syntaxes - RDF/XML, N-Triples, RDFa, Turtle - first 2 recs last one not

<Anchakor> what would be the point of throwing out RDF Semantics? is pat hayes participating in this discussion?

dajobe: other syntaxes have less use

<dingl> pointer http://n2.talis.com/wiki/RDF_JSON_Specification

dajobe: some minor change is possible in most syntaxes
... if backwards compatability is not a concern then can remove rdf:ID, property attributes, reification
... if major change is possible then turtle could add named graphs
... recommend that new syntaxes cover *entire* RDF model
... Turtle - make a REC, polish, tidy
... JSON - make a version for RDF as a Rec
... binary - no need demonstrated yet
... named graphs not an obvious addition

dingl: what about ATOM

dajobe: not much takeup for ATOM, so not a major need

<Jeremy> Somone: what about TriG

pmika: what about a data feed?

ivan: submission on gdata from Google
... also interest from Microsoft

<leef> I am interested in Atom as an encoding for the RDF model, not an RDF expression of the Atom model

cygri: active work in community - so may need to wait before REC

pmika: there is enough work that it would be good to start on REC now

<sandro> (Microsoft interested in increasing compatibility between RDF and OData)

<sandro> Dave: DON'T use binary XML for this.

dajobe: new XML syntaxes - XML is tree, RDF is graph - so there is no good solution - so don't try

<AndyS> Turtle is not a subset of TriG which is hard to explain.

<LeeF> TriG is really a serialization of RDF Datasets (c.f. SPARQL spec)

dajobe: Turtle has worked - why? - it doesn't look like XML

<sandro> dajobe: DO NOT create any new XML Syntaxes for RDF. There's no way to make a really good one.

<LeeF> Is anyone here (or elsewhere) strongly suggesting a new XML syntax?

Li Ding: XML has order, RDF doesn't, this is another mismatch

dajobe: some parts of RDF capture order

<sandro> jjc: I get a lot of defect reports from end users where people expect their RDF/XML to look nice.

David Booth: What I Want in RDF 2.0

dbooth: What I Want in RDF 2.0

http://www.w3.org/2009/12/rdf-ws/papers/ws19

<sandro> dbooth: What helps US (experts) is far less important than what will help new users.

dbooth: REC for some human-friendly syntax
... REC for rules language based on SPARQL CONSTRUCT

<LeeF> Disagree strongly with focusing on new RDF users rather than existing RDF users

<sandro> dbooth: 1. standards a rules language based on sparql construct.

ivan: isn't this just something for RIF core
... RDF friendly syntax for RIF core?

dbooth: yes

<sandro> sandro: would a presentation syntax for RIF that looked like SPARQL construct solve the problem

mdean: OPTIONAL in SPARQL is a very powerful construct

<sandro> dbooth: Yes.

dbooth: SPARQL has wide use - so use it

<LeeF> sandro, I would be very happy if I had a clearly defined way to understand SPARQL in terms of RIF semantics

pmika: how does this relate to RIF?

dbooth: don't know

<sandro> sandro: Put this on the agenda for tomorrow -- RIF-SPARQL-etc

<LeeF> pgearon, I guess the answer to my earlier question is "dbooth is" :-)

dbooth: REC for some XML Schema-friendly serialization - maybe TriX - RDF/XML is awful from many points
... add literals as subjects

<AxelPolleres> cool, +1 for the breakout on RDF rules based on SPARQL+RIF ... thinking about making a short presentation why it is *not* a no-brainer, but still feasible

some people want literals as subjects, some don't

<LeeF> I'm in the "don't care one way or the other" group :-)

<pgearon> I have been wondering if literals as subjects could be replaced with formal semantics on rdf:value

ivan: this may raise internationalization issues

<dajobe> literals as subjects are not allowed in rdf triples as per rdf concepts spec.

dbooth: named graphs - obvious to me

<pgearon> yes, but there are a lot of parts of the rdf concepts spec that are already being ignored

dbooth: bnodes are a pain - do *something* - maybe get rid of them - maybe skolemization

<sandro> +1 std way to skolemize bnodes

<sandro> (for the folks who want to skolemize them)

cygri: too late - bnodes as existentials are here!

axel: bnodes are useful

dbooth: *syntax matters*

<AxelPolleres> bnodes are natural *local* identifiers, noty accessible form ouside a doc ... by definition.

<AxelPolleres> ... that is needed sometimes

<AndyS> Bnode refs: Needed to have distributed graphs - currently can't do based on stds only

*break for coffee*

<Jeremy> scribenick: Jeremy

jun is presenter

slides: http://users.ox.ac.uk/~zool0770/presentations/2010_06_rdf_next.pdf

Provenance Requirements for the Next Version of RDF

co-authors: Jun Zhao, Christian Bizer, Yolanda Gil, Paolo Missier, and Satya Sahoo

<ivan> slidenick: Jeremy

<iand> info URIs could be an option for skolemization

Authors are W3C Provenance Group

<LeeF> scribenick: Jeremy

<pgearon> iand: based on UUIDs?

Provenance

<ivan> Jun Zhao's slides

<iand> pgearon: register a new bnode domain

<iand> info:rdf:iandavis.com:/what/ever/I/like/foo123

<pgearon> iand: OK, so it has the same effect as a UUID, only manually generated, and human readable

Problems start with sets of RDF statements ...

Provenance allows addressing quality issues with linked data

<sandro> I'm amused to see Dan Connolly's "Oh Yeah?" button adopted in Jun's slides.

is zakim here at all?

<dbooth> I guess not

I see RRSAgent

<dbooth> peter: Jun seems to be using the term "resource" in a generic English sense, rather than the RDF sense.

peter: resource has technical meaning in RDF - the use on slides "Requirement 1: Identity" seems different
... Requirement 2: new URIs means new URIs related to old URIs

jun: yes

<dbooth> Jun: When should a new URI be minted versus when should existing URI be used? URI evolution

<AxelPolleres> peter: this is an issue outside RDF

<AxelPolleres> ???: it IS an issue of the *use* of RDF

Best practice is missing about when to use different items from state of the art

Some state of art items are not yet standardized

Annotations of RDF graphs general requirement not just provenance

Q&A

Scott: it is important to say stuff about a named graph.
... from linked open data cloud ...
... provenance allows you to say where a particular graph came from how it was made etc
... also can say stuff about what is in it - annotations

Ivan: what's the question

Scott: ??? something about saying something about named graphs ....

<sandro> mscott: do y'all think it's important to be able to talk about what's in a named graph, to characterize it?

andy: it seemed to be talking about a set of statements

<sandro> ivan: Provenance is somewhat independent of RDF -- but this is important to us to know about their requirements w.r.t. 'named graphs'.

andy: this may be more general than named graph

jun: we do not want to tie to particular technology
... not in scope for provenance group

<guus> a poll in the SW group at VU (35 people) put named graph as THE top req in case of an RDF revision, far ahead of anything else

dbooth: do we need another category of output: best practices

<sandro> I want a little buzzer to press when anyone says "Named Graphs". (I hate the ambiguity of the term.)

ivan: i think the provenance XG will come back with suggestion of group

<webr3> sandro: +100

debMcG: named graphs need to be first class objects
... with this I am happy - goodbye

speaker: Elisa

talk: http://www.w3.org/2009/12/rdf-ws/slides/RDFNextSteps-OMG-2.pdf

OMG Ontology PSIG,

Elisa Kendall: OMG Ontology PSIG Position Paper

PSIG = Platform Special Interest Group

(slide 1)

<sandro> (Jeremy, I think sometimes people mean graph literals, sometimes they mean graph reification (reasoning about the elements in a graph), sometimes they mean a way to talk about the state of a triplestore, ....)

(Sandro, that ambiguity was deliberate)

<mscottm> Replying to Sandro's question: "do y'all think it's important to be able to talk about what's in a named graph, to characterize it?" YES. Would be nice if the characterization was available from the SPARQL endpoint.

(slides 2) Elisa clarifies difference in charter between OMG and W3C

<sandro> (Well, I find it causes me almost physical pain, each time I hear someone use the term, because I don't actually know which position they are advocating.)

(slide 3) we need one or two documents for the basics

<sandro> mscottm, I was scribe-assisting, writing down your question, not asking it.

not seven or eight

sandro: let's put tidying up namespaces on board

peter: wehy does namespace matter

evan: in metamodel you may namespace into ....

a package

<AxelPolleres> rdfs:domain owl:sameAs rdf:domain ... done?

<sandro> +1 Axel. :-) DL folks might not like that, though. :-)

(slide 4)

Sandro: Jena and Sesame are not really APIs because not multiple impl

<AxelPolleres> but then... why not also owl:sameAs owl:sameAs rdf:sameAs ?... admittedly probably that goes too far, but ... where'd be the border... kinda leaning towards disliking my own proposal now

<webr3> re named graphs: when people say named graphs, often they mean the URI of the resource which contains a serialized RDF description of the current state of that resource. This doesn't 'Name a Graph' because a graph is a distinct set of triples, you can't change a set and if you add or remove anything it becomes a new set (thus a new graph).

<webr3> re named graphs: what most want is a way to be able to refer to a distinct set of triples and annotate it in order to provide provenance, enable version control, temporal matters and most uses of RDf in message rather information space, but this can't be achieved with any form of named graph.

Sandro: DIG only real API

<webr3> re named graphs: .. especially not with the conflated named graph most think of, nested graphs *does* however provide the means to cover all aforementioned the things we need /end

<vmom> axel: every sparql query result will list:: "x rdf:domain y. x rdfs:domain y". it will be tricky to process it query time

DaveB: W3C is not very good at API

Elisa: OMG issued an RFP: API for KB

<sandro> elisa: need standard Java/Enterprise interfaces (APIs)

s(slide 5)

<pgearon> AxelPolleres: I don't want rdf:sameAs.... I want to see rdf:equals (same meaning, but with a name that tells newbies what it actually means)

Ivan: DOM went wrong because one api for all languages, but then we have too many languages to support

DaveB: Java commuinity should do API for Java

Ivan: well defined web interface for SPARQL

<DaveB> I meant to say w3c isn't so good at programming APIs

<DaveB> web APIs, a *little* better

<AxelPolleres> vmon: you mean for SPARQL engines that support entailment... anyways, as mentioned, throughinh the URIs together by sameAs is arguable... where should one stop, we peobably don't want to embrace all of rdfs: and owl: within rdf: ... this is all a surface syntax issue, what it seems to me is rather Elisa is arguing for a "surface syntax" where she doesn't have to care for the namespaces, whereas peter says, "so what, it's all IRIs, it could equally be

<AxelPolleres> a:domain b:range c:sameAs, d:type..." both are right in a sense

(sorry for misscribing)

<pgearon> DaveB: Yes. I've had several people approach me about this (API for Java). e.g. bblfish

<AxelPolleres> s/throughing/throwing/

squabbling over the defn of "week"

(semantics)

<DaveB> looks like it'll appear at http://www.omg.org/ontology/

":What do you want?" (David Wood)

<DaveB> didn't sound to me like the namespace separation were showstoppers for Elisa

Elisa: slide 3: named graphs

<DaveB> "it would be great"

<DaveB> = nice to have

Elisa: namespace untangling

Peter Mika: profile docs in RDFa would be potential soln to namespace problem

<iand> i think many people are using the "named graph" phrase incompatibly here

Richard: agree with Peter Mika
... jiggling around is not soln
... need to hide

<dbooth> Richard: RDFa profiles are a good example of how to do this

Jeremy: however we jiggle around namespaces someone will be unhappy

<DaveB> +1

Elisa: I would be happy with this sort of soln

DaveB: we mix data and schema, untanlged namespaces happen

Elisa: minimally, in a document update, add commentary about tangled namespace

to say to reader "you are not a lunatic to be confused here"

DavidW: WG could issue WG note "Known pitfalls"

<sandro> David: "KNOWN PITFALLS IN RDF" WG Note.

<DaveB> here be pits

Axel Polleres

next up

Axel Polleres: RDF and XML: Towards a Unified Query Layer

authors are authors of XSPARQL

(slide 5, 6) transformation as well as query

slide 8: too many variants of RDF/XML rep of single graph

(slide 9) structure of SPARQL and XUQERY similar: head + body

slide 14: formal semantics combine

slide 16: why

<dbooth> Anyone know URL for Axel's slides?

http://www.polleres.net/presentations/20100626W3C_RDF_NS_RDFXML_UnifiedQueryLayer.pptx

no sorry

http://www.polleres.net/presentations/20100626W3C_RDF_NS_RDFXML_UnifiedQueryLayer.pdf

Summary: RDF and XML communities need to talk to one another

]Jeremy: I wrote paper on canonical RDF/XML a long time ago

on hp web site

DaveB: so did I

DaveB and Jeremy: but no real take up

Peter: XML and RDF are different, very different

Axel: in a way this is a scripting language

<mdean> should add canonical RDF/XML to whiteboard - probably under RDF-Core Maybe Never

DavidWood: where is the line in other formats

<AndyS> Link all "query" into one thing? Seems top down.

?: RDFa how do you query, as XML or using SPARQL

Axel: as RDF

Sandro: there is a wd in RID on mapping XML docs to RIF Frames (which are RDFs)

does that address ?

Axel: I am afriad that is like saying XSLT is the answer

Sandro: I advocate direct mapping canoncial RDB to RDF and then use rules to transform

Peter: XSLT is wrong tech for mapping in second phase of Sandro's case

Sandro: RIF is declarative

(off topic on quality of RIF)

Jeremy: suggests globally replace "RDF URI Reference: with "IRI"

DavidWood: aren't you just moving around where the implicit knowledge is?

<DaveB> the rdb2rdf wg seems to have made one doc: http://www.w3.org/2001/sw/rdb2rdf/use-cases/

Axel: one use case is legacy datasources

In this one you need xforms to RDF queried by SPARQL

But other use case is going from RDF to something else

DavidW: would this be addressed by canonical RDF/XML

Jeremy: it is disgusting

AndyS: what about JSON

Ivan: there was an attempt to write a 2nd Cambridge Communique

it was friendly, but (Sandro): there was not a single consensus statement

Ivan: there is a social gap
... some XML people feel threatened (economically) by RDF

DavidB = david booth

DaveB = Dave Beckett

canoniocal RDF/XML

psu.edu [PDF]Jeremy J Carroll Signing RDF Graphs - The SemanticWeb-ISWC 2003, 2003 - Springer

http://www.hpl.hp.com/techreports/2003/HPL-2003-142.pdf

<DeborahMcGuinness> *greetings from sfo - looks like you are at lunch. sorry had to leave early

<LeeF> scribenick: LeeF

Revisiting Blank Nodes in RDF to Avoid the Semantic Mismatch with SPARQL

Speaker is Alejandro Mallea

Alejandro: I'm going to talk about issues with the semantics of blank nodes

ivan: the semantics of what??? ;-)

Alejandro: in SQL, NULL doesn't count as an item when counting items
... in SPARQL, a blank node counts as 1

AndyS: Why is that similar?

Alejandro: We have the same information -- we interpreted a blank node as (SQL) NULL

ivan: I would read a blank node as "John owns something" and expect a count of 1

Alejandro: But this behavior is not natural to SQL people

pfps: everyone agrees the behavior of NULL in SQL is wrong - why should we be wrong like them?

Alejandro: in SQL NULL means we don't know and in SPARQL blank nodes mean we don't know a name
... graphs get meaning when nodes are related to real objects

<AndyS> Codd pointed out there are more than one kind of null in SQL. Codd, E.F. (1990). The Relational Model for Database Management (ed 2)

<sandro> jjc: You're suffering a bit from the Realist Fallacy, as if there is one right Interpretation

Alejandro: proposed new definition - A representation of an RDF Graph G is the image of G under an interpretation. In a sense, it's a real version of G.

<sandro> Alejandro: I'm saying *a* real version, not *the" real version

<dbooth> dbooth suggests that Alejandro take a look at his SemTech paper, which does not talk about bnodes, but talks a lot about interpretations: http://dbooth.org/2010/ambiguity/paper.html

Alejandro: the set of representations of G is equal to the union of the representations of all ground versions of G
... two different blank nodes can be replaced by the same URI, which is different from what SPARQL does

<sandro> wood: *laugh* It's really hard to watch this with Jeremy's head going up and down and pfps's head going side to side

<webr3> Perhaps a bnode doesn't equate to SQL NULL, perhaps a bnode equates to a table where the primary key is across all columns, thus _:b1 is a pointer to the set of values of that node

<AxelPolleres> alejandro, FILTER a != b is different from a owl:differentFrom b

Alejandro: blank nodes don't add much meaning - the only difference that we can tell is that blank nodes are non-dereferenceable

<sandro> Alejandro: In terms of meaning, blank nodes don't add expressive power to the ground datasets. The only relevant difference is they are non-dereferenceable.

Alejandro: SPARQL considers distinct blank symbols as distinct objects

<AxelPolleres> ... that is != in SPARQL could *very informally* be viewed as "not known to be equal"

dbooth: doesn't SPARQL consider blank nodes as possibly distinct items?

<sandro> dbooth: SPARQL treats them as POSSIBLY distinct, it can't assume they are the same.

Alejandro: No, they're always distinct

AxelPolleres: != in SPARQL is syntactical, it's not semantic

<sandro> axel: The problem is != in SPARQL is syntactic, NOT the semantic not-equal.

Alejandro: if blank nodes are treated as incomplete information, then the data complexity of SPARQL with only BGPs, SELECT, UNION, and FILTER (?X != ?Y) is coNP-hard
... We then looked at how blank nodes are used on practice on the Web
... blank nodes are rarely used -- often used aspointers to collections of data
... they almost always have an in-defree of 1 and an out-degree of 1 or more

DavidW: how often? did you measure?

Alejandro: we didn't measure, but it was every time in our sample
... We also looked at the linked data perspective, which discourages the use of blank nodes

ivan: that's the opinion of some (respectable) people

<AxelPolleres> in my humble opinion, the view presented by alejandro reflects mostly coneptual disagreements of what "incomplete data" means between how we treat it in the form of bnodes in RDF and the community doing research on incomplete databases (which is where they're coming from), or no? it is valid to raise that there is this disagreement. Plus, he is right that bnodes are mostly used in the [] way rather than really named bnodes would be needed.

<dbooth> dbooth: The fact that the in-degree is typically 1 suggests that a *standard* way to write n-ary predicates may help address this.

Alejandro: we propose to redefine the semantics of blank nodes in RDB to align with the semantics in SPARQL
... That is, assume that two blank nodes with different BNIDs are different
... which turns blank nodes into just non-dereferenceable URIs
... further discussion --
... what is the usage role of blank nodes?
... anonymous idnetifiers, unknown information, eliminated altogether, other?

<AxelPolleres> bnodes are anonymous identifiers

DavidW: first suggestion is to make a new type of collection in RDF?

Alejandro: one option, not necessarily our position

ivan: We already have blank nodes recorded in a similar fashion, so let's move on
... we'll discuss in breakout groups tomorrow

DavidW: we have several SPARQL implementors in the room who have had to deal with this issue
... I'd like to know what decisions they've made

Jeff(?): does this mean unique name assumption for blank nodes?

Jeff(?): having unique name assumption only for blank nodes but not for ordinary resources

Alejandro: My opinion is to eliminate blank nodes - as a group, we propose to align semantics as in SPARQL

Jeff(?): But what does that mean?

<AndyS> SPARQL defn for bNode treatment: http://www.w3.org/TR/rdf-sparql-query/#BasicGraphPattern

Alejandro: Need help form SPARQL people for that

DavidW: that's why I brought up the SPARQL implementors

mdean: last year I analyzed the billion triple challenge corpus - there were 12 datasets there and 5 of those datasets had more blank nodes than URIs
... that seems to be different results then you got

Alejandro: in the US Census data set, 99% are blank nodes - very similar usage to what I've outlined here

mdean: I'm finding a lot of other datasets also have extensive use of blank nodes

ivan: which means eliminating blank nodes completely would be a big problem

dbooth: a standardized encoding for Nary predicates ... not sure how much interest htere is there, but this seems like what Alejandro is observing

<AxelPolleres> I see the point... it is about some awkwardness about leanness or not, which makes the behaviour of queries on lean and non-lean graphs different, or no? that is, you can have different results of queries on a lean version of the same graph, which is equivalent.

PeterMika: ???

Alejandro: our result was that everything you can do with blank nodes you can do without

<mdean> 2009 Billion Triples Challenge analysis http://asio.bbn.com/2009/06/semtech/Dean_Mike_Billion.ppt slide 14

<general murmur of disagreement>

AndyS: can I tell the difference in SPARQL without using COUNT(...) ? COUNT ends up closing the world no matter what

Alejandro: with DISTINCT

Contextualized RDF Importing

<AxelPolleres> does that summarize Alejandro's point? ... It is awkward to get potentially different answers on queries on (simple) equivalent RDF graphs?

<AxelPolleres> speaker is Jie Bao

JieBao: <gives two examples of LiDing with different roles & affiliations at different organizations
... using owl:sameAs leads to confusing/wrong conclusions because context has been lost

<dbooth> anyone got the URL for the slides?

JieBao: 2nd example is assumptions - foaf:mbox is an owl:IFP, but what if in an open forum the value of foaf:mbox is "n/a"?
... 3rd example is "World" -- which universe is something true in?
... context is something related to the meaning of a sentence (provenance, assumptions, world)
... we need a way to make context explicit when a triple is published
... what about named graphs, C-OWL, N3 quotation, or Contextx in AI?
... Named graphs - name is a context. But contexts are more than a name - some triples may be in multiple contextx - one context may be reused

<webr3> slides: http://www.w3.org/2001/sw/wiki/File:2010-06-24_RDF_Context.pdf

cygri: but the same triple can be in multiple graphs, what's the problem?

JieBao: duplicate information increases the risk of inconsistency and many other things

DavidW: you're saying that you can't draw a clean boundary to deifne the context?

JieBao: Yes

jjc: to me, the context information is just things encoded in graphs

<jjc> turtles all the way down

JieBao: C-OWL is about mapping that respects contexts
... knowledge transfer is controlled, but context is more than mapping
... N# -- contexts are more than quotation
... we propose to base on named graphs and add two vocabulary terms: rdf:context & rdf:imports
... when we publish a set of triples, we can relate a context document to that set of triples
... G: rdf:context C - C may give a context definition document
... one graph can import another - each graph may have a context
... contexts may have an (in)compatibility relationship with one another that controls what happens on import

<iand> provenance is a broad term that is basically the main use case for named graphs

pfps: do documents have multiple graphs in them?

JieBao: possible but not necessary

pfps: if you don't have multiple graphs in one document, then this looks like owl:imports and owl:incompatileWith

JieBao: no, because even if you import, you're not required to reuse the semantics

pfps: I don't see the difference

JieBao: the difference is copy&paste (OWL) vs. citation

<discussion of example on slide 12>

DavidW: we'd have the same conflict between RDF and OWL with this that we have today

JieBao: yes, but the main difference is having the choice of which parts are reused

dbooth: am I right in understanding that basically what you're doing would be supported by named graphs?

JieBao: Yes

ivan: but you have to add on as a separate specification somewhere which adds the semantics on the imports and context properties

dbooth: so that would be a semantic extension?

stefan: so this is named graphs + RDF infrastructure for contexts

jjc: What needs standardizing?
... when we did the named graphs work we were trying to minimize the scope of it to focus on a minimal piece

<webr3> can you trust a graph to specify it's own context..

jjc: after you do the named graph stuff you can optionally do the hairy stuff

JieBao: maybe standardize named graph stuff today and context stuff maybe later

<LeeF_> ivan: this touches on - how would all the inferencing rules of RDF SWchema work together with the contents of named graphs

<LeeF_> scribenick: LeeF_

jjc: if we standardize named graphs, then people can go off and do research not under the W3C banner for things like context

DavidW: does your context operate over one or more named graphs?

JieBao: Yes

DavidW: so you can't have a context that operates on part of a named graph

JieBao: Correct

DavidW: that helps simplify this

<LeeF> scribenick: LeeF

<Anchakor> found this btw: http://www.cs.rpi.edu/~baojie/pub/2010-03-25_context_websci.pdf

RDF(S) needs annotations

Speaker is AxelPolleres

<dbooth> Axel's paper: http://www.w3.org/2009/12/rdf-ws/papers/ws09 slides: http://www.polleres.net/presentations/20100626W3C_RDF_NS_RDFneedsAnnotations.pdf

AxelPolleres: context, as before
... e.g. time, provenance
... trust/certainty
... needs come from academia, practice, XGs, etc.
... two issues are (1) representation of annotations and semantics of annotations
... we claim that RDF needs agreement on representation and semantics
... we propose something we call annotated RDFS
... sensor example - need to capture location of a tag in a room, time of the sensor reading, signal strength
... one way of representing these is with reification
... problem is no semantics
... and reification is not popular
... other possi bilities is N-Quads, TriG, TriX

iand: what about N-ary predicates?

AxelPolleres: that's the same as reification

dbooth: as N-ary predicates, the subject would be an observation

<lots of yes murmurs>

jjc: the distinction is that you can decide up front as part of your data model that certain things such as time, location are important - that becomes the safe as all other parts of your data model OR you can say that in general annotations are important for EVERYTHING so things like time & location should be part of the data model

AxelPolleres: we need semantics of these annotations for RDF(S)
... we have a generic framework for describing annotation domains and telling how they can coexist with non-annotated RDF data
... an annotation domain is a lattice with the representation of the annotation (time intervals), an order between the elements, and a top and bottom element

???: are partial orders enoguh?

s/enoguh/enough

AxelPolleres: it does need a top and bottom element
... we need a t-norm operator (often AND), and a combining operator (OR)

AndyS: in the sensor case, there are dependent events, so you can't combine probabilities in such a simple way?

AxelPolleres: if you're combining annotation domains, then we're treating them independently

AndyS: in that case with probabilities it's a race to the bottom?

AxelPolleres: this is not probabilities, it's fuzziness
... several options for integrating with non-annotated triples
... (1) treat non-annotated triples as top element
... (2) another approach is that a triple is true at "some" time (a la blank nodes)

AndyS: ordered blank nodes!

AxelPolleres: (3) triple is valid until "now" - current time
... the only upwards compatible option here is (1)

iand: how do you annotate which clock was used for the timings?
... meta annotations?

AxelPolleres: Seriously though. :-)

AndyS: Do you need layers of annotations? Can I put annotations on the annotations?

AxelPolleres: No. The annotations are separate.

<sandro> everyone: it's a problem that you can't annotate annotations

<sandro> axel: No, not really, but I'll get back to that.

AxelPolleres: inference rules use t-norm and OR operators to combine contexts

cygri: why do this within W3C rather than defining this somewhere else and advertise it?

AxelPolleres: you need interoperability when you want to talk about temporal (e.g.) information

cygri: but W3C is for when there are multiple non-interoperable implementations/proposals out there - I don't see that here

AxelPolleres: people use ad hoc solutions for this right now

cygri: think about Good Relations - someone has written it down, promoted it to the point of adoption - what's lacking from what you have now is the deployment & promotion

AxelPolleres: Yes & no. The temporal stuff is there and implicit. Provenance is there and implicit.

jjc: you need to point to something losing money because of an interoperability failure -- there's not enough use here for there to be a problem to solve

mscottm: there's an opportunity cost

AxelPolleres: there is RDB2RDF work, but no temporal DB to RDF because people can't do it

jjc: people are doing RDB2RDF in different interoperable ways

ivan: what does this require on the core level?

DavidW: Franz with AllegroGraph got to a point where they neede dto do annotations - their solution was to create a quad store where they assign a URI to every single triple - that allows them to cascade annotations

ivan: rdflib does this also
... this could be an alternative to the named graph

jjc: named graphs is more popular than reification because reification is standardized and people have to use it

<webr3> assigning a uri to every triple is just creating a named graph where the graph contains exactly one triple, nested graphs would cater for this and named graphs use cases and much more

sandro: "named graph" is a horrible name - "graph metadata" sounds good

<mscottm> 1+

RDF: Back to Graph

<sandro> (actually, I said "graph metadata" is the best I know so far, but it's still not great.

<sandro> )

sandro, mscottm -- in Anzo, every graph has an accompanying "metadata graph" for pretty much these purposes

<DaveB> let's not re-use/abuse 'metadata'

<sandro> Tell me something better, DaveB

speaker is Peter F Patel-Schneider

<DaveB> metagraph

Peter F Patel-Schneider: RDF: Back to the Graph

<dbooth> Peter's paper: http://www.w3.org/2009/12/rdf-ws/papers/ws05 slides: http://ect.bell-labs.com/who/pfps/talks/rdf/rdf-next-steps-pfps.html

<Anchakor> everything is sort of "meta"

pfps: I'm not proposing anything different than what's already out there in the world
... RDF has 2 competing purposes
... it's a data structure language & it's a KR formalism
... some people like the 1st, some people like the 2nd, some people do neither
... the problem here is if you're using this stuff as the foundation to build upon
... if we believe that all syntax is triples and all semantics is based on RDF semantics, then semantic extensions result in paradoxes
... the claim that RDF is the basis of the Semantic Web is a lie
... OWL, RIF, SPARQL don't use triples for everything
... RDFS uses triples, but there are lots of incomplete implementations
... let's stop saying that it's true if it's not true
... let's say that Semantic Web semantics is not necessarily an extension of the RDF semantics
... syntax is not just triples

<Anchakor> pfps +1

pfps: this is how extensions have been done by mathematical philosophers for ages
... invent new syntax when you have something new to say
... if we did this, then:
... RDFS might have its own syntax
... OWL would have its own syntax
... RIF, SPARQL would have their own syntaxes
... mostly compatible semantics
... but this is reality (except for RDFS)
... there is a good rationale to have a common core of the Semantic Web
... what shoudl this be?
... it could be RDF if RDF is containing *data*
... retain things like "say anything about anything" (more or less)
... IRIs as global names, entities, properties, ...
... allow higher languages to use RDF for their data and interpret it however they want
... OWL could strip out annotations in a pre-processing step (e.g. remove facts not true "now")
... RDF would still support linked data
... RDF could be either just a data structuring language or it could be used as part of the syntax of a representation language
... the higher level language could validate / restrict inputs
... e.g. restrict vocabulary
... this leads to a freer Semantic Web
... this doesn't change that much
... we can extend RDF freely without necessarily affecting things like RDFS or OWL - the higher pieces can use syntactic or semantic extraction methods to handle the extensions

<sandro> NOW is a time I want Pat here. :-/

pfps: MIME types, change over period to make this happen

dbooth: are you suggesting that the semantics should be separated from the RDF? when RDF is given to someone, then they choose what semantics they apply to the RDF?

pfps: more or less --

dbooth: if an RDF author writes RDF and sends it to someone else - how should the consumer of the RDF statements know what semantics are intended by the author?

pfps: MIME type

cygri: or rdf:type on the document

pfps: an internal or extenral syntactic data-ish marker

stefan: if RDF is a data structure language, it still has a semantics - a la a database has semantics - it may not be full FOL semantics, but it has semantics that can be described and expressed using logics
... the different languages on the stack still need to respect each other
... maybe what is wrong here is not what is wrong with RDF but what is wrong with OWL

pfps: the point is that there's nothing wrong with the duality as long as you're low down in the stack - as soon as you get higher (not just OWL), you run into these problems

stefan: I think people still typically do more database-oriented work

pfps: there should retain compatibility issues -- i'm saying that the lockstep is too strict

jjc: the semantics that RDF statements have differs from the RDF Semantics
... the underlying RDF semantics actually seems to come from SPARQL
... I agree that this is the current situation -- what do we need to change?

pfps: I want to deprecate the RDF Semantics document as it applies to RDF(S)
... precisely so that other things can be added

jjc: no one is suggesting mapping a named graph extension to triples

<AndyS> SPARQL treats things as symbols (still partially there under entailment regimes as well). Oops.

DavidW: we're saying precisely the opposite

pfps: but you will need a semantics for named graphs, that will have to cover every corner case for ... whatever.
... as soon as you have named graphs, you need to deal with cycles, multiple documents, etc.

jjc: perhaps "maybe never" give a semantics to named graphs

cygri: of all the stuff i've heard today, this is the one that I really wish we could do
... there's some stuff in RDF Semantics that can't just be deprecated - maybe 3 pages or so

pfps: agreed, but most of that is in RDF Concepts as well

cygri: Could we just point to the useful bits in RDF Semantics and let people ignore the rest of it?

pfps: Possibly

cygri: most people are ignoring it already

pfps: What about RDFS? RDFS has at least an operational semantics for its built-in constructors
... possible world semantics for RDF graphs belongs at a higher level
... the principles of Semantic Web at an RDF graph level still belongs to RDF (e.g. identifiers)

dbooth: I think you need to distinguish between the intended semantics when authored and the semantics that an RDF consumer chooses to apply to it - may be differnet

s/differnet/different

dbooth: suppose 2 graphs A & B with different semantics - what happens when you merge them?

pfps: depends on compatibility issues
... i think the intended semantics of the author is always mangled by the consumer

<dbooth> dbooth: Suppose you have graph Ga with semantics Sa, and graph Gb with semantics Sb. And then you merge graphs Ga and Gb. What should be the semantics of the merged graph?

<Anchakor> there could be an semantics interoperability vocabulary

<dbooth> dbooth; Presumably the intended semantics should be both Sa and Sb.

stefan: in my terms, you're proposing finally applying database semantics into RDF - including UNA, CWA, etc.

pfps: no! just data, not knowledge

pgearon: how many people have leaned out a graph in reality?

jjc: I have!

AxelPolleres: Can you clarify what you said about RDFS?

pfps: Personally, I don't think RDFS has much place in the universe - BUT I was saying that there are parts of the semantics of RDFS that if you're going to keep RDFS as an RL then you want some of these semantics
... maybe the right way to do RDFS is completely operational?

<pgearon> people have made graphs lean? For commercial purposes? Or for theoretic/research purposes?

pfps: that frees you from concerns but opens up a can of worms because there are so many more degrees of freedoms compared to model theoretic semantics

sandro: this is appealing but i'm worried about linked data and worried that the key to linked data is being able to merge graphs

cygri: triples are just edges in a graph, not true statements

sandro: I think that breaks the Semantic Web as a social construct

???: several issues that I want to comment on

<sandro> dbooth: I agree

<Anchakor> it's not like the data would have no semantics if rdf semantics is deprecated, it's a sort of signal of the openness of the system, allowing anyone, perhaps just in natural language define semantics

scribe: Semantic Web calls for proposals for NSF - how do we make available data on the Web and create unexpected use of the data?
... semantics would be assigned by the user side - publisher can recommend semantics but user will take a different interpretation
... since we're talking about data structures, do we care about IRIs and HTTP or do we not care?
... if no linked data, then are we back at graph databases that's been looked at in the past by DB community?

<AndyS> Related: http://www.w3.org/2009/12/rdf-ws/papers/ws31

pfps: No, I think we want to keep IRIs as names at the data level
... my proposal is to slash out pieces of the semantics document?

cygri: I don't think saying that W3C is going to deprecate this document would fly
... could we summarize this? fold this into RDF Concepts?

jjc: we could move the word "normative" around

pfps: Yes, and/or any new additions to RDF don't need to show up in this document

ivan: that is an important statement

jjc: the typical reader would not notice this

pfps: one intended consequence would be to trash the RDFS semantics as wlel

s/wlel/well

<dbooth> The important thing in communicating information is that the RDF consumer must have the *ability* to know what the RDF author intended, whether or not he/she chooses to use it. I.e., the RDF author must be able to indicate the intended semantics.

<dbooth> But the semantic web is all about *merging* data. This means that the mechanism for indicating the semantics must be amenable to graph merging. This works well if predicate URIs in the graph are used to signal the semantics. I don't see how this could work as well if the intended semantics are *separated* from graph, such as being in a MIME type.

*break!*

Dinner and Logistics

<Anchakor> it is hard to imagine this without RDFS

<AxelPolleres> scribe: AxelPolleres

Fabien's presentaion upcoming... http://www.slideshare.net/fabien_gandon/name-that-graph

<LeeF> scribenick: AxelPolleres

Ivan and Sandro arguing about working overnight...

fabien: a lot said about named graphs already
... "preaching to the converted"
... named graphs useful to model context

<dbooth> i/Fabien's presentaion upcoming/Topic: Fabien Gandon: Name that Graph

fabien: document != graph
... so, using the doc URI to speak about a graph is bad practice.
... we heard about C-OWL, con text ,etc.
... not yet mentioned: nested typed graphs
... nested graphs also have an equivalent to bnodes.

we use nested graphs in RDF, e.g. for tagging

fabien: ... or for nested context

sandro: is that an XML syntax extension? compatible with RDF/XML?

fabien: we had to modify by an additional attribute.

sandro: so, not a syntax errror

<sandro> dajobe: It parses as RDF/XML

fabien: we use that for various applications.

axelR: Can you use different applications at the same time?

fabien: in principle yes, with some limitation
... I want RDF1.1 not RDF2.0
... i.e. agree with small steps

naso: how can you meet all your requirements with a single mechanism?

fabien: named graphs are an underpinning for all of those

stefan: i have you down for named graphs and bnodes

fabien: I don't like bnodes

andy's presentation “Supporting Change Propagations in RDF”, Andy Seaborne and Ian Davis

http://openjena.org/~afs/2010-06%20RDF-NS%20Change%20Propagation.pdf

AndyS: Web not only read-only
... changes, edits

<dbooth> i/Seaborne and Ian/Topic: Andy Seaborne: Supporting Change Propagation in RDF/

AndyS: looking at the web as a single graph doesn't caprute the semantic web

<dbooth> Andy's paper: http://www.w3.org/2009/12/rdf-ws/papers/ws07 slides: http://openjena.org/~afs/2010-06%20RDF-NS%20Change%20Propagation.pdf

AndyS: moving around large graphs on the web is problematic (gives some examples)

s/caprute/capture/

AndyS: surveys approaches for change propagation (Delta, RDF Difference, SemVersion, ChangeSets, RDFSync)
... you move around manifest, two graphs (add, remove)
... how to package those graphs?

<LeeF> Think it's a good idea to drill into the idea of RDF Datasets more - I think it would be good to consider them explicitly

AndyS: Named Graphs is different to RDF Datasets

+1 to LeeF, understanding you say so far they're already part of SPARQL standard, but you say could be useful for other uses on RDF?

Andy: exmplifying ChangeSets, sparql update
... TriG

s/TriG/Graph Bundles(TriG)

scribe: Syntax for Graph Bundles matters

<dbooth> Andy's example in n3:

<dbooth> [[

Richard: you could have a literal whose value is a graph.

<dbooth> @prefix : <http://purl.org/vocab/changeset/schema#> .

<dbooth> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<dbooth> <http://example.com/changesets#change> a :ChangeSet;

<dbooth> :addition [

<dbooth> a rdf:Statement;

<dbooth> rdf:object "New Title";

<dbooth> rdf:predicate <http://purl.org/dc/elements/1.1/title>;

<dbooth> rdf:subject <http://example.com/res#thing> ];

<dbooth> :changeReason "Change of title";

<dbooth> :createdDate "2006-01-01T00:00:00Z";

<dbooth> :creatorName "Anne Onymous";

<dbooth> :removal [

<dbooth> a rdf:Statement;

<dbooth> rdf:object "Original Title";

<dbooth> rdf:predicate <http://purl.org/dc/elements/1.1/title>;

<dbooth> rdf:subject <http://example.com/res#thing> ];

<dbooth> :subjectOfChange <http://example.com/res#thing> .

<dbooth> ]]

ivan: vocabulary for change might be useful to standardise as well.

sandro: how to change bnodes?

AndyS: that's a problem, TriG NQuad-s don't specify scope of bnodes.
... bnode could be treated as "_:URI"

<sandro> AndyS: I want BNodes to be just a kind of URIs, so they're table and I can do this, yes.

sandro: this would be the strongest use case for changing bnodes.

<dbooth> Ian: In Talis we don't support bnodes because we want to propagate changes.

<sandro> sandro: because you need at least some stable notion of URI names in order to propagate changes

<sandro> andy: the label only has meaning if you go back to the original graph

<sandro> mika: this is related to feed formats (atom)

<sandro> ivan: Yes

axel: seems enough to qualify bnodes by their graph name (bnodes are local identifiers)

there is an issue on how to model bnode (scope) in named graphs

James Leigh: RDF Isolation API

RDF Isolation API, James Leigh

http://www.w3.org/2009/12/rdf-ws/slides/rdf-isolation.pdf

<dbooth> James's paper: http://www.w3.org/2009/12/rdf-ws/papers/ws13

james: this also needs changesets (connection with andy's talk)
... protocol to change an RDF store and do query operations
... can also delegate to other services

<dbooth> s/topic: RDF Isolation API, //