SV_MEETING_TITLE -- 27 Jun 2010

<jjc> Semantics break out

<jjc> scribenick: jjc

Semantics

Four issues at

http://www.w3.org/2001/sw/wiki/RDF_Core_Charter_2010#Semantics

Blank Nodes, SPARQL-Style RDF Semantics

Archaisms, Literals as Subjects

Jeremy and Peter do not like SPARQL-Style RDF Semantics

as a title

Evan: let's start with the easy bits

Paul: rdf:value - keep this to deal with literals as subjects

List of Archaisms under syntax:

* reification (align with some "named graph" support)

* rdf:Alt (just remove)

* rdf:Bag (fix or remove)

* rdf:Seq (use rdf:List instead; it's costly to have two similar options)

* rdf:value

* xs:string (use plain literals instead)

* rdf:XMLLiteral (use plain literals instead, with quoted XML)

* rdf:ID (use rdf:about instead)

What should we do for these?

discussion of Archaisms

reification: Jeremy - there is no semantics

containers: Jeremy there is no semantics

Peter: yes there is container membership

Jeremy: yes

Paul: what do we want to do

Peter: no one knows what containers mean

Paul: I am reluctant to deprecate something which we do not have equivalent

Peter: we do, you can roll your own

Jeremy: if we are going to depreacte anything, we deprecate Alt

James: let's add to the list for discussion

Peter: we could remove axiomatic triples for rdf:_nn

and hence all the semantics

Paul: are we happy with the semantics of xs:string and plain literals being different

Jeremy: they're not - most widely misimplemented part of RDF Semantics

Peter: simple and D entailments to do with these string literals are different

XMLLiteral ....

rathole into whether we can have inconsistency of RDF or is it RDFS

In RDFS you can get an inconsisteny with an ill-typed XML Literal

in D semantics also illformed xsd literals

<scribe> ACTION: pfps edit wiki to include list of Archaism [recorded in http://www.w3.org/2010/06/27-rdfn-s-minutes.html#action01]

Jeremy: does anyone else have other Archaims

e.g. ill-formed lists

Peter: this would be a big change to the semantics

you could infer sameAs

brief discussion of rdfs:comment etc.

blank nodes

James: does mulgara change the labels internally

Paul: no -we reserve the right to

Jeremy: I don't like the wording

James: is it about scope

Paul: qu about SPARQL and b node semantics

Ian apparently claims that current semantics of blank nodes creates NP complete problem in SPARQL

Jeremy: but subgraph isomporphism is there anyway because of variables

and this is NP complete

Peter: yes

Paul: but we have b node semantics documented

but not used

Peter: maybe it was a mistake to talk about entailment

then we talk about query instead

But maybe this becomes a SPARQL issue

that they should not talk about entailment

--- BREAK

Before break: Jeremy we are not progressing

Evan: but you seem to be making progress on entailment issue

<ekw> scribenick: ekw

paul: we should look at blank nodes and decide if they are addressable
... put it forward as a proposal or say its not something we can do

alejandro: people are using blank nodes in different ways

<pfps> we need to remember to put in stuff to fix the inference rules

alejandro: why can DBpedia create a huge

DB without them, while others can't

jjc: people think that they shouldn't use them, but then they misuse other features to do the same thing
... I think that we have agreed that the formal semantics of RDF will change, but the informal semantics should preserve the blank node disctinction

alehandro: do we need a suggested way of handling this (the pragmatic support for blank nodes)

pfps: there are two things that we could do
... we could decide that blank nodes as currently spec'd are just bad
... you might just decide "There are no blank nodes in RDF graphs."

jjc: a blank node is a node who's name that we don't know rather than a node without a name (an existential)

pfps: the semantics wouldn't have to change for this

jjc: we could delete the text describing blank nodes as an existential since people don't understand it anyway

paul: if we go to SemTech and talk with org's using this stuff, how are they looking at blank nodes?

jjc: the smallest change would be to provide a skolemization algorithm for blank nodes
... however that wouldn't address the issue of the folks who are against using blanknodes

paul: this could change the ways graphs merge
... I don't know if it breaks what's out there, but it certainly changes the story.

jjc: another con is it may make it harder to compare 2 graphs using graph isomorphism

paul: we have established that blank nodes could benefit from some work
... is it possible with working on blank nodes that it could change the semantics? If so, we should record this.

jjc: should we look at literals as subjects now?

PFPS not JJC on last comment

paul: I can't think of a use case for a literal as a predicate, but can for a literal as a subject.
... 3 squareRootOf 9 for example

Stephan: What's the danger of this?

jjc: A con is that rdf/xml changes would be significant.
... as pro it would actually simplify some situations.
... on OWL systems, its difficult but in a triple store system it's significantly easier.

Some discussion about how this relates to the restriction on InverseFuntional properties in OWL.

Going forward this would add more divergence between RDF and OWL (causing a document fork)

Stephan: I don't find these use cases compelling enough to justify this change.
... what I have mind is the social impact that this would have.

This could cause people to make statements about the string instead of about the entity.

Paul: lack of this feature has annoyed me.
... such as in data bases of pseudo primes.

jjc: I don't think we should be neutral about it. I think this group should say that this feature is not worth doing.
... although one of the things that TBL wants is graph literals as subjects.

Paul: how about a best practice of making a blank node sameAs a literal, and use the blank node as a subject everywhere?

Stephan: That would be to me, shooting yourself in the foot.
... I feel unhappy about these type of proposal.
... what's wrong with suggesting that a group investigate this and collect use cases?

subtopic: SPARQL-style semantics

jjc: I would suggest that introductory blurb should talk about RDF as a data language rather than "as seen in SPARQL systems"

[scribe had to leave the room for a half hour]

<AndyS> Issues of simplified RDF semantics

<AndyS1> Scribe: Andy Seaborne

<AndyS1> scribenick: AndyS

Section: Semantics for Next Steps
... datasets: alternatives appraoches for semantis need to be
... considered including model theoretic or (if now normative) entailment rules

Are named graphs first class citizens? Both "yes" and "no" are possible.

JJC: Q: what is the relationship of two named graphs in a single document? If any (leave pragmatic)?

PFPS: When synatx is done, not all work is done.

-> require that any extensions come with semantics

Section: Blank Nodes

add possibility of global naming for blank nodes (not URIs , maybe URIs - alternatives)

Issue: currently reading twice creates different bnodes - preserve this?

JJC: (round tripping discussion)
... want to round trip i.e. preserver references, across serialization and exchange.
... e.g. "this bnodes (triples using...) have changed"

Blank nodes ... remote references use cases ...

scribe: skolemized: what is not yet skolemized?

skolemization is not bnode label

scribe: editting may not preserve skolemization (large, ugly, not human friendly)
... speculation on possible solutions
... to scope space of possibilities

editting the blank nodes section

End of break out session

- DRAFT -

SV_MEETING_TITLE

27 Jun 2010

Attendees

Contents

Semantics

blank nodes

Summary of Action Items

Scribe.perl diagnostic output