See also: IRC log
<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
cygri: Four Boundary Conditions for RDF Next Steps
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: 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)
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.
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*
dajobe: RDF syntaxes 2.0
<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?
... 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.
dbooth: What I Want in RDF 2.0
<sandro> dbooth: What helps US (experts) is far less important than what will help new users.
dbooth: REC for some
... 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?
<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
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?
<ivan> Jun Zhao's slides
<iand> pgearon: register a new bnode domain
<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"
... Requirement 2: new URIs means new URIs related to old URIs
<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
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
... 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
OMG Ontology PSIG,
PSIG = Platform Special Interest Group
<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 ....
<AxelPolleres> rdfs:domain owl:sameAs rdf:domain ... done?
<sandro> +1 Axel. :-) DL folks might not like that, though. :-)
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)
<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
squabbling over the defn of "week"
<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
... 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
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
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?
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
psu.edu [PDF]Jeremy J Carroll Signing RDF Graphs - The SemanticWeb-ISWC 2003, 2003 - Springer
<DeborahMcGuinness> *greetings from sfo - looks like you are at lunch. sorry had to leave early
<LeeF> scribenick: LeeF
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
... 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
... 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
... 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
... 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.
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
<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
... 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?
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?
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
... 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?
DavidW: so you can't have a context that operates on part of a named graph
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
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
... e.g. time, provenance
... 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?
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
<sandro> (actually, I said "graph metadata" is the best I know so far, but it's still not great.
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
<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
... 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
... 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?
cygri: most people are ignoring it already
pfps: What about RDFS? RDFS has
at least an operational semantics for its built-in
... 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
dbooth: suppose 2 graphs A & B with different semantics - what happens when you merge them?
pfps: depends on compatibility
... 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
... 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
<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.
<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
... "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
... 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
AndyS: Web not 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)
AndyS: surveys approaches for
change propagation (Delta, RDF Difference, SemVersion,
... 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,
scribe: Syntax for Graph Bundles matters
<dbooth> Andy's example in n3:
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> .
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
<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, //