RDF Working Group Wiki - User contributions [en]

TF-RDF-XML

Fgandon — Wed, 16 Jan 2013 16:34:40 GMT

Fgandon: /* Change 5: datatyped empty literals */

= Changes from Task Force "RDF-XML" =
List of the changes considered for the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification].

Changes include the [http://www.w3.org/2001/sw/RDFCore/errata#rdf-syntax-grammar Errata for RDF Syntax]

== Change 1: typo "tiple" ==
'''status:'''done.

[http://www.w3.org/2001/sw/RDFCore/errata#syntax-typo-tiple initial erratum]

Syntax typo “tiple” in 7.2.11 Production nodeElement:
"and the following tiple is added to the graph"

== Change 2: hard coded reference to XML and Unicode versions ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#UTF-XML-refs-syntax initial erratum]

Hard coded reference to XML 1.0 and to Unicode 3.0 are unduly restrictive. Both reference should be exchanged against a normative reference to the generically latest versions of both standards.

== Change 3: signature resolve(e, s) ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#missing-parent-accessor initial erratum]

Section 6.3.3 Grammar Action Notation of the RDF/XML Syntax Specification defines the resolve action with the <code>signature resolve(e, s)</code>, i.e. taking two arguments, and yet we find the following:

in 7.2.11 Production nodeElement
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

in 7.2.21 Production emptyPropertyElt
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

while both should read:
<nowiki>u:=uri(identifier:=resolve(e, a.string-value))</nowiki>

== Change 4: missing parent accessor ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#incorrect-resolve initial erratum]
Section 6 of the RDF/XML Syntax Specification (Revised) says that the parent property of the element information item in the XML Infoset is required, but section 6.1.2 Element Event does not create a parent accessor for that event.
Element events therefore do not have a parent accessor, and yet a parent accessor on element events is made use of in a number or sections. See the error submission for further details.

== Change 5: datatyped empty literals ==
'''status:''' open.

[http://www.w3.org/2001/sw/RDFCore/errata#datatyped-empty-literals inital erratum] with [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0000.html email 1] and [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0003.html email 2]

RDF 1.1 WG mailing list: [http://lists.w3.org/Archives/Public/public-rdf-wg/2012Oct/0230.html initial mail for requesting opinions on that issue]

Serialization of datatyped empty literals is not anticipated by the RDF/XML grammar.
This is believed by several developers and former WG-members to be an omission in the grammar defined by the RDF/XML Syntax Specification: a bug was reported (and acknowledged by the editor), relating to the use of an rdf:datatype attribute on empty RDF properties. See the archived mailing list thread for technical details. In addition to the question of the RDF/XML grammar's syntactic completeness, note that this issue identifies a construct that occurs within RDF graphs that cannot be serialized in the RDF/XML syntax.

'''current state:'''
<nowiki>
Current section "7.2.16 Production literalPropertyElt" says
start-element(URI == propertyElementURIs ), attributes == set(idAttr?, datatypeAttr?))
text()
end-element()
Note that the empty literal case is defined in production emptyPropertyElt.
(...)

Current section "7.2.21 Production emptyPropertyElt" says
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*))
end-element()
(...)

with section "7.2.7 Production propertyAttributeURIs" specifying and
anyURI - ( coreSyntaxTerms | rdf:Description | rdf:li | oldTerms )
(...)

with section "7.2.2 Production coreSyntaxTerms" including datatypes:
rdf:RDF | rdf:ID | rdf:about | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
(...)
</nowiki>

'''proposed change:'''
<nowiki>
7.2.21 Production emptyPropertyElt
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr | datatypeAttr)?, propertyAttr*))
end-element()
</nowiki>

== Change 6: ID and datatype exclusion on literal property ==
'''status:''' open.

[http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0023.html intial mail]

Concerning the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html#section-RELAXNG-Schema RELAX NG Compact Schema for RDF/XML].
The production rules only allow either an rdf:ID attribute or an rdf:datatype attribute to be specified on a literal property, but not both. This is different from the normative grammar in chapter 7. The result of following this grammar would be that triples with a datatyped literal as object cannot be reified in the normal way.

(Changes are required in the document and the linked rdfxml.rnc)

'''actual grammar:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
(idAttr | datatypeAttr )?, xmllang?, xmlbase?, text
}
</nowiki>

'''proposed change:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
idAttr?, datatypeAttr?, xmllang?, xmlbase?, text
}
</nowiki>

== Change 7: HTML5 in RDF-XML ==
'''status:''' open.

We should decide whether rdf/xml will be extended to support html5 datatype and to include special syntactic support for our new HTML datatype

'''Current position:''' just include examples of HTML using CDATA

== Change 8: named graph support in RDF-XML ==
'''status:''' to be discussed

We could consider an extension of the RDF/XML syntax e.g. an attribute rdf:graph may be inserted in an RDF/XML document to specify the label of the graph.

The label of a triple is:
* the label specified by a rdf:graph attribute on the XML element encoding this triple, if one exists, otherwise
* the label of the element's parent element (obtained following recursively the same rules), otherwise
* the default label otherwise.

The scope of a graph label declaration extends from the beginning of the start-element in which it appears to the end of the corresponding end-element, excluding the scope of any graph label declarations. Such a graph label declaration applies to all elements and attributes within its scope. In the case of an empty element, the scope is the element itself.

Only one graph label can be declared as attribute of a single element.

Thus the rdf:graph attribute can be used on any node element or property element to indicate that the included content belongs to a specific graph. The most specific in-scope graph label present (if any) is applied.

We allow explicitly default graph : the rdf:graph="" form indicates the default graph.

TF-RDF-XML

Fgandon — Wed, 16 Jan 2013 16:34:29 GMT

Fgandon: /* Change 5: datatyped empty literals */

= Changes from Task Force "RDF-XML" =
List of the changes considered for the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification].

Changes include the [http://www.w3.org/2001/sw/RDFCore/errata#rdf-syntax-grammar Errata for RDF Syntax]

== Change 1: typo "tiple" ==
'''status:'''done.

[http://www.w3.org/2001/sw/RDFCore/errata#syntax-typo-tiple initial erratum]

Syntax typo “tiple” in 7.2.11 Production nodeElement:
"and the following tiple is added to the graph"

== Change 2: hard coded reference to XML and Unicode versions ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#UTF-XML-refs-syntax initial erratum]

Hard coded reference to XML 1.0 and to Unicode 3.0 are unduly restrictive. Both reference should be exchanged against a normative reference to the generically latest versions of both standards.

== Change 3: signature resolve(e, s) ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#missing-parent-accessor initial erratum]

Section 6.3.3 Grammar Action Notation of the RDF/XML Syntax Specification defines the resolve action with the <code>signature resolve(e, s)</code>, i.e. taking two arguments, and yet we find the following:

in 7.2.11 Production nodeElement
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

in 7.2.21 Production emptyPropertyElt
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

while both should read:
<nowiki>u:=uri(identifier:=resolve(e, a.string-value))</nowiki>

== Change 4: missing parent accessor ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#incorrect-resolve initial erratum]
Section 6 of the RDF/XML Syntax Specification (Revised) says that the parent property of the element information item in the XML Infoset is required, but section 6.1.2 Element Event does not create a parent accessor for that event.
Element events therefore do not have a parent accessor, and yet a parent accessor on element events is made use of in a number or sections. See the error submission for further details.

== Change 5: datatyped empty literals ==
'''status:''' open.

[http://www.w3.org/2001/sw/RDFCore/errata#datatyped-empty-literals inital erratum] with [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0000.html email 1] and [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0003.html email 2]

RDF 1.1 WG mailing list:[http://lists.w3.org/Archives/Public/public-rdf-wg/2012Oct/0230.html initial mail for requesting opinions on that issue]

Serialization of datatyped empty literals is not anticipated by the RDF/XML grammar.
This is believed by several developers and former WG-members to be an omission in the grammar defined by the RDF/XML Syntax Specification: a bug was reported (and acknowledged by the editor), relating to the use of an rdf:datatype attribute on empty RDF properties. See the archived mailing list thread for technical details. In addition to the question of the RDF/XML grammar's syntactic completeness, note that this issue identifies a construct that occurs within RDF graphs that cannot be serialized in the RDF/XML syntax.

'''current state:'''
<nowiki>
Current section "7.2.16 Production literalPropertyElt" says
start-element(URI == propertyElementURIs ), attributes == set(idAttr?, datatypeAttr?))
text()
end-element()
Note that the empty literal case is defined in production emptyPropertyElt.
(...)

Current section "7.2.21 Production emptyPropertyElt" says
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*))
end-element()
(...)

with section "7.2.7 Production propertyAttributeURIs" specifying and
anyURI - ( coreSyntaxTerms | rdf:Description | rdf:li | oldTerms )
(...)

with section "7.2.2 Production coreSyntaxTerms" including datatypes:
rdf:RDF | rdf:ID | rdf:about | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
(...)
</nowiki>

'''proposed change:'''
<nowiki>
7.2.21 Production emptyPropertyElt
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr | datatypeAttr)?, propertyAttr*))
end-element()
</nowiki>

== Change 6: ID and datatype exclusion on literal property ==
'''status:''' open.

[http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0023.html intial mail]

Concerning the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html#section-RELAXNG-Schema RELAX NG Compact Schema for RDF/XML].
The production rules only allow either an rdf:ID attribute or an rdf:datatype attribute to be specified on a literal property, but not both. This is different from the normative grammar in chapter 7. The result of following this grammar would be that triples with a datatyped literal as object cannot be reified in the normal way.

(Changes are required in the document and the linked rdfxml.rnc)

'''actual grammar:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
(idAttr | datatypeAttr )?, xmllang?, xmlbase?, text
}
</nowiki>

'''proposed change:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
idAttr?, datatypeAttr?, xmllang?, xmlbase?, text
}
</nowiki>

== Change 7: HTML5 in RDF-XML ==
'''status:''' open.

We should decide whether rdf/xml will be extended to support html5 datatype and to include special syntactic support for our new HTML datatype

'''Current position:''' just include examples of HTML using CDATA

== Change 8: named graph support in RDF-XML ==
'''status:''' to be discussed

We could consider an extension of the RDF/XML syntax e.g. an attribute rdf:graph may be inserted in an RDF/XML document to specify the label of the graph.

The label of a triple is:
* the label specified by a rdf:graph attribute on the XML element encoding this triple, if one exists, otherwise
* the label of the element's parent element (obtained following recursively the same rules), otherwise
* the default label otherwise.

The scope of a graph label declaration extends from the beginning of the start-element in which it appears to the end of the corresponding end-element, excluding the scope of any graph label declarations. Such a graph label declaration applies to all elements and attributes within its scope. In the case of an empty element, the scope is the element itself.

Only one graph label can be declared as attribute of a single element.

Thus the rdf:graph attribute can be used on any node element or property element to indicate that the included content belongs to a specific graph. The most specific in-scope graph label present (if any) is applied.

We allow explicitly default graph : the rdf:graph="" form indicates the default graph.

TF-RDF-XML

Fgandon — Wed, 16 Jan 2013 16:34:17 GMT

Fgandon: /* Change 5: datatyped empty literals */

= Changes from Task Force "RDF-XML" =
List of the changes considered for the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification].

Changes include the [http://www.w3.org/2001/sw/RDFCore/errata#rdf-syntax-grammar Errata for RDF Syntax]

== Change 1: typo "tiple" ==
'''status:'''done.

[http://www.w3.org/2001/sw/RDFCore/errata#syntax-typo-tiple initial erratum]

Syntax typo “tiple” in 7.2.11 Production nodeElement:
"and the following tiple is added to the graph"

== Change 2: hard coded reference to XML and Unicode versions ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#UTF-XML-refs-syntax initial erratum]

Hard coded reference to XML 1.0 and to Unicode 3.0 are unduly restrictive. Both reference should be exchanged against a normative reference to the generically latest versions of both standards.

== Change 3: signature resolve(e, s) ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#missing-parent-accessor initial erratum]

Section 6.3.3 Grammar Action Notation of the RDF/XML Syntax Specification defines the resolve action with the <code>signature resolve(e, s)</code>, i.e. taking two arguments, and yet we find the following:

in 7.2.11 Production nodeElement
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

in 7.2.21 Production emptyPropertyElt
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

while both should read:
<nowiki>u:=uri(identifier:=resolve(e, a.string-value))</nowiki>

== Change 4: missing parent accessor ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#incorrect-resolve initial erratum]
Section 6 of the RDF/XML Syntax Specification (Revised) says that the parent property of the element information item in the XML Infoset is required, but section 6.1.2 Element Event does not create a parent accessor for that event.
Element events therefore do not have a parent accessor, and yet a parent accessor on element events is made use of in a number or sections. See the error submission for further details.

== Change 5: datatyped empty literals ==
'''status:''' open.

[http://www.w3.org/2001/sw/RDFCore/errata#datatyped-empty-literals inital erratum] with [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0000.html email 1] and [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0003.html email 2]
RDF 1.1 WG mailing list:[http://lists.w3.org/Archives/Public/public-rdf-wg/2012Oct/0230.html initial mail for requesting opinions on that issue]

Serialization of datatyped empty literals is not anticipated by the RDF/XML grammar.
This is believed by several developers and former WG-members to be an omission in the grammar defined by the RDF/XML Syntax Specification: a bug was reported (and acknowledged by the editor), relating to the use of an rdf:datatype attribute on empty RDF properties. See the archived mailing list thread for technical details. In addition to the question of the RDF/XML grammar's syntactic completeness, note that this issue identifies a construct that occurs within RDF graphs that cannot be serialized in the RDF/XML syntax.

'''current state:'''
<nowiki>
Current section "7.2.16 Production literalPropertyElt" says
start-element(URI == propertyElementURIs ), attributes == set(idAttr?, datatypeAttr?))
text()
end-element()
Note that the empty literal case is defined in production emptyPropertyElt.
(...)

Current section "7.2.21 Production emptyPropertyElt" says
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*))
end-element()
(...)

with section "7.2.7 Production propertyAttributeURIs" specifying and
anyURI - ( coreSyntaxTerms | rdf:Description | rdf:li | oldTerms )
(...)

with section "7.2.2 Production coreSyntaxTerms" including datatypes:
rdf:RDF | rdf:ID | rdf:about | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
(...)
</nowiki>

'''proposed change:'''
<nowiki>
7.2.21 Production emptyPropertyElt
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr | datatypeAttr)?, propertyAttr*))
end-element()
</nowiki>

== Change 6: ID and datatype exclusion on literal property ==
'''status:''' open.

[http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0023.html intial mail]

Concerning the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html#section-RELAXNG-Schema RELAX NG Compact Schema for RDF/XML].
The production rules only allow either an rdf:ID attribute or an rdf:datatype attribute to be specified on a literal property, but not both. This is different from the normative grammar in chapter 7. The result of following this grammar would be that triples with a datatyped literal as object cannot be reified in the normal way.

(Changes are required in the document and the linked rdfxml.rnc)

'''actual grammar:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
(idAttr | datatypeAttr )?, xmllang?, xmlbase?, text
}
</nowiki>

'''proposed change:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
idAttr?, datatypeAttr?, xmllang?, xmlbase?, text
}
</nowiki>

== Change 7: HTML5 in RDF-XML ==
'''status:''' open.

We should decide whether rdf/xml will be extended to support html5 datatype and to include special syntactic support for our new HTML datatype

'''Current position:''' just include examples of HTML using CDATA

== Change 8: named graph support in RDF-XML ==
'''status:''' to be discussed

We could consider an extension of the RDF/XML syntax e.g. an attribute rdf:graph may be inserted in an RDF/XML document to specify the label of the graph.

The label of a triple is:
* the label specified by a rdf:graph attribute on the XML element encoding this triple, if one exists, otherwise
* the label of the element's parent element (obtained following recursively the same rules), otherwise
* the default label otherwise.

The scope of a graph label declaration extends from the beginning of the start-element in which it appears to the end of the corresponding end-element, excluding the scope of any graph label declarations. Such a graph label declaration applies to all elements and attributes within its scope. In the case of an empty element, the scope is the element itself.

Only one graph label can be declared as attribute of a single element.

Thus the rdf:graph attribute can be used on any node element or property element to indicate that the included content belongs to a specific graph. The most specific in-scope graph label present (if any) is applied.

We allow explicitly default graph : the rdf:graph="" form indicates the default graph.

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 11:35:48 GMT

Fgandon: /* Change 7: HTML5 in RDF-XML */

= Changes from Task Force "RDF-XML" =
List of the changes considered for the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification].

Changes include the [http://www.w3.org/2001/sw/RDFCore/errata#rdf-syntax-grammar Errata for RDF Syntax]

== Change 1: typo "tiple" ==
'''status:'''done.

[http://www.w3.org/2001/sw/RDFCore/errata#syntax-typo-tiple initial erratum]

Syntax typo “tiple” in 7.2.11 Production nodeElement:
"and the following tiple is added to the graph"

== Change 2: hard coded reference to XML and Unicode versions ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#UTF-XML-refs-syntax initial erratum]

Hard coded reference to XML 1.0 and to Unicode 3.0 are unduly restrictive. Both reference should be exchanged against a normative reference to the generically latest versions of both standards.

== Change 3: signature resolve(e, s) ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#missing-parent-accessor initial erratum]

Section 6.3.3 Grammar Action Notation of the RDF/XML Syntax Specification defines the resolve action with the <code>signature resolve(e, s)</code>, i.e. taking two arguments, and yet we find the following:

in 7.2.11 Production nodeElement
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

in 7.2.21 Production emptyPropertyElt
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

while both should read:
<nowiki>u:=uri(identifier:=resolve(e, a.string-value))</nowiki>

== Change 4: missing parent accessor ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#incorrect-resolve initial erratum]
Section 6 of the RDF/XML Syntax Specification (Revised) says that the parent property of the element information item in the XML Infoset is required, but section 6.1.2 Element Event does not create a parent accessor for that event.
Element events therefore do not have a parent accessor, and yet a parent accessor on element events is made use of in a number or sections. See the error submission for further details.

== Change 5: datatyped empty literals ==
'''status:''' open.

[http://www.w3.org/2001/sw/RDFCore/errata#datatyped-empty-literals inital erratum] with [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0000.html email 1] and [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0003.html email 2]

Serialization of datatyped empty literals is not anticipated by the RDF/XML grammar.
This is believed by several developers and former WG-members to be an omission in the grammar defined by the RDF/XML Syntax Specification: a bug was reported (and acknowledged by the editor), relating to the use of an rdf:datatype attribute on empty RDF properties. See the archived mailing list thread for technical details. In addition to the question of the RDF/XML grammar's syntactic completeness, note that this issue identifies a construct that occurs within RDF graphs that cannot be serialized in the RDF/XML syntax.

'''current state:'''
<nowiki>
Current section "7.2.16 Production literalPropertyElt" says
start-element(URI == propertyElementURIs ), attributes == set(idAttr?, datatypeAttr?))
text()
end-element()
Note that the empty literal case is defined in production emptyPropertyElt.
(...)

Current section "7.2.21 Production emptyPropertyElt" says
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*))
end-element()
(...)

with section "7.2.7 Production propertyAttributeURIs" specifying and
anyURI - ( coreSyntaxTerms | rdf:Description | rdf:li | oldTerms )
(...)

with section "7.2.2 Production coreSyntaxTerms" including datatypes:
rdf:RDF | rdf:ID | rdf:about | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
(...)
</nowiki>

'''proposed change:'''
<nowiki>
7.2.21 Production emptyPropertyElt
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr | datatypeAttr)?, propertyAttr*))
end-element()
</nowiki>

== Change 6: ID and datatype exclusion on literal property ==
'''status:''' open.

[http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0023.html intial mail]

Concerning the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html#section-RELAXNG-Schema RELAX NG Compact Schema for RDF/XML].
The production rules only allow either an rdf:ID attribute or an rdf:datatype attribute to be specified on a literal property, but not both. This is different from the normative grammar in chapter 7. The result of following this grammar would be that triples with a datatyped literal as object cannot be reified in the normal way.

(Changes are required in the document and the linked rdfxml.rnc)

'''actual grammar:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
(idAttr | datatypeAttr )?, xmllang?, xmlbase?, text
}
</nowiki>

'''proposed change:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
idAttr?, datatypeAttr?, xmllang?, xmlbase?, text
}
</nowiki>

== Change 7: HTML5 in RDF-XML ==
'''status:''' open.

We should decide whether rdf/xml will be extended to support html5 datatype and to include special syntactic support for our new HTML datatype

'''Current position:''' just include examples of HTML using CDATA

== Change 8: named graph support in RDF-XML ==
'''status:''' to be discussed

We could consider an extension of the RDF/XML syntax e.g. an attribute rdf:graph may be inserted in an RDF/XML document to specify the label of the graph.

The label of a triple is:
* the label specified by a rdf:graph attribute on the XML element encoding this triple, if one exists, otherwise
* the label of the element's parent element (obtained following recursively the same rules), otherwise
* the default label otherwise.

The scope of a graph label declaration extends from the beginning of the start-element in which it appears to the end of the corresponding end-element, excluding the scope of any graph label declarations. Such a graph label declaration applies to all elements and attributes within its scope. In the case of an empty element, the scope is the element itself.

Only one graph label can be declared as attribute of a single element.

Thus the rdf:graph attribute can be used on any node element or property element to indicate that the included content belongs to a specific graph. The most specific in-scope graph label present (if any) is applied.

We allow explicitly default graph : the rdf:graph="" form indicates the default graph.

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 11:34:39 GMT

Fgandon: /* Changes from Task Force "RDF-XML" */

= Changes from Task Force "RDF-XML" =
List of the changes considered for the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification].

Changes include the [http://www.w3.org/2001/sw/RDFCore/errata#rdf-syntax-grammar Errata for RDF Syntax]

== Change 1: typo "tiple" ==
'''status:'''done.

[http://www.w3.org/2001/sw/RDFCore/errata#syntax-typo-tiple initial erratum]

Syntax typo “tiple” in 7.2.11 Production nodeElement:
"and the following tiple is added to the graph"

== Change 2: hard coded reference to XML and Unicode versions ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#UTF-XML-refs-syntax initial erratum]

Hard coded reference to XML 1.0 and to Unicode 3.0 are unduly restrictive. Both reference should be exchanged against a normative reference to the generically latest versions of both standards.

== Change 3: signature resolve(e, s) ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#missing-parent-accessor initial erratum]

Section 6.3.3 Grammar Action Notation of the RDF/XML Syntax Specification defines the resolve action with the <code>signature resolve(e, s)</code>, i.e. taking two arguments, and yet we find the following:

in 7.2.11 Production nodeElement
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

in 7.2.21 Production emptyPropertyElt
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

while both should read:
<nowiki>u:=uri(identifier:=resolve(e, a.string-value))</nowiki>

== Change 4: missing parent accessor ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#incorrect-resolve initial erratum]
Section 6 of the RDF/XML Syntax Specification (Revised) says that the parent property of the element information item in the XML Infoset is required, but section 6.1.2 Element Event does not create a parent accessor for that event.
Element events therefore do not have a parent accessor, and yet a parent accessor on element events is made use of in a number or sections. See the error submission for further details.

== Change 5: datatyped empty literals ==
'''status:''' open.

[http://www.w3.org/2001/sw/RDFCore/errata#datatyped-empty-literals inital erratum] with [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0000.html email 1] and [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0003.html email 2]

Serialization of datatyped empty literals is not anticipated by the RDF/XML grammar.
This is believed by several developers and former WG-members to be an omission in the grammar defined by the RDF/XML Syntax Specification: a bug was reported (and acknowledged by the editor), relating to the use of an rdf:datatype attribute on empty RDF properties. See the archived mailing list thread for technical details. In addition to the question of the RDF/XML grammar's syntactic completeness, note that this issue identifies a construct that occurs within RDF graphs that cannot be serialized in the RDF/XML syntax.

'''current state:'''
<nowiki>
Current section "7.2.16 Production literalPropertyElt" says
start-element(URI == propertyElementURIs ), attributes == set(idAttr?, datatypeAttr?))
text()
end-element()
Note that the empty literal case is defined in production emptyPropertyElt.
(...)

Current section "7.2.21 Production emptyPropertyElt" says
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*))
end-element()
(...)

with section "7.2.7 Production propertyAttributeURIs" specifying and
anyURI - ( coreSyntaxTerms | rdf:Description | rdf:li | oldTerms )
(...)

with section "7.2.2 Production coreSyntaxTerms" including datatypes:
rdf:RDF | rdf:ID | rdf:about | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
(...)
</nowiki>

'''proposed change:'''
<nowiki>
7.2.21 Production emptyPropertyElt
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr | datatypeAttr)?, propertyAttr*))
end-element()
</nowiki>

== Change 6: ID and datatype exclusion on literal property ==
'''status:''' open.

[http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0023.html intial mail]

Concerning the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html#section-RELAXNG-Schema RELAX NG Compact Schema for RDF/XML].
The production rules only allow either an rdf:ID attribute or an rdf:datatype attribute to be specified on a literal property, but not both. This is different from the normative grammar in chapter 7. The result of following this grammar would be that triples with a datatyped literal as object cannot be reified in the normal way.

(Changes are required in the document and the linked rdfxml.rnc)

'''actual grammar:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
(idAttr | datatypeAttr )?, xmllang?, xmlbase?, text
}
</nowiki>

'''proposed change:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
idAttr?, datatypeAttr?, xmllang?, xmlbase?, text
}
</nowiki>

== Change 7: HTML5 in RDF-XML ==
We should decide whether rdf/xml will be extended to support html5 datatype and to include special syntactic support for our new HTML datatype

'''Current position:''' just include examples of HTML using CDATA

== Change 8: named graph support in RDF-XML ==
'''status:''' to be discussed

We could consider an extension of the RDF/XML syntax e.g. an attribute rdf:graph may be inserted in an RDF/XML document to specify the label of the graph.

The label of a triple is:
* the label specified by a rdf:graph attribute on the XML element encoding this triple, if one exists, otherwise
* the label of the element's parent element (obtained following recursively the same rules), otherwise
* the default label otherwise.

The scope of a graph label declaration extends from the beginning of the start-element in which it appears to the end of the corresponding end-element, excluding the scope of any graph label declarations. Such a graph label declaration applies to all elements and attributes within its scope. In the case of an empty element, the scope is the element itself.

Only one graph label can be declared as attribute of a single element.

Thus the rdf:graph attribute can be used on any node element or property element to indicate that the included content belongs to a specific graph. The most specific in-scope graph label present (if any) is applied.

We allow explicitly default graph : the rdf:graph="" form indicates the default graph.

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 11:19:28 GMT

Fgandon: /* Change 6: ID and datatype exclusion on literal property */

= Changes from Task Force "RDF-XML" =
List of the changes considered for the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification].

Changes include the [http://www.w3.org/2001/sw/RDFCore/errata#rdf-syntax-grammar Errata for RDF Syntax]

== Change 1: typo "tiple" ==
'''status:'''done.

[http://www.w3.org/2001/sw/RDFCore/errata#syntax-typo-tiple initial erratum]

Syntax typo “tiple” in 7.2.11 Production nodeElement:
"and the following tiple is added to the graph"

== Change 2: hard coded reference to XML and Unicode versions ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#UTF-XML-refs-syntax initial erratum]

Hard coded reference to XML 1.0 and to Unicode 3.0 are unduly restrictive. Both reference should be exchanged against a normative reference to the generically latest versions of both standards.

== Change 3: signature resolve(e, s) ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#missing-parent-accessor initial erratum]

Section 6.3.3 Grammar Action Notation of the RDF/XML Syntax Specification defines the resolve action with the <code>signature resolve(e, s)</code>, i.e. taking two arguments, and yet we find the following:

in 7.2.11 Production nodeElement
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

in 7.2.21 Production emptyPropertyElt
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

while both should read:
<nowiki>u:=uri(identifier:=resolve(e, a.string-value))</nowiki>

== Change 4: missing parent accessor ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#incorrect-resolve initial erratum]
Section 6 of the RDF/XML Syntax Specification (Revised) says that the parent property of the element information item in the XML Infoset is required, but section 6.1.2 Element Event does not create a parent accessor for that event.
Element events therefore do not have a parent accessor, and yet a parent accessor on element events is made use of in a number or sections. See the error submission for further details.

== Change 5: datatyped empty literals ==
'''status:''' open.

[http://www.w3.org/2001/sw/RDFCore/errata#datatyped-empty-literals inital erratum] with [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0000.html email 1] and [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0003.html email 2]

Serialization of datatyped empty literals is not anticipated by the RDF/XML grammar.
This is believed by several developers and former WG-members to be an omission in the grammar defined by the RDF/XML Syntax Specification: a bug was reported (and acknowledged by the editor), relating to the use of an rdf:datatype attribute on empty RDF properties. See the archived mailing list thread for technical details. In addition to the question of the RDF/XML grammar's syntactic completeness, note that this issue identifies a construct that occurs within RDF graphs that cannot be serialized in the RDF/XML syntax.

'''current state:'''
<nowiki>
Current section "7.2.16 Production literalPropertyElt" says
start-element(URI == propertyElementURIs ), attributes == set(idAttr?, datatypeAttr?))
text()
end-element()
Note that the empty literal case is defined in production emptyPropertyElt.
(...)

Current section "7.2.21 Production emptyPropertyElt" says
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*))
end-element()
(...)

with section "7.2.7 Production propertyAttributeURIs" specifying and
anyURI - ( coreSyntaxTerms | rdf:Description | rdf:li | oldTerms )
(...)

with section "7.2.2 Production coreSyntaxTerms" including datatypes:
rdf:RDF | rdf:ID | rdf:about | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
(...)
</nowiki>

'''proposed change:'''
<nowiki>
7.2.21 Production emptyPropertyElt
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr | datatypeAttr)?, propertyAttr*))
end-element()
</nowiki>

== Change 6: ID and datatype exclusion on literal property ==
'''status:''' open.

[http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0023.html intial mail]

Concerning the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html#section-RELAXNG-Schema RELAX NG Compact Schema for RDF/XML].
The production rules only allow either an rdf:ID attribute or an rdf:datatype attribute to be specified on a literal property, but not both. This is different from the normative grammar in chapter 7. The result of following this grammar would be that triples with a datatyped literal as object cannot be reified in the normal way.

(Changes are required in the document and the linked rdfxml.rnc)

'''actual grammar:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
(idAttr | datatypeAttr )?, xmllang?, xmlbase?, text
}
</nowiki>

'''proposed change:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
idAttr?, datatypeAttr?, xmllang?, xmlbase?, text
}
</nowiki>

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 11:17:49 GMT

Fgandon: /* Change 6: ID and datatype exclusion on literal property */

= Changes from Task Force "RDF-XML" =
List of the changes considered for the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification].

Changes include the [http://www.w3.org/2001/sw/RDFCore/errata#rdf-syntax-grammar Errata for RDF Syntax]

== Change 1: typo "tiple" ==
'''status:'''done.

[http://www.w3.org/2001/sw/RDFCore/errata#syntax-typo-tiple initial erratum]

Syntax typo “tiple” in 7.2.11 Production nodeElement:
"and the following tiple is added to the graph"

== Change 2: hard coded reference to XML and Unicode versions ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#UTF-XML-refs-syntax initial erratum]

Hard coded reference to XML 1.0 and to Unicode 3.0 are unduly restrictive. Both reference should be exchanged against a normative reference to the generically latest versions of both standards.

== Change 3: signature resolve(e, s) ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#missing-parent-accessor initial erratum]

Section 6.3.3 Grammar Action Notation of the RDF/XML Syntax Specification defines the resolve action with the <code>signature resolve(e, s)</code>, i.e. taking two arguments, and yet we find the following:

in 7.2.11 Production nodeElement
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

in 7.2.21 Production emptyPropertyElt
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

while both should read:
<nowiki>u:=uri(identifier:=resolve(e, a.string-value))</nowiki>

== Change 4: missing parent accessor ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#incorrect-resolve initial erratum]
Section 6 of the RDF/XML Syntax Specification (Revised) says that the parent property of the element information item in the XML Infoset is required, but section 6.1.2 Element Event does not create a parent accessor for that event.
Element events therefore do not have a parent accessor, and yet a parent accessor on element events is made use of in a number or sections. See the error submission for further details.

== Change 5: datatyped empty literals ==
'''status:''' open.

[http://www.w3.org/2001/sw/RDFCore/errata#datatyped-empty-literals inital erratum] with [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0000.html email 1] and [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0003.html email 2]

Serialization of datatyped empty literals is not anticipated by the RDF/XML grammar.
This is believed by several developers and former WG-members to be an omission in the grammar defined by the RDF/XML Syntax Specification: a bug was reported (and acknowledged by the editor), relating to the use of an rdf:datatype attribute on empty RDF properties. See the archived mailing list thread for technical details. In addition to the question of the RDF/XML grammar's syntactic completeness, note that this issue identifies a construct that occurs within RDF graphs that cannot be serialized in the RDF/XML syntax.

'''current state:'''
<nowiki>
Current section "7.2.16 Production literalPropertyElt" says
start-element(URI == propertyElementURIs ), attributes == set(idAttr?, datatypeAttr?))
text()
end-element()
Note that the empty literal case is defined in production emptyPropertyElt.
(...)

Current section "7.2.21 Production emptyPropertyElt" says
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*))
end-element()
(...)

with section "7.2.7 Production propertyAttributeURIs" specifying and
anyURI - ( coreSyntaxTerms | rdf:Description | rdf:li | oldTerms )
(...)

with section "7.2.2 Production coreSyntaxTerms" including datatypes:
rdf:RDF | rdf:ID | rdf:about | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
(...)
</nowiki>

'''proposed change:'''
<nowiki>
7.2.21 Production emptyPropertyElt
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr | datatypeAttr)?, propertyAttr*))
end-element()
</nowiki>

== Change 6: ID and datatype exclusion on literal property ==
'''status:''' open.

[http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0023.html intial mail]

Concerning the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html#section-RELAXNG-Schema RELAX NG Compact Schema for RDF/XML].
The production rules only allow either an rdf:ID attribute or an rdf:datatype attribute to be specified on a literal property, but not both. This is different from the normative grammar in chapter 7. The result of following this grammar would be that triples with a datatyped literal as object cannot be reified in the normal way.

'''actual grammar:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
(idAttr | datatypeAttr )?, xmllang?, xmlbase?, text
}
</nowiki>

'''proposed change:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
idAttr?, datatypeAttr?, xmllang?, xmlbase?, text
}
</nowiki>

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 11:17:09 GMT

Fgandon:

= Changes from Task Force "RDF-XML" =
List of the changes considered for the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification].

Changes include the [http://www.w3.org/2001/sw/RDFCore/errata#rdf-syntax-grammar Errata for RDF Syntax]

== Change 1: typo "tiple" ==
'''status:'''done.

[http://www.w3.org/2001/sw/RDFCore/errata#syntax-typo-tiple initial erratum]

Syntax typo “tiple” in 7.2.11 Production nodeElement:
"and the following tiple is added to the graph"

== Change 2: hard coded reference to XML and Unicode versions ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#UTF-XML-refs-syntax initial erratum]

Hard coded reference to XML 1.0 and to Unicode 3.0 are unduly restrictive. Both reference should be exchanged against a normative reference to the generically latest versions of both standards.

== Change 3: signature resolve(e, s) ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#missing-parent-accessor initial erratum]

Section 6.3.3 Grammar Action Notation of the RDF/XML Syntax Specification defines the resolve action with the <code>signature resolve(e, s)</code>, i.e. taking two arguments, and yet we find the following:

in 7.2.11 Production nodeElement
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

in 7.2.21 Production emptyPropertyElt
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

while both should read:
<nowiki>u:=uri(identifier:=resolve(e, a.string-value))</nowiki>

== Change 4: missing parent accessor ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#incorrect-resolve initial erratum]
Section 6 of the RDF/XML Syntax Specification (Revised) says that the parent property of the element information item in the XML Infoset is required, but section 6.1.2 Element Event does not create a parent accessor for that event.
Element events therefore do not have a parent accessor, and yet a parent accessor on element events is made use of in a number or sections. See the error submission for further details.

== Change 5: datatyped empty literals ==
'''status:''' open.

[http://www.w3.org/2001/sw/RDFCore/errata#datatyped-empty-literals inital erratum] with [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0000.html email 1] and [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0003.html email 2]

Serialization of datatyped empty literals is not anticipated by the RDF/XML grammar.
This is believed by several developers and former WG-members to be an omission in the grammar defined by the RDF/XML Syntax Specification: a bug was reported (and acknowledged by the editor), relating to the use of an rdf:datatype attribute on empty RDF properties. See the archived mailing list thread for technical details. In addition to the question of the RDF/XML grammar's syntactic completeness, note that this issue identifies a construct that occurs within RDF graphs that cannot be serialized in the RDF/XML syntax.

'''current state:'''
<nowiki>
Current section "7.2.16 Production literalPropertyElt" says
start-element(URI == propertyElementURIs ), attributes == set(idAttr?, datatypeAttr?))
text()
end-element()
Note that the empty literal case is defined in production emptyPropertyElt.
(...)

Current section "7.2.21 Production emptyPropertyElt" says
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*))
end-element()
(...)

with section "7.2.7 Production propertyAttributeURIs" specifying and
anyURI - ( coreSyntaxTerms | rdf:Description | rdf:li | oldTerms )
(...)

with section "7.2.2 Production coreSyntaxTerms" including datatypes:
rdf:RDF | rdf:ID | rdf:about | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
(...)
</nowiki>

'''proposed change:'''
<nowiki>
7.2.21 Production emptyPropertyElt
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr | datatypeAttr)?, propertyAttr*))
end-element()
</nowiki>

== Change 6: ID and datatype exclusion on literal property ==
'''status:''' open.

[http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0023.html intial mail]

Concerning the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html#section-RELAXNG-Schema RELAX NG Compact Schema for RDF/XML].
The production rules only allow either an rdf:ID attribute or an rdf:datatype attribute to be specified on a literal property, but not both. This is different from the normative grammar in chapter 7. The result of following this grammar would be that triples with a datatyped literal as object cannot be reified in the normal way.

'''actual grammar:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
(idAttr | datatypeAttr )?, xmllang?, xmlbase?, text
}

'''proposed change:'''
<nowiki>literalPropertyElt =
element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
rdf:resource | rdf:nodeID | rdf:datatype |
rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix |
rdf:bagID | xml:* ) {
idAttr?, datatypeAttr?, xmllang?, xmlbase?, text
}
</nowiki>

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 11:05:10 GMT

Fgandon: /* Task Force "RDF-XML" */

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 11:00:37 GMT

Fgandon: /* Change 5: datatyped empty literals */

= Task Force "RDF-XML" =
List of the changes considered for the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification].

Changes include the [http://www.w3.org/2001/sw/RDFCore/errata#rdf-syntax-grammar Errata for RDF Syntax]

== Change 1: typo "tiple" ==
'''status:'''done.

[http://www.w3.org/2001/sw/RDFCore/errata#syntax-typo-tiple initial erratum]

Syntax typo “tiple” in 7.2.11 Production nodeElement:
"and the following tiple is added to the graph"

== Change 2: hard coded reference to XML and Unicode versions ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#UTF-XML-refs-syntax initial erratum]

Hard coded reference to XML 1.0 and to Unicode 3.0 are unduly restrictive. Both reference should be exchanged against a normative reference to the generically latest versions of both standards.

== Change 3: signature resolve(e, s) ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#missing-parent-accessor initial erratum]

Section 6.3.3 Grammar Action Notation of the RDF/XML Syntax Specification defines the resolve action with the <code>signature resolve(e, s)</code>, i.e. taking two arguments, and yet we find the following:

in 7.2.11 Production nodeElement
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

in 7.2.21 Production emptyPropertyElt
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

while both should read:
<nowiki>u:=uri(identifier:=resolve(e, a.string-value))</nowiki>

== Change 4: missing parent accessor ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#incorrect-resolve initial erratum]
Section 6 of the RDF/XML Syntax Specification (Revised) says that the parent property of the element information item in the XML Infoset is required, but section 6.1.2 Element Event does not create a parent accessor for that event.
Element events therefore do not have a parent accessor, and yet a parent accessor on element events is made use of in a number or sections. See the error submission for further details.

== Change 5: datatyped empty literals ==
'''status:''' open.

[http://www.w3.org/2001/sw/RDFCore/errata#datatyped-empty-literals inital erratum] with [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0000.html email 1] and [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0003.html email 2]

Serialization of datatyped empty literals is not anticipated by the RDF/XML grammar.
This is believed by several developers and former WG-members to be an omission in the grammar defined by the RDF/XML Syntax Specification: a bug was reported (and acknowledged by the editor), relating to the use of an rdf:datatype attribute on empty RDF properties. See the archived mailing list thread for technical details. In addition to the question of the RDF/XML grammar's syntactic completeness, note that this issue identifies a construct that occurs within RDF graphs that cannot be serialized in the RDF/XML syntax.

'''current state:'''
<nowiki>
Current section "7.2.16 Production literalPropertyElt" says
start-element(URI == propertyElementURIs ), attributes == set(idAttr?, datatypeAttr?))
text()
end-element()
Note that the empty literal case is defined in production emptyPropertyElt.
(...)

Current section "7.2.21 Production emptyPropertyElt" says
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*))
end-element()
(...)

with section "7.2.7 Production propertyAttributeURIs" specifying and
anyURI - ( coreSyntaxTerms | rdf:Description | rdf:li | oldTerms )
(...)

with section "7.2.2 Production coreSyntaxTerms" including datatypes:
rdf:RDF | rdf:ID | rdf:about | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
(...)
</nowiki>

'''proposed change:'''
<nowiki>
7.2.21 Production emptyPropertyElt
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr | datatypeAttr)?, propertyAttr*))
end-element()
</nowiki>

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 10:59:30 GMT

Fgandon: /* Task Force "RDF-XML" */

= Task Force "RDF-XML" =
List of the changes considered for the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification].

Changes include the [http://www.w3.org/2001/sw/RDFCore/errata#rdf-syntax-grammar Errata for RDF Syntax]

== Change 1: typo "tiple" ==
'''status:'''done.

[http://www.w3.org/2001/sw/RDFCore/errata#syntax-typo-tiple initial erratum]

Syntax typo “tiple” in 7.2.11 Production nodeElement:
"and the following tiple is added to the graph"

== Change 2: hard coded reference to XML and Unicode versions ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#UTF-XML-refs-syntax initial erratum]

Hard coded reference to XML 1.0 and to Unicode 3.0 are unduly restrictive. Both reference should be exchanged against a normative reference to the generically latest versions of both standards.

== Change 3: signature resolve(e, s) ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#missing-parent-accessor initial erratum]

Section 6.3.3 Grammar Action Notation of the RDF/XML Syntax Specification defines the resolve action with the <code>signature resolve(e, s)</code>, i.e. taking two arguments, and yet we find the following:

in 7.2.11 Production nodeElement
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

in 7.2.21 Production emptyPropertyElt
<nowiki>u:=uri(identifier:=resolve(a.string-value))</nowiki>

while both should read:
<nowiki>u:=uri(identifier:=resolve(e, a.string-value))</nowiki>

== Change 4: missing parent accessor ==
'''status:''' done.

[http://www.w3.org/2001/sw/RDFCore/errata#incorrect-resolve initial erratum]
Section 6 of the RDF/XML Syntax Specification (Revised) says that the parent property of the element information item in the XML Infoset is required, but section 6.1.2 Element Event does not create a parent accessor for that event.
Element events therefore do not have a parent accessor, and yet a parent accessor on element events is made use of in a number or sections. See the error submission for further details.

== Change 5: datatyped empty literals ==
'''status:''' open.

[http://www.w3.org/2001/sw/RDFCore/errata#datatyped-empty-literals inital erratum] with [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0000.html email 1] and [http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0003.html email 2]

Serialization of datatyped empty literals is not anticipated by the RDF/XML grammar.
This is believed by several developers and former WG-members to be an omission in the grammar defined by the RDF/XML Syntax Specification: a bug was reported (and acknowledged by the editor), relating to the use of an rdf:datatype attribute on empty RDF properties. See the archived mailing list thread for technical details. In addition to the question of the RDF/XML grammar's syntactic completeness, note that this issue identifies a construct that occurs within RDF graphs that cannot be serialized in the RDF/XML syntax.

'''proposal:'''
<nowiki>
Current section "7.2.16 Production literalPropertyElt" says
start-element(URI == propertyElementURIs ), attributes == set(idAttr?, datatypeAttr?))
text()
end-element()
Note that the empty literal case is defined in production emptyPropertyElt.
(...)

Current section "7.2.21 Production emptyPropertyElt" says
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*))
end-element()
(...)

with section "7.2.7 Production propertyAttributeURIs" specifying and
anyURI - ( coreSyntaxTerms | rdf:Description | rdf:li | oldTerms )
(...)

with section "7.2.2 Production coreSyntaxTerms" including datatypes:
rdf:RDF | rdf:ID | rdf:about | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
(...)

My understanding here is that we could change section 7.2.21 this way:

7.2.21 Production emptyPropertyElt
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr | datatypeAttr)?, propertyAttr*))
end-element()
</nowiki>

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 10:50:21 GMT

Fgandon: /* Change 3: signature resolve(e, s) */

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 10:49:57 GMT

Fgandon: /* Change 3: signature resolve(e, s) */

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 10:49:08 GMT

Fgandon: /* Change 3 */

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 10:44:40 GMT

Fgandon: /* Change 2: hard coded reference to XML and Unicode versions */

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 10:43:42 GMT

Fgandon: /* Change 2 */

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 10:41:36 GMT

Fgandon: /* Change 1: typo "tiple" */

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 10:41:16 GMT

Fgandon: /* Change 1 */

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 10:38:23 GMT

Fgandon: /* Task Force "RDF-XML" */

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 10:34:20 GMT

Fgandon: /* Task Force "RDF-XML" */

= Task Force "RDF-XML" =
List of the changes considered for the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification]
Changes include the [http://www.w3.org/2001/sw/RDFCore/errata#rdf-syntax-grammar Errata for RDF Syntax]

== Change 1 ==

== Change 2 ==

== Change 3 ==

TF-RDF-XML

Fgandon — Tue, 30 Oct 2012 10:32:41 GMT

Fgandon: Created page with "= Task Force "RDF-XML" = List of the changes considered for the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification] == Change 1 == …"

= Task Force "RDF-XML" =
List of the changes considered for the [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification]

== Change 1 ==

== Change 2 ==

== Change 3 ==

Main Page

Fgandon — Tue, 30 Oct 2012 10:29:46 GMT

Fgandon: /* Ongoing Work */ RDF-XML changes page

__NOTOC__
= RDF Working Group =

{{BlueBanner|''Mission: Update the [http://www.w3.org/standards/techs/rdf#w3c_all 2004 RDF Recommendations], extending RDF to include features desirable and important for interoperability, but without a negative effect on deployment.'' (See [http://www.w3.org/2011/01/rdf-wg-charter Charter])}}

== Deliverables ==

See '''[[Documents]]''' for a list of expected documents.

Editors' drafts
* [https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html RDF 1.1 Abstract Syntax]
* [https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-json/index.html RDF 1.1 JSON Serialisation (RDF/JSON)]
* [https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/index.html Turtle]
* [https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-schema/index.html RDF Vocabulary Description Language 1.1: RDF Schema]
* [https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-syntax/index.html JSON-LD Syntax] and [https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-api/index.html API]
* [http://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html# TriG]
* [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification]

Published official drafts
* [http://www.w3.org/TR/2012/WD-turtle-20120710/ Turtle] Last Call, 2012-07-10
* [http://www.w3.org/TR/2012/WD-rdf11-concepts-20120605/ RDF 1.1 Concepts and Abstract Syntax], Working Draft, 2012-06-05
* [http://www.w3.org/TR/2012/WD-json-ld-syntax-20120712/ JSON-LD Syntax 1.0] and [http://www.w3.org/TR/2012/WD-json-ld-api-20120712/ JSON-LD API 1.0], First Public Working Drafts, 2012-07-12

Also see [http://www.w3.org/2011/rdf-wg/wiki/Category:Inputs Inputs].

== Ongoing Work ==

* Task Force [[TF-Graphs|Graphs]] (Named Graphs)
* Task Force [[TF-Turtle|Turtle]]
* Task force [[TF-JSON|JSON]]
* Task force [[TF-RDF-XML|RDF-XML]]
* [[Misc_Tasks|Cleanup tasks]]

Besides the [http://www.w3.org/2011/rdf-wg/track tracker], there is also a [http://demo.3roundstones.net/rdf/2012/rdfwg/resolutions.xhtml?view list of WG resolutions] available.

== Participation ==

See
[http://www.w3.org/2000/09/dbwg/details?group=46168&public=1 list of current participants],
(or [http://www.w3.org/2000/09/dbwg/details?group=46168 with contact info]),
[[Special:ListUsers|wiki user pages]],
[http://www.w3.org/2011/rdf-wg/track/users nicknames]

If you want to join this group, see [[How to Join]].

If you are officially in the group, you will automatically receive group email and your w3.org login and password will work on this wiki.

See the evolving list of [[Editors]].

== [[Meetings]] ==

Face-to-face:
* [[F2F1]] Amsterdam, 13-14 April 2011
* [[F2F2]] Boston (MIT) and London (BBC), 12-13 October 2011
* [[FTF3|F2F3]] Lyon, France, 29-30 October 2012 (at TPAC)

Teleconferences ([http://www.w3.org/2000/09/dbwg/details?group=46168&public=1 official participants] and invited guests only):
* Wednesdays, 11am US/Eastern time, for up to 90 minutes.
* Dial +1-617-761-6200 or sip:zakim@voip.w3.org then conference code 73394#
* [http://www.w3.org/Project/IRC/ IRC] channel: [irc://irc.w3.org:6665/#rdf-wg #rdf-wg].
* An agenda is [http://lists.w3.org/Archives/Public/public-rdf-wg/latest sent] 24 hours in advance; minutes follow within a day or two.
* [[Scribes]]

{{:Meetings}}

=== Coordination telecons ===

Coordinations with Provenance WG:
* Teleconference 2011.09.15 [[Meetings:Telecon2011.09.15|Agenda]] [http://www.w3.org/2011/rdf-wg/meeting/2011-09-15 Minutes]

== Timeline ==

Only trivial updates since the [http://www.w3.org/2011/01/rdf-wg-charter#deliverables charter version].

* 2011-02: First teleconference
* 2011-04: First face-to-face meeting ([[F2F1]])
* 2011-05: Publication of the First Public Working Drafts for the RDF Recommendation Set
* 2011-10 or 11: Second face-to-face meeting ([[F2F2]])
* 2012-04: Third face-to-face meeting
* 2012-05: Publication of the Last Call Working Draft for the RDF Recommendation Set
* 2012-06: Publication of the Last Call Working Draft for the RDF Primer and Test Cases
* 2012-10 or 11: Fourth face-to-face meeting
* 2012-11: Publication of the Proposed Recommendations
* 2012-01: Publication of all final documents

== W3C Working Group Resources ==

* [http://www.w3.org/Guide/ Art of Consensus (guide to working at W3C)] (W3C member confidential)
* [http://www.w3.org/2005/10/Process-20051014 World Wide Web Consortium (W3C) Process Document]
* [http://www.w3.org/Member/Mail/Overview.html All W3C Groups] (W3C member confidential)
* [http://www.w3.org/2006/tools/wiki/Mercurial Info on Mercurial usage]
* Telco tools
** [http://www.w3.org/2001/12/zakim-irc-bot.html Zakim commands]
** [http://www.w3.org/2005/06/tracker/irc Trackbot description]
** [http://www.w3.org/2009/CommonScribe/manual CommonScribe user guide]

== Patent Policy ==

This Working Group operates under the [http://www.w3.org//Consortium/Patent-Policy-20040205/ W3C Patent Policy] (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

For more information about disclosure obligations for this group, please see the [http://www.w3.org/2004/01/pp-impl/46168/status W3C Patent Policy Status Page].

== Staff ==

Email the chairs and staff contacts at [mailto:team-rdf-chairs@w3.org team-rdf-chairs@w3.org].

* [http://www.linkedin.com/pub/david-wood/a/b24/495 David Wood], 3 Round Stones Inc., Co-Chair
* [http://www.cs.vu.nl/~guus/ Guus Schreiber], VU University Amsterdam, Co-Chair
* [http://www.w3.org/People/Sandro Sandro Hawke], W3C, Staff Contact
* [http://www.w3.org/People/Ivan Ivan Herman], W3C, Staff Contact

Main Page

Fgandon — Tue, 30 Oct 2012 10:24:14 GMT

Fgandon: /* Deliverables */ added link to RDF 1.1 XML Syntax Specification

__NOTOC__
= RDF Working Group =

{{BlueBanner|''Mission: Update the [http://www.w3.org/standards/techs/rdf#w3c_all 2004 RDF Recommendations], extending RDF to include features desirable and important for interoperability, but without a negative effect on deployment.'' (See [http://www.w3.org/2011/01/rdf-wg-charter Charter])}}

== Deliverables ==

See '''[[Documents]]''' for a list of expected documents.

Editors' drafts
* [https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html RDF 1.1 Abstract Syntax]
* [https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-json/index.html RDF 1.1 JSON Serialisation (RDF/JSON)]
* [https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/index.html Turtle]
* [https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-schema/index.html RDF Vocabulary Description Language 1.1: RDF Schema]
* [https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-syntax/index.html JSON-LD Syntax] and [https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-api/index.html API]
* [http://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html# TriG]
* [http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html RDF 1.1 XML Syntax Specification]

Published official drafts
* [http://www.w3.org/TR/2012/WD-turtle-20120710/ Turtle] Last Call, 2012-07-10
* [http://www.w3.org/TR/2012/WD-rdf11-concepts-20120605/ RDF 1.1 Concepts and Abstract Syntax], Working Draft, 2012-06-05
* [http://www.w3.org/TR/2012/WD-json-ld-syntax-20120712/ JSON-LD Syntax 1.0] and [http://www.w3.org/TR/2012/WD-json-ld-api-20120712/ JSON-LD API 1.0], First Public Working Drafts, 2012-07-12

Also see [http://www.w3.org/2011/rdf-wg/wiki/Category:Inputs Inputs].

== Ongoing Work ==

* Task Force [[TF-Graphs|Graphs]] (Named Graphs)
* Task Force [[TF-Turtle|Turtle]]
* Task force [[TF-JSON|JSON]]
* [[Misc_Tasks|Cleanup tasks]]

Besides the [http://www.w3.org/2011/rdf-wg/track tracker], there is also a [http://demo.3roundstones.net/rdf/2012/rdfwg/resolutions.xhtml?view list of WG resolutions] available.

== Participation ==

See
[http://www.w3.org/2000/09/dbwg/details?group=46168&public=1 list of current participants],
(or [http://www.w3.org/2000/09/dbwg/details?group=46168 with contact info]),
[[Special:ListUsers|wiki user pages]],
[http://www.w3.org/2011/rdf-wg/track/users nicknames]

If you want to join this group, see [[How to Join]].

If you are officially in the group, you will automatically receive group email and your w3.org login and password will work on this wiki.

See the evolving list of [[Editors]].

== [[Meetings]] ==

Face-to-face:
* [[F2F1]] Amsterdam, 13-14 April 2011
* [[F2F2]] Boston (MIT) and London (BBC), 12-13 October 2011
* [[FTF3|F2F3]] Lyon, France, 29-30 October 2012 (at TPAC)

Teleconferences ([http://www.w3.org/2000/09/dbwg/details?group=46168&public=1 official participants] and invited guests only):
* Wednesdays, 11am US/Eastern time, for up to 90 minutes.
* Dial +1-617-761-6200 or sip:zakim@voip.w3.org then conference code 73394#
* [http://www.w3.org/Project/IRC/ IRC] channel: [irc://irc.w3.org:6665/#rdf-wg #rdf-wg].
* An agenda is [http://lists.w3.org/Archives/Public/public-rdf-wg/latest sent] 24 hours in advance; minutes follow within a day or two.
* [[Scribes]]

{{:Meetings}}

=== Coordination telecons ===

Coordinations with Provenance WG:
* Teleconference 2011.09.15 [[Meetings:Telecon2011.09.15|Agenda]] [http://www.w3.org/2011/rdf-wg/meeting/2011-09-15 Minutes]

== Timeline ==

Only trivial updates since the [http://www.w3.org/2011/01/rdf-wg-charter#deliverables charter version].

* 2011-02: First teleconference
* 2011-04: First face-to-face meeting ([[F2F1]])
* 2011-05: Publication of the First Public Working Drafts for the RDF Recommendation Set
* 2011-10 or 11: Second face-to-face meeting ([[F2F2]])
* 2012-04: Third face-to-face meeting
* 2012-05: Publication of the Last Call Working Draft for the RDF Recommendation Set
* 2012-06: Publication of the Last Call Working Draft for the RDF Primer and Test Cases
* 2012-10 or 11: Fourth face-to-face meeting
* 2012-11: Publication of the Proposed Recommendations
* 2012-01: Publication of all final documents

== W3C Working Group Resources ==

* [http://www.w3.org/Guide/ Art of Consensus (guide to working at W3C)] (W3C member confidential)
* [http://www.w3.org/2005/10/Process-20051014 World Wide Web Consortium (W3C) Process Document]
* [http://www.w3.org/Member/Mail/Overview.html All W3C Groups] (W3C member confidential)
* [http://www.w3.org/2006/tools/wiki/Mercurial Info on Mercurial usage]
* Telco tools
** [http://www.w3.org/2001/12/zakim-irc-bot.html Zakim commands]
** [http://www.w3.org/2005/06/tracker/irc Trackbot description]
** [http://www.w3.org/2009/CommonScribe/manual CommonScribe user guide]

== Patent Policy ==

This Working Group operates under the [http://www.w3.org//Consortium/Patent-Policy-20040205/ W3C Patent Policy] (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

For more information about disclosure obligations for this group, please see the [http://www.w3.org/2004/01/pp-impl/46168/status W3C Patent Policy Status Page].

== Staff ==

Email the chairs and staff contacts at [mailto:team-rdf-chairs@w3.org team-rdf-chairs@w3.org].

* [http://www.linkedin.com/pub/david-wood/a/b24/495 David Wood], 3 Round Stones Inc., Co-Chair
* [http://www.cs.vu.nl/~guus/ Guus Schreiber], VU University Amsterdam, Co-Chair
* [http://www.w3.org/People/Sandro Sandro Hawke], W3C, Staff Contact
* [http://www.w3.org/People/Ivan Ivan Herman], W3C, Staff Contact

F2F3

Fgandon — Mon, 29 Oct 2012 17:58:18 GMT

Fgandon: /* Participants */

MINUTES: [http://www.w3.org/2011/rdf-wg/meeting/2012-10-29 Day 1] [http://www.w3.org/2011/rdf-wg/meeting/2012-10-30 Day 2]

Scheduled for 29-30 October 2012 at [http://www.w3.org/2012/10/TPAC/ TPAC 2012], Lyon, France

See the (closed) poll results at: https://www.w3.org/2002/09/wbs/46168/FTF-Fall2012/results

== TPAC location and accommodation ==

=== Venue ===

VENUE: CITÉ CENTRE DE CONGRÈS DE LYON
[http://www.ccc-lyon.com/ Cité Centre de Congrès de Lyon]
50, quai Charles de Gaulle
([http://www.w3.org/2012/10/TPAC/#Transportation "Musée d'Art Contemporain" on the Trolleybus line C1])
69463 Lyon Cedex 06
France
Tel: +33 4 72 82 26 26
Fax: +33 4 72 82 26 27

=== Zakim Reservation for Remote Participation ===

Monday, 29 Oct - Tuesday, 30 Oct 06:00-16:00 UTC (2:00am-12:00pm Boston local)

Zakim Bridge +1.617.761.6200, conference 73394 ("RDFWG")

=== Accommodations ===

See "Accommodation" section on the [http://www.w3.org/2012/10/TPAC/ TPAC page].

'''Please note that no block booking has been made. It is strongly recommended to make hotel reservations as soon as possible as there will be other meetings at the conference center.'''

== Participants ==

; Intend to attend at TPAC (you must [http://www.w3.org/2012/10/TPAC/#Registration register]!)
: David Wood
: Sandro Hawke
: Ivan Herman
: Guus Schreiber
: [[User:Azimmerm | Antoine Zimmermann]]
: Richard Cyganiak
: Pierre-Antoine Champin
: Arnaud Le Hors
: Yves Raimond
: François Daoust (day 2)
: [[User:Fgandon | Fabien Gandon]] (via registration)
: Eric Prud'hommeaux (via registration)
: Alexandre Bertails (via registration)

; Intend to attend remotely
: [[User:Andy_Seaborne | Andy Seaborne]] (specific sessions)
: [[User:gkellogg | Gregg Kellogg]]
: Scott Bauer
: Markus Lanthaler
: Alex Hall
: Charles Greer
: [[User:gcarothe | Gavin Carothers]]
: Souripriya Das
: [[User:tthibodeau | Ted Thibodeau]]
: [[User: Phayes3 | Pat Hayes]] (some sessions)
: [[User:msporny|Manu Sporny]] (JSON-LD sessions)
: Tom Baker (RDF Concepts)
: Zhe Wu

; Regrets
: Peter F. Patel-Schneider (conflicting meeting, may be able to phone in some times)
: Steve Harris (unfortunately I had to cancel, and I won't be able to attend remotely)

; At risk

; Observers
: Steve Speicher (IBM Corporation) : attending Monday, Tuesday
: Steve Holbrook (IBM Corporation) : attending Monday, Tuesday
: Harry Halpin (W3C Staff) : attending Monday, Tuesday
: Al Villarica (Smart Communications Inc.,) : attending Monday
: Karen Myers (W3C Staff) : attending Tuesday
: Larry Masinter (Adobe Systems Inc.) : attending Tuesday

== Agenda ==

=== Day 1 ===

; 09.00-09.30
: Arrival, coffee
; 09.30-10.30
: Welcome, logistics, short intro round, recap of meeting goals, agenda amendments. [[F2F3-objectives|Some thoughts on objectives]]
; 10.30-11.00
: RDF 1.1 Primer (Editors: Guus Schreiber, Fabien Gandon)
; 11.00-11.30
: RDF/XML (Editor: Fabien Gandon)
; 11.30-12.00
: RDF 1.1 Schema (Editor: Dan Brickley)
; 12.00-13.00
: LUNCH - Forum 3, Level -2 - Forums
; 13.00-14.00
: RDF Concepts (Editors: Richard Cyganiak, David Wood)
; 14.00-15.00
: RDF Semantics (Editors: Pat Hayes, Peter Patel-Schneider)
; 15.00-15.30
: Finalize Concepts/Semantics issues
; 15.30-16.00
: COFFEE/TEA BREAK - Place Haute, Level 1 - Rhône Pasteur
; 16.00-16.30
: Turtle (Editors: Gavin Carothers, Eric Prud'hommeaux)
; 16.30-17.00
: Day 1 recap, identification of topics for day-2 breakouts
; 18.30-22.00
: [http://www.w3.org/2012/10/TPAC/meetup-Lyon.html Developer Meetup at Lyon City Hall]

=== Day 2 ===

; 09.00-09.15
: Arrival, coffee, day 2 logistics
; 09.15-10.30
: TriG (Editor?)
; 10.30-11.00
: COFFEE/TEA BREAK - Place Haute, Level 1 - Rhône Pasteur
; 11.00-12.30
: N-quads (Should we pursue? Editor?)
; 12.30-13.30
: LUNCH - Forum 3, Level -2 - Forums
; 13.30-14.00
: JSON-LD Syntax 1.0 (Editors: Manu Sporny, Gregg Kellogg, Markus Lanthaler)
; 14.00-14.45
: JSON-LD API 1.0 (Editors: Manu Sporny, Gregg Kellogg, Markus Lanthaler)
; 14.45-15.30
: Breakout sessions on possible Notes (Alternative Semantics Note?, JSON-LD Recipes Note?, others?)
; 15.30-16.00
: COFFEE/TEA BREAK - Place Haute, Level 1 - Rhône Pasteur
; 16.00-16.30
: Plenary to discuss Notes
; 16.30-17.00
: Day 2 recap
; 18.45-19.30
: AC Reception - Place Haute, Level 1 Rhône Pasteur
; 19.30-21.30
: AC Dinner - Pasteur Lounge, Level 1 - Rhône Pasteur

Chatlog 2012-01-25

Fgandon — Wed, 25 Jan 2012 17:32:32 GMT

Fgandon:

{{chatlog|rrsagent=http://www.w3.org/2012/01/25-rdf-wg-irc.txt|chatlog={{fullurl:{{PAGENAME}}}}}}
<pre><nowiki>
15:12:56 <RRSAgent> RRSAgent has joined #rdf-wg
15:12:56 <RRSAgent> logging to http://www.w3.org/2012/01/25-rdf-wg-irc
15:12:58 <trackbot> RRSAgent, make logs world
15:12:58 <Zakim> Zakim has joined #rdf-wg
15:13:00 <trackbot> Zakim, this will be 73394
15:13:00 <Zakim> ok, trackbot; I see SW_RDFWG()11:00AM scheduled to start in 47 minutes
15:13:01 <trackbot> Meeting: RDF Working Group Teleconference
15:13:01 <trackbot> Date: 25 January 2012
15:16:40 <danbri> danbri has joined #rdf-wg
15:25:05 <AndyS> AndyS has joined #rdf-wg
15:56:07 <mdmdm> mdmdm has joined #rdf-wg
15:56:21 <AndyS1> AndyS1 has joined #rdf-wg
15:57:09 <FabGandon> FabGandon has joined #rdf-wg
15:57:17 <ivan_> ivan_ has joined #rdf-wg
15:57:47 <cgreer> cgreer has joined #rdf-wg
15:57:51 <Zakim> SW_RDFWG()11:00AM has now started
15:57:58 <Zakim> +Scott_Bauer
15:58:15 <Zakim> -Scott_Bauer
15:58:16 <Zakim> SW_RDFWG()11:00AM has ended
15:58:16 <Zakim> Attendees were Scott_Bauer
15:58:32 <Zakim> SW_RDFWG()11:00AM has now started
15:58:39 <Zakim> +gavinc
15:59:04 <Zakim> +cgreer
15:59:26 <Zakim> +??P14
15:59:35 <AndyS1> zakim, ??P14 is me
15:59:35 <Zakim> +AndyS1; got it
15:59:40 <Zakim> +bhyland
16:00:19 <davidwood> Zakim, bhyland is me
16:00:19 <Zakim> +davidwood; got it
16:00:32 <davidwood> Zakim, who is here?
16:00:32 <Zakim> On the phone I see gavinc, cgreer, AndyS1, davidwood
16:00:33 <Zakim> On IRC I see cgreer, ivan_, FabGandon, AndyS1, mdmdm, AndyS, danbri, Zakim, RRSAgent, MacTed, LeeF, ivan, mischat, cygri, gavinc_, manu, davidwood, manu1, trackbot, yvesr, NickH,
16:00:36 <Zakim> ... sandro, ericP
16:00:42 <Zakim> +OpenLink_Software
16:01:21 <Zakim> +[Sophia]
16:01:21 <Zakim> +Eric
16:01:31 <MacTed> Zakim, OpenLink_Software is temporarily me
16:01:31 <Zakim> +MacTed; got it
16:01:37 <MacTed> Zakim, mute me
16:01:38 <Zakim> MacTed should now be muted
16:01:43 <FabGandon> zakim, [Sophia] is FabGandon
16:01:43 <Zakim> +FabGandon; got it
16:03:11 <ivan_> zakim, dial ivan-voip
16:03:16 <Zakim> ok, ivan_; the call is being made
16:03:20 <Zakim> +Ivan
16:03:52 <Zakim> +Scott_Bauer
16:05:09 <FabGandon> Scribe: Fabien Gandon
16:05:18 <FabGandon> ScribeNick: FabGandon
16:05:41 <zwu2> zwu2 has joined #rdf-wg
16:05:43 <davidwood> Zakim, who is here?
16:05:43 <Zakim> On the phone I see gavinc, cgreer, AndyS1, davidwood, MacTed (muted), FabGandon, Eric, Ivan, Scott_Bauer
16:05:45 <Zakim> On IRC I see zwu2, cgreer, ivan_, FabGandon, AndyS1, mdmdm, AndyS, danbri, Zakim, RRSAgent, MacTed, LeeF, mischat, cygri, gavinc_, manu, davidwood, manu1, trackbot, yvesr, NickH,
16:05:47 <zwu2> zakim, code?
16:05:47 <Zakim> ... sandro, ericP
16:05:49 <Zakim> the conference code is 73394 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), zwu2
16:05:55 <danbri> hi folks, regrets from me ... laptop too overwhelmed to run Skype right now (giant mysql job)
16:06:12 <davidwood> PROPOSED to accept the minutes of the 18 Jan telecon:
16:06:12 <davidwood> http://www.w3.org/2011/rdf-wg/meeting/2012-01-18
16:06:33 <Zakim> +zwu2
16:06:36 <davidwood> Action item review:
16:06:36 <trackbot> Sorry, couldn't find user - item
16:06:36 <davidwood> http://www.w3.org/2011/rdf-wg/track/actions/pendingreview
16:06:36 <davidwood> http://www.w3.org/2011/rdf-wg/track/actions/open
16:06:37 <zwu2> zakim, mute me
16:06:37 <Zakim> zwu2 should now be muted
16:06:53 <AlexHall> AlexHall has joined #rdf-wg
16:07:31 <Zakim> + +1.443.212.aaaa
16:07:40 <AlexHall> zakim, aaaa is me
16:07:40 <Zakim> +AlexHall; got it
16:07:52 <Zakim> +Souri
16:08:08 <Guus> Guus has joined #rdf-wg
16:08:24 <Souri> Souri has joined #RDF-WG
16:09:11 <Zakim> +Guus
16:09:19 <swh> swh has joined #rdf-wg
16:10:25 <Zakim> +LeeF
16:11:55 <davidwood> Topic: Reviewers for XSD 1.1?
16:12:12 <davidwood> http://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/ W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures
16:12:12 <davidwood> http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/ W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes
16:12:27 <FabGandon> they moved to proposed Rec and affect RDF
16:12:46 <FabGandon> davidwood ... we need reviewers
16:13:06 <FabGandon> Iven: the first part does not impact us
16:13:15 <FabGandon> s/Iven/Ivan
16:13:54 <ericP> http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/
16:14:04 <ericP> [[
16:14:05 <ericP> This second edition is not a new version, it merely incorporates the changes dictated by the corrections to errors found in the first edition as agreed by the XML Schema Working Group, as a convenience to readers. A separate list of all such corrections is available at http://www.w3.org/2001/05/xmlschema-errata.
16:14:11 <ericP> ]]
16:14:16 <FabGandon> davidwood: eg. of problems links between XMLLiteral and RDF Literals
16:14:22 <AndyS1> http://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/
16:15:09 <FabGandon> davidwood: we need to lood at XSD Strings
16:15:24 <ericP> -> http://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/#changes changes from schema 1.0 to 1.1
16:15:24 <FabGandon> s/lood/look
16:15:29 <AndyS1> and XSD decimal canonical form (FYI)
16:16:28 <ivan_> The changes URI is http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes
16:16:32 <FabGandon> ... we need someone to go through changes
16:16:43 <FabGandon> ericP: I can do it
16:17:23 <FabGandon> AlexHall: volonteer
16:17:43 <ivan_> -> http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes changes
16:17:59 <ivan_> q+
16:18:17 <FabGandon> proposed : "ACTION: ericP and AlexHall to review changes in W3C XML Schema Definition Language (XSD)"
16:18:17 <davidwood> http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes
16:19:18 <gavinc_> AndyS1, http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#f-decimalCanmap !
16:19:25 <ericP> ACTION: ericP to review changes in W3C XML Schema Definition Language (XSD) -- http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes
16:19:26 <trackbot> Created ACTION-135 - Review changes in W3C XML Schema Definition Language (XSD) -- http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes [on Eric Prud'hommeaux - due 2012-02-01].
16:19:35 <ericP> ACTION: AlexHall to review changes in W3C XML Schema Definition Language (XSD) -- http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes
16:19:35 <trackbot> Created ACTION-136 - Review changes in W3C XML Schema Definition Language (XSD) -- http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes [on Alex Hall - due 2012-02-01].
16:19:36 <FabGandon> Ivan: the changes in the datatypes may affect us too
16:19:59 <davidwood> I see "Conforming implementations may now support ·primitive· datatypes and facets in addition to those defined here."
16:20:49 <FabGandon> Ivan: there might be changes for instance in data comparison
16:21:10 <davidwood> " this allows float and double to treat positive and negative zero as distinct values, but nevertheless to treat them as equal for purposes of bounds checking" (!) :)
16:21:25 <davidwood> ^^ These things are important to end users, after all
16:21:41 <FabGandon> ericP: is there anyway for the structure to have an impact our data model ?
16:22:12 <FabGandon> Ivan: my opinion is that we are not affected by structure
16:23:06 <FabGandon> ... but the RDF semantics makes a selection of the datatype and this may have to be reviewed.
16:23:35 <davidwood> Topic: RDF-ISSUE-82 (TriG repeated graph iris)
16:24:28 <AndyS1> q+
16:24:35 <ivan_> q-
16:24:36 <FabGandon> gavinc_: consensus on the second option changing "merge" to "union", blank nodes with the same plabel are considered the same
16:25:34 <ScottB_> ScottB_ has joined #rdf-wg
16:25:58 <FabGandon> ... no semantics for blank nodes between graphs with different labels
16:26:32 <FabGandon> ... inference graphs are kept different and are an example where same labels may mean same nodes
16:27:25 <FabGandon> ... no equivalent in RDF/XML or Turtle right now.
16:27:41 <MacTed> Zakim, unmute me
16:27:41 <Zakim> MacTed should no longer be muted
16:28:09 <AndyS1> ack me
16:28:33 <AndyS1> +1
16:28:35 <ericP> +1
16:28:38 <cgreer> +1
16:28:41 <ivan_> 1
16:28:43 <zwu2> +1
16:28:44 <LeeF> +1
16:28:45 <Guus> +1
16:28:47 <AlexHall> +1
16:28:47 <gavinc_> +1
16:28:48 <Souri> +1
16:28:54 <gavinc_> "In a TriG document graph statements with the same graph IRI should be
16:28:56 <gavinc_> unioned to form a single RDF Graph. Blank nodes in each graph
16:28:57 <gavinc_> statement with the same label are considered to be the same blank
16:28:59 <gavinc_> node."
16:29:03 <FabGandon> davidwood: any objection to the wording (strawpoll)
16:29:18 <MacTed> +1
16:29:31 <FabGandon> ... we have a consensus
16:30:08 <gavinc_> RESOLVE to close ISSUE-82 with the wording: "In a TriG document graph statements with the same graph IRI should be unioned to form a single RDF Graph. Blank nodes in each graph statement with the same label are considered to be the same blank node."
16:31:45 <davidwood> Topic: Named Graphs
16:31:48 <ericP> davidwood: +☮
16:32:27 <gavinc_> also on the wiki http://www.w3.org/2011/rdf-wg/wiki/Example_of_Endorsement_Use_Case
16:32:38 <FabGandon> davidwood: starting with the endorsement use case
16:32:42 <AZ> AZ has joined #rdf-wg
16:33:38 <FabGandon> ... does anyone push this use case ?
16:34:03 <FabGandon> MacTed: this use case could become very important
16:34:45 <LeeF> We don't ourselves do this sort of endorsement today, nor do our customers.
16:34:56 <gavinc_> It is a current use case for Lex Machina, Inc :D
16:35:18 <davidwood> OK, good
16:35:21 <FabGandon> ... there is a difference between me asserting and me endorsing
16:36:12 <Zakim> +??P39
16:36:27 <AZ> zakim, ??P39 is me
16:36:27 <Zakim> +AZ; got it
16:36:40 <Zakim> -AZ
16:38:23 <Zakim> +AZ
16:41:14 <gavinc_> The hash system in my example DOES NOT require trusting much at all
16:41:48 <gavinc_> +q
16:42:15 <FabGandon> AndyS: controling the domain name of a graph name does ensure the trust i.e. there is a whole chain e.g. DNS
16:42:47 <ericP> i thought the point of this was to say "it's within..."
16:43:18 <FabGandon> ... the hash gives you stability / repeatability
16:43:55 <FabGandon> gavinc_: endorsing without hashing may not be very useful
16:44:32 <FabGandon> ericP: within your store you can rely on your architecture
16:45:27 <cgreer> q+
16:45:32 <gavinc_> -q
16:46:32 <FabGandon> AndyS: a lot of this can be done working with documents
16:46:51 <davidwood> ack cgreer
16:47:38 <FabGandon> cgreer: you don't want to endorse a graph that is merged with an other one.
16:48:31 <FabGandon> gavinc_: my example works because there is an intermediary doc
16:49:12 <FabGandon> ericP: can the provenance wg help here ?
16:49:46 <FabGandon> AndyS: no they are at the URI level
16:54:10 <FabGandon> davidwood: is the problem linked to the question of whether we name graphs with URI or not?
16:55:40 <FabGandon> ivan: the general mechanism is we have a URI and we have a predicate
16:55:59 <Guus> q+ to ask which mechanism
16:56:27 <Guus> +1 with Andy
16:57:14 <Guus> quints are out of scope, I would suggest
16:57:20 <davidwood> ack Guus
16:57:20 <Zakim> Guus, you wanted to ask which mechanism
16:58:26 <ericP> +1 to octs
16:58:55 <davidwood> -1 to octs :)
16:59:08 <FabGandon> gavinc_: we can adapt the syntax without making them quints
16:59:42 <AndyS1> { eg:sandro eg:endorses <g1>. <g1> a rdf:StaticGraphContainer. } <g1> { ... the triples I'm endorsing ... }
17:00:16 <ivan_> +1 to David
17:00:32 <AndyS1> { eg:sandro eg:endorses <g1>. <g1> a rdf:StaticGraphContainer. } <g1> { ... the triples I'm endorsing ... }
17:00:48 <LeeF> LeeF has left #rdf-wg
17:01:03 <LeeF> LeeF has joined #rdf-wg
17:01:42 <AndyS1> http://lists.w3.org/Archives/Public/public-rdf-wg/2012Jan/0021.html
17:02:09 <AndyS1> (sandro's message -- includes multiple designs)
17:04:02 <Guus> q+
17:04:37 <cgreer> RDF doesn't disallow inconsistent graphs (+1 Guus)
17:04:47 <FabGandon> ivan: one problem was when in OWL the types of merged containers are disjoint
17:04:56 <davidwood> ack Guus
17:05:15 <FabGandon> Guus: I'm interested in the easy syntax
17:06:29 <FabGandon> ... examples of syntax would help the discussion
17:07:37 <FabGandon> proposing : ACTION: Guus to write down an example of the syntaxes for the named graphs
17:08:33 <FabGandon> Ivan: we could publish a version of Turtle tomorrow
17:09:09 <FabGandon> ... without changing it too much
17:09:47 <FabGandon> ACTION: Guus to write down an example of the syntaxes for the named graphs
17:09:48 <trackbot> Created ACTION-137 - Write down an example of the syntaxes for the named graphs [on Guus Schreiber - due 2012-02-01].
17:10:34 <Guus> q+
17:10:59 <davidwood> ack Guus
17:10:59 <FabGandon> ivan: then we have to decide whether or not we modify the RDF semantics
17:12:14 <FabGandon> Guus: nobody has yet come up with a clear proposal to update the semantics
17:14:57 <Zakim> -gavinc
17:15:19 <FabGandon> ivan: we need at least to write down in plain english the definitions of the core primitives
17:15:48 <MacTed> +1 Ivan's summary, "Named Graph" is inherently ambiguous, and must be defined multiply, for different contexts
17:17:43 <LeeF> I think we may be kidding ourselves if we think we're gong to get high-interoperability with defining this stuff multiple ways
17:18:22 <Zakim> -AZ
17:18:23 <Zakim> -cgreer
17:18:29 <Zakim> -AlexHall
17:18:33 <Zakim> -Scott_Bauer
17:18:35 <AlexHall> AlexHall has left #rdf-wg
17:18:39 <Zakim> -zwu2
17:18:43 <davidwood> MacTed: Define named graphs both by typing URIs and also by using predicates.
17:18:44 <FabGandon> rrsagent, create minutes
17:18:44 <RRSAgent> I have made the request to generate http://www.w3.org/2012/01/25-rdf-wg-minutes.html FabGandon
17:19:24 <FabGandon> rrsagent, please make logs world-visible
17:19:42 <FabGandon> rrsagent, please publish the minutes
17:19:42 <RRSAgent> I have made the request to generate http://www.w3.org/2012/01/25-rdf-wg-minutes.html FabGandon
17:20:35 <Zakim> -LeeF
17:22:05 <FabGandon> what should I do with the URL http://www.w3.org/2012/01/25-rdf-wg-minutes.html to get the wiki version to be cleaned ?
17:22:24 <AndyS1> I'm not here
17:23:44 <Zakim> -Guus
17:25:24 <AndyS1> FabGandon - instructions for minutes - http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0406.html
17:25:44 <AndyS1> (thx to LeeF)
# SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000227
</nowiki></pre>

Chatlog 2012-01-25

Fgandon — Wed, 25 Jan 2012 17:30:39 GMT

Fgandon:

{{chatlog|rrsagent=http://www.w3.org/2012/01/25-rdf-wg-irc.txt|chatlog={{fullurl:{{PAGENAME}}}}}}
<pre><nowiki>
15:12:56 <RRSAgent> RRSAgent has joined #rdf-wg
15:12:56 <RRSAgent> logging to http://www.w3.org/2012/01/25-rdf-wg-irc
15:12:58 <trackbot> RRSAgent, make logs world
15:12:58 <Zakim> Zakim has joined #rdf-wg
15:13:00 <trackbot> Zakim, this will be 73394
15:13:00 <Zakim> ok, trackbot; I see SW_RDFWG()11:00AM scheduled to start in 47 minutes
15:13:01 <trackbot> Meeting: RDF Working Group Teleconference
15:13:01 <trackbot> Date: 25 January 2012
15:16:40 <danbri> danbri has joined #rdf-wg
15:25:05 <AndyS> AndyS has joined #rdf-wg
15:56:07 <mdmdm> mdmdm has joined #rdf-wg
15:56:21 <AndyS1> AndyS1 has joined #rdf-wg
15:57:09 <FabGandon> FabGandon has joined #rdf-wg
15:57:17 <ivan_> ivan_ has joined #rdf-wg
15:57:47 <cgreer> cgreer has joined #rdf-wg
15:57:51 <Zakim> SW_RDFWG()11:00AM has now started
15:57:58 <Zakim> +Scott_Bauer
15:58:15 <Zakim> -Scott_Bauer
15:58:16 <Zakim> SW_RDFWG()11:00AM has ended
15:58:16 <Zakim> Attendees were Scott_Bauer
15:58:32 <Zakim> SW_RDFWG()11:00AM has now started
15:58:39 <Zakim> +gavinc
15:59:04 <Zakim> +cgreer
15:59:26 <Zakim> +??P14
15:59:35 <AndyS1> zakim, ??P14 is me
15:59:35 <Zakim> +AndyS1; got it
15:59:40 <Zakim> +bhyland
16:00:19 <davidwood> Zakim, bhyland is me
16:00:19 <Zakim> +davidwood; got it
16:00:32 <davidwood> Zakim, who is here?
16:00:32 <Zakim> On the phone I see gavinc, cgreer, AndyS1, davidwood
16:00:33 <Zakim> On IRC I see cgreer, ivan_, FabGandon, AndyS1, mdmdm, AndyS, danbri, Zakim, RRSAgent, MacTed, LeeF, ivan, mischat, cygri, gavinc_, manu, davidwood, manu1, trackbot, yvesr, NickH,
16:00:36 <Zakim> ... sandro, ericP
16:00:42 <Zakim> +OpenLink_Software
16:01:21 <Zakim> +[Sophia]
16:01:21 <Zakim> +Eric
16:01:31 <MacTed> Zakim, OpenLink_Software is temporarily me
16:01:31 <Zakim> +MacTed; got it
16:01:37 <MacTed> Zakim, mute me
16:01:38 <Zakim> MacTed should now be muted
16:01:43 <FabGandon> zakim, [Sophia] is FabGandon
16:01:43 <Zakim> +FabGandon; got it
16:03:11 <ivan_> zakim, dial ivan-voip
16:03:16 <Zakim> ok, ivan_; the call is being made
16:03:20 <Zakim> +Ivan
16:03:52 <Zakim> +Scott_Bauer
16:05:09 <FabGandon> Scribe: Fabien Gandon
16:05:18 <FabGandon> ScribeNick: FabGandon
16:05:41 <zwu2> zwu2 has joined #rdf-wg
16:05:43 <davidwood> Zakim, who is here?
16:05:43 <Zakim> On the phone I see gavinc, cgreer, AndyS1, davidwood, MacTed (muted), FabGandon, Eric, Ivan, Scott_Bauer
16:05:45 <Zakim> On IRC I see zwu2, cgreer, ivan_, FabGandon, AndyS1, mdmdm, AndyS, danbri, Zakim, RRSAgent, MacTed, LeeF, mischat, cygri, gavinc_, manu, davidwood, manu1, trackbot, yvesr, NickH,
16:05:47 <zwu2> zakim, code?
16:05:47 <Zakim> ... sandro, ericP
16:05:49 <Zakim> the conference code is 73394 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), zwu2
16:05:55 <danbri> hi folks, regrets from me ... laptop too overwhelmed to run Skype right now (giant mysql job)
16:06:12 <davidwood> PROPOSED to accept the minutes of the 18 Jan telecon:
16:06:12 <davidwood> http://www.w3.org/2011/rdf-wg/meeting/2012-01-18
16:06:33 <Zakim> +zwu2
16:06:36 <davidwood> Action item review:
16:06:36 <trackbot> Sorry, couldn't find user - item
16:06:36 <davidwood> http://www.w3.org/2011/rdf-wg/track/actions/pendingreview
16:06:36 <davidwood> http://www.w3.org/2011/rdf-wg/track/actions/open
16:06:37 <zwu2> zakim, mute me
16:06:37 <Zakim> zwu2 should now be muted
16:06:53 <AlexHall> AlexHall has joined #rdf-wg
16:07:31 <Zakim> + +1.443.212.aaaa
16:07:40 <AlexHall> zakim, aaaa is me
16:07:40 <Zakim> +AlexHall; got it
16:07:52 <Zakim> +Souri
16:08:08 <Guus> Guus has joined #rdf-wg
16:08:24 <Souri> Souri has joined #RDF-WG
16:09:11 <Zakim> +Guus
16:09:19 <swh> swh has joined #rdf-wg
16:10:25 <Zakim> +LeeF
16:11:55 <davidwood> Topic: Reviewers for XSD 1.1?
16:12:12 <davidwood> http://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/ W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures
16:12:12 <davidwood> http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/ W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes
16:12:27 <FabGandon> they moved to proposed Rec and affect RDF
16:12:46 <FabGandon> davidwood ... we need reviewers
16:13:06 <FabGandon> Iven: the first part does not impact us
16:13:15 <FabGandon> s/Iven/Ivan
16:13:54 <ericP> http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/
16:14:04 <ericP> [[
16:14:05 <ericP> This second edition is not a new version, it merely incorporates the changes dictated by the corrections to errors found in the first edition as agreed by the XML Schema Working Group, as a convenience to readers. A separate list of all such corrections is available at http://www.w3.org/2001/05/xmlschema-errata.
16:14:11 <ericP> ]]
16:14:16 <FabGandon> davidwood: eg. of problems links between XMLLiteral and RDF Literals
16:14:22 <AndyS1> http://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/
16:15:09 <FabGandon> davidwood: we need to lood at XSD Strings
16:15:24 <ericP> -> http://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/#changes changes from schema 1.0 to 1.1
16:15:24 <FabGandon> s/lood/look
16:15:29 <AndyS1> and XSD decimal canonical form (FYI)
16:16:28 <ivan_> The changes URI is http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes
16:16:32 <FabGandon> ... we need someone to go through changes
16:16:43 <FabGandon> ericP: I can do it
16:17:23 <FabGandon> AlexHall: volonteer
16:17:43 <ivan_> -> http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes changes
16:17:59 <ivan_> q+
16:18:17 <FabGandon> proposed : "ACTION: ericP and AlexHall to review changes in W3C XML Schema Definition Language (XSD)"
16:18:17 <davidwood> http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes
16:19:18 <gavinc_> AndyS1, http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#f-decimalCanmap !
16:19:25 <ericP> ACTION: Eric Prud'hommeaux to review changes in W3C XML Schema Definition Language (XSD) -- http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes
16:19:26 <trackbot> Created ACTION-135 - Review changes in W3C XML Schema Definition Language (XSD) -- http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes [on Eric Prud'hommeaux - due 2012-02-01].
16:19:35 <ericP> ACTION: AlexHall to review changes in W3C XML Schema Definition Language (XSD) -- http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes
16:19:35 <trackbot> Created ACTION-136 - Review changes in W3C XML Schema Definition Language (XSD) -- http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes [on Alex Hall - due 2012-02-01].
16:19:36 <FabGandon> Ivan: the changes in the datatypes may affect us too
16:19:59 <davidwood> I see "Conforming implementations may now support ·primitive· datatypes and facets in addition to those defined here."
16:20:49 <FabGandon> Ivan: there might be changes for instance in data comparison
16:21:10 <davidwood> " this allows float and double to treat positive and negative zero as distinct values, but nevertheless to treat them as equal for purposes of bounds checking" (!) :)
16:21:25 <davidwood> ^^ These things are important to end users, after all
16:21:41 <FabGandon> erciP: is there anyway for the structure to have an impact our data model ?
16:22:12 <FabGandon> Ivan: my opinion is that we are not affected by structure
16:23:06 <FabGandon> ... but the RDF semantics makes a selection of the datatype and this may have to be reviewed.
16:23:35 <davidwood> Topic: RDF-ISSUE-82 (TriG repeated graph iris)
16:24:28 <AndyS1> q+
16:24:35 <ivan_> q-
16:24:36 <FabGandon> gavinc_: consensus on the second option changing "merge" to "union", blank nodes with the same plabel are considered the same
16:25:34 <ScottB_> ScottB_ has joined #rdf-wg
16:25:58 <FabGandon> ... no semantics for blank nodes between graphs with different labels
16:26:32 <FabGandon> ... inference graphs are kept different and are an example where same labels may mean same nodes
16:27:25 <FabGandon> ... no equivalent in RDF/XML or Turtle right now.
16:27:41 <MacTed> Zakim, unmute me
16:27:41 <Zakim> MacTed should no longer be muted
16:28:09 <AndyS1> ack me
16:28:33 <AndyS1> +1
16:28:35 <ericP> +1
16:28:38 <cgreer> +1
16:28:41 <ivan_> 1
16:28:43 <zwu2> +1
16:28:44 <LeeF> +1
16:28:45 <Guus> +1
16:28:47 <AlexHall> +1
16:28:47 <gavinc_> +1
16:28:48 <Souri> +1
16:28:54 <gavinc_> "In a TriG document graph statements with the same graph IRI should be
16:28:56 <gavinc_> unioned to form a single RDF Graph. Blank nodes in each graph
16:28:57 <gavinc_> statement with the same label are considered to be the same blank
16:28:59 <gavinc_> node."
16:29:03 <FabGandon> davidwood: any objection to the wording (strawpoll)
16:29:18 <MacTed> +1
16:29:31 <FabGandon> ... we have a consensus
16:30:08 <gavinc_> RESOLVE to close ISSUE-82 with the wording: "In a TriG document graph statements with the same graph IRI should be unioned to form a single RDF Graph. Blank nodes in each graph statement with the same label are considered to be the same blank node."
16:31:45 <davidwood> Topic: Named Graphs
16:31:48 <ericP> davidwood: +☮
16:32:27 <gavinc_> also on the wiki http://www.w3.org/2011/rdf-wg/wiki/Example_of_Endorsement_Use_Case
16:32:38 <FabGandon> davidwood: starting with the endorsement use case
16:32:42 <AZ> AZ has joined #rdf-wg
16:33:38 <FabGandon> ... does anyone push this use case ?
16:34:03 <FabGandon> MacTed: this use case could become very important
16:34:45 <LeeF> We don't ourselves do this sort of endorsement today, nor do our customers.
16:34:56 <gavinc_> It is a current use case for Lex Machina, Inc :D
16:35:18 <davidwood> OK, good
16:35:21 <FabGandon> ... there is a difference between me asserting and me endorsing
16:36:12 <Zakim> +??P39
16:36:27 <AZ> zakim, ??P39 is me
16:36:27 <Zakim> +AZ; got it
16:36:40 <Zakim> -AZ
16:38:23 <Zakim> +AZ
16:41:14 <gavinc_> The hash system in my example DOES NOT require trusting much at all
16:41:48 <gavinc_> +q
16:42:15 <FabGandon> AndyS: controling the domain name of a graph name does ensure the trust i.e. there is a whole chain e.g. DNS
16:42:47 <ericP> i thought the point of this was to say "it's within..."
16:43:18 <FabGandon> ... the hash gives you stability / repeatability
16:43:55 <FabGandon> gavinc_: endorsing without hashing may not be very useful
16:44:32 <FabGandon> ericP: within your store you can rely on your architecture
16:45:27 <cgreer> q+
16:45:32 <gavinc_> -q
16:46:32 <FabGandon> AndyS: a lot of this can be done working with documents
16:46:51 <davidwood> ack cgreer
16:47:38 <FabGandon> cgreer: you don't want to endorse a graph that is merged with an other one.
16:48:31 <FabGandon> gavinc_: my example works because there is an intermediary doc
16:49:12 <FabGandon> ericP: can the provenance wg help here ?
16:49:46 <FabGandon> AndyS: no they are at the URI level
16:54:10 <FabGandon> davidwood: is the problem linked to the question of whether we name graphs with URI or not?
16:55:40 <FabGandon> ivan: the general mechanism is we have a URI and we have a predicate
16:55:59 <Guus> q+ to ask which mechanism
16:56:27 <Guus> +1 with Andy
16:57:14 <Guus> quints are out of scope, I would suggest
16:57:20 <davidwood> ack Guus
16:57:20 <Zakim> Guus, you wanted to ask which mechanism
16:58:26 <ericP> +1 to octs
16:58:55 <davidwood> -1 to octs :)
16:59:08 <FabGandon> gavinc_: we can adapt the syntax without making them quints
16:59:42 <AndyS1> { eg:sandro eg:endorses <g1>. <g1> a rdf:StaticGraphContainer. } <g1> { ... the triples I'm endorsing ... }
17:00:16 <ivan_> +1 to David
17:00:32 <AndyS1> { eg:sandro eg:endorses <g1>. <g1> a rdf:StaticGraphContainer. } <g1> { ... the triples I'm endorsing ... }
17:00:48 <LeeF> LeeF has left #rdf-wg
17:01:03 <LeeF> LeeF has joined #rdf-wg
17:01:42 <AndyS1> http://lists.w3.org/Archives/Public/public-rdf-wg/2012Jan/0021.html
17:02:09 <AndyS1> (sandro's message -- includes multiple designs)
17:04:02 <Guus> q+
17:04:37 <cgreer> RDF doesn't disallow inconsistent graphs (+1 Guus)
17:04:47 <FabGandon> ivan: one problem was when in OWL the types of merged containers are disjoint
17:04:56 <davidwood> ack Guus
17:05:15 <FabGandon> Guus: I'm interested in the easy syntax
17:06:29 <FabGandon> ... examples of syntax would help the discussion
17:07:37 <FabGandon> proposing : ACTION: Guus to write down an example of the syntaxes for the named graphs
17:08:33 <FabGandon> Ivan: we could publish a version of Turtle tomorrow
17:09:09 <FabGandon> ... without changing it too much
17:09:47 <FabGandon> ACTION: Guus to write down an example of the syntaxes for the named graphs
17:09:48 <trackbot> Created ACTION-137 - Write down an example of the syntaxes for the named graphs [on Guus Schreiber - due 2012-02-01].
17:10:34 <Guus> q+
17:10:59 <davidwood> ack Guus
17:10:59 <FabGandon> ivan: then we have to decide whether or not we modify the RDF semantics
17:12:14 <FabGandon> Guus: nobody has yet come up with a clear proposal to update the semantics
17:14:57 <Zakim> -gavinc
17:15:19 <FabGandon> ivan: we need at least to write down in plain english the definitions of the core primitives
17:15:48 <MacTed> +1 Ivan's summary, "Named Graph" is inherently ambiguous, and must be defined multiply, for different contexts
17:17:43 <LeeF> I think we may be kidding ourselves if we think we're gong to get high-interoperability with defining this stuff multiple ways
17:18:22 <Zakim> -AZ
17:18:23 <Zakim> -cgreer
17:18:29 <Zakim> -AlexHall
17:18:33 <Zakim> -Scott_Bauer
17:18:35 <AlexHall> AlexHall has left #rdf-wg
17:18:39 <Zakim> -zwu2
17:18:43 <davidwood> MacTed: Define named graphs both by typing URIs and also by using predicates.
17:18:44 <FabGandon> rrsagent, create minutes
17:18:44 <RRSAgent> I have made the request to generate http://www.w3.org/2012/01/25-rdf-wg-minutes.html FabGandon
17:19:24 <FabGandon> rrsagent, please make logs world-visible
17:19:42 <FabGandon> rrsagent, please publish the minutes
17:19:42 <RRSAgent> I have made the request to generate http://www.w3.org/2012/01/25-rdf-wg-minutes.html FabGandon
17:20:35 <Zakim> -LeeF
17:22:05 <FabGandon> what should I do with the URL http://www.w3.org/2012/01/25-rdf-wg-minutes.html to get the wiki version to be cleaned ?
17:22:24 <AndyS1> I'm not here
17:23:44 <Zakim> -Guus
17:25:24 <AndyS1> FabGandon - instructions for minutes - http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0406.html
17:25:44 <AndyS1> (thx to LeeF)
# SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000227
</nowiki></pre>

F2F2

Fgandon — Wed, 03 Aug 2011 15:30:31 GMT

Fgandon:

12-13 October 2011

See the (closed) poll results at: http://www.w3.org/2002/09/wbs/46168/RDFWGFTF2/results

== Participants ==

; Intend to attend (you must sign up to get Internet access, food, ...)
: David Wood
: Peter F. Patel-Schneider (very likely if East, only moderately likely if West)
: Scott Bauer
: Dan Brickley (tentative - really not sure yet, depends on timing, location, funding, ...)
: Pierre-Antoine Champin (tentative - really not sure yet, depends on timing, location, funding, ...)
: Ted Thibodeau (tentative. more likely if in Boston than in Murray Hill; much less likely if in CA)
: Ivan Herman can attend a European site, not in the US
: Steve Harris, maybe attend US East coast, definitely UK/Ireland.
: Zhe Wu(tentative)

; Intend to attend remotely
: Richard Cyganiak

; Regrets
: Fabien Gandon

Chatlog 2011-04-14

Fgandon — Sun, 17 Apr 2011 14:00:52 GMT

Fgandon:

{{chatlog|rrsagent=http://www.w3.org/2011/04/14-rdf-wg-irc.txt|chatlog={{fullurl:{{PAGENAME}}}}}}
<pre><nowiki>
<sandro> Guest: Paul Groth
<sandro> Guest: Steven Pemberton
<sandro> Present: Ivan, Mischa, Dan_Brickley, Matheus, Peter, Jan, Baget, Humfrey, Yves, Cygri, Champin, Fabien, Steve, Matteo, Sandro, Wood, Guus
<sandro> Remote: AZ, Gavin, Zhe, Corby, MacTed, Pat, Tom, AlexHall, webr3, LeeF, manu, souri
02:28:54 <MacTed> MacTed has joined #rdf-wg
05:17:45 <mbrunati> mbrunati has joined #rdf-wg
05:21:57 <mbrunati> mbrunati has joined #rdf-wg
05:22:16 <mbrunati> mbrunati has left #rdf-wg
06:21:58 <pgroth> pgroth has joined #rdf-wg
06:47:46 <pgroth_> pgroth_ has joined #rdf-wg
06:51:46 <tomlurge> tomlurge has joined #rdf-wg
07:11:44 <danbri> danbri has joined #rdf-wg
07:13:25 <OlivierCorby> OlivierCorby has joined #rdf-wg
07:18:50 <FabGandon> FabGandon has joined #rdf-wg
07:20:56 <ivan> ivan has joined #rdf-wg
07:21:03 <tomayac> tomayac has joined #rdf-wg
07:21:55 <tomayac> bonjour monsieur!
07:24:23 <pgroth> pgroth has joined #rdf-wg
07:30:32 <AZ> AZ has joined #rdf-wg
07:31:34 <mbrunati> mbrunati has joined #rdf-wg
07:32:13 <pchampin> pchampin has joined #rdf-wg
07:33:17 <tomayac> "the conference is restricted at this time" => have the dial-in details changed? using rdfwg1# code
07:34:05 <FabGandon> should work but we haven't called yet and a number of participants are still missing in the room
07:34:26 <tomayac> 9:30 sharp-ish ;-)
07:34:27 <PatH> PatH has joined #rdf-wg
07:39:52 <Guus> Guus has joined #rdf-wg
07:40:04 <SteveH> SteveH has joined #rdf-wg
07:40:19 <Steven_> Steven_ has joined #rdf-wg
07:40:29 <Steven_> zakim, list
07:40:29 <Zakim> I see SW_RDFWG(RDFWG1)2:00AM active and no others scheduled to start in the next 15 minutes
07:40:43 <mischat> mischat has joined #rdf-wg
07:40:49 <FabGandon> we will have to do an adhoc teleconf the teleconf chanel is not available for today
07:41:10 <pfps> pfps has joined #rdf-wg
07:41:13 <Steven_> zakim, code?
07:41:13 <Zakim> the conference code is 733941 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Steven_
07:41:38 <FabGandon> trying again...
07:41:39 <cmatheus> cmatheus has joined #rdf-wg
07:41:40 <Steven_> zakim, who is on the call?
07:41:40 <Zakim> On the phone I see OlivierCorby, OlivierCorby.a, OlivierCorby.aa, OlivierCorby.aaa
07:41:41 <cygri> cygri has joined #rdf-wg
07:41:55 <davidwood> davidwood has joined #rdf-wg
07:42:13 <PatH> Same message here
07:42:23 <tomayac> same here
07:42:45 <davidwood> We're working on it - please stand by
07:42:56 <Steven_> zakim, room for 15 for 600 minutes?
07:42:58 <Zakim> ok, Steven_; conference Team_(rdf-wg)07:42Z scheduled with code 26631 (CONF1) for 600 minutes until 1742Z
07:43:06 <davidwood> We'll announce a new dial in code shortly
07:43:12 <FabGandon> dial 26631
07:43:18 <davidwood> PLEASE USE CONFERENCE CODE 26631
07:43:35 <Steven_> Steven_ has changed the topic to: CODE is 26631
07:43:41 <davidwood> Sorry for the confusion. Our bridge was not configured as we expected.
07:44:04 <Steven_> zakim, who is on the call?
07:44:04 <Zakim> On the phone I see OlivierCorby, OlivierCorby.a, OlivierCorby.aa, OlivierCorby.aaa
07:44:21 <NickH> Good Morning!
07:44:25 <Steven_> zakim, this is rdf-wg
07:44:25 <Zakim> Steven_, this was SW_RDFWG(RDFWG1)2:00AM
07:44:27 <Zakim> ok, Steven_; that matches Team_(rdf-wg)07:42Z
07:44:33 <Steven_> zakim, who is on the call?
07:44:34 <Zakim> On the phone I see Meeting_Room, PatH, tomayac, OlivierCorby
07:44:40 <OlivierCorby> Hi, phone is ok now
07:44:48 <Zakim> +AZ
07:45:46 <PatH> Sound quality is rather poor today
07:45:50 <FabGandon> scribe: Fabien
07:46:31 <gavinc> gavinc has joined #rdf-wg
07:46:40 <FabGandon> guus: identifying the 4 issues to be discussed
07:46:50 <Steven> 30, 31, 15
07:46:51 <FabGandon> ... 5 30 31 and 15
07:46:57 <gavinc> zakim, the code is?
07:46:57 <Zakim> I don't understand your question, gavinc.
07:47:01 <JFB> JFB has joined #rdf-wg
07:47:03 <Steven> zakim, code?
07:47:03 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Steven
07:47:32 <FabGandon> cygri: 31 is a bit out of the list
07:47:52 <mischat> http://www.w3.org/2011/rdf-wg/track/issues/30
07:48:06 <FabGandon> davidwood: sugest we start with issue 30
07:48:06 <Zakim> +gavinc
07:48:07 <FabGandon> Topic: Four issues of "Named Graphs".
07:48:08 <FabGandon> subtopic: Aligning SPARQL notions and RDF 1.1 g-* notions.
07:48:18 <FabGandon> ISSUE-30: How does SPARQL's notion of RDF dataset relate our notion of multiple graphs?
07:48:18 <trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added
07:48:20 <Steven> s/sugest/suggest/
07:49:47 <mischat> http://www.w3.org/TR/rdf-sparql-query/#rdfDataset <-- sparql dataset as per rdf sparql query 1.0
07:50:23 <FabGandon> Cygri : SPARQL defines Dataset as data data model used in SPARQL query i.e. collection of graph = one default graph and a set of named graphs <IRI,Graph>
07:50:33 <tomayac> AZ: +1, sound is low quality :-(
07:50:47 <mischat> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal
07:51:19 <FabGandon> ... they use the term named graph and it is a g-snap in our terminology because immutable
07:51:50 <pchampin> http://www.w3.org/TR/2009/WD-sparql11-update-20091022/#sec_graphStore
07:52:37 <PatH> +q
07:52:43 <FabGandon> ... graph store :"unlike an RDF dataset, named graphs can be added to or deleted from a graph store"
07:53:03 <FabGandon> ivan: the mutability is on the store not on the graph
07:53:47 <pchampin> pchampin has joined #rdf-wg
07:53:49 <FabGandon> ... are the graphs explicitly immutable ?
07:53:51 <PatH> sound quality is poor but usable
07:54:26 <FabGandon> cygri : the spec are not specific on this ; not really addressed
07:54:57 <Guus> q?
07:55:17 <FabGandon> ivan: IMO the dataset is a set of g-boxes
07:55:38 <Guus> zakim, who is here?
07:55:38 <Zakim> On the phone I see Meeting_Room, PatH, tomayac, OlivierCorby, AZ, gavinc
07:55:52 <FabGandon> cygri: the evaluation of a SPARQL query is defined against an immutable dataset
07:56:00 <gavinc> gavinc has joined #rdf-wg
07:56:09 <davidwood> q+ to discuss graph store relationships to g-boxes and g-snaps.
07:56:34 <ivan> q?
07:56:39 <ivan> ack PatH
07:56:42 <davidwood> ack PatH
07:56:47 <FabGandon> PatH: we shouldn’t be agnostic we should say what the graph is e.g. we should say it is a g-box that has a name
07:57:25 <FabGandon> cygri: SPARQL uses the term named graph, the IRI is the name for the graph in SPARQL
07:57:59 <mischat> PatH: there is no need to introduce confusion
07:57:59 <AZ> We can certainly see a SPARQL dataset as a snapshot of the graph store (the graph store is mutable but the snapshot is fixed to define what's the result of a query)
07:58:47 <FabGandon> PatH: RDF should specify the semantic of names if there is to be an interpretation of that name
07:59:14 <FabGandon> ... if we don't we leave the question open to endless discussions.
07:59:53 <davidwood> +1 to PatH, in that if we define what we mean we won't have misunderstandings as we do with "information resource" or "what *is* RDF".
08:00:41 <JFB> +1 to PatH: if there is some specifing meaning to names, it must be formalized in RDF Semantics
08:00:42 <FabGandon> PatH: we need to declare in a declarative text what the interpretation is for the IRI naming a graph.
08:01:34 <FabGandon> cygri: Can we use the name of doc as the name of graph.
08:01:44 <FabGandon> PatH: we can't prevent that
08:03:10 <Zakim> davidwood, you wanted to discuss graph store relationships to g-boxes and g-snaps.
08:03:57 <FabGandon> davidwood: several graph stores are maintainers of g-boxes implemented as multiple reader single writer
08:04:38 <FabGandon> ... when a query comes in they generate sets of g-snaps from the current state of the g-boxes.
08:05:12 <FabGandon> SteveH: yes that's what happens.
08:05:30 <PatH> we have yet to specify what a g-box is semantically. We will have to speak of states and g-snaps there.
08:06:22 <PatH> in other words, this box/snap issue will have to be dealt with there in any case.
08:06:31 <sandro> guus: When you do a SPARQL Query, you are querying at a point in time, so you are querying against the set of g-snaps which is the current contents of those g-boxes.
08:06:32 <FabGandon> Guus: at that point there is no conflict between our view and SPARQL
08:06:40 <davidwood> PatH: Yes
08:06:56 <davidwood> Yes, there is no conflict.
08:07:00 <FabGandon> subtopic: relation between the graph and its name.
08:07:40 <sandro> pchampin: I want to be able to use my own arbitrary data as the "graph" name in SPARQL.
08:08:00 <FabGandon> pchampin: I feel uncomfortable with fixing the semantics of the relation name of graphs and the store ; it depends on my use of the quadstore
08:08:57 <FabGandon> cygri: I don’t see this machinery as answering a large demand ; I don’t feel there is a huge demand on fixing that semantics
08:09:27 <FabGandon> ... what do we gain from defining the interpretation of named graphs ?
08:09:56 <pchampin> sometimes, I name a graph in my quad store with the URI of the g-box this graph comes from,
08:10:08 <pchampin> sometimes, I name it with the URI of the resource it is about
08:10:09 <FabGandon> danbri: are you confortable with the level of interoperability that would set?
08:10:36 <sandro> +1 danbri we need more interop between datastores (there is breakage when people use different styles of URIs)
08:11:10 <pfps> I don't know how the RDF semantics is going to speak to things like timestamping downloads of RDF documents.
08:11:38 <FabGandon> PatH: defining the semantics will not have so much implication on the implementation that seems to be feared. The idea is not to interfere with the machinery.
08:11:42 <davidwood> ack PatH
08:11:46 <danbri> it's something like a lack of mechanism for saying how *my* sparql store is managed. One might use 'the URI I fetched = the graph URI', another uses a uuid: per-transaction, and a table-of-contents history graph. Sure I can send SPARQL queries across both at same time, but the results might be barely meaningful.
08:13:10 <FabGandon> sandro: the machinery will complain for instance if I use the URI of a graph to identify a person and these classes are disjoint.
08:13:59 <danbri> PatH, the triples could have semantics, but their bundling and tagging with graph URIs could lack semantics
08:14:03 <pchampin> q+ to talk about named graphs in SPARQL endpoints
08:14:10 <FabGandon> SteveH: there are many use cases where we don't want to do some logical inference on top of RDF.
08:14:53 <pchampin> +1 danbri: I write no *triple* stating that a person is a graph :-)
08:15:01 <sandro> Pat: It violates the semantics of the language to have the name of a graph also be the name of a person.
08:15:15 <FabGandon> cygri: How does the fact of using a URI for a graph and a person raises a problem in SPARQL?
08:15:20 <AZ> A name can name several things, like in OWL 2 DL, a name can name a class and a property
08:15:38 <pgroth> could we do both? a name and a tag?
08:15:40 <AZ> and classes are disjoint from properties in OWL 2 DL
08:15:42 <FabGandon> PatH: lets not call it the names then.
08:16:43 <sandro> +1 pat
08:16:51 <FabGandon> pfps: RDF is agnostic as to the use of the same IRI to name a graph or a person.
08:16:51 <ivan> ack pchampin
08:16:51 <Zakim> pchampin, you wanted to talk about named graphs in SPARQL endpoints
08:17:21 <sandro> pchampin: I'm using the "graph id" as merely a "tag"
08:17:38 <FabGandon> pchampin: ok to say it’s not really a name but merely a tag.
08:18:07 <sandro> +100000 the world here would be MUCH CLEARER if SPARQL forced you to only use graph IDs that you own!!
08:18:24 <cygri> sandro -100000
08:18:56 <pfps> sandro - so you think that you shouldn't use "anyone else's" IRIs in a named graph?
08:19:03 <cygri> q+ to disagree with sandro -- web crawling use case
08:19:34 <FabGandon> sandro: I wish SPARQL restricted you to use only URIs that you own i.e. use graphs in a domain you control
08:20:01 <danbri> sandro, that feels to me like having the SQL spec specify that you can only store things that are true
08:20:09 <pchampin> I sure was not suggesting to restrict SPARQL... :-/
08:20:35 <pchampin> just pointing out that its flexibility allows for different practices... beyong "naming according to Pat"
08:20:41 <FabGandon> cygri: strong use case against that : when you crawl the web you want to use the URI from where you got the data.
08:21:17 <FabGandon> sandro: it may be more efficient but you create interoperability problems.
08:21:34 <sandro> Utility is at odds with Interoperability.
08:21:37 <PatH> hard to hear..
08:21:44 <sandro> Local utility vs Global utility.
08:21:53 <yvesr> another use case is ACL on quad stores
08:22:15 <FabGandon> pchampin: not suggesting restricting what SPARQL allows to do ; just advocating flexibility.
08:22:41 <cygri> q+ to talk about n3
08:22:44 <FabGandon> pgroth: I wonder if we don't need a typing mechanism.
08:22:44 <sandro> pgroth: There's "naming graph" and there's graph tags.
08:22:55 <Zakim> cygri, you wanted to talk about n3
08:23:39 <FabGandon> cygri: if you want a graph associated with a URI in N3 you need to put a predicate in-between.
08:24:09 <danbri> is this OK SPARQL? http://pastebin.com/raw.php?i=TaJVsste
08:24:19 <FabGandon> ... there is something in the middle that indicates the relation, don't restrict that because in SPARQL it is not restricted.
08:25:19 <yvesr> danbri, i guess it would - why wouldn't it?
08:25:42 <FabGandon> pfps: in RDF everything is a resources: a graph must be an resource or not ; how can we disconnect graph from that if we name them with IRI?
08:26:01 <danbri> q+ to try http://pastebin.com/raw.php?i=TaJVsste
08:26:52 <FabGandon> Guus: we need to identify the things we do agree on.
08:26:55 <Zakim> danbri, you wanted to try http://pastebin.com/raw.php?i=TaJVsste
08:27:14 <PatH> sounds like a sparql RDF dataset is not a collection of named graphs. Which surprises me, but I can live with.
08:27:20 <FabGandon> danbri: I want to talk about this test case http://pastebin.com/raw.php?i=TaJVsste
08:28:14 <FabGandon> ... this is a SPARQL query querying different databases.
08:28:36 <FabGandon> ... can we name graphs with mailto:bla@bla.bla
08:28:38 <PatH> but see what pat just wrote.
08:29:08 <FabGandon> yes we can
08:29:37 <FabGandon> davidwood: some people say we should always use http://
08:29:55 <FabGandon> danbri: there is a drift from using http:// URIs
08:30:07 <FabGandon> SteveH: I don't see anything wrong with that.
08:30:25 <sandro> sandro: This is just neats vs scruffies --- the graph might be a (scruffy) tag, or might be a name of a proper RDF graph.
08:30:29 <FabGandon> danbri: what about the provenance perspective?
08:30:34 <pfps> well, a SPARQL RDF dataset is defined as potentially containing "named graphs" as this is the first (as far as I know) W3C mention of "named graph", then SPARQL wins and SPARQL RDF datasets have named graphs
08:31:10 <pfps> the upshot of this is that the RDF WG may need a new name for what we have been calling named graphs
08:31:27 <FabGandon> pgroth: we care about pointing at a resource or at a graph talking about a resource.
08:31:37 <FabGandon> ... we need to be able to point at the content.
08:32:04 <PatH> pfps, suggest rather we keep named graphs but allow datasets to be something else.
08:32:30 <danbri> so my example lets me represent the (likely derrived from other stuff) info that Pat says Guus is the name of the holder of his homepage
08:32:52 <pfps> then we need to quickly get SPARQL not to "use up" this name - oops too late, named graphs is already in SPARQL 1.0
08:33:40 <pgroth> i like the idea of a default interpretation
08:33:47 <FabGandon> pchampin: graphs are resources they need naming and not necessarily a named attached to a SPARQL endpoint.
08:33:51 <pgroth> that the iri is the name of the graph
08:34:10 <SteveH> q+ to talk about <uri> :relation <graph>
08:34:33 <FabGandon> pfps: do RDF graphs have to be resources ?
08:34:55 <danbri> http://www.w3.org/TR/rdf-mt/#gloss ''Resource (n.)(as used in RDF)(i) An entity; anything in the universe. (ii) As a class name: the class of everything; the most inclusive category possible.''
08:35:09 <PatH> aaaargh. what are 'levels'????
08:35:16 <FabGandon> cygri: graphs are in the abstract syntax; resources are in the model theory
08:36:18 <FabGandon> pchampin: graphs must be resources
08:36:23 <sandro> pfps: We have A and Not-A (where A=Graphs are Resources)
08:37:20 <sandro> pat: Of COURSE graphs are resources. The model theory clearly says everything is a resource.
08:37:26 <JFB> +1 everything is a resource, if I am, why wouldn't a graph be ?
08:37:28 <FabGandon> PatH: there are no such notions of levels ; thats not the pb.
08:37:50 <pchampin> +1
08:37:54 <sandro> pat: We could say that SPARQL Datasets are about tagged graphs NOT naming.
08:37:55 <SteveH> +1
08:37:57 <sandro> +1 pat
08:37:59 <mischat> +1
08:38:00 <danbri> +1
08:38:12 <yvesr> +1
08:38:24 <danbri> q+ to suggest [eventual] best practice note on how *in practice* people are associating URIs with bundles-of-triples
08:38:34 <FabGandon> ... if we say we tag graphs and not we name then we can stop arguing
08:39:02 <AZ> But then, how one talks about a graph in triples?
08:39:29 <FabGandon> davidwood: I need a clarification on the difference between the name and a tag.
08:39:30 <ivan> ack SteveH
08:39:30 <Zakim> SteveH, you wanted to talk about <uri> :relation <graph>
08:40:14 <FabGandon> PatH: the difference is in the relation, tag is neutral.
08:40:16 <danbri> 'bundles'
08:40:30 <pgroth> why can't we have a default interpretation ?
08:40:48 <sandro> possible consensus: SPARQL "named graphs" are not "named" in the logical sense.
08:40:58 <cygri> +1 ivan
08:40:59 <danbri> pgroth, because there are multiple equally respectable default db management habits
08:41:27 <gavinc> FROM NAMED
08:42:01 <sandro> :'(''
08:42:20 <FabGandon> ivan: we don't have much choice, the term "named graph" is already used in the whole SPARQL community.
08:42:40 <pgroth> danbri, but default doesn't mean you have to
08:43:14 <sandro> sandro: Can we at least tell people this is a misleading name?
08:43:19 <SteveH> +1
08:43:56 <PatH> potentially misleading
08:44:02 <danbri> From a SPARQL perspective, it is legitimate to (a) tag graph-bundles with URI the triples were dereferenced from (b) to tag graph-bundles with URI for the party who made the claim (c) or a trasaction ID, eg. uuid:
08:44:13 <sandro> More Consensus: SPARQL "named graphs" are not necessarily "named" in the logical sense, or RDF graphs.
08:44:25 <sandro> FabGandon we have "tagged boxes" and we will call them "named graphs"
08:44:38 <pchampin> q+ to raise some concern about the semantics of NQuads, then
08:44:49 <Zakim> danbri, you wanted to suggest [eventual] best practice note on how *in practice* people are associating URIs with bundles-of-triples
08:44:56 <PatH> can we introduce the terminology of "sparql naming"
08:45:12 <davidwood> q+ to as about naming of RDF
08:45:26 <FabGandon> danbri: may be we should first document the current uses of "named graphs"
08:45:40 <mischat> q+ to ask about the difference in FROM NAMED and the GRAPH URI
08:45:52 <yvesr> +1
08:45:57 <sandro> +1 danbri: document the common practices for using sparql graphs names.
08:45:58 <PatH> I dont want to start policing sparql usage.
08:46:09 <FabGandon> ... I have three in mind but may be we should have a wiki page to collect them
08:46:12 <davidwood> No, we certainly don't
08:46:13 <danbri> path --- absolutely not policing, but documenting
08:46:17 <yvesr> PatH, not policing, surevying what's actually happening
08:46:18 <PatH> just keep terminology clean
08:46:22 <PatH> OK
08:46:27 <danbri> -- so we can send SPARQL queries that use GRAPH to services managed in a certain fashion
08:46:51 <FabGandon> pchampin: NQuads is used to dump a full store
08:46:55 <danbri> eg. see http://pastebin.com/TaJVsste ... maybe you have a DB I could usefully send that query to; but maybe Ivan's SPARQL db is managed with a different GRAPH/URI policy
08:47:02 <danbri> ...so naming those deployment patterns
08:47:02 <mischat> i do think that best practices for linked data re: graphs and named graphs
08:47:03 <Zakim> davidwood, you wanted to as about naming of RDF
08:47:05 <FabGandon> ivan: NQuad is juts syntax
08:47:06 <Zakim> pchampin, you wanted to raise some concern about the semantics of NQuads, then
08:47:20 <danbri> FDR!
08:47:39 <FabGandon> davidwood: concerned about redefining everything.
08:48:09 <FabGandon> sandro: SPARQL named graphs has little to do with named g-boxes.
08:48:13 <ivan> ack mischat
08:48:13 <Zakim> mischat, you wanted to ask about the difference in FROM NAMED and the GRAPH URI
08:48:23 <FabGandon> Guss: SPARQL is agnostic about.
08:49:04 <FabGandon> mischat: It is nice that SPARQL doesn’t force you to use the URL of the doc for the named graph.
08:49:23 <sandro> steve: FROM NAMED pulls a graph from some undefined place and puts it in the set of named graphs, but... [lost]
08:50:05 <FabGandon> SteveH: the exact behavior of the default graph changes from store to store.
08:50:25 <cygri> +1 mischat
08:50:32 <yvesr> +1
08:50:42 <danbri> yup
08:50:59 <FabGandon> mischat: the best practices could be in a note and not in rec.
08:51:54 <FabGandon> davidwood: we don't want to get in the way of LOD
08:51:57 <raphael> raphael has joined #rdf-wg
08:53:06 <FabGandon> ivan: too early to phrase it as a resolution ?
08:53:11 <sandro> PROPOSED: Close ISSUE-30 saying that SPARQL Datasets and Named Graphs have no strict or formal connection to a logic of RDF "naming" of Graphs.
08:53:29 <pfps> PROPOSED the upcoming notion of multiple graphs is not necessarily the same as named graphs in SPARQL
08:53:49 <danbri> perhaps - SPARQL quads are not the kinds of thing that can be interpreted as True vs False; RDF WG quads might or might not add more...
08:54:11 <PatH> suggest that the key point is that just because sparql uses a uri to, um, identify a graph, it does not mean that the uri can be used to refer to the graph in an rdf triple.
08:54:52 <FabGandon> ivan: we currently have no formal connection between the name and the graph in RDF
08:54:53 <danbri> ie. we can ask if the triple "uri-for-guus :homepage http://www.cs.vu.nl/~guus/" is true or not; but we can't yet ask if the quad "{uri-for-graph} uri-for-guus :homepage http://www.cs.vu.nl/~guus/" is true or false
08:55:32 <AZ> PatH +1
08:55:42 <danbri> (path, +1 to what?)
08:55:53 <FabGandon> Guus: who agrees with PatH ?
08:56:13 <AZ> +1
08:56:26 <FabGandon> PatH: you can use the URI but there is no guaranty that it refers to the graph.
08:56:27 <sandro> sandro: Pat means "refer" in a model theory sense, not a computer science sense.
08:57:05 <gavinc> So what does: SELECT ?s WHERE {GRAPH ?s { ?s ?p ?o }} end up meaning in this case?
08:57:17 <FabGandon> yvesr: we don't know what a multiple graph is and therefore can we talk about it in a resolution?
08:57:56 <zwu2> zwu2 has joined #rdf-wg
08:58:25 <FabGandon> ivan: when we have clarified notions then we can come back to that question.
08:58:28 <yvesr> we can't resolve an issue where half of the question is still undefined
08:58:56 <PatH> i like 'thruth'
08:59:07 <FabGandon> ... the issue should be postponed.
08:59:11 <danbri> quadly thruthyness
08:59:22 <ivan> rrsagent, pointer?
08:59:22 <RRSAgent> See http://www.w3.org/2011/04/14-rdf-wg-irc#T08-59-22
08:59:22 <PatH> :-)
08:59:32 <FabGandon> Guus: we can close that issue and open and more precise one.
08:59:37 <JFB> +1 for semantics of a predicate that would capture SPARQL's behaviour, but we're not ready yet for that
08:59:54 <yvesr> issue-30 might be dependent on issue-15
09:00:36 <FabGandon> pchampin: this question is linked to issue 15 http://www.w3.org/2011/rdf-wg/track/issues/15
09:00:44 <sandro> issue-15?
09:00:44 <trackbot> ISSUE-15 -- What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc -- open
09:00:44 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/15
09:00:45 <mischat> again, you could have a best practices document stating how you can use named graphs in a quad store in a truthy way, but neither rdf nor sparql mandates this, but it would be a good thing for quad store/linked data interoperability -- would be a good note for a primer
09:02:00 <FabGandon> Guus: 30 is about alignment with SPARQL and 15 is about our internal changes to RDF.
09:02:31 <FabGandon> ... in solving issue 15 we should not conflict with SPARQL.
09:02:37 <PatH> yes, fine
09:02:53 <PatH> yes,
09:03:14 <PatH> sorry cant unmute but agree with what you are saying
09:03:26 <FabGandon> Guus: we should remove dataset from issue 15 this is addressed in issue 30
09:03:47 <sandro> PROPOSED: ISSUE-15 is about our internal notions of multiple graphs, while ISSUE-30 is about how that related to SPARQL's notion. We do not expect the association of IRIs and graphs in SPARQL datasets to be RDF's identification/reference relationship.
09:04:03 <FabGandon> davidwood: etc. is not precise enough , issue 15 should be rephrased properly
09:04:48 <danbri> proposed: "While it is attractive to seek more clarity on relationship between some graph of triples and URIs they're tagged with, ... we note that SPARQL deployments have assigned URIs in a variety of ways, each of which being useful and compliant. There may be value in documenting these deployment styles (e.g. URIs for docs, abstract graphs, human sources or transaction IDs) so that SPARQL stores and serializations of URI-tagged triples can b
09:04:48 <danbri> e made more richly interoperable."
09:05:02 <FabGandon> Guus: we should start with defining our own terminology before aligning with SPARQL.
09:05:11 <cygri> proposed: "Named Graphs in SPARQL “loosely associate” IRIs and graphs. They do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."
09:06:20 <FabGandon> ISSUE-30: cygri proposes "Named Graphs in SPARQL “loosely associate” IRIs and graphs. They do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."
09:06:20 <trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added
09:07:12 <danbri> i tried ' each of which being useful and compliant' instead of 'loosly' (above)
09:07:23 <sandro> "are simple associations"
09:07:35 <AZ> Maybe: "Named Graphs in SPARQL associate IRIs and graphs *but* they do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."
09:07:42 <FabGandon> PatH: don't like the word "loosely" prefer : temporary
09:08:14 <sandro> PROPOSED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not necessarily establish graphs as referents of IRIs
09:08:35 <AZ> I would not put the necessarily there
09:08:51 <mischat> SteveH: sparql uses the verb "graph" to talk about arbitrary graphs and the "named graphs" for graphs which which can be fetched via http, or is that just my pov?
09:09:03 <sandro> PROPOSED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily "name" graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs
09:09:10 <sandro> +1
09:09:14 <pfps> +1
09:09:15 <cygri> +1 sandro
09:09:16 <AZ> +1
09:09:16 <mbrunati> +1
09:09:20 <pchampin> +1
09:09:23 <davidwood> +1
09:09:24 <cmatheus> +1
09:09:26 <yvesr> +1
09:09:27 <danbri> +1
09:09:32 <zwu2> +0
09:09:33 <NickH> +1
09:09:38 <SteveH> +1
09:09:51 <mischat> +1
09:10:04 <mischat> any objections for this being added as a note to issue-30 ?
09:10:04 <FabGandon> ISSUE-30: Proposed WG position : Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs.
09:10:04 <trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added
09:10:07 <sandro> RESOLVED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily "name" graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs (relevant to ISSUE-30)
09:10:31 <cygri> ISSUE-15?
09:10:31 <FabGandon> subtopic: link between the name and the triples of the graph.
09:10:31 <trackbot> ISSUE-15 -- What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc -- open
09:10:31 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/15
09:10:56 <PatH> +1 also my vote
09:11:11 <FabGandon> davidwood: moving to ISSUE 15 ; let's try to rephrase it.
09:11:41 <AZ> AZ: isn't it implicitly asking "how" one can associate a URI to a g-* ?
09:12:00 <PatH> propose, uri always refers to g-box, but some boxes are immutable.
09:12:12 <pgroth> agree with pat
09:12:16 <FabGandon> sandro: g-boxes, g-snap, g-text could be named
09:12:48 <PatH> because a snap is always a state (of a box) rather than a resource in its own right.
09:12:48 <FabGandon> ivan: can we have a predicate to say this IRI identifies this g-box ?
09:13:15 <pgroth> although i need to refer to a g-snap
09:13:51 <pchampin> PatH: can't a number have a URI ??
09:14:06 <FabGandon> pgroth: would that prevent you to refer to a particular state of a box ?
09:14:22 <PatH> dont think it can be done just using a predicate unless we endow that predicate with spoecial semantic force.
09:14:37 <danbri> (around foaf/webid/foaf+ssl and so on, we'll start seeing people identifying concrete sets of well known triples by hash of their encoding, eg. the triples W3C served for the RDF ns for the last 5 years)
09:15:00 <FabGandon> ivan: the snap vs. box is exactly about mutability
09:15:03 <pchampin> PatH??: <someuri> owl:sameas 42
09:15:57 <PatH> sure, that is ok, but states are transient.
09:16:28 <FabGandon> davidwood: if a g-box is a resource than we can talk about it.
09:16:49 <sandro> q+ to say the difference
09:16:59 <FabGandon> pgroth: so what is a snap then if not an immutable box ?
09:17:29 <FabGandon> sandro: another difference is equality.
09:17:45 <gavinc> The NAME is not part of the g-snap
09:17:54 <danbri> sandro, does that work ok w/ bnodes? do we have samegraphness defined adequately for graphs w/ bnodes?
09:18:14 <FabGandon> davidwood: two g-snaps may have the same content and still be different snaps.
09:18:27 <FabGandon> ... we haven't decided on that yet.
09:18:50 <sandro> danbri, yes, but you also have to allow bnodes to be shared between graphs.
09:18:51 <FabGandon> ... it depends on how we resolve issue 15
09:18:53 <SteveH> q+ to ask Sandro about why two g-boxes can't be equal [unless I got the wrong end of the stick]
09:19:16 <gavinc> ... I don't think g-snaps had names?
09:19:42 <PatH> stephen, two anythings cannot be equal.
09:19:54 <davidwood> ack sandro
09:19:54 <Zakim> sandro, you wanted to say the difference
09:19:55 <sandro> ack sandro
09:19:57 <ivan> ack sandro
09:19:58 <davidwood> ack PatH
09:20:03 <danbri> (sandro, eg. if there is an rdf/xml file bundled with Jena that is packaged old version of DC schema; and the similar-but-different triples we get from a DCMI namespace URI fetch ... )
09:20:10 <FabGandon> subtopic: REST and named graphs.
09:20:39 <FabGandon> PatH: The guiding abstraction should be the REST model
09:21:54 <FabGandon> davidwood: reprensentations are not resources by default
09:22:04 <davidwood> ack pchampin
09:22:08 <ivan> ack PatH
09:22:13 <sandro> it's the g-text that's the representation, not the g-snap.
09:22:29 <FabGandon> sandro: the representation is the g-text, a string
09:22:33 <danbri> PatH, does "is not a resource" there mean "not a Web/http resource" rather than "is not a resource-considered-as-synonym-for-thing"?
09:22:46 <danbri> (if you can channel for timbl...)
09:22:46 <FabGandon> pchampin: the g-snap is the state of the resource
09:22:51 <yvesr> g-box - resource ; g-snap - state ; g-text : representation
09:22:58 <pgroth> g-box = resource, g-snap = content negotiation, g-text = state serlization
09:22:58 <PatH> sorry, sandro is right. but the snap is an abstraction/parsing of the text.
09:23:01 <mischat> g-snap is information resource at time T ?
09:23:10 <davidwood> ack pgroth
09:23:15 <ivan> ack pgroth
09:23:30 <PatH> and so is similarly unidentifiable.
09:23:36 <JFB> g-snap: state of the resource or state of the representation ?
09:23:48 <PatH> yes, sandro is right.
09:23:54 <yvesr> pgroth: i don't agree - g-snap != content-negotiation
09:23:54 <pchampin> @JFB: state of the resource
09:24:06 <yvesr> s/pgroth:/pgroth,/
09:24:17 <FabGandon> cygri: you can't talk about the representation.
09:24:49 <sandro> q?
09:24:56 <PatH> danbri, i want those to be the same sense of resource
09:25:15 <FabGandon> davidwood: a representation is not a resource but with an additional step you can choose to make an identifier for that representation and talk about it.
09:25:28 <pchampin> data: URIs ?
09:25:34 <pchampin> I mean "data colon URIs"
09:25:38 <davidwood> ack SteveH
09:25:38 <Zakim> SteveH, you wanted to ask Sandro about why two g-boxes can't be equal [unless I got the wrong end of the stick]
09:27:18 <sandro> sandro: Two g-boxes remain distinct even though their contents/state might happen to be the same at some point in time.
09:27:42 <FabGandon> q?
09:27:51 <PatH> sandro, sorry to introduce extra confusion.
09:28:33 <PatH> +1 to pfps
09:28:37 <sandro> q+ to talk about use cases
09:28:54 <FabGandon> pfps: We could say we don’t change the semantics, Quads are syntax
09:29:34 <mischat> i like the idea that RDF semantics not changing, and using quads as syntax, +1 to pfps
09:29:44 <PatH> i think there are now also quints, sexts, etc..
09:29:45 <danbri> I can't understand how the same meeting can, 30 mins ago, accept resources=all things in the universe, yet 5 mins ago, deny that the stuff you get back from an HTTP request is a resource. Ug.
09:30:01 <sandro> pchampin, you're right, I think, that data: URIs give us identifiers for representations / g-texts.
09:30:25 <danbri> (even without handy URIs they're still things and therefore Resources in rdfsemantics sense)
09:30:27 <FabGandon> ... RDF semantics defines the meaning of the underlying data structure but not augmented with a semantics for datasets.
09:30:48 <sandro> danbri, we didn't agree with that -- it was just claimed and ignored. :-)
09:31:47 <pfps> so, after all the stuff that I said, I still remain agnostic as to which direction to go
09:32:00 <FabGandon> subtopic: defining Graph primitives in RDF semantics.
09:32:34 <FabGandon> ivan: if we have predicates to link IRI and g-* we need to define them in the RDF semantics
09:33:14 <PatH> yes, we do. so the semantics will have to deal with the *-ideas.
09:33:36 <PatH> yes, exactly.
09:33:47 <FabGandon> pfps: if you want to talk about this inside the RDF voc you have to define it in the RDF semantics indeed.
09:33:59 <PatH> +1
09:34:06 <pfps> from an OWL perspective, the "don't change the semantics view" is very seductive
09:34:25 <SteveH> also from the DB implementors view
09:34:42 <PatH> extend does not imply change, hoever.
09:34:45 <sandro> ISSUE: Should there be an rdf:Graph construct, or something like that?
09:34:46 <trackbot> Created ISSUE-35 - Should there be an rdf:Graph construct, or something like that? ; please complete additional details at http://www.w3.org/2011/rdf-wg/track/issues/35/edit .
09:34:46 <FabGandon> Guus: should there be an rdf:Graph primitive ?
09:35:00 <sandro> (from Guus and David -- I don't understand the question.)
09:35:23 <Zakim> sandro, you wanted to talk about use cases
09:35:40 <FabGandon> pfps: if g-boxes just want to have fun they need to be in the semantics.
09:37:06 <FabGandon> sandro: one of the scenarios is "annotating graphs" e.g. be able to select a part of graph state things about it.
09:38:26 <FabGandon> pchampin: we need a vocabulary for the g-* e.g. just to be about to talk about them when we load them.
09:39:44 <FabGandon> PatH: if the notion of g-box is important then the semantics has to clarify that notion it does not need to be a revolution.
09:39:50 <FabGandon> subtopic: REST and Named graphs (bis).
09:39:52 <pfps> perhaps, but by this same argument, the semantics should specify what happens when you go an HTTP get on a URL
09:40:07 <mischat> i am not sure about the adoption rate of '<> rdf:type rdf:Statement.' , do people even ever use them ...
09:40:19 <PatH> not that bad, peter...
09:40:58 <sandro> PROPOSED: We aligned g-* with REST, where g-box=information resource, g-snap=state of the resource, g-text=representation of the state of the resource
09:41:07 <FabGandon> cygri: documenting the alignment with REST may be useful for us but not in the deliverables ; it is too complex and time-consuming.
09:42:02 <FabGandon> ivan: would lead to endless discussions.
09:42:18 <sandro> PROPOSED: We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource, g-text=representation of the state of the resource
09:42:53 <pchampin> NB: a predicate would not state the relation between a URI and a graph, but between a resource (identified by a URI) and a graph
09:43:22 <PatH> i think we will be doing the world a disservice if we leave ambiguity and confusion. That is what the last RDF WG did, but there is a decade of practice now to guide us.
09:43:33 <mischat> sandro, perhaps s/state of the resource/state of the resource at time t/
09:43:35 <pfps> do we have a failrly coherent document that describes REST?
09:43:58 <sandro> PROPOSED: We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource (at time t), g-text=representation of the state of the resource (at time t)
09:44:03 <PatH> zakim, mute me
09:44:03 <Zakim> PatH should now be muted
09:44:21 <sandro> +1
09:44:22 <pfps> NB: I do understand that coherency is rather absent in the REST universe.
09:44:24 <davidwood> +1
09:44:26 <SteveH> +1
09:44:30 <gavinc> +1
09:44:31 <PatH> +1
09:44:33 <zwu2> +1
09:44:36 <danbri> -1
09:44:40 <AZ> +1
09:44:51 <JFB> +1
09:44:57 <mbrunati> +1
09:45:06 <ivan> 0
09:45:14 <sandro> (clarify -- this is only for the subset of IRs that can be respresented in RDF.)
09:45:18 <pfps> +.5 as I'm not exactly sure just what REST is
09:45:24 <JFB> @AZ yes, found that surprising
09:45:24 <PatH> az, that will teach you to make lumpy custard.
09:45:46 <Zakim> +AZ
09:46:02 <NickH> +1 (but agree that REST isn't very well specified)
09:46:09 <yvesr> +1
09:46:12 <FabGandon> danbri: some environments don’t have a notion of REST.
09:46:13 <pchampin> -1
09:46:43 <FabGandon> Guus: we are only considering the notions behind REST.
09:46:57 <danbri> REST is good, but it doesn't seem a 1:1 relationship to me
09:47:07 <sandro> pchampin: my concern is that we might be missing some more complicated resources whose state is not represented by a graph, because it's not just time.
09:47:16 <SteveH> +1 to danbri, but I don't think it detracts from the analogy
09:47:19 <PatH> seems to me that if its not related to restthen I dont know why we even have these distinctions ourselves.
09:47:21 <pchampin> e.g. authentication, etc
09:47:33 <SteveH> pchampin, right, or cookies for e.g.
09:47:34 <cygri> good point pchampin. language negotiation etc
09:47:43 <danbri> maybe i'm pulling Web-derrived data from a local Lucene store; from Mahout clustering, or prolog, doing stuff in code and stuffing bits into graphs with URI tags. REST is in the environment but the data flow is much more complex than fetch'n'store
09:47:46 <pchampin> yes, this too
09:48:02 <sandro> guus: two groups; (1) json, (2) skolemization
09:48:13 <tomayac> json += tomayac
09:48:19 <PatH> will skolem have a phone link?
09:48:39 <FabGandon> ISSUE-15: Text to be further discussed : "We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource (at time t), g-text=representation of the state of the resource (at time t)"
09:48:39 <trackbot> ISSUE-15 What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc notes added
09:48:44 <danbri> SteveH, sure, considered as an analogy it can be instructive (and in fact I'm trying to extend REST concepts a bit more into XMPP message types)
10:09:29 <pfps> Topic: skolemization (whatever that is!)
10:09:36 <tomayac> is there a dial-in no. for json?
10:09:49 <pfps> no dialin for json yet
10:09:56 <Zakim> +zwu2
10:09:56 <davidwood> davidwood has joined #rdf-wg
10:10:00 <pfps> and there won't be one
10:10:02 <sandro> no dialin for json ever, sorry.
10:10:05 <davidwood> zakim, who is on the phone?
10:10:05 <Zakim> On the phone I see Meeting_Room, tomayac, gavinc, AZ, zwu2
10:10:09 <zwu2> zakim, mute me
10:10:09 <Zakim> zwu2 should now be muted
10:10:40 <Zakim> +PatH
10:10:52 <PatH> zakim, mute me
10:10:52 <Zakim> PatH should now be muted
10:11:02 <mischat> tomayac: do you want to be dialled in ?
10:11:12 <yvesr> scribe: yvesr
10:11:12 <danbri> so - what are we skolemising and why?
10:11:19 <mischat> do JSON people want to call in
10:11:20 <sandro> topic: Skolemization Breakout
10:11:21 <pgroth> the skolemization has taken over this chat room
10:11:27 <pfps> The problem, as I see it, is that RDF stores hold blank nodes, but they have problems sending identifiers for these blank nodes out in response to queries and getting them back.
10:11:29 <mischat> yeah we are about to set up a voice thing
10:11:31 <mischat> i sec
10:11:40 <yvesr> SteveH: long-standing issue in the way bnodes are defined
10:11:49 <yvesr> SteveH: close-enough to existential variables in rdf
10:12:02 <yvesr> SteveH: most implementations turn it into an internal identifier
10:12:05 <sandro> SteveH: I have a longstanding issue who how bnodes are defined, as existential variables. But the reality is that all the triplestores turn it into an internal identifier.
10:12:13 <yvesr> SteveH: turning them into 'skolems'
10:12:21 <cygri> (JSON breakout is happening over in the #rdf-json channel)
10:12:46 <sandro> pfps: So far, they havent' done anything wrong.
10:13:09 <Zakim> -tomayac
10:13:13 <yvesr> SteveH: 2 problems - 1) bnodes in the wild (when there shouldn't be) and 2) people deliberately writing them (i.e. FOAF)
10:13:27 <danbri> q+ to account for the foaf case
10:13:42 <PatH> there is also a strong deprtecation of bnode use in the linked data community.
10:13:44 <sandro> SteveH: But sometimes you encounter bnodes in the wild, where it would be nice to have URIs, as in foaf. In practice it's annoying.
10:13:46 <yvesr> SteveH: in FOAF, you end up using inverse functional properties to identify individuals
10:13:54 <davidwood> Zakim, open the queue
10:13:54 <Zakim> ok, davidwood, the speaker queue is open
10:14:09 <danbri> q+ to account for the foaf case
10:14:24 <sandro> q+ to present proposal
10:14:43 <yvesr> SteveH: People are missing a feature from relational databases (not assigning an explicit primary key)
10:15:03 <yvesr> SteveH: some triple stores have internal uri schems to talk about bnodes
10:15:12 <sandro> SteveH: Folks also have internal URI schemes for talking about bnodes. People really want this for SPARQL round-tripping.
10:15:14 <davidwood> ack danbri
10:15:14 <Zakim> danbri, you wanted to account for the foaf case
10:15:15 <yvesr> SteveH: those can surface in query results - and can be used in queries
10:15:18 <pfps> q+
10:15:28 <PatH> q+
10:15:38 <pfps> q+ to say that such RDF stores aren't really doing anything 'wrong'
10:15:48 <yvesr> danbri: There's a reason for the FOAF choice - leading to anonymous resources
10:16:02 <yvesr> danbri: no owl:sameAs, not clear what to do with resources
10:16:19 <yvesr> danbri: identifying people with properties was a pragmatic decision
10:16:44 <yvesr> davidwood: how would you do it today?
10:17:07 <yvesr> danbri: if you were in a position to assign uris for other people, then FOAF would have gone for URIs
10:17:24 <yvesr> danbri: bnodes are a pain to deal with...
10:17:44 <yvesr> q+
10:18:01 <davidwood> ack sandro
10:18:01 <Zakim> sandro, you wanted to present proposal
10:18:01 <ivan> ack sandro
10:18:06 <sandro> steveH: The assigned URIs leak out of query interface, which is what makes them useful.
10:18:27 <zwu2> zwu2 has joined #rdf-wg
10:18:31 <danbri> original statement of the foafy smushing stuff: http://lists.xml.org/archives/xml-dev/200012/msg00597.html
10:18:44 <yvesr> sandro: Long discussion on the semantic-web list a couple of weeks ago - a proposal was done that adress everyone's requeirements
10:19:09 <yvesr> sandro: pick one of two uri pattern choices to skolemize bnodes
10:19:29 <yvesr> sandro: http://... if you want to dereference, or tag:...
10:20:03 <yvesr> sandro: if you encounter one of those uris, it's machine generated
10:20:17 <yvesr> sandro: those uris can be considered as disposable
10:20:19 <danbri> so the first dozen or so FOAF files used genid: as a URI scheme, eg. http://svn.foaf-project.org/foaftown/2010/allfactoids/copies/danbri/danbri-foaf.rdf ... about="genid:poulter" etc
10:21:00 <FabGandon> yvesr: how do you know they are machine generated?
10:21:13 <PatH> it is always valid to 'deskolemize', so we dont need to say anything about that.
10:21:20 <FabGandon> SteveH: because they have genid
10:21:39 <yvesr> danbri: reserved uri pattern - genid in the uri means that it is machine generated
10:21:42 <sandro> 1. If you're going to Skolemize, use a URI like this:
10:21:42 <sandro> - http://example.org/.well-known/genid/[whatever]
10:21:42 <sandro> - tag:example.org,2011/.well-known/genid/[whatever]
10:21:42 <sandro> 2. If you encounter one of these URIs:
10:21:42 <sandro>
10:21:43 <sandro> - you know it's machine generated
10:21:45 <sandro> - consider it more disposable, more mergeable
10:22:08 <PatH> +1 to speaker. genid is better.
10:22:11 <gavinc> eg: generate-id() in XPath/XSLT
10:22:12 <sandro> We mean LITERALLY the string "genid".
10:22:13 <yvesr> SteveH: Prefers genid over bnodes
10:22:40 <PatH> s/speaker/stevenh
10:22:43 <yvesr> SteveH: you might want to use "genids" to identify graphs
10:22:51 <davidwood> ?
10:22:53 <davidwood> q?
10:22:57 <yvesr> sandro: Use "genid" or "gensym"?
10:23:00 <davidwood> ack pfps
10:23:00 <Zakim> pfps, you wanted to say that such RDF stores aren't really doing anything 'wrong'
10:23:05 <ivan> ack pfps
10:23:49 <davidwood> q+ to mention the use of made-up ids as a pattern to replace bnodes
10:24:07 <yvesr> JFB: bnodes are stronger - they can never be used in another graph
10:24:18 <yvesr> SteveH: this is already dropped in sparql-update
10:24:53 <yvesr> pfps: Technically, it is not a valid entailment
10:25:24 <ivan> q+
10:25:35 <danbri> related prev discussion: sergey melnik tried to create a canonical URIs for bnode/anon resources - http://lists.w3.org/Archives/Public/www-rdf-interest/1999Dec/0046.html
10:25:59 <sandro> pfps: As long as these are fresh, you wont get any incorrect inferences.
10:26:20 <yvesr> pfps: SPARQL-update validates the leaky bnodes, what this proposal says is that graph stores are able to make that transformation
10:26:25 <sandro> pfps: This says an RDF store is entitled to change bnodes like this.
10:27:05 <davidwood> ack PatH
10:27:08 <sandro> pfps: "RDF graphs stores can, on their own recognisance, do this transformation"
10:27:37 <yvesr> PatH: the fact that such uris can leak out is a good thing
10:27:51 <yvesr> PatH: We don't have to worry about leakage
10:27:52 <sandro> q?
10:28:22 <davidwood> ack yvesr
10:28:51 <zwu2> cannot hear much
10:28:55 <PatH> zakim, mute me
10:28:55 <Zakim> PatH should now be muted
10:29:19 <PatH> sound is very patchy.
10:29:25 <PatH> better
10:31:07 <davidwood> ack davidwood
10:31:07 <Zakim> davidwood, you wanted to mention the use of made-up ids as a pattern to replace bnodes
10:31:31 <yvesr> yvesr: RDFa creates lots of bnodes in the wild
10:31:56 <yvesr> yvesr: and sometimes there are things that you can't identify, or don't want to mint a URI for (e.g. transient things)
10:32:01 <danbri> ivan, in your homepage you have <div id="container" about="http://www.ivan-herman.net/foaf#me" typeof="foaf:Person dc:Agent"> .... that's the verbose aspect. But maybe you could use a relative URI at least?
10:32:22 <yvesr> davidwood: I don't think there is soemthing wrong with bnodes, and it's fine to skolemize them
10:32:37 <yvesr> s/soemthing/something/
10:33:04 <yvesr> davidwood: Machines should do the job, transparently
10:33:40 <sandro> q?
10:33:45 <davidwood> ack ivan
10:33:45 <sandro> q+ to draft proposal
10:33:50 <yvesr> SteveH: what you want is a bnode syntax, not a bnode semantics
10:34:14 <yvesr> ivan: I can understand that a number of people would want to derefence these things
10:34:19 <PatH> sandro, type it.
10:34:21 <yvesr> ivan: what happens when you derefence them?
10:34:24 <sandro> PROPOSAL: It's okay for systems to Skolemize bnodes, replacing them with IRIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. Must be reg'd with IETF.
10:34:33 <yvesr> ivan: what advice do you give, and how are people to set it up?
10:34:57 <yvesr> ivan: the first uri pattern is an http:// uri, and needs to be dereferencable - what does it do?
10:34:58 <PatH> should be fine for these to give 404s.
10:35:03 <davidwood> SteveH: Yes, I want the usefulness of bnode semantics with a simple, automated bnode syntax assistance.
10:35:29 <yvesr> ivan: do we want to get this reflected in various syntaxes?
10:35:48 <davidwood> q?
10:36:20 <yvesr> SteveH: what we would do in 4store would be to generate bnode skolems based on a prefix
10:36:32 <yvesr> SteveH: prefix is defined in configuration
10:36:52 <yvesr> SteveH: accessible as any other identifier in the store
10:37:30 <yvesr> ivan: you're using your SPARQL engine as a tool - the W3C needs to provide a global mechanism for what happens when you derefence a http://...genid... uri
10:37:35 <PatH> sandro, if these are supposed to refer to non-information resources, then according to http-range-14, they ought to give a 303 redirect. Can they have a # ending to remove this requirement?
10:38:22 <yvesr> q+
10:38:58 <yvesr> ivan: Linked Data people don't want to have bnodes in their graph
10:39:19 <yvesr> pfps: there's no way to make them happy
10:39:35 <yvesr> ivan: there is a way to set up a simple service somewhere that would do the job
10:39:41 <sandro> PatH, how about if it's http[s]://[domain]/.well-known/genid/[locally-uniq-id]#
10:40:13 <PatH> fine with me, as long as doesnt require a 303 mechanism
10:40:18 <davidwood> q+ to discuss broadness of skolemization (stores, validation, services, etc)
10:40:23 <yvesr> SteveH: if you dereference a bnode, one thing you could do is to just say 'this is a bnode'
10:40:42 <davidwood> ack sandro
10:40:42 <Zakim> sandro, you wanted to draft proposal
10:40:56 <sandro> PROPOSAL: It's okay for systems to Skolemize bnodes, replacing them with IRIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id]# or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. Must be reg'd with IETF.
10:41:00 <danbri> q+ to express risk of single point of failure / keeping a bnode-description-service secure is nontrivial, costly work
10:41:38 <yvesr> sandro: the hash is to stay clear of httpRange-14
10:41:52 <gavinc> Annoyed but not strong/formal objection to using tag: --0?
10:41:58 <yvesr> sandro:
10:42:02 <PatH> +1 danbri, should not presume a service of any kind.
10:42:07 <yvesr> SteveH: i can think of lots of reasons not to do that
10:42:15 <sandro> gavinc, why does the tag bother you? what would you prefer?
10:42:40 <yvesr> davidwood: uri lookups cost time and money
10:42:50 <gavinc> tag was designed specificly for HUMAN generated uniqueness
10:42:50 <davidwood> ack yvesr
10:43:04 <gavinc> q+
10:43:05 <danbri> (re bit.ly / tinyurl analogy, ... it's taking us a month of HTTP requests to bit.ly to expand otherwise mysterious shortlinks from a twitter crawl, ... they only allow 2 lookups / second ... single points of control worrying)
10:44:22 <pchampin> shouldn't we add "fresh IRI" in Sandro's proposal?
10:44:41 <sandro> yvesr: I don't like Skolem ids leaking out.
10:44:54 <danbri> LOD community have established the convention than any party can invent HTTP URIs freely, for anything and anyone; so why not just generate LOD URIs or uuid: URIs? I don't see this proposal adding value to those options
10:44:56 <FabGandon> WRT the service approach, beyond the risk of single point of failure it is a point of centralization in the model and in general centralization is not good for web arch IMHO
10:44:58 <PatH> all specifically RDF uses dont require dereferencing. Seems like main purpose of these being recognizable is to AVOID dereferencing them.
10:45:37 <davidwood> ack gavinc
10:45:39 <zwu2> q+
10:45:42 <ivan> ack gavinc
10:45:45 <sandro> sandro: Maybe "*if* you're going to skolemize, you SHOULD use one of these two forms"
10:46:23 <PatH> disagree. should be free to skolemize any way you like, as long as it is 'frtesh'
10:46:24 <yvesr> gavinc: seems very wrong to use tag uris
10:46:29 <PatH> fresh
10:46:50 <yvesr> gavinc: is UUID terrible?
10:47:16 <yvesr> SteveH: minting a new UUID for all bnodes is not very affordable
10:47:27 <yvesr> gavinc: we got rid of all bnodes at o'reilly because of that
10:47:28 <davidwood> Sandro thinks yes, UUIDs doesn't allow you to use genie
10:47:40 <davidwood> s/genie/genid/
10:47:49 <yvesr> q?
10:48:27 <yvesr> ivan: is it true that the tag: scheme says 'it is for humans'?
10:48:51 <yvesr> gavinc: the generation mechanism needs to happen by humans
10:48:58 <davidwood> ack davidwood
10:48:58 <Zakim> davidwood, you wanted to discuss broadness of skolemization (stores, validation, services, etc)
10:49:11 <zwu2> zakim, unmute me
10:49:11 <Zakim> zwu2 should no longer be muted
10:49:25 <yvesr> davidwood: There is opportunity to use skolemisation in quite a lot of places, not only in stores
10:49:50 <yvesr> davidwood: input, output, validation process, skolemization services
10:49:52 <pchampin> q+ to talk about the fresh URIs and them leaking from the store
10:50:14 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they SHOULD use URIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id]# or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
10:50:14 <davidwood> q?
10:50:15 <yvesr> davidwood: if you're doing skolemization, you SHOULD do it in the way we're defining
10:50:22 <danbri> ack danbri
10:50:22 <Zakim> danbri, you wanted to express risk of single point of failure / keeping a bnode-description-service secure is nontrivial, costly work
10:50:22 <davidwood> ack danbri
10:50:35 <davidwood> zakim, close the queue
10:50:35 <Zakim> ok, davidwood, the speaker queue is closed
10:50:44 <PatH> prposal. it is permissible to replace bnodes by URIs provided that the URIs are 'fresh', ie not used in any other rdf graph. It is recommended to include a string /genid/. one way is sandro's prposal.
10:50:59 <danbri> q-
10:51:04 <yvesr> ivan: Would that effect any of the syntaxes, and how?
10:51:07 <PatH> q+
10:51:07 <yvesr> SteveH: it wouldn't
10:51:08 <danbri> I defer; question withdrawn
10:51:15 <yvesr> SteveH: it wouldn't be the parser's job to do it
10:51:22 <yvesr> SteveH: it doesn't have enough information
10:51:33 <yvesr> ivan: for RDFa, it would make sense - and it might make sense for Turtle files too
10:51:38 <mischat_> mischat_ has joined #rdf-wg
10:51:49 <yvesr> ivan: many people use the square brackets - lazyness
10:51:50 <danbri> ( I assume args for the skolem function is not just the textual input, but also the base URI...)
10:52:06 <yvesr> ivan: i should be able to tell the parser to mint me some URIs for those
10:52:23 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they SHOULD use fresh URIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
10:52:24 <davidwood> +1 to PatH's proposal
10:52:32 <davidwood> ack zwu
10:52:39 <yvesr> SteveH: reverse transformation - output documents *with* bnodes
10:53:08 <mischat_> Webr3 about?
10:53:12 <yvesr> zwu2: if you have one triple in a store, :john :friendOf _:a
10:53:16 <PatH> steveh, it is always valid to 'deskolemize' with bnodes.
10:53:24 <yvesr> zwu2: you would get back a skolemized bnode
10:53:31 <mischat_> webr3, if you are about join #rdf-json
10:53:36 <yvesr> zwu2: if we're using that skolemized bnode as a query
10:53:44 <yvesr> are we supposed to return :john or not?
10:53:49 <yvesr> zwu2: are we supposed to return :john or not?
10:53:52 <yvesr> SteveH: yes
10:54:08 <PatH> yes. once it is a uri, you can do this.
10:54:09 <yvesr> davidwood: if identifiers leak out to the outside world, it maintains validity
10:54:31 <yvesr> ivan: if i use the bnode filter operation in a SPARQL query, what happens?
10:54:37 <yvesr> ivan: does it match the skolemized bnode?
10:54:47 <yvesr> SteveH: that's an issue for us
10:54:49 <PatH> zakim, unmute me.
10:54:49 <Zakim> PatH should no longer be muted
10:54:56 <yvesr> SteveH: we need to define if they count as bnodes or not
10:55:12 <yvesr> ivan: as a user, who doesn't understand this stuff, i would expect the bnode function to work
10:55:21 <yvesr> SteveH: in 4store, it would answer true
10:55:39 <yvesr> SteveH: it only gets skolemized on the export
10:55:47 <yvesr> SteveH: internal consistency
10:55:47 <ivan> q?
10:55:48 <davidwood> ack pchampin
10:55:49 <Zakim> pchampin, you wanted to talk about the fresh URIs and them leaking from the store
10:55:53 <ivan> ack pchampin
10:56:34 <yvesr> pchampin: We shoudl specify what is ok for the system to do
10:56:39 <PatH> az, no problem
10:56:43 <yvesr> pchampin: We should specify what the system would return
10:56:44 <SteveH> AZ, that wouldn't be legal RDF syntax, though you could write it by hand
10:56:57 <davidwood> PatH, can you please resend your proposal?
10:56:58 <yvesr> pfps: Troubles finding the SPARQL bnode definition
10:57:25 <danbri> pat hayes
10:57:40 <SteveH> http://www.w3.org/TR/rdf-sparql-query/#func-isBlank
10:57:49 <SteveH> ...the BNODE() function actually mints bNodes
10:57:50 <yvesr> PatH: genid SHOULD be in the URI but not absolutely required
10:57:58 <SteveH> but I think it was understood what was being discussed
10:58:07 <yvesr> PatH: it should be possible for people to invent URIs and use them
10:58:15 <yvesr> PatH: they could use software to do that automatically
10:59:08 <yvesr> PatH: We should not allow skolems that are specific to a single query
10:59:24 <sandro> PatH: Note that Skolemization is not valid in an antecedent (eg query).
10:59:31 <sandro> SteveH: that's fine.
10:59:40 <PatH> prposal. it is permissible to replace bnodes by URIs provided that the URIs are 'fresh', ie not used in any other rdf graph. It is recommended to include a string /genid/. one way is sandro's prposal.
10:59:46 <yvesr> SteveH: the skolemization process has to be stable
11:00:00 <yvesr> davidwood: Can we get consensus around this proposal?
11:00:19 <yvesr> davidwood: are there concerns around sandro's mandated use?
11:00:43 <yvesr> davidwood: if you're going to skolemize, you need to use a globally unique URI
11:00:49 <sandro> freshness is iffy -- since you want stability....
11:00:52 <yvesr> davidwood: and we encourage you to do it in a way
11:01:46 <danbri> -1 where did 'allowed' enter the rdf universe?
11:01:49 <zwu2> as long as generated uri is fresh to the triple store, it is good enough
11:01:54 <yvesr> -1 as well
11:02:01 <danbri> -> say what it means, not what people can/can't do
11:02:22 <PatH> must be fresh, should include /genid/
11:02:47 <yvesr> sandro: MAY is you're allowed to
11:02:58 <yvesr> pfps: SHOULD is you should do it, unless there's a very good reason not to
11:03:16 <PatH> sandro, why is freshness "iffy"
11:03:37 <danbri> proposed: "A graph transformed such that each bnode is replaced with a fresh bnode [meeting some constraints], ... then that new graph is true under the same conditions of the original."
11:03:40 <danbri> q+ to propose
11:04:10 <danbri> we are not the SPARQL WG
11:04:12 <yvesr> davidwood: if systems are going to leak bnodes, they must use fresh uris
11:04:52 <yvesr> SteveH: consistent mapping between internal representation and external id
11:05:02 <zwu2> so we can reuse "fresh" uris
11:05:11 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
11:05:20 <yvesr> danbri: we're not the SPARQL working group - so I think this language inappropriate
11:05:33 <yvesr> danbri: we should instead say something about graph structures
11:06:11 <yvesr> ivan: current RDF documents already talk about skolemization
11:06:31 <yvesr> ivan: the only thing we're saying here is that if it is used, you should use this pattern
11:06:52 <danbri> http://www.w3.org/TR/rdf-mt/#prf
11:06:54 <yvesr> pfps: RDF Semantics talk about skolemization
11:07:51 <yvesr> sandro: you need a web service to do the skolemization
11:08:00 <PatH> wha?
11:08:05 <yvesr> ???
11:08:18 <danbri> madness!!!
11:08:18 <yvesr> SteveH: you can't guarantee uniqueness
11:08:30 <danbri> (that's a technical term, no disrespect intended)
11:09:12 <PatH> call it 'bnode purging' and people will love it.
11:09:16 <yvesr> sandro: tag: skolemized bnode are more horrible than bnode
11:09:35 <danbri> PatH, can it be couched more declaratively? this 'should' stuff worries me
11:09:40 <JFB> RDF Semantics talks about Skolemization in Appendix A. Its notion of freshness is "fresh in the current graph"
11:09:42 <yvesr> ivan: the R2RML folks are fighting with the same problem
11:09:46 <PatH> danbri, yes.
11:10:01 <yvesr> ivan: what happens when the DB doesn't have a (publicly exposable) primary key
11:10:13 <PatH> jfb, no, that is not what was intended.
11:10:14 <pchampin> s/the DB/a table in the DB/
11:10:19 <sandro> PatH, in "you need a web service to do the skolemization" , I mean to be particularly useful, and make people happy you did the Skolemization....
11:10:45 <danbri> sandro, what are you seeing as the args to the skolemisation function? not just a document + base_uri?
11:10:49 <yvesr> ivan: if we come up with this note, we need to send it to the R2RML group - potential first users
11:11:17 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
11:11:37 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use a fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
11:11:44 <sandro> objections from danbri and yves.
11:11:49 <PatH> unhappy with 'disposable'
11:12:13 <yvesr> danbri: very short URIs are important to me
11:12:19 <yvesr> danbri: don't force me to use this long pattern
11:12:25 <sandro> danbri: short URIs are important to me. don't force me to do it this way.
11:12:41 <yvesr> SteveH: uri pattern is quite verbose
11:12:45 <PatH> and would prefer to just say 'SHOULD include string /genid/'
11:12:49 <danbri> sorry - am sounding grumpier than I am. This could be a useful pattern for some.
11:12:50 <sandro> SteveH: for the non-deref form I prefer something smaller.
11:13:08 <zwu2> how about genid:local_unique_id
11:13:14 <yvesr> danbri: if we cut the proposal to the first MUST, any objections?
11:13:35 <PatH> and sandro's particular form offered as an offtheshelf solution.
11:13:39 <yvesr> all: what does disposable mean?
11:13:44 <yvesr> pfps: all pragmatics from here
11:13:54 <PatH> +1
11:14:20 <yvesr> sandro: you can skolemize, at some cost
11:14:33 <danbri> when you said "You're changing the data", that's in the right direction pfps
11:14:56 <PatH> you always can skolemize. It is not valid, but it preserves satisfiability.
11:15:02 <yvesr> sandro: proposition restrcited to MUST is actually stronger - want to expose the fact that it has been skolemized
11:15:36 <yvesr> sandro: genid:... would be good, but needs to be pushed through the IETF
11:15:54 <yvesr> ivan: this is a pain
11:16:11 <yvesr> sandro: don't want to be stuck in the IETF
11:16:24 <zwu2> you guys are not hungry, are you?
11:16:25 <danbri> the crux seems to be 'is it still in some appropriate equivalence class of graphs from the original? or has it been inappropriately interfered with..."
11:16:43 <PatH> why do we need to involve the IETF???
11:17:00 <gavinc> scheme registration :(
11:17:03 <yvesr> PatH, for a potential new uri scheme for those skolems
11:17:09 <pchampin> PatH: if we want a genid: URI scheme
11:17:11 <pfps> if we want to use URIs of the form genid:... we need to get approval
11:17:20 <PatH> screw a new scheme. they are just uris.
11:17:42 <yvesr> SteveH: are the two graphs the same? the skolemized and the original one?
11:17:53 <ivan> Pat, the issue is that the proposed URI-s are ugly and long...
11:18:01 <PatH> we need pertmission to include some text inside a URI??
11:18:30 <sandro> we need permission to say that all URIs containing certain text have a certain meaning, Pat.
11:18:34 <PatH> ivan, that is another issue.
11:18:35 <yvesr> you can't project from skolemized to original, but you can the other way around
11:18:52 <yvesr> FabGandon: you can't project from skolemized to original, but you can the other way around
11:18:59 <PatH> we artent saying anything about meaning, sandro.
11:19:17 <PatH> we are just making them recognizable.
11:19:58 <PatH> dawn is breaking here.
11:20:04 <yvesr> davidwood: if we're close to a solution, let's keep on on that
11:21:04 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, without doing damage to the graph, they MUST use a fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id] (or, someday, genid:...). Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
11:21:31 <FabGandon> yvesr: still not happy with the SHOULD part
11:21:40 <PatH> -1 to that. way too restricting. overkill.
11:21:53 <FabGandon> ... not confortable with specifying a URI parttern.
11:22:00 <pchampin> still uncomfortable with the "disposable" part; I don't know what that means
11:22:05 <zwu2> +0
11:22:13 <FabGandon> ivan: happier with IETF pattern
11:22:15 <PatH> agree with fabgandon
11:22:45 <FabGandon> Fabien happier with genid:
11:23:07 <PatH> we do not need to get IETF involved.
11:23:35 <pchampin> PatH: if we want genid: URIs, we do
11:23:39 <Zakim> -zwu2
11:23:42 <PatH> have a good lunch, guys.
11:23:55 <Zakim> -PatH
11:23:59 <AZ> enjoy your meal
11:24:04 <Zakim> -AZ
11:24:18 <PatH> pchampin: I do not neeed he IETF t put 'gnid' into a URI name.
11:24:41 <PatH> Anyway, back to email :-)
11:25:09 <gavinc> about:, irc:, javascript:, jar:, rsync:, ssh:, ... need the IETF is a nice idea, the world doesn't exactly agree ;)
11:25:33 <gavinc> heck, if WHATWG has its way with the IETF ... no comment
11:25:54 <Zakim> -gavinc
11:31:13 <mischat__> mischat__ has joined #rdf-wg
11:58:16 <cmatheus> cmatheus has joined #rdf-wg
12:02:18 <mbrunati> mbrunati has joined #rdf-wg
12:02:23 <Guus> Guus has joined #rdf-wg
12:02:29 <ivan> -> http://www.w3.org/mid/4DA6A6AD.70205@deri.org -> Antoine's objection to yesterday's resolution
12:02:55 <ivan> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0307.html instead
12:03:00 <cygri> cygri has joined #rdf-wg
12:03:02 <danbri> 404
12:03:04 <danbri> ah
12:03:19 <ivan> -> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0309.html Lee's reply
12:03:38 <AlexHall> AlexHall has joined #rdf-wg
12:05:51 <gavinc> zakim, code?
12:05:51 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), gavinc
12:06:18 <danbri> zakim, who is on the phone?
12:06:18 <Zakim> On the phone I see Meeting_Room
12:06:19 <mischat> can people here the room ?
12:06:19 <sandro> zakim, who is on the call?
12:06:19 <Zakim> On the phone I see Meeting_Room
12:06:23 <mischat> s/here/hear/
12:06:27 <Zakim> +gavinc
12:06:53 <sandro> topic: Debrief Breakouts
12:07:03 <sandro> subtopic: JSON Breakout Debrief
12:07:34 <cmatheus> scribe:cmatheus
12:07:34 <cmatheus> cygri: talked about note to enumerate problem JSON space
12:07:51 <cmatheus> three examples; linked data, BBC, NYT
12:08:01 <Zakim> + +1.443.212.aabb
12:08:16 <ivan> q+
12:08:25 <cmatheus> part of problem: data always connected to some api
12:08:31 <AlexHall> zakim, +1.443.212.aabb is me
12:08:31 <Zakim> +AlexHall; got it
12:08:47 <cmatheus> linked data approach provides tools but its complicated
12:09:30 <cmatheus> talked about focusing on simple actions a json developer might want to take: enumerate instances, describe instance
12:10:21 <cmatheus> mischat: will also enlist help form rdfa TF
12:10:26 <ivan> q+
12:10:35 <ivan> zakim, open queue
12:10:35 <Zakim> ok, ivan, the speaker queue is open
12:10:39 <ivan> q+
12:10:48 <ivan> ack
12:10:49 <Guus> q?
12:10:54 <davidwood> ack ivan
12:11:37 <Zakim> +??P18
12:11:48 <cmatheus> ivan: discussion with Sandro about rdf web app working group (rdfa wg)
12:11:58 <webr3> Zakim, I am ??P18
12:11:58 <Zakim> +webr3; got it
12:12:30 <cmatheus> ivan: their intention is for low level things to be hidden from JS user
12:12:53 <cmatheus> whatever comes out of that group should be coordinated
12:13:04 <cmatheus> need to keep groups in sync
12:13:33 <cmatheus> guus: does this mean our use case numbver one is being done by rdfs wg?
12:13:43 <cmatheus> ivan: it's in the bin
12:13:56 <danbri> 'in the bin?' = trash?
12:14:13 <webr3> next week..
12:14:26 <cmatheus> according to plan rdfa api will be published next week
12:14:41 <cmatheus> this group should look at that document
12:14:56 <Steven> Steven has joined #rdf-wg
12:15:05 <cmatheus> guus: reporting of second breakout?
12:15:22 <sandro> subtopic: Report of Skolemization Breakout
12:15:40 <cmatheus> steveh: problem is if you have bnodes and you want to run a query to get them out there's no way to do that.
12:15:58 <cmatheus> plan is to provide a standard skolemize method to let you get them out
12:16:16 <cmatheus> everyone agreed this was good
12:16:35 <sandro> SteveH: If you query a sparql store and get bnodes out, there's no way to ask about them. We'd like to stdize a way to allow those bnodes to be given lables (be IRI nodes) so you can ask more. The sticky part is about indicating which nodes started out live as bnodes.
12:16:39 <LeeF> LeeF has joined #rdf-wg
12:16:44 <cmatheus> sticky part whether it's desirable to have a way to tell that these started out as bnodes.
12:17:19 <Zakim> +LeeF
12:18:02 <cmatheus> guus: is there consensus that you should be able to tell that they were blank nodes?
12:18:44 <Zakim> +AZ
12:18:46 <Steven> -> http://www.w3.org/2011/04/14-rdf-json-minutes.html Minutes of JSON breakout
12:18:53 <cmatheus> davidwood: core issue: how are people external to the skolem process able to tell they were bnodes.
12:18:57 <danbri> (@cygri, I made a twitter list with rdfwg members, from your post - https://twitter.com/#!/danbri/rdfwg )
12:19:45 <cmatheus> question to peter: do you object to there being a way to be able to tell that these are bnodes?
12:19:53 <sandro> davidwood: Peter, do you object to there being a mechanism for indicating skolem nodes?
12:20:07 <sandro> Peter: I object to it being mandated.
12:20:16 <cmatheus> peter: against it being manditory
12:20:34 <cmatheus> as a consum I don't need to know whether someone skolemized.
12:20:40 <sandro> peter: As a consumer, I don't need to know, in all cases, whether Skolemization was done. It would be nice to know, but it's not even a should.
12:20:58 <gavinc> +q to ask if isBlank() behavior should stay the same with skolemized or non skolemized?
12:20:59 <cmatheus> it's nice if we all did it or all agreed on doing it.
12:21:18 <danbri> so was this skolemised? http://data.linkedmdb.org/page/film/2014 ... who cares!
12:21:24 <sandro> SteveH: I want to be able to mint URIs that are skolem constants for bnodes such that when I get them back I can tell they were bnodes?
12:21:55 <cmatheus> steveh: if the producer gets the bnodes back should they be able to tell if they were created as bnodes? different from having any user being able to tell.
12:22:20 <cmatheus> davidwood: in short, we were not able to get consensus
12:22:23 <gavinc> -q
12:22:31 <cmatheus> guus: will leave it open for the moment
12:22:38 <sandro> danbri, there are several practical situations when I would care, yes.
12:23:07 <cmatheus> guus: turning to clean up
12:23:15 <SteveH> danbri, if someone does INSERT DATA { <http://data.linkedmdb.org/page/film/2014> ... } and it's ont of my bNodes, I really need to be able to tell
12:23:24 <SteveH> otherwise it will screw up the data
12:23:58 <cmatheus> sandro: yesterday issue 10: deprecated, will use archaic
12:24:13 <cmatheus> issues on xs:string, containers
12:24:57 <cmatheus> next item for today: reification
12:25:04 <cmatheus> this is issue-25
12:25:35 <cmatheus> propse that we leave this until after we have a replacement for it
12:26:08 <cmatheus> issue-26: trivial, rdfxml syntax has two ways to state subject: rdf:about and rdf:id
12:26:08 <trackbot> ISSUE-26 Should we deprecate rdf:ID on RDF/XML node elements? (use rdf:about instead) notes added
12:26:26 <cmatheus> proposal to mark idea as archaic
12:26:47 <cmatheus> Steveh: it can be usefull to use rdf:id to ensure you don't reuse an id
12:26:56 <sandro> SteveH: rdf:ID can be useful to find times when you accidentally use it twice....
12:26:59 <cmatheus> (since rdf:id's must be unique)
12:27:08 <AlexHall> do most rdf/xml parsers enforce the uniqueness of rdf:ID?
12:27:08 <cmatheus> guus: no objection to marking archaic
12:27:40 <cmatheus> cygri: I would argue against it. it's a minor issue. fixes a minor problem among the many rdf has.
12:27:51 <cmatheus> if this is the only change let's not go there
12:28:00 <gavinc> Googling for rdf:ID lists documents which give conflicting advice on using it vs. rdf:about
12:28:17 <cmatheus> sandro: wouldn't suggest that we go to much lenght to fix, but would recommend author's not to suggest using rdf:id
12:28:52 <danbri> http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-ID-xml-base
12:28:58 <cmatheus> guus: there is a cost involved to learning to use rdf:id vs. rdf:about
12:29:03 <danbri> "So for example if rdf:ID="name", that would be equivalent to rdf:about="#name". rdf:ID provides an additional check since the same name can only appear once in the scope of an xml:base value (or document, if none is given), so is useful for defining a set of distinct, related terms relative to the same RDF URI reference."
12:29:32 <cmatheus> danbri: rdf:node_id are for bnodes
12:29:34 <danbri> q+
12:30:25 <cmatheus> sandro: no body advocating rdf:id is a good thing just that it's not worth doing much about it
12:30:53 <sandro> PROPOSED: We don't think people should be using rdf:ID, but maybe it's not worth expressing this sentiment in any documents.
12:31:28 <webr3> so why not just deprecate it?
12:31:35 <cmatheus> guus: no one arguing for keeping it
12:31:42 <sandro> webr3, lots of people just gave their reasons.
12:31:46 <sandro> q?
12:31:47 <davidwood> davidwood has joined #rdf-wg
12:31:54 <davidwood> q?
12:31:59 <cmatheus> ivan: I would not touch rdf/xml
12:32:10 <pchampin> @web3: we deprecated the term 'deprecate' yesterday :)
12:32:13 <SteveH> http://www.google.com/search?q=%22rdf%3AID%22 suggests we should keep it
12:32:17 <cmatheus> if we begin to do something with it we will have to do a serious job
12:32:56 <cmatheus> danbri: rdf spec grammar, rdf:id can be used to check name reuse
12:33:12 <sandro> danbri: By saying anything, we complicated the RDF environment.
12:33:16 <cmatheus> if we say anything at all we add complexity to rdf environment.
12:33:24 <pfps> q+
12:33:35 <cmatheus> guus: propose we do not change
12:33:40 <ivan> ack danbri
12:33:42 <ivan> ack pfps
12:33:46 <sandro> PROPOSED: Close ISSUE-26 doing nothing.
12:33:49 <cmatheus> pfps: because it is being used we should do something about it
12:33:57 <LeeF> ISSUE-26?
12:33:57 <trackbot> ISSUE-26 -- Should we deprecate rdf:ID on RDF/XML node elements? (use rdf:about instead) -- open
12:33:57 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/26
12:34:07 <gavinc> I think my objection to rdf:ID is what happens if your xml:base ends with a / ;)
12:34:29 <gavinc> the issue is "appending the attribute value to the result of appending "#""
12:34:38 <NickH> Why is getting rid of rdf:ID more effort than getting rid of XMLLiteral / xsd:String etc?
12:34:42 <cmatheus> davidwood: why if it caused confusion and we agree we shouldn't use it, why should we continue to accept it?
12:34:49 <danbri> q+ to propose that we replace rdf:about and rdf:resource with rdf:uri, i.e. <foaf:Person rdf:uri="#me"><foaf:homepage rdf:uri="/"></foaf:Person>
12:34:55 <cmatheus> marking it archaic is not removing it
12:35:11 <sandro> PROPOSED: Close ISSUE-26 doing nothing.
12:35:12 <NickH> sorry for the inaccuracy
12:35:18 <danbri> q-
12:35:36 <ivan> +1
12:35:38 <cygri> +1
12:35:39 <SteveH> +1
12:35:40 <danbri> +1
12:35:41 <pfps> +0
12:35:41 <AZ> +1
12:35:42 <pchampin> +1
12:35:42 <mbrunati> 1
12:35:43 <gavinc> -0
12:35:43 <cmatheus>cmatheus::+1
12:35:44 <sandro> +0 (I understand)
12:35:44 <webr3> +0
12:35:47 <JFB> +1/3
12:35:51 <davidwood> +0
12:35:57 <mischat> +1
12:36:00 <NickH> Why is marking rdf:ID as archaic more effort than marking XMLLiteral / xsd:String etc archaic?
12:36:05 <FabGandon> +2/3
12:36:07 <sandro> RESOLVED: Close ISSUE-26 doing nothing.
12:36:33 <davidwood> NickH: Because marking rdf:ID as archaic would require a change to the RDF/XML document.
12:36:34 <cmatheus> sandro: rdf:value
12:36:49 <cmatheus> all I can say, mark it as archaic
12:36:51 <danbri> NickH - because those are *vocabulary* constructs which affect the entire ecosystem - rdfa, turtle, json, sparql, owl...
12:37:01 <sandro> SteveH: I like rdf:value
12:37:05 <sandro> Guus: I like it too!
12:37:07 <cmatheus> FabGandon: it's in a best practice note
12:37:26 <LeeF> SCOVO uses rdf:value (for better or for worse)
12:37:26 <NickH> danbri / davidwood thanks
12:37:33 <webr3> I like rdf:value just wish it was defined more clearly
12:37:39 <LeeF> (http://sw.joanneum.at/scovo/schema.html)
12:37:53 <sandro> Guus: In representation of museum data, we annotate with a bnode structure and then use a rdf:value for what's really pointed to.
12:37:54 <cmatheus> guus: example of its use: have things about values such as its dimension
12:38:13 <gavinc> +q Dublin Core also uses it
12:38:13 <danbri> rdf:value was partly from reification, and partly for n-ary -> http://lists.w3.org/Archives/Public/semantic-web/2010Jul/0252.html
12:38:26 <gavinc> +q to talk mention that Dublin Core also uses it
12:38:29 <sandro> guus: Lots of people use this pattern, effectively.
12:38:41 <danbri> it's a bit like toString()
12:38:45 <FabGandon> Note 3 in SWBPWG http://www.w3.org/TR/swbp-n-aryRelations/#sec-notes
12:38:46 <cmatheus> guus: this is a property that points to the value
12:38:54 <cmatheus> it's highly deployed in some communities
12:39:39 <LeeF> Even if it was the most hated thing in the spec, I don't think we ought to deprecate it if it's as widely in use as it appears.
12:39:53 <danbri> re weights-and-measures, http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ uses it for exactly that -- search for <n:units rdf:resource="http://www.nist.gov/units/Pounds"/>
12:39:54 <cmatheus> Steveh: done work with numeric data, want to be able to lterals as subjects in a sense
12:40:00 <yvesr> SteveH, was it signal processign related stuff?
12:40:09 <yvesr> SteveH, had to do the same for this kind of things
12:40:10 <cmatheus> ivan: when you need to add a unit to a value this is perhaps the best way to do it
12:40:16 <sandro> PROPOSED: Close ISSUE-27 doing nothing (not marking rdf:value as archaic).
12:40:20 <gavinc> -q
12:40:21 <pfps> -1
12:40:21 <webr3> +1
12:40:22 <SteveH> yvesr, no, demographics
12:40:23 <cmatheus> danbri: was in the original recommendation for that purpose
12:40:23 <LeeF> +1
12:40:24 <ivan> +1
12:40:26 <gavinc> +1
12:40:30 <AZ> +0
12:40:33 <SteveH> yvesr, but I think it might also be used in LV2
12:40:35 <pchampin> q?
12:40:37 <gavinc> +q to talk mention that Dublin Core also uses it
12:40:39 <davidwood> +1
12:40:40 <cmatheus> cygri: would like evidence on its deployment
12:40:42 <mbrunati> +1
12:40:43 <SteveH> yvesr, for presets and defaults
12:40:55 <FabGandon> +1/2
12:40:58 <cmatheus> pfps: I've seen it. always badly.
12:41:03 <sandro> pfps: Every single case where I've seen it used, it's used badly.
12:41:05 <cmatheus> danbri: how could you tell?
12:41:27 <cmatheus> pfps: there's always a back handed agreement for how it is used
12:41:30 <sandro> pfps: ... where there is a backhanded agreement about what it really means, and where the meaning is really different in every case.
12:41:39 <cmatheus> ivan: this can be done because it is an open ended property
12:41:48 <cmatheus> pfps: destroys the utility of rdf
12:42:00 <cmatheus> rdf:value is used as a local property
12:42:06 <webr3> +1 pfps
12:42:15 <cmatheus> cygri: where used they should have defined a local property
12:42:21 <cmatheus> guus: that's not true
12:42:22 <webr3> it's centered on out of band knowledge about the data
12:42:22 <AZ> +1 cygri
12:42:30 <sandro> cygri: I would argue that every time it's used, a local property should be defined for that.
12:42:37 <cmatheus> rdf:value is for something where we don't have a solution
12:42:56 <cmatheus> steveh: like rdfs:label -- it's a handy thing to have around
12:43:00 <webr3> rdfs:label is a typed link, rdf:value is untyped
12:43:05 <sandro> issue-27
12:43:09 <sandro> issue-27?
12:43:10 <trackbot> ISSUE-27 -- Should we deprecate rdf:value? -- open
12:43:10 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/27
12:43:31 <sandro> http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue
12:43:36 <cmatheus> guus: rdf:label points to a string instead of name and rdf:value points to the value
12:43:48 <cmatheus> same kind of function as rdf:label
12:43:51 <mischat> ?q
12:43:56 <danbri> ±0
12:44:16 <danbri> http://www.w3.org/TR/rdf-schema/#ch_value "rdf:value has no meaning on its own. It is provided as a piece of vocabulary that may be used in idioms such as illustrated in example 16 of the RDF primer [RDF-PRIMER]. Despite the lack of formal specification of the meaning of this property, there is value in defining it to encourage the use of a common idiom in examples of this kind."
12:44:18 <cmatheus> pfps: don't mark it as archaic but realize you're making a bad mistake
12:44:20 <LeeF> Can we put an action to address this in the updated primer?
12:44:22 <danbri> ie. RDFS current encourages its use
12:44:33 <cmatheus> sandro: do you want document to say something about it?
12:44:42 <gavinc> Does Dublin Core do it wrong? http://dublincore.org/documents/dc-rdf-notes/
12:44:54 <cmatheus> pfps: no. every time it's been used its been used badly.
12:45:05 <webr3> pfps +1
12:45:10 <sandro> pfps: Every time I've seen rdf:value it's been bad practice, destroying the "beauty" of RDF.
12:45:19 <webr3> it's like <a href="boo">, untyped
12:45:19 <pchampin> @sandro the example in the RDF primer is a bad one :-( (weight)
12:45:30 <cmatheus> pfps: rdf:value is the same as rdf:thispropertydoesn'tmeana*?/thing
12:45:35 <davidwood> davidwood has joined #rdf-wg
12:45:38 <cmatheus> sandro: is this resolved?
12:45:47 <sandro> pfps: I'm not formally objecting to this proposal.
12:45:59 <Zakim> -Meeting_Room
12:46:00 <webr3> should it a couple of new properties be defined for common uses of rdf:value ..
12:46:03 <gavinc> ah
12:46:08 <gavinc> and there goes the phone
12:46:09 <Steven> zakim, who is noisy?
12:46:10 <cmatheus> cygri: is there some text on good use of rdf:value?
12:46:11 <danbri> q+ to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.
12:46:17 <sandro> Guus: I disagree with Peter's characterization
12:46:22 <Zakim> Steven, listening for 10 seconds I heard sound from the following: gavinc (4%)
12:46:23 <sandro> davidwood: As do I.
12:46:42 <cmatheus> I would disagree with some of the things in the Primer
12:46:45 <sandro> cygri: The use for units of measure is extremely questionable.
12:47:06 <Steven> zakim, code?
12:47:06 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Steven
12:47:08 <cmatheus> there's a lot of work on how to measure units of measure, they come up with different solutions
12:47:13 <gavinc> No, I can not hear.
12:47:35 <cmatheus> Sandro: meeting room got hung up on
12:47:53 <sandro> s/Sandor/Sandro/
12:48:12 <Zakim> +Meeting_Room
12:48:50 <cmatheus> cygri: if you just use rdf:value and have addition properties hanging off of value telling you what the value means, that's bad
12:49:48 <yvesr> :fft rdf:value "..."
12:50:03 <cmatheus> the Primer leads people into bad modeling and we should do something about it
12:50:11 <sandro> cygri: The primer gives bad modeling advice, and I don't like that.
12:50:14 <pchampin> +1 cygri
12:50:16 <yvesr> :fft :derived_from :signal .
12:50:20 <yvesr> all good practice, imho
12:50:21 <cmatheus> guus: we can close this and open a new issue about the Primer
12:50:25 <NickH> yvesr: so avoid repeating very large literal values?
12:50:30 <cmatheus> cygri: okay
12:50:37 <yvesr> NickH, yep
12:50:49 <gavinc> -q
12:50:53 <yvesr> s/yvesr:/yvesr,/
12:51:19 <davidwood> davidwood has joined #rdf-wg
12:51:22 <sandro> PROPOSED: Close ISSUE-27, not marking rdf:value as archaic, but with the understand that the modeling advice in RDF Primer will be revisited.
12:51:26 <yvesr> +1
12:51:28 <ivan> +1
12:51:37 <danbri> q?
12:51:39 <danbri> ack danbri
12:51:39 <Zakim> danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.
12:51:44 <gavinc> +1
12:51:47 <danbri> ahh, i forgot already
12:51:49 <cygri> -0
12:51:59 <davidwood> Dublin Core uses rdf:value in the same manner as the examples in the RDF spec. I think it is therefore compliant.
12:52:00 <AZ> +0
12:52:00 <danbri> action danbri danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.
12:52:00 <trackbot> Created ACTION-33 - Danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value. [on Dan Brickley - due 2011-04-21].
12:52:05 <pchampin> +1
12:52:27 <cmatheus> sandro: can put an Action on Richard to review primer
12:52:58 <cmatheus> cygri: I think there is a technical issue about a bug in the rdf Primer about advice on use of rdf:value
12:53:23 <cmatheus> guus: could result in Primer ignoring rdf:value
12:53:33 <sandro> RESOLVED: Close ISSUE-27, not marking rdf:value as archaic, but with the understand that the modeling advice in RDF Primer will be revisited.
12:54:17 <cmatheus> sandro: only plan to spend another 35 minutes here
12:54:28 <cmatheus> those were all the ones marked as Archic
12:54:43 <cmatheus> s/Archic/Archaic/
12:54:43 <FabGandon> issue-6?
12:54:43 <trackbot> ISSUE-6 -- Handling RDF Errata -- open
12:54:43 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/6
12:55:03 <FabGandon> issue-7?
12:55:04 <trackbot> ISSUE-7 -- Leftover issues from the RDF Core WG -- open
12:55:04 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/7
12:55:12 <cmatheus> ivan: issue 6: handling of Errata
12:55:14 <mischat> http://www.w3.org/2001/sw/RDFCore/errata
12:55:29 <cmatheus> we have to have a mechanism not to forget these
12:55:30 <davidwood> davidwood has joined #rdf-wg
12:55:38 <mischat> this related to danbri's suggestion of going through the archives
12:55:46 <mischat> s/related/relates/
12:56:01 <cmatheus> nothing earthshakingly major
12:56:24 <cmatheus> issue-7: some issues left open from previous working group
12:56:24 <trackbot> ISSUE-7 Leftover issues from the RDF Core WG notes added
12:56:45 <mischat> http://www.w3.org/2000/03/rdf-tracking/#/%23futures
12:56:53 <cmatheus> danbri: brief comment on list
12:57:07 <cmatheus> some were engineering hacks, left for next group
12:57:20 <webr3> +1
12:57:21 <cmatheus> ivan: we still need to go through them
12:57:34 <cmatheus> davidwood: propose a telecom to discuss these
12:57:40 <yvesr> http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects :)
12:57:47 <cmatheus> pfps: someone should go through them ahead of time
12:57:59 <cmatheus> davidwood: I volunteer to do that
12:58:17 <cmatheus> ivan: IRI versus URI story
12:58:18 <sandro> ACTION: wood prepare resolutions to dispose of each of the leftover items, http://www.w3.org/2000/03/rdf-tracking/#/%23futures
12:58:18 <trackbot> Created ACTION-34 - Prepare resolutions to dispose of each of the leftover items, http://www.w3.org/2000/03/rdf-tracking/#/%23futures [on David Wood - due 2011-04-21].
12:58:25 <cmatheus> frankly I am lost with the details
12:58:53 <gavinc> Jeremy had something on what needed to be updated with the IRIs, but I seem to have miss placed it.
12:58:54 <cmatheus> Andy and Eric know a lot about that
12:58:59 <FabGandon> issue-8?
12:58:59 <trackbot> ISSUE-8 -- Incorporate IRI-s into the RDF documents -- open
12:58:59 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/8
12:59:40 <cmatheus> sandro: we want to look at every where we say something about URI and replace it with IRI
12:59:53 <ivan> The IRI Spec[1] is from 2005, and it may be necessary to retrofit it to RDF. Eg, what is the relationship between "http://xn--rsum-bpad.example.org/" and "http://xn--rsum-bpad.example.org/"? Are they the same resource or not? Note that SPARQL has something on that[2]...
13:00:39 <gavinc> Jeremy thought there were a few when we spoke about it. But again, I've missplaced the record of that conversation
13:00:51 <sandro> "http://résumé.example.org" and "http://xn--rsum-bpad.example.org"?
13:01:03 <cmatheus> ivan: (showing on the screen an issue with url's in irc)
13:01:37 <cmatheus> are the displayed iri's refereing to same resource or not?
13:02:10 <cmatheus> cygri: two iri's are identifcal if the characters are the same, except in a number of cases...
13:02:24 <cmatheus> s/identifcal/identical/
13:02:25 <davidwood> q+
13:02:58 <cmatheus> the one uri can be normalized into the other
13:03:25 <cmatheus> guus: if it's a problem we can flag it but's it's not in the realm of where we should go
13:03:44 <mischat> http://www.w3.org/TR/sparql11-query/#syntaxTerms
13:03:47 <cmatheus> mischat: if we go this way we will need to have best practise note on this
13:03:53 <cmatheus> sandro: example?
13:03:55 <sandro> mischat: back-tick is valid in URI-References but not IRIs.
13:04:08 <cmatheus> mischat: a back tick. caused our app to go down.
13:04:25 <cmatheus> davidwood: I've seen issues with that, I think it was with back tick.
13:04:36 <gavinc> for reference, IRI spec: http://www.ietf.org/rfc/rfc3987
13:04:46 <cmatheus> guus: objet to description of issues -- it's outside of scope
13:05:11 <pchampin> from the charter (required section): Clarify the usage of IRI references for RDF resources
13:05:18 <cmatheus> mischat: rdf group was guessing at what iris would look like
13:05:32 <cmatheus> davidwood: issue from implementation standdpoint
13:05:50 <ivan> q+
13:06:00 <cmatheus> when trying to index rdf, if you have to do a lot of checking, implementers will screem, Talis for one.
13:06:00 <ivan> ack davidwood
13:06:27 <cmatheus> if we said an iri and uri were equivalent that would cause serious practical problems
13:06:43 <cmatheus> steveH: I understand what you're saying but don't understand the technical problem
13:07:04 <gavinc> +q
13:07:15 <cmatheus> davidwood: when ingesting rdf you must say whether this uri is equivalent to some other uri's in your system
13:07:15 <sandro> SteveH: Every triplestore I know just uses utf-8, so the question is which chars are allowed.
13:07:29 <cmatheus> steveh: it just changes your grammar
13:07:35 <cmatheus> davidwood: you may be right
13:07:42 <cmatheus> SteveH: I'm pretty sure I am
13:07:43 <ivan> ack davidwood
13:07:47 <sandro> SteveH: SPARQL says they have to be the same normalized utf-8 byte string.
13:07:50 <mischat> q+
13:07:54 <cmatheus> davidwood: I'm talking about in SPARQL
13:08:00 <cmatheus> the specs say different things
13:08:07 <cmatheus> cygri: I don't think they do
13:08:23 <cmatheus> in RDF world things are conistent
13:08:37 <cmatheus> s/sconistent/consistent/
13:08:51 <mischat> i don't think they are consistent, you can a SPARQL INSERT triples which you cant CONSTRUCT as valid RDF/XML
13:08:55 <cmatheus> there's no way you can align this with the rest of the web architecture
13:09:08 <SteveH> mischat, no you cant
13:09:08 <cmatheus> but can give recommendations.
13:09:16 <SteveH> mischat, oh, wait, not maybe that's right
13:09:18 <sandro> cygri: We can (and should) give recommendations to publishers about how to mint URIs to avoid these problems, like don't say :80 and dont use uppercase URI scheme or host names.
13:09:22 <mischat> it is right SteveH
13:09:26 <cmatheus> if you avoid certain things then you will get same result
13:09:32 <davidwood> correction: I was *not* talking about SPARQL, but Turtle or other forms of ingesting into a store, and then only in the case where we decided that a given IRI was equivalent to a different character string URI.
13:09:35 <cmatheus> worth writing up as an aid to users of rdf
13:09:51 <davidwood> q?
13:09:52 <cmatheus> ivan: this discussion went beyond what I intended
13:09:57 <davidwood> ack ivan
13:10:38 <cmatheus> but look what happend when we just but the same iri's through two different systems and got very different results
13:10:48 <cmatheus> this is something we need to address
13:10:49 <gavinc> I think the section in question is: http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref
13:10:56 <cmatheus> guus: this is not something we're going to solve
13:11:12 <mischat> this is the IRI RFC http://www.ietf.org/rfc/rfc3987.txt
13:11:19 <gavinc> The RFC lists a set of normalization methods http://www.ietf.org/rfc/rfc3987
13:11:29 <cmatheus> ivan: why? there is a document that says how to implement a system that will do the right thing
13:11:45 <Guus> q?
13:11:46 <cmatheus> davidwood: what is the sate of iri's in the standard (RC)
13:11:58 <cmatheus> cygri: it's implemented in all browsers
13:12:19 <davidwood> ack gavinc
13:12:24 <cmatheus> davidwood: that's different from the state of the standard
13:13:01 <cmatheus> gavinc: we went through this a month ago but I can't find the work we did -- not sure if it got lost in the shuffle
13:13:15 <cmatheus> we didn't think the spec was as brioken as some of the people are saying
13:13:22 <cmatheus> sorry, I don't remember the details
13:13:36 <sandro> davidwood, it's a PROPOSED STANDARD, per http://www.rfc-editor.org/rfcxx00.html#STDbySTD
13:13:48 <sandro> (like almost everything)
13:14:17 <cmatheus> mischat: the issue I have is I can issert certain triples, with content with a back tick, and then retrive it and I get something different.
13:14:50 <cmatheus> ivan: there are cetrtain charcters that you cannot put into a xml doc, but in turtle it would not be a problem
13:14:54 <sandro> (although URI RFC-3986 is actually a "STANDARD" STD-66 )
13:15:05 <cmatheus> pfps: turtle is currently stuck at uri's
13:15:45 <Guus> q?
13:15:54 <cmatheus> gavinc: I don't think turtle is cemented to uris
13:16:03 <davidwood> IRIs seem to be an IETF standards-track (but not standard) RFC (3987), which does not expire. There is a newer proposal, which will expire in Sep 2011 (https://datatracker.ietf.org/doc/draft-ietf-iri-3987bis/)
13:16:07 <cmatheus> gramar refers to iris
13:16:08 <Guus> ack mischat
13:16:37 <cmatheus> sandor: we should revisit this when Eric and Andy (perhaps Jeremy) are around
13:16:43 <cmatheus> ivan: issue 9
13:16:54 <sandro> s/sandor/sandro/
13:17:01 <cmatheus> small thing for Pat and Peter from der Horst
13:17:04 <cygri> davidwood: that's the same as the URI RFC
13:17:18 <cmatheus> an obvious thing that the editor has to take care of
13:17:30 <cmatheus> issue 11, more complicated
13:17:40 <davidwood> davidwood has joined #rdf-wg
13:18:19 <cmatheus> docs published by other wg's that extended the rdf semantics or contained elements related to rdf semantics
13:18:45 <cmatheus> implementors focusing on rdf have to visit all docs
13:19:07 <cmatheus> rdf plain literal added vocabulary
13:19:32 <cmatheus> POWDER likewise
13:19:46 <FabGandon> issue-11?
13:19:46 <trackbot> ISSUE-11 -- Reconciliation of various, semantics-oriented documents with the core RDF ones -- open
13:19:46 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/11
13:20:14 <cmatheus> SPARQL 1.1 has Entailment Regimes
13:20:25 <cmatheus> something we should look at
13:20:36 <cmatheus> guus: is there anything we need to do now
13:20:36 <danbri> ( @davidwood, i made a first cut at suggesting closure of the old RDFCore issues: http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0317.html )
13:20:42 <cmatheus> ivan: probably not
13:20:56 <cmatheus> guus: let's leave this open but ensure it gets resolved
13:21:07 <cmatheus> ivan: string literals handled
13:21:31 <cmatheus> xml literals discussed and still open
13:21:36 <cmatheus> that's all
13:23:31 <cmatheus> ivan: (discussion about POWDER extension to rdf schema...)
13:24:10 <cmatheus> guus: bad idea that there are many different groups dealing with these issues
13:25:22 <cmatheus> ivan: not proposing to do any extra work -- need to make references to the other sources of relevant information
13:25:45 <cmatheus> guus: if we need to do more than references than this needs to be handled at a higher organizational level
13:26:16 <cmatheus> guus: suggest 20 minute break
13:26:20 <davidwood> davidwood has joined #rdf-wg
13:26:40 <cmatheus> in final session. short planning round for next F2F
13:26:52 <cmatheus> will come back and discuss document set
13:27:11 <cmatheus> and candidate docs
13:27:13 <davidwood> danbri: Thanks. That list is very helpful. I'll start with your list and see if I have any different ideas. I plan to add that discussion to the agenda for next Wed.
13:27:21 <Zakim> -webr3
13:27:38 <gavinc> ?
13:27:42 <gavinc> I heard my name?
13:28:00 <Zakim> -AlexHall
13:28:07 <gavinc> or not ;)
13:33:58 <manu> manu has joined #rdf-wg
13:36:25 <mischat> this is the excerpt from the IRI rfc which highlights my issue with roundtripping RDF
13:36:26 <mischat> http://pastebin.com/ZiQHQ2ab
13:39:42 <Zakim> +zwu2
13:40:07 <zwu2> zwu2 has joined #rdf-wg
13:42:26 <zwu2> zwu2 has joined #rdf-wg
13:48:11 <Zakim> + +1.443.212.aacc
13:48:18 <FabGandon> I wonder if it wouldn't be an easyer position to consider that every IRI loaded in a triple store is first turned into its ASCII version and then treated as the URI before including the character by character comparison.
13:48:50 <AlexHall> zakim, +1.443.212.aacc is me
13:48:50 <Zakim> +AlexHall; got it
13:49:25 <gavinc> No, the spec is already clear that URIs are unicode
13:49:44 <gavinc> "A URI reference within an RDF graph (an RDF URI reference) is a Unicode string"
13:50:40 <mbrunati> mbrunati has joined #rdf-wg
13:50:46 <cygri> scribe: cygri
13:50:51 <cygri> scribenick: cygri
13:50:53 <FabGandon> still we could have the transformation before and always work on the transformed version, no?
13:51:04 <zwu2> zakim, mute me
13:51:04 <Zakim> zwu2 should now be muted
13:51:24 <cygri> Topic: Next F2F meeting
13:52:08 <cygri> guus: there's pressure towards balance between european and north american locations
13:52:01 <cygri> LeeF: I'd recommend considering the sort of 2-site w/ video conference F2F that has been successful for SPARQL WG.
13:52:15 <cygri> ... The problem is that for time zones that only really works for US East Coast + UK (or so)
13:52:23 <cygri> ivan: W3C will have technical plenary week
13:52:33 <cygri> ... where several WGs meet
13:52:32 <cygri> ... http://www.w3.org/2011/11/TPAC/
13:52:45 <cygri> ... Santa Clara Marriott, Santa Clara, California, (Silicon Valley) USA 31 October to 4 November 2011
13:52:48 <Souri> Souri has joined #rdf-wg
13:53:10 <cygri> ... I try to convince the RDF apps WG to have their F2F there
13:53:38 <cygri> ... downside is that it's the week after ISWC
13:54:09 <cygri> davidwood: we might want to have the F2F meetings earlier rather than later
13:54:47 <cygri> ivan: july/august not a good time for europeans
13:54:54 <MacTed> MacTed has joined #rdf-wg
13:56:31 <cygri> guus: suppose we would do it at TPAC, for whom would that be an obstacle?
13:57:17 <cygri> SteveH: time difference is a problem
13:58:09 <cygri> davidwood: I question whether we should have a west coast f2f
13:57:47 <gavinc> Sigh.
13:58:11 <cygri> zwu2: CA in US sounds great
13:58:26 <cygri> sandro: how about right before ISWC?
13:59:03 <Zakim> + +1.603.897.aadd
13:59:31 <Souri> zakim, aadd is me
13:59:31 <Zakim> +Souri; got it
13:59:57 <cygri> ivan: other WGs: sparql, rdb2rdf, provenance, government linked data
14:00:05 <zwu2_> zwu2_ has joined #rdf-wg
14:00:38 <cygri> steveh: east coast much easier than west coast
14:00:54 <cygri> sandro: i'm happy to host at W3C, if i can find a room
14:01:02 <cygri> s/W3C/MIT/
14:01:17 <cygri> pfps: happy to host at bell labs
14:01:56 <cygri> guus: so, east coast location, 1st half of october?
14:02:21 <cygri> pfps: better earlier, end of september (more distance to tpac)
14:02:44 <cygri> guus: week of 26th september?
14:02:54 <cygri> SteveH: clash with SemTech London
14:03:11 <cygri> FabGandon: week of 12th of september?
14:04:03 <cygri> SteveH: we could host at Garlik
14:04:16 <cygri> pfps: find someone at oxford?
14:06:11 <cygri> guus: week of 3rd october, boston?
14:06:33 <cygri> sandro: remote participants, are you likely to be able to make this?
14:04:18 <cygri> gavinc: MIT sounds better then Europe
14:06:16 <cygri> ... TPAC sounds the best still
14:06:57 <cygri> ... I can travel if it's in the US; europe less likely
14:06:25 <danbri> (I don't know what I can attend nor where, but prefer east coast as most plausible)
14:07:04 <sandro> zakim, who is on the call?
14:07:04 <Zakim> On the phone I see gavinc, LeeF, AZ, Meeting_Room, zwu2 (muted), AlexHall, Souri
14:07:12 <cygri> LeeF: Yes
14:07:44 <cygri> ... Possibly if it were scheduled with our input :)
14:07:57 <cygri> ... The challenge this time was the date being picked without input, and hving existingcommitments
14:07:13 <cygri> Souri: East Coast is the best for me. Europe is doubtful.
14:07:19 <zwu2_> zakim, unmute me
14:07:19 <Zakim> sorry, zwu2_, I do not know which phone connection belongs to you
14:07:20 <davidwood> davidwood has joined #rdf-wg
14:07:58 <cygri> davidwood: to the remote americans: would you be able to come to a f2f in europe in the future?
14:08:00 <cygri> zwu2: CA is fine. East coast will do too
14:08:06 <cygri> AlexHall: No, I don't anticipate being able to travel to Europe
14:08:17 <cygri> souri: east cost is best, europe problematic
14:08:29 <cygri> AZ: I don't know if will be able to come to the US
14:08:40 <cygri> ... My situation after August is quite unclear
14:08:56 <cygri> davidwood: this tells me we should alternate meetings between europe and US
14:09:04 <cygri> ivan: tpac still best
14:09:37 <cygri> guus: i'll set up a poll
14:09:59 <cygri> Souri: We had a very good setup for SPARQL f2f last time using video connections between Cambridge/MIT and Oxford.
14:10:21 <cygri> ACTION: guus to set up poll regarding F2F date
14:10:21 <trackbot> Created ACTION-35 - Set up poll regarding F2F date [on Guus Schreiber - due 2011-04-21].
14:10:26 <cygri> gavinc: 2 video remote sites would also be excellent
14:11:59 <cygri> guus: options will be: US east cost: Boston or Murray Hill
14:12:07 <cygri> ... and TPAC
14:12:29 <zwu2_> is CA a choice at all?
14:13:00 <gavinc> CA, US ... not CA Canada
14:12:53 <gavinc> well
14:12:43 <gavinc> TPAC is CA
14:13:11 <zwu2_> yes CA, US
14:12:40 <cygri> Topic: Scribing
14:12:53 <cygri> sandro: would be helpful if scribes could use topics and subtopics
14:12:53 <cygri> (IRC commands for scribe are “Topic: xyz” and “Subtopic: xyzxyz”)
14:13:10 <mischat> http://www.w3.org/2011/rdf-wg/meeting/2011-04-13 and http://www.w3.org/2011/rdf-wg/meeting/2011-04-14
14:14:19 <cygri> Topic: RDF document set and finding editors
14:14:29 <cygri> guus: this was on telecon agenda for a long time
14:14:43 <cygri> ... strong preference for not creating completely new set of docs
14:14:50 <cygri> ... but update the existing RDF Core documents
14:15:03 <cygri> ... have new editors and update these documents
14:15:25 <cygri> sandro: seems to depend on how big the changes are
14:15:49 <cygri> guus: for instance RDF Concepts would have to add sections on terminology and other things
14:16:04 <cygri> ... hopefully not too many changes to RDF Semantics
14:16:11 <davidwood> davidwood has joined #rdf-wg
14:16:12 <cygri> ... primer should be completely new rewritten version
14:16:19 <cygri> ... test cases we have to see
14:16:51 <cygri> ivan: test cases were REC in 2004. i don't see why they should be
14:17:16 <cygri> .. formally, would that mean we re-use the same short names?
14:17:31 <cygri> ... so would they formally be new versions of the same documents?
14:18:30 <cygri> cygri: we should use the same short names to avoid having multiple REC documents floating around
14:18:35 <cygri> ivan: what does SPARQL do?
14:18:36 <Zakim> -AZ
14:18:48 <cygri> steveh: (scribe got lost. not yet decided?)
14:18:57 <Zakim> +AZ
14:19:15 <cygri> guus: good guideline: substantial changes => new short name
14:19:28 <cygri> steveh: in SPARQL isn't decided yet
14:19:43 <cygri> sandro: OWL rewrote everything and new short names
14:19:50 <cygri> davidwood: that was not a good idea
14:20:07 <cygri> guus: i don't hear objections, so let's work on that assumption
14:20:16 <sandro> sandro: sounds like we're just talking about 2nd editions of Recs, not new Recs.
14:20:40 <cygri> Subtopic: RDF Concepts
14:20:41 <cygri> guus: these are lots of documents
14:21:01 <cygri> ... RDF Concepts. main change will be graph terminology
14:21:40 <cygri> ivan: and archaization? and XMLLiteral?
14:22:37 <cygri> cygri: i can be editor on that one
14:22:41 <cygri> davidwood: me too
14:22:41 <sandro> guus: eds, Richard and David
14:22:45 <cygri> Subtopic: RDF Semantics
14:22:48 <cygri> guus: RDF Semantics
14:23:29 <cygri> ... ideal would be pfps and PatH
14:23:35 <cygri> pfps: ok
14:23:35 <Zakim> -AZ
14:23:40 <sandro> ACTION: guus to ask Pat to be an editor of RDF Semantics
14:23:41 <trackbot> Created ACTION-36 - Ask Pat to be an editor of RDF Semantics [on Guus Schreiber - due 2011-04-21].
14:24:00 <cygri> Subtopic: RDF Schema
14:24:15 <cygri> guus: RDF Schema
14:24:29 <sandro> Guus: DanBri, will you edit RDF Vocab?
14:24:36 <cygri> danbri: ok
14:24:45 <cygri> sandro: can we change the name to "RDF Schema"?
14:24:57 <sandro> ISSUE: Should we change the title of rdf-schema to use the word "Schema" ?
14:24:57 <trackbot> Created ISSUE-36 - Should we change the title of rdf-schema to use the word "Schema" ? ; please complete additional details at http://www.w3.org/2011/rdf-wg/track/issues/36/edit .
14:25:00 <cygri> Subtopic: Turtle Syntax
14:25:31 <cygri> guus: Turtle
14:25:39 <cygri> ivan: EricP has volunteered to do that
14:26:38 <cygri> mischat: i'm willing to help but might not be able to help much with syntax/grammar
14:27:00 <cygri> ivan: amount of work on turtle might not be much
14:27:13 <cygri> gavinc: I'd be happy to provide test cases?
14:28:43 <cygri> mischat: i'll take it into consideration. if andy wants do do it, i won't feel bad
14:29:02 <cygri> guus: we need to publish FPWDs soon. turtle obvious candidate
14:29:56 <cygri> ... mid-june should be doable
14:27:19 <danbri> I guess the concept we're going for is "2nd Edition" for most of these? sandro/ivan - is that defined in http://www.w3.org/2005/07/pubrules somewhere?
14:27:45 <sandro> danbri, yes.
14:28:11 <sandro> danbri, I've never done it myself, but I've seen it.
14:30:00 <cygri> Subtopic: N-Triples Syntax
14:30:32 <cygri> guus: possible other documents: n-triples
14:31:08 <cygri> sandro: n-triples might be appendix of turtle, or appendix of test cases
14:31:15 <Steven> Steven has joined #rdf-wg
14:31:21 <cygri> guus: might be a separate piece of work anyways
14:31:29 <cygri> ... spread out the responsibilities
14:31:58 <cygri> mischat: AndyS's page http://www.w3.org/2011/rdf-wg/wiki/N-Triples-Format
14:32:01 <cygri> cygri: andy did a wiki page on n-triples
14:33:06 <zwu2_> zakim, unmute me
14:33:06 <Zakim> sorry, zwu2_, I do not know which phone connection belongs to you
14:34:00 <cygri> sandro: zwu2, can you be ed of n-triples to make sure nothing bad happens to it?
14:34:02 <cygri> zwu2: i can do that
14:34:08 <zwu2_> zakim, who is here
14:34:09 <Zakim> zwu2_, you need to end that query with '?'
14:34:14 <zwu2_> zakim, who is here?
14:34:14 <Zakim> On the phone I see gavinc, LeeF, Meeting_Room, zwu2, AlexHall, Souri
14:34:20 <sandro> sandro: does it matter to you, Zhe, whether you are credited as an editor for that work?
14:34:27 <sandro> Zhe: I'm okay either way there.
14:35:21 <cygri> Souri: I can help on the n-triples -- my org (Oracle) has heavy investment on n-triples
14:34:48 <danbri> (asking informally, I'm told that "Second Editions" typically get their own short-name in /TR/ --- but to check with the webmaster team)
14:35:22 <cygri> Subtopic: RDF/JSON
14:35:23 <cygri> guus: json
14:35:24 <cygri> davidwood: i'll take an action to ask talis about a possible editor for the json rdf-to-rdf thing
14:35:28 <ivan> zakim, who is here?
14:35:28 <Zakim> On the phone I see gavinc, LeeF, Meeting_Room, zwu2, AlexHall, Souri
14:35:43 <zwu2_> q-
14:36:01 <cygri> cygri: souri just volunteered to help on n-triples
14:36:15 <cygri> guus: anyone else for rdf/json?
14:36:33 <cygri> ivan: only other person i can think of is tomayac
14:36:47 <sandro> action: wood to ask Talis to provide an editor for JSON
14:36:47 <trackbot> Created ACTION-37 - Ask Talis to provide an editor for JSON [on David Wood - due 2011-04-21].
14:36:56 <cygri> ... asking him would be a good idea
14:37:13 <cygri> action: ivan to ask thomas about RDF/JSON editorship
14:37:13 <trackbot> Created ACTION-38 - Ask thomas about RDF/JSON editorship [on Ivan Herman - due 2011-04-21].
14:38:00 <cygri> Subtopic: JSON Recipes Note
14:38:10 <cygri> guus: JSON recipes note
14:38:43 <cygri> ... we had some volunteers: mishat, NickH, mbrunati
14:38:50 <cygri> ... and i'll volunteer one of my postdocs
14:38:58 <cygri> yvesr: i want to contribute to that note as well
14:39:28 <cygri> s/mishat/mischat/
14:39:35 <cygri> Subtopic: RDF Primer
14:39:37 <cygri> guus: rdf primer
14:39:42 <cygri> ... i volunteer
14:39:54 <cygri> LeeF: I would like to devote time to the rdf primer, though not necessarily as an editor.
14:39:59 <cygri> FabGandon: me
14:40:05 <cygri> pchampin: me
14:40:18 <cygri> cmatheus: me
14:40:56 <cygri> ivan: we need one, max two people to lead it, and perhaps a larger number of contributors
14:43:03 <mischat> :)
14:43:27 <davidwood> davidwood: Guus and Fabian to edit the Primer, with many contributors expected.
14:43:39 <cygri> cygri: so primer will have guus, FabGandon as lead editors, with possibly many contributors
14:44:00 <cygri> Subtopic: TriG/N-Quads Syntax
14:45:45 <cygri> cygri: on TriG/N-Quads, probably not a new doc but part of turtle ... i can help there
14:46:00 <cygri> Subtopic: RDF/XML Syntax
14:46:16 <cygri> ivan: RDF/XML ... we may not touch it at all, but might want to check with henry
14:47:33 <cygri> sandro: henry made clear that he won't do the RDF/XML work himself
14:47:48 <cygri> ... are there errata against RDF/XML?
14:48:24 <cygri> FabGandon: i'm happy to apply the errata
14:46:18 <zwu2_> I don't hate rdf/xml at all
14:46:52 <zwu2_> I just don't write manually in rdf/xml much
14:46:59 <mischat> i am a bit of a fan, it has the most robust tooling
14:47:10 <mischat> i dont like writing any rdf by hand
14:47:27 <sandro> I happily misread that, mischat, as the most robust trolling.
14:47:42 <AlexHall> the problem with rdf/xml is when newcomers confuse the xml syntax with the rdf semantics
14:47:48 <danbri> (btw re Turtle, http://www.w3.org/DesignIssues/N3Alternatives might be interesting)
14:49:44 <yvesr> AlexHall, and people using xpath on rdf/xml
14:49:52 <yvesr> caused us so much problems at the BBC
14:50:06 <yvesr> you change serialiser, and you end up breaking applications
14:50:09 <zwu2_> tricky to use xpath I guess
14:50:32 <yvesr> maybe an xpath-able version of rdf/xml would be in order? don't know though...
14:50:33 <gavinc> zwu, tricky is an understatement
14:50:40 <zwu2_> :)
14:51:38 <AlexHall> yvesr, it's in the charter as a time-permitting feature
14:49:00 <cygri> Subtopic: Tools for editors
14:49:56 <davidwood> q?
14:50:23 <cygri> danbri: practicalities around CVS access? use mercurial?
14:50:58 <cygri> sandro: four options: 1. edit xhtml in cvs; 2. use xmlspec
14:51:10 <danbri> w3c mercurial repo: https://dvcs.w3.org/hg/
14:51:48 <cygri> ... 3. respec (an html5 and js thing)
14:50:48 <danbri> danbri: http://dev.w3.org/2009/dap/ReSpec.js/documentation.html
14:52:28 <cygri> ivan: respec works well for me
14:53:21 <cygri> ... only downside: we have to transform old docs into respec. initial price.
14:53:34 <pchampin> pchampin: the Media Annotation WG uses respec for the API document
14:53:41 <pchampin> pchampin: http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html
14:53:53 <cygri> sandro: 4th option: use the wiki. there's a script to put stuff from xhtml into the wiki, and another for the way back
14:54:12 <danbri> I was thinking more about the testcases repository (as a consensus documentation tool / decision record) -> should that be w3c cvs datespace again, or mercurial?
14:55:21 <cygri> ivan: (more respec advocacy)
14:55:51 <cygri> sandro: if we don't use my code, i won't do the pubs
14:55:59 <cygri> FabGandon: upside of using the wiki: no cvs
14:56:11 <cygri> ivan: downside is that ppl hate wiki markup
14:56:34 <cygri> sandro: i should look at respec and look at how it handles [something]
14:56:38 <sandro> ACTION: sandro look at respec's handling of references
14:56:38 <trackbot> Created ACTION-39 - Look at respec's handling of references [on Sandro Hawke - due 2011-04-21].
14:57:05 <cygri> SteveH: don't use xmlspec
14:57:36 <cygri> ... especially if only small changes, just do them in xht�ml
14:58:10 <mischat> mischat: votes for a distributed version control system instead of a centralised one
14:59:17 <Souri> Souri: based upon my R2RML editing experience: +1 for option 1 (edit xhtml in cvs); +0.5 for option 4 (wiki)
14:57:35 <danbri> so should RDFS spec be in HTML/RDFa? if so, which vocabulary terms should it include RDF claims about? rdf+rdfs?
14:59:19 <danbri> http://www.w3.org/blog/systeam/2010/06/16/why_we_chose_mercurial_as_our_dvcs/
14:59:20 <cygri> Topic: AOB
14:59:59 <sandro> sandro: (discussion of whether emacs can reify skolemized bnodes....)
15:00:03 <yvesr> yvesr: (in rdf/xml...)
15:02:01 <Zakim> -gavinc
15:02:02 <sandro> Bye remote folks!
15:02:06 <zwu2_> bye and have a safe trip home!
15:02:17 <manu> Have a safe trip back home to everyone there - :)
15:02:31 <Zakim> -zwu2
15:02:38 <AlexHall> AlexHall has left #rdf-wg
15:02:39 <Zakim> -AlexHall
15:02:46 <cygri> guus: adjourned
15:02:57 <cygri> trackbot, generate minutes
15:02:57 <trackbot> Sorry, cygri, I don't understand 'trackbot, generate minutes'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
15:03:11 <cygri> RRSAgent, generate minutes
15:03:11 <RRSAgent> I have made the request to generate http://www.w3.org/2011/04/14-rdf-wg-minutes.html cygri
15:03:14 <Zakim> -Souri
15:03:54 <Zakim> -LeeF
# SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00001723
</nowiki></pre>

Chatlog 2011-04-14

Fgandon — Sun, 17 Apr 2011 13:57:17 GMT

Fgandon:

{{chatlog|rrsagent=http://www.w3.org/2011/04/14-rdf-wg-irc.txt|chatlog={{fullurl:{{PAGENAME}}}}}}
<pre><nowiki>
<sandro> Guest: Paul Groth
<sandro> Guest: Steven Pemberton
<sandro> Present: Ivan, Mischa, Dan_Brickley, Matheus, Peter, Jan, Baget, Humfrey, Yves, Cygri, Champin, Fabien, Steve, Matteo, Sandro, Wood, Guus
<sandro> Remote: AZ, Gavin, Zhe, Corby, MacTed, Pat, Tom, AlexHall, webr3, LeeF, manu, souri
02:28:54 <MacTed> MacTed has joined #rdf-wg
05:17:45 <mbrunati> mbrunati has joined #rdf-wg
05:21:57 <mbrunati> mbrunati has joined #rdf-wg
05:22:16 <mbrunati> mbrunati has left #rdf-wg
06:21:58 <pgroth> pgroth has joined #rdf-wg
06:47:46 <pgroth_> pgroth_ has joined #rdf-wg
06:51:46 <tomlurge> tomlurge has joined #rdf-wg
07:11:44 <danbri> danbri has joined #rdf-wg
07:13:25 <OlivierCorby> OlivierCorby has joined #rdf-wg
07:18:50 <FabGandon> FabGandon has joined #rdf-wg
07:20:56 <ivan> ivan has joined #rdf-wg
07:21:03 <tomayac> tomayac has joined #rdf-wg
07:21:55 <tomayac> bonjour monsieur!
07:24:23 <pgroth> pgroth has joined #rdf-wg
07:30:32 <AZ> AZ has joined #rdf-wg
07:31:34 <mbrunati> mbrunati has joined #rdf-wg
07:32:13 <pchampin> pchampin has joined #rdf-wg
07:33:17 <tomayac> "the conference is restricted at this time" => have the dial-in details changed? using rdfwg1# code
07:34:05 <FabGandon> should work but we haven't called yet and a number of participants are still missing in the room
07:34:26 <tomayac> 9:30 sharp-ish ;-)
07:34:27 <PatH> PatH has joined #rdf-wg
07:39:52 <Guus> Guus has joined #rdf-wg
07:40:04 <SteveH> SteveH has joined #rdf-wg
07:40:19 <Steven_> Steven_ has joined #rdf-wg
07:40:29 <Steven_> zakim, list
07:40:29 <Zakim> I see SW_RDFWG(RDFWG1)2:00AM active and no others scheduled to start in the next 15 minutes
07:40:43 <mischat> mischat has joined #rdf-wg
07:40:49 <FabGandon> we will have to do an adhoc teleconf the teleconf chanel is not available for today
07:41:10 <pfps> pfps has joined #rdf-wg
07:41:13 <Steven_> zakim, code?
07:41:13 <Zakim> the conference code is 733941 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Steven_
07:41:38 <FabGandon> trying again...
07:41:39 <cmatheus> cmatheus has joined #rdf-wg
07:41:40 <Steven_> zakim, who is on the call?
07:41:40 <Zakim> On the phone I see OlivierCorby, OlivierCorby.a, OlivierCorby.aa, OlivierCorby.aaa
07:41:41 <cygri> cygri has joined #rdf-wg
07:41:55 <davidwood> davidwood has joined #rdf-wg
07:42:13 <PatH> Same message here
07:42:23 <tomayac> same here
07:42:45 <davidwood> We're working on it - please stand by
07:42:56 <Steven_> zakim, room for 15 for 600 minutes?
07:42:58 <Zakim> ok, Steven_; conference Team_(rdf-wg)07:42Z scheduled with code 26631 (CONF1) for 600 minutes until 1742Z
07:43:06 <davidwood> We'll announce a new dial in code shortly
07:43:12 <FabGandon> dial 26631
07:43:18 <davidwood> PLEASE USE CONFERENCE CODE 26631
07:43:35 <Steven_> Steven_ has changed the topic to: CODE is 26631
07:43:41 <davidwood> Sorry for the confusion. Our bridge was not configured as we expected.
07:44:04 <Steven_> zakim, who is on the call?
07:44:04 <Zakim> On the phone I see OlivierCorby, OlivierCorby.a, OlivierCorby.aa, OlivierCorby.aaa
07:44:21 <NickH> Good Morning!
07:44:25 <Steven_> zakim, this is rdf-wg
07:44:25 <Zakim> Steven_, this was SW_RDFWG(RDFWG1)2:00AM
07:44:27 <Zakim> ok, Steven_; that matches Team_(rdf-wg)07:42Z
07:44:33 <Steven_> zakim, who is on the call?
07:44:34 <Zakim> On the phone I see Meeting_Room, PatH, tomayac, OlivierCorby
07:44:40 <OlivierCorby> Hi, phone is ok now
07:44:48 <Zakim> +AZ
07:45:46 <PatH> Sound quality is rather poor today
07:45:50 <FabGandon> scribe: Fabien
07:46:31 <gavinc> gavinc has joined #rdf-wg
07:46:40 <FabGandon> guus: identifying the 4 issues to be discussed
07:46:50 <Steven> 30, 31, 15
07:46:51 <FabGandon> ... 5 30 31 and 15
07:46:57 <gavinc> zakim, the code is?
07:46:57 <Zakim> I don't understand your question, gavinc.
07:47:01 <JFB> JFB has joined #rdf-wg
07:47:03 <Steven> zakim, code?
07:47:03 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Steven
07:47:32 <FabGandon> cygri: 31 is a bit out of the list
07:47:52 <mischat> http://www.w3.org/2011/rdf-wg/track/issues/30
07:48:06 <FabGandon> davidwood: sugest we start with issue 30
07:48:06 <Zakim> +gavinc
07:48:07 <FabGandon> Topic: Four issues of "Named Graphs".
07:48:08 <FabGandon> subtopic: Aligning SPARQL notions and RDF 1.1 g-* notions.
07:48:18 <FabGandon> ISSUE-30: How does SPARQL's notion of RDF dataset relate our notion of multiple graphs?
07:48:18 <trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added
07:48:20 <Steven> s/sugest/suggest/
07:49:47 <mischat> http://www.w3.org/TR/rdf-sparql-query/#rdfDataset <-- sparql dataset as per rdf sparql query 1.0
07:50:23 <FabGandon> Cygri : SPARQL defines Dataset as data data model used in SPARQL query i.e. collection of graph = one default graph and a set of named graphs <IRI,Graph>
07:50:33 <tomayac> AZ: +1, sound is low quality :-(
07:50:47 <mischat> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal
07:51:19 <FabGandon> ... they use the term named graph and it is a g-snap in our terminology because immutable
07:51:50 <pchampin> http://www.w3.org/TR/2009/WD-sparql11-update-20091022/#sec_graphStore
07:52:37 <PatH> +q
07:52:43 <FabGandon> ... graph store :"unlike an RDF dataset, named graphs can be added to or deleted from a graph store"
07:53:03 <FabGandon> ivan: the mutability is on the store not on the graph
07:53:47 <pchampin> pchampin has joined #rdf-wg
07:53:49 <FabGandon> ... are the graphs explicitly immutable ?
07:53:51 <PatH> sound quality is poor but usable
07:54:26 <FabGandon> cygri : the spec are not specific on this ; not really addressed
07:54:57 <Guus> q?
07:55:17 <FabGandon> ivan: IMO the dataset is a set of g-boxes
07:55:38 <Guus> zakim, who is here?
07:55:38 <Zakim> On the phone I see Meeting_Room, PatH, tomayac, OlivierCorby, AZ, gavinc
07:55:52 <FabGandon> cygri: the evaluation of a SPARQL query is defined against an immutable dataset
07:56:00 <gavinc> gavinc has joined #rdf-wg
07:56:09 <davidwood> q+ to discuss graph store relationships to g-boxes and g-snaps.
07:56:34 <ivan> q?
07:56:39 <ivan> ack PatH
07:56:42 <davidwood> ack PatH
07:56:47 <FabGandon> PatH: we shouldn’t be agnostic we should say what the graph is e.g. we should say it is a g-box that has a name
07:57:25 <FabGandon> cygri: SPARQL uses the term named graph, the IRI is the name for the graph in SPARQL
07:57:59 <mischat> PatH: there is no need to introduce confusion
07:57:59 <AZ> We can certainly see a SPARQL dataset as a snapshot of the graph store (the graph store is mutable but the snapshot is fixed to define what's the result of a query)
07:58:47 <FabGandon> PatH: RDF should specify the semantic of names if there is to be an interpretation of that name
07:59:14 <FabGandon> ... if we don't we leave the question open to endless discussions.
07:59:53 <davidwood> +1 to PatH, in that if we define what we mean we won't have misunderstandings as we do with "information resource" or "what *is* RDF".
08:00:41 <JFB> +1 to PatH: if there is some specifing meaning to names, it must be formalized in RDF Semantics
08:00:42 <FabGandon> PatH: we need to declare in a declarative text what the interpretation is for the IRI naming a graph.
08:01:34 <FabGandon> cygri: Can we use the name of doc as the name of graph.
08:01:44 <FabGandon> PatH: we can't prevent that
08:03:10 <Zakim> davidwood, you wanted to discuss graph store relationships to g-boxes and g-snaps.
08:03:57 <FabGandon> davidwood: several graph stores are maintainers of g-boxes implemented as multiple reader single writer
08:04:38 <FabGandon> ... when a query comes in they generate sets of g-snaps from the current state of the g-boxes.
08:05:12 <FabGandon> SteveH: yes that's what happens.
08:05:30 <PatH> we have yet to specify what a g-box is semantically. We will have to speak of states and g-snaps there.
08:06:22 <PatH> in other words, this box/snap issue will have to be dealt with there in any case.
08:06:31 <sandro> guus: When you do a SPARQL Query, you are querying at a point in time, so you are querying against the set of g-snaps which is the current contents of those g-boxes.
08:06:32 <FabGandon> Guus: at that point there is no conflict between our view and SPARQL
08:06:40 <davidwood> PatH: Yes
08:06:56 <davidwood> Yes, there is no conflict.
08:07:00 <FabGandon> subtopic: relation between the graph and its name.
08:07:40 <sandro> pchampin: I want to be able to use my own arbitrary data as the "graph" name in SPARQL.
08:08:00 <FabGandon> pchampin: I feel uncomfortable with fixing the semantics of the relation name of graphs and the store ; it depends on my use of the quadstore
08:08:57 <FabGandon> cygri: I don’t see this machinery as answering a large demand ; I don’t feel there is a huge demand on fixing that semantics
08:09:27 <FabGandon> ... what do we gain from defining the interpretation of named graphs ?
08:09:56 <pchampin> sometimes, I name a graph in my quad store with the URI of the g-box this graph comes from,
08:10:08 <pchampin> sometimes, I name it with the URI of the resource it is about
08:10:09 <FabGandon> danbri: are you confortable with the level of interoperability that would set?
08:10:36 <sandro> +1 danbri we need more interop between datastores (there is breakage when people use different styles of URIs)
08:11:10 <pfps> I don't know how the RDF semantics is going to speak to things like timestamping downloads of RDF documents.
08:11:38 <FabGandon> PatH: defining the semantics will not have so much implication on the implementation that seems to be feared. The idea is not to interfere with the machinery.
08:11:42 <davidwood> ack PatH
08:11:46 <danbri> it's something like a lack of mechanism for saying how *my* sparql store is managed. One might use 'the URI I fetched = the graph URI', another uses a uuid: per-transaction, and a table-of-contents history graph. Sure I can send SPARQL queries across both at same time, but the results might be barely meaningful.
08:13:10 <FabGandon> sandro: the machinery will complain for instance if I use the URI of a graph to identify a person and these classes are disjoint.
08:13:59 <danbri> PatH, the triples could have semantics, but their bundling and tagging with graph URIs could lack semantics
08:14:03 <pchampin> q+ to talk about named graphs in SPARQL endpoints
08:14:10 <FabGandon> SteveH: there are many use cases where we don't want to do some logical inference on top of RDF.
08:14:53 <pchampin> +1 danbri: I write no *triple* stating that a person is a graph :-)
08:15:01 <sandro> Pat: It violates the semantics of the language to have the name of a graph also be the name of a person.
08:15:15 <FabGandon> cygri: How does the fact of using a URI for a graph and a person raises a problem in SPARQL?
08:15:20 <AZ> A name can name several things, like in OWL 2 DL, a name can name a class and a property
08:15:38 <pgroth> could we do both? a name and a tag?
08:15:40 <AZ> and classes are disjoint from properties in OWL 2 DL
08:15:42 <FabGandon> PatH: lets not call it the names then.
08:16:43 <sandro> +1 pat
08:16:51 <FabGandon> pfps: RDF is agnostic as to the use of the same IRI to name a graph or a person.
08:16:51 <ivan> ack pchampin
08:16:51 <Zakim> pchampin, you wanted to talk about named graphs in SPARQL endpoints
08:17:21 <sandro> pchampin: I'm using the "graph id" as merely a "tag"
08:17:38 <FabGandon> pchampin: ok to say it’s not really a name but merely a tag.
08:18:07 <sandro> +100000 the world here would be MUCH CLEARER if SPARQL forced you to only use graph IDs that you own!!
08:18:24 <cygri> sandro -100000
08:18:56 <pfps> sandro - so you think that you shouldn't use "anyone else's" IRIs in a named graph?
08:19:03 <cygri> q+ to disagree with sandro -- web crawling use case
08:19:34 <FabGandon> sandro: I wish SPARQL restricted you to use only URIs that you own i.e. use graphs in a domain you control
08:20:01 <danbri> sandro, that feels to me like having the SQL spec specify that you can only store things that are true
08:20:09 <pchampin> I sure was not suggesting to restrict SPARQL... :-/
08:20:35 <pchampin> just pointing out that its flexibility allows for different practices... beyong "naming according to Pat"
08:20:41 <FabGandon> cygri: strong use case against that : when you crawl the web you want to use the URI from where you got the data.
08:21:17 <FabGandon> sandro: it may be more efficient but you create interoperability problems.
08:21:34 <sandro> Utility is at odds with Interoperability.
08:21:37 <PatH> hard to hear..
08:21:44 <sandro> Local utility vs Global utility.
08:21:53 <yvesr> another use case is ACL on quad stores
08:22:15 <FabGandon> pchampin: not suggesting restricting what SPARQL allows to do ; just advocating flexibility.
08:22:41 <cygri> q+ to talk about n3
08:22:44 <FabGandon> pgroth: I wonder if we don't need a typing mechanism.
08:22:44 <sandro> pgroth: There's "naming graph" and there's graph tags.
08:22:55 <Zakim> cygri, you wanted to talk about n3
08:23:39 <FabGandon> cygri: if you want a graph associated with a URI in N3 you need to put a predicate in-between.
08:24:09 <danbri> q: is this OK SPARQL? http://pastebin.com/raw.php?i=TaJVsste
08:24:19 <FabGandon> ... there is something in the middle that indicates the relation, don't restrict that because in SPARQL it is not restricted.
08:25:19 <yvesr> danbri, i guess it would - why wouldn't it?
08:25:42 <FabGandon> pfps: in RDF everything is a resources: a graph must be an resource or not ; how can we disconnect graph from that if we name them with IRI?
08:26:01 <danbri> q+ to try http://pastebin.com/raw.php?i=TaJVsste
08:26:52 <FabGandon> Guus: we need to identify the things we do agree on.
08:26:55 <Zakim> danbri, you wanted to try http://pastebin.com/raw.php?i=TaJVsste
08:27:14 <PatH> sounds like a sparql RDF dataset is not a collection of named graphs. Which surprises me, but I can live with.
08:27:20 <FabGandon> danbri: I want to talk about this test case http://pastebin.com/raw.php?i=TaJVsste
08:28:14 <FabGandon> ... this is a SPARQL query querying different databases.
08:28:36 <FabGandon> ... can we name graphs with mailto:bla@bla.bla
08:28:38 <PatH> but see what pat just wrote.
08:29:08 <FabGandon> yes we can
08:29:37 <FabGandon> davidwood: some people say we should always use http://
08:29:55 <FabGandon> danbri: there is a drift from using http:// URIs
08:30:07 <FabGandon> SteveH: I don't see anything wrong with that.
08:30:25 <sandro> sandro: This is just neats vs scruffies --- the graph might be a (scruffy) tag, or might be a name of a proper RDF graph.
08:30:29 <FabGandon> danbri: what about the provenance perspective?
08:30:34 <pfps> well, a SPARQL RDF dataset is defined as potentially containing "named graphs" as this is the first (as far as I know) W3C mention of "named graph", then SPARQL wins and SPARQL RDF datasets have named graphs
08:31:10 <pfps> the upshot of this is that the RDF WG may need a new name for what we have been calling named graphs
08:31:27 <FabGandon> pgroth: we care about pointing at a resource or at a graph talking about a resource.
08:31:37 <FabGandon> ... we need to be able to point at the content.
08:32:04 <PatH> pfps, suggest rather we keep named graphs but allow datasets to be something else.
08:32:30 <danbri> so my example lets me represent the (likely derrived from other stuff) info that Pat says Guus is the name of the holder of his homepage
08:32:52 <pfps> then we need to quickly get SPARQL not to "use up" this name - oops too late, named graphs is already in SPARQL 1.0
08:33:40 <pgroth> i like the idea of a default interpretation
08:33:47 <FabGandon> pchampin: graphs are resources they need naming and not necessarily a named attached to a SPARQL endpoint.
08:33:51 <pgroth> that the iri is the name of the graph
08:34:10 <SteveH> q+ to talk about <uri> :relation <graph>
08:34:33 <FabGandon> pfps: do RDF graphs have to be resources ?
08:34:55 <danbri> http://www.w3.org/TR/rdf-mt/#gloss ''Resource (n.)(as used in RDF)(i) An entity; anything in the universe. (ii) As a class name: the class of everything; the most inclusive category possible.''
08:35:09 <PatH> aaaargh. what are 'levels'????
08:35:16 <FabGandon> cygri: graphs are in the abstract syntax; resources are in the model theory
08:36:18 <FabGandon> pchampin: graphs must be resources
08:36:23 <sandro> pfps: We have A and Not-A (where A=Graphs are Resources)
08:37:20 <sandro> pat: Of COURSE graphs are resources. The model theory clearly says everything is a resource.
08:37:26 <JFB> +1 everything is a resource, if I am, why wouldn't a graph be ?
08:37:28 <FabGandon> PatH: there are no such notions of levels ; thats not the pb.
08:37:50 <pchampin> +1
08:37:54 <sandro> pat: We could say that SPARQL Datasets are about tagged graphs NOT naming.
08:37:55 <SteveH> +1
08:37:57 <sandro> +1 pat
08:37:59 <mischat> +1
08:38:00 <danbri> +1
08:38:12 <yvesr> +1
08:38:24 <danbri> q+ to suggest [eventual] best practice note on how *in practice* people are associating URIs with bundles-of-triples
08:38:34 <FabGandon> ... if we say we tag graphs and not we name then we can stop arguing
08:39:02 <AZ> But then, how one talks about a graph in triples?
08:39:29 <FabGandon> davidwood: I need a clarification on the difference between the name and a tag.
08:39:30 <ivan> ack SteveH
08:39:30 <Zakim> SteveH, you wanted to talk about <uri> :relation <graph>
08:40:14 <FabGandon> PatH: the difference is in the relation, tag is neutral.
08:40:16 <danbri> 'bundles'
08:40:30 <pgroth> why can't we have a default interpretation ?
08:40:48 <sandro> possible consensus: SPARQL "named graphs" are not "named" in the logical sense.
08:40:58 <cygri> +1 ivan
08:40:59 <danbri> pgroth, because there are multiple equally respectable default db management habits
08:41:27 <gavinc> FROM NAMED
08:42:01 <sandro> :'(''
08:42:20 <FabGandon> ivan: we don't have much choice, the term "named graph" is already used in the whole SPARQL community.
08:42:40 <pgroth> danbri, but default doesn't mean you have to
08:43:14 <sandro> sandro: Can we at least tell people this is a misleading name?
08:43:19 <SteveH> +1
08:43:56 <PatH> potentially misleading
08:44:02 <danbri> From a SPARQL perspective, it is legitimate to (a) tag graph-bundles with URI the triples were dereferenced from (b) to tag graph-bundles with URI for the party who made the claim (c) or a trasaction ID, eg. uuid:
08:44:13 <sandro> More Consensus: SPARQL "named graphs" are not necessarily "named" in the logical sense, or RDF graphs.
08:44:25 <sandro> FabGandon we have "tagged boxes" and we will call them "named graphs"
08:44:38 <pchampin> q+ to raise some concern about the semantics of NQuads, then
08:44:49 <Zakim> danbri, you wanted to suggest [eventual] best practice note on how *in practice* people are associating URIs with bundles-of-triples
08:44:56 <PatH> can we introduce the terminology of "sparql naming"
08:45:12 <davidwood> q+ to as about naming of RDF
08:45:26 <FabGandon> danbri: may be we should first document the current uses of "named graphs"
08:45:40 <mischat> q+ to ask about the difference in FROM NAMED and the GRAPH URI
08:45:52 <yvesr> +1
08:45:57 <sandro> +1 danbri: document the common practices for using sparql graphs names.
08:45:58 <PatH> I dont want to start policing sparql usage.
08:46:09 <FabGandon> ... I have three in mind but may be we should have a wiki page to collect them
08:46:12 <davidwood> No, we certainly don't
08:46:13 <danbri> path --- absolutely not policing, but documenting
08:46:17 <yvesr> PatH, not policing, surevying what's actually happening
08:46:18 <PatH> just keep terminology clean
08:46:22 <PatH> OK
08:46:27 <danbri> -- so we can send SPARQL queries that use GRAPH to services managed in a certain fashion
08:46:51 <FabGandon> pchampin: NQuads is used to dump a full store
08:46:55 <danbri> eg. see http://pastebin.com/TaJVsste ... maybe you have a DB I could usefully send that query to; but maybe Ivan's SPARQL db is managed with a different GRAPH/URI policy
08:47:02 <danbri> ...so naming those deployment patterns
08:47:02 <mischat> i do think that best practices for linked data re: graphs and named graphs
08:47:03 <Zakim> davidwood, you wanted to as about naming of RDF
08:47:05 <FabGandon> ivan: NQuad is juts syntax
08:47:06 <Zakim> pchampin, you wanted to raise some concern about the semantics of NQuads, then
08:47:20 <danbri> FDR!
08:47:39 <FabGandon> davidwood: concerned about redefining everything.
08:48:09 <FabGandon> sandro: SPARQL named graphs has little to do with named g-boxes.
08:48:13 <ivan> ack mischat
08:48:13 <Zakim> mischat, you wanted to ask about the difference in FROM NAMED and the GRAPH URI
08:48:23 <FabGandon> Guss: SPARQL is agnostic about.
08:49:04 <FabGandon> mischat: It is nice that SPARQL doesn’t force you to use the URL of the doc for the named graph.
08:49:23 <sandro> steve: FROM NAMED pulls a graph from some undefined place and puts it in the set of named graphs, but... [lost]
08:50:05 <FabGandon> SteveH: the exact behavior of the default graph changes from store to store.
08:50:25 <cygri> +1 mischat
08:50:32 <yvesr> +1
08:50:42 <danbri> yup
08:50:59 <FabGandon> mischat: the best practices could be in a note and not in rec.
08:51:54 <FabGandon> davidwood: we don't want to get in the way of LOD
08:51:57 <raphael> raphael has joined #rdf-wg
08:53:06 <FabGandon> ivan: too early to phrase it as a resolution ?
08:53:11 <sandro> PROPOSED: Close ISSUE-30 saying that SPARQL Datasets and Named Graphs have no strict or formal connection to a logic of RDF "naming" of Graphs.
08:53:29 <pfps> PROPOSED the upcoming notion of multiple graphs is not necessarily the same as named graphs in SPARQL
08:53:49 <danbri> perhaps - SPARQL quads are not the kinds of thing that can be interpreted as True vs False; RDF WG quads might or might not add more...
08:54:11 <PatH> suggest that the key point is that just because sparql uses a uri to, um, identify a graph, it does not mean that the uri can be used to refer to the graph in an rdf triple.
08:54:52 <FabGandon> ivan: we currently have no formal connection between the name and the graph in RDF
08:54:53 <danbri> ie. we can ask if the triple "uri-for-guus :homepage http://www.cs.vu.nl/~guus/" is true or not; but we can't yet ask if the quad "{uri-for-graph} uri-for-guus :homepage http://www.cs.vu.nl/~guus/" is true or false
08:55:32 <AZ> PatH +1
08:55:42 <danbri> (path, +1 to what?)
08:55:53 <FabGandon> Guus: who agrees with PatH ?
08:56:13 <AZ> +1
08:56:26 <FabGandon> PatH: you can use the URI but there is no guaranty that it refers to the graph.
08:56:27 <sandro> sandro: Pat means "refer" in a model theory sense, not a computer science sense.
08:57:05 <gavinc> So what does: SELECT ?s WHERE {GRAPH ?s { ?s ?p ?o }} end up meaning in this case?
08:57:17 <FabGandon> yvesr: we don't know what a multiple graph is and therefore can we talk about it in a resolution?
08:57:56 <zwu2> zwu2 has joined #rdf-wg
08:58:25 <FabGandon> ivan: when we have clarified notions then we can come back to that question.
08:58:28 <yvesr> we can't resolve an issue where half of the question is still undefined
08:58:56 <PatH> i like 'thruth'
08:59:07 <FabGandon> ... the issue should be postponed.
08:59:11 <danbri> quadly thruthyness
08:59:22 <ivan> rrsagent, pointer?
08:59:22 <RRSAgent> See http://www.w3.org/2011/04/14-rdf-wg-irc#T08-59-22
08:59:22 <PatH> :-)
08:59:32 <FabGandon> Guus: we can close that issue and open and more precise one.
08:59:37 <JFB> +1 for semantics of a predicate that would capture SPARQL's behaviour, but we're not ready yet for that
08:59:54 <yvesr> issue-30 might be dependent on issue-15
09:00:36 <FabGandon> pchampin: this question is linked to issue 15 http://www.w3.org/2011/rdf-wg/track/issues/15
09:00:44 <sandro> issue-15?
09:00:44 <trackbot> ISSUE-15 -- What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc -- open
09:00:44 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/15
09:00:45 <mischat> again, you could have a best practices document stating how you can use named graphs in a quad store in a truthy way, but neither rdf nor sparql mandates this, but it would be a good thing for quad store/linked data interoperability -- would be a good note for a primer
09:02:00 <FabGandon> Guus: 30 is about alignment with SPARQL and 15 is about our internal changes to RDF.
09:02:31 <FabGandon> ... in solving issue 15 we should not conflict with SPARQL.
09:02:37 <PatH> yes, fine
09:02:53 <PatH> yes,
09:03:14 <PatH> sorry cant unmute but agree with what you are saying
09:03:26 <FabGandon> Guus: we should remove dataset from issue 15 this is addressed in issue 30
09:03:47 <sandro> PROPOSED: ISSUE-15 is about our internal notions of multiple graphs, while ISSUE-30 is about how that related to SPARQL's notion. We do not expect the association of IRIs and graphs in SPARQL datasets to be RDF's identification/reference relationship.
09:04:03 <FabGandon> davidwood: etc. is not precise enough , issue 15 should be rephrased properly
09:04:48 <danbri> proposed: "While it is attractive to seek more clarity on relationship between some graph of triples and URIs they're tagged with, ... we note that SPARQL deployments have assigned URIs in a variety of ways, each of which being useful and compliant. There may be value in documenting these deployment styles (e.g. URIs for docs, abstract graphs, human sources or transaction IDs) so that SPARQL stores and serializations of URI-tagged triples can b
09:04:48 <danbri> e made more richly interoperable."
09:05:02 <FabGandon> Guus: we should start with defining our own terminology before aligning with SPARQL.
09:05:11 <cygri> proposed: "Named Graphs in SPARQL “loosely associate” IRIs and graphs. They do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."
09:06:20 <FabGandon> ISSUE-30: cygri proposes "Named Graphs in SPARQL “loosely associate” IRIs and graphs. They do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."
09:06:20 <trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added
09:07:12 <danbri> i tried ' each of which being useful and compliant' instead of 'loosly' (above)
09:07:23 <sandro> "are simple associations"
09:07:35 <AZ> Maybe: "Named Graphs in SPARQL associate IRIs and graphs *but* they do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."
09:07:42 <FabGandon> PatH: don't like the word "loosely" prefer : temporary
09:08:14 <sandro> PROPOSED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not necessarily establish graphs as referents of IRIs
09:08:35 <AZ> I would not put the necessarily there
09:08:51 <mischat> SteveH: sparql uses the verb "graph" to talk about arbitrary graphs and the "named graphs" for graphs which which can be fetched via http, or is that just my pov?
09:09:03 <sandro> PROPOSED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily "name" graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs
09:09:10 <sandro> +1
09:09:14 <pfps> +1
09:09:15 <cygri> +1 sandro
09:09:16 <AZ> +1
09:09:16 <mbrunati> +1
09:09:20 <pchampin> +1
09:09:23 <davidwood> +1
09:09:24 <cmatheus> +1
09:09:26 <yvesr> +1
09:09:27 <danbri> +1
09:09:32 <zwu2> +0
09:09:33 <NickH> +1
09:09:38 <SteveH> +1
09:09:51 <mischat> +1
09:10:04 <mischat> any objections for this being added as a note to issue-30 ?
09:10:04 <FabGandon> ISSUE-30: Proposed WG position : Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs.
09:10:04 <trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added
09:10:07 <sandro> RESOLVED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily "name" graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs (relevant to ISSUE-30)
09:10:31 <cygri> ISSUE-15?
09:10:31 <FabGandon> subtopic: link between the name and the triples of the graph.
09:10:31 <trackbot> ISSUE-15 -- What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc -- open
09:10:31 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/15
09:10:56 <PatH> +1 also my vote
09:11:11 <FabGandon> davidwood: moving to ISSUE 15 ; let's try to rephrase it.
09:11:41 <AZ> AZ: isn't it implicitly asking "how" one can associate a URI to a g-* ?
09:12:00 <PatH> propose, uri always refers to g-box, but some boxes are immutable.
09:12:12 <pgroth> agree with pat
09:12:16 <FabGandon> sandro: g-boxes, g-snap, g-text could be named
09:12:48 <PatH> because a snap is always a state (of a box) rather than a resource in its own right.
09:12:48 <FabGandon> ivan: can we have a predicate to say this IRI identifies this g-box ?
09:13:15 <pgroth> although i need to refer to a g-snap
09:13:51 <pchampin> PatH: can't a number have a URI ??
09:14:06 <FabGandon> pgroth: would that prevent you to refer to a particular state of a box ?
09:14:22 <PatH> dont think it can be done just using a predicate unless we endow that predicate with spoecial semantic force.
09:14:37 <danbri> (around foaf/webid/foaf+ssl and so on, we'll start seeing people identifying concrete sets of well known triples by hash of their encoding, eg. the triples W3C served for the RDF ns for the last 5 years)
09:15:00 <FabGandon> ivan: the snap vs. box is exactly about mutability
09:15:03 <pchampin> PatH??: <someuri> owl:sameas 42
09:15:57 <PatH> sure, that is ok, but states are transient.
09:16:28 <FabGandon> davidwood: if a g-box is a resource than we can talk about it.
09:16:49 <sandro> q+ to say the difference
09:16:59 <FabGandon> pgroth: so what is a snap then if not an immutable box ?
09:17:29 <FabGandon> sandro: another difference is equality.
09:17:45 <gavinc> The NAME is not part of the g-snap
09:17:54 <danbri> sandro, does that work ok w/ bnodes? do we have samegraphness defined adequately for graphs w/ bnodes?
09:18:14 <FabGandon> davidwood: two g-snaps may have the same content and still be different snaps.
09:18:27 <FabGandon> ... we haven't decided on that yet.
09:18:50 <sandro> danbri, yes, but you also have to allow bnodes to be shared between graphs.
09:18:51 <FabGandon> ... it depends on how we resolve issue 15
09:18:53 <SteveH> q+ to ask Sandro about why two g-boxes can't be equal [unless I got the wrong end of the stick]
09:19:16 <gavinc> ... I don't think g-snaps had names?
09:19:42 <PatH> stephen, two anythings cannot be equal.
09:19:54 <davidwood> ack sandro
09:19:54 <Zakim> sandro, you wanted to say the difference
09:19:55 <sandro> ack sandro
09:19:57 <ivan> ack sandro
09:19:58 <davidwood> ack PatH
09:20:03 <danbri> (sandro, eg. if there is an rdf/xml file bundled with Jena that is packaged old version of DC schema; and the similar-but-different triples we get from a DCMI namespace URI fetch ... )
09:20:10 <FabGandon> subtopic: REST and named graphs.
09:20:39 <FabGandon> PatH: The guiding abstraction should be the REST model
09:21:54 <FabGandon> davidwood: reprensentations are not resources by default
09:22:04 <davidwood> ack pchampin
09:22:08 <ivan> ack PatH
09:22:13 <sandro> it's the g-text that's the representation, not the g-snap.
09:22:29 <FabGandon> sandro: the representation is the g-text, a string
09:22:33 <danbri> PatH, does "is not a resource" there mean "not a Web/http resource" rather than "is not a resource-considered-as-synonym-for-thing"?
09:22:46 <danbri> (if you can channel for timbl...)
09:22:46 <FabGandon> pchampin: the g-snap is the state of the resource
09:22:51 <yvesr> g-box - resource ; g-snap - state ; g-text : representation
09:22:58 <pgroth> g-box = resource, g-snap = content negotiation, g-text = state serlization
09:22:58 <PatH> sorry, sandro is right. but the snap is an abstraction/parsing of the text.
09:23:01 <mischat> g-snap is information resource at time T ?
09:23:10 <davidwood> ack pgroth
09:23:15 <ivan> ack pgroth
09:23:30 <PatH> and so is similarly unidentifiable.
09:23:36 <JFB> g-snap: state of the resource or state of the representation ?
09:23:48 <PatH> yes, sandro is right.
09:23:54 <yvesr> pgroth: i don't agree - g-snap != content-negotiation
09:23:54 <pchampin> @JFB: state of the resource
09:24:06 <yvesr> s/pgroth:/pgroth,/
09:24:17 <FabGandon> cygri: you can't talk about the representation.
09:24:49 <sandro> q?
09:24:56 <PatH> danbri, i want those to be the same sense of resource
09:25:15 <FabGandon> davidwood: a representation is not a resource but with an additional step you can choose to make an identifier for that representation and talk about it.
09:25:28 <pchampin> data: URIs ?
09:25:34 <pchampin> I mean "data colon URIs"
09:25:38 <davidwood> ack SteveH
09:25:38 <Zakim> SteveH, you wanted to ask Sandro about why two g-boxes can't be equal [unless I got the wrong end of the stick]
09:27:18 <sandro> sandro: Two g-boxes remain distinct even though their contents/state might happen to be the same at some point in time.
09:27:42 <FabGandon> q?
09:27:51 <PatH> sandro, sorry to introduce extra confusion.
09:28:33 <PatH> +1 to pfps
09:28:37 <sandro> q+ to talk about use cases
09:28:54 <FabGandon> pfps: We could say we don’t change the semantics, Quads are syntax
09:29:34 <mischat> i like the idea that RDF semantics not changing, and using quads as syntax, +1 to pfps
09:29:44 <PatH> i think there are now also quints, sexts, etc..
09:29:45 <danbri> I can't understand how the same meeting can, 30 mins ago, accept resources=all things in the universe, yet 5 mins ago, deny that the stuff you get back from an HTTP request is a resource. Ug.
09:30:01 <sandro> pchampin, you're right, I think, that data: URIs give us identifiers for representations / g-texts.
09:30:25 <danbri> (even without handy URIs they're still things and therefore Resources in rdfsemantics sense)
09:30:27 <FabGandon> ... RDF semantics defines the meaning of the underlying data structure but not augmented with a semantics for datasets.
09:30:48 <sandro> danbri, we didn't agree with that -- it was just claimed and ignored. :-)
09:31:47 <pfps> so, after all the stuff that I said, I still remain agnostic as to which direction to go
09:32:00 <FabGandon> subtopic: defining Graph primitives in RDF semantics.
09:32:34 <FabGandon> ivan: if we have predicates to link IRI and g-* we need to define them in the RDF semantics
09:33:14 <PatH> yes, we do. so the semantics will have to deal with the *-ideas.
09:33:36 <PatH> yes, exactly.
09:33:47 <FabGandon> pfps: if you want to talk about this inside the RDF voc you have to define it in the RDF semantics indeed.
09:33:59 <PatH> +1
09:34:06 <pfps> from an OWL perspective, the "don't change the semantics view" is very seductive
09:34:25 <SteveH> also from the DB implementors view
09:34:42 <PatH> extend does not imply change, hoever.
09:34:45 <sandro> ISSUE: Should there be an rdf:Graph construct, or something like that?
09:34:46 <trackbot> Created ISSUE-35 - Should there be an rdf:Graph construct, or something like that? ; please complete additional details at http://www.w3.org/2011/rdf-wg/track/issues/35/edit .
09:34:46 <FabGandon> Guus: should there be an rdf:Graph primitive ?
09:35:00 <sandro> (from Guus and David -- I don't understand the question.)
09:35:23 <Zakim> sandro, you wanted to talk about use cases
09:35:40 <FabGandon> pfps: if g-boxes just want to have fun they need to be in the semantics.
09:37:06 <FabGandon> sandro: one of the scenarios is "annotating graphs" e.g. be able to select a part of graph state things about it.
09:38:26 <FabGandon> pchampin: we need a vocabulary for the g-* e.g. just to be about to talk about them when we load them.
09:39:44 <FabGandon> PatH: if the notion of g-box is important then the semantics has to clarify that notion it does not need to be a revolution.
09:39:50 <FabGandon> subtopic: REST and Named graphs (bis).
09:39:52 <pfps> perhaps, but by this same argument, the semantics should specify what happens when you go an HTTP get on a URL
09:40:07 <mischat> i am not sure about the adoption rate of '<> rdf:type rdf:Statement.' , do people even ever use them ...
09:40:19 <PatH> not that bad, peter...
09:40:58 <sandro> PROPOSED: We aligned g-* with REST, where g-box=information resource, g-snap=state of the resource, g-text=representation of the state of the resource
09:41:07 <FabGandon> cygri: documenting the alignment with REST may be useful for us but not in the deliverables ; it is too complex and time-consuming.
09:42:02 <FabGandon> ivan: would lead to endless discussions.
09:42:18 <sandro> PROPOSED: We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource, g-text=representation of the state of the resource
09:42:53 <pchampin> NB: a predicate would not state the relation between a URI and a graph, but between a resource (identified by a URI) and a graph
09:43:22 <PatH> i think we will be doing the world a disservice if we leave ambiguity and confusion. That is what the last RDF WG did, but there is a decade of practice now to guide us.
09:43:33 <mischat> sandro, perhaps s/state of the resource/state of the resource at time t/
09:43:35 <pfps> do we have a failrly coherent document that describes REST?
09:43:58 <sandro> PROPOSED: We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource (at time t), g-text=representation of the state of the resource (at time t)
09:44:03 <PatH> zakim, mute me
09:44:03 <Zakim> PatH should now be muted
09:44:21 <sandro> +1
09:44:22 <pfps> NB: I do understand that coherency is rather absent in the REST universe.
09:44:24 <davidwood> +1
09:44:26 <SteveH> +1
09:44:30 <gavinc> +1
09:44:31 <PatH> +1
09:44:33 <zwu2> +1
09:44:36 <danbri> -1
09:44:40 <AZ> +1
09:44:51 <JFB> +1
09:44:57 <mbrunati> +1
09:45:06 <ivan> 0
09:45:14 <sandro> (clarify -- this is only for the subset of IRs that can be respresented in RDF.)
09:45:18 <pfps> +.5 as I'm not exactly sure just what REST is
09:45:24 <JFB> @AZ yes, found that surprising
09:45:24 <PatH> az, that will teach you to make lumpy custard.
09:45:46 <Zakim> +AZ
09:46:02 <NickH> +1 (but agree that REST isn't very well specified)
09:46:09 <yvesr> +1
09:46:12 <FabGandon> danbri: some environments don’t have a notion of REST.
09:46:13 <pchampin> -1
09:46:43 <FabGandon> Guus: we are only considering the notions behind REST.
09:46:57 <danbri> REST is good, but it doesn't seem a 1:1 relationship to me
09:47:07 <sandro> pchampin: my concern is that we might be missing some more complicated resources whose state is not represented by a graph, because it's not just time.
09:47:16 <SteveH> +1 to danbri, but I don't think it detracts from the analogy
09:47:19 <PatH> seems to me that if its not related to restthen I dont know why we even have these distinctions ourselves.
09:47:21 <pchampin> e.g. authentication, etc
09:47:33 <SteveH> pchampin, right, or cookies for e.g.
09:47:34 <cygri> good point pchampin. language negotiation etc
09:47:43 <danbri> maybe i'm pulling Web-derrived data from a local Lucene store; from Mahout clustering, or prolog, doing stuff in code and stuffing bits into graphs with URI tags. REST is in the environment but the data flow is much more complex than fetch'n'store
09:47:46 <pchampin> yes, this too
09:48:02 <sandro> guus: two groups; (1) json, (2) skolemization
09:48:13 <tomayac> json += tomayac
09:48:19 <PatH> will skolem have a phone link?
09:48:39 <FabGandon> ISSUE-15: Text to be further discussed : "We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource (at time t), g-text=representation of the state of the resource (at time t)"
09:48:39 <trackbot> ISSUE-15 What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc notes added
09:48:44 <danbri> SteveH, sure, considered as an analogy it can be instructive (and in fact I'm trying to extend REST concepts a bit more into XMPP message types)
10:09:29 <pfps> Topic: skolemization (whatever that is!)
10:09:36 <tomayac> is there a dial-in no. for json?
10:09:49 <pfps> no dialin for json yet
10:09:56 <Zakim> +zwu2
10:09:56 <davidwood> davidwood has joined #rdf-wg
10:10:00 <pfps> and there won't be one
10:10:02 <sandro> no dialin for json ever, sorry.
10:10:05 <davidwood> zakim, who is on the phone?
10:10:05 <Zakim> On the phone I see Meeting_Room, tomayac, gavinc, AZ, zwu2
10:10:09 <zwu2> zakim, mute me
10:10:09 <Zakim> zwu2 should now be muted
10:10:40 <Zakim> +PatH
10:10:52 <PatH> zakim, mute me
10:10:52 <Zakim> PatH should now be muted
10:11:02 <mischat> tomayac: do you want to be dialled in ?
10:11:12 <yvesr> scribe: yvesr
10:11:12 <danbri> so - what are we skolemising and why?
10:11:19 <mischat> do JSON people want to call in
10:11:20 <sandro> topic: Skolemization Breakout
10:11:21 <pgroth> the skolemization has taken over this chat room
10:11:27 <pfps> The problem, as I see it, is that RDF stores hold blank nodes, but they have problems sending identifiers for these blank nodes out in response to queries and getting them back.
10:11:29 <mischat> yeah we are about to set up a voice thing
10:11:31 <mischat> i sec
10:11:40 <yvesr> SteveH: long-standing issue in the way bnodes are defined
10:11:49 <yvesr> SteveH: close-enough to existential variables in rdf
10:12:02 <yvesr> SteveH: most implementations turn it into an internal identifier
10:12:05 <sandro> SteveH: I have a longstanding issue who how bnodes are defined, as existential variables. But the reality is that all the triplestores turn it into an internal identifier.
10:12:13 <yvesr> SteveH: turning them into 'skolems'
10:12:21 <cygri> (JSON breakout is happening over in the #rdf-json channel)
10:12:46 <sandro> pfps: So far, they havent' done anything wrong.
10:13:09 <Zakim> -tomayac
10:13:13 <yvesr> SteveH: 2 problems - 1) bnodes in the wild (when there shouldn't be) and 2) people deliberately writing them (i.e. FOAF)
10:13:27 <danbri> q+ to account for the foaf case
10:13:42 <PatH> there is also a strong deprtecation of bnode use in the linked data community.
10:13:44 <sandro> SteveH: But sometimes you encounter bnodes in the wild, where it would be nice to have URIs, as in foaf. In practice it's annoying.
10:13:46 <yvesr> SteveH: in FOAF, you end up using inverse functional properties to identify individuals
10:13:54 <davidwood> Zakim, open the queue
10:13:54 <Zakim> ok, davidwood, the speaker queue is open
10:14:09 <danbri> q+ to account for the foaf case
10:14:24 <sandro> q+ to present proposal
10:14:43 <yvesr> SteveH: People are missing a feature from relational databases (not assigning an explicit primary key)
10:15:03 <yvesr> SteveH: some triple stores have internal uri schems to talk about bnodes
10:15:12 <sandro> SteveH: Folks also have internal URI schemes for talking about bnodes. People really want this for SPARQL round-tripping.
10:15:14 <davidwood> ack danbri
10:15:14 <Zakim> danbri, you wanted to account for the foaf case
10:15:15 <yvesr> SteveH: those can surface in query results - and can be used in queries
10:15:18 <pfps> q+
10:15:28 <PatH> q+
10:15:38 <pfps> q+ to say that such RDF stores aren't really doing anything 'wrong'
10:15:48 <yvesr> danbri: There's a reason for the FOAF choice - leading to anonymous resources
10:16:02 <yvesr> danbri: no owl:sameAs, not clear what to do with resources
10:16:19 <yvesr> danbri: identifying people with properties was a pragmatic decision
10:16:44 <yvesr> davidwood: how would you do it today?
10:17:07 <yvesr> danbri: if you were in a position to assign uris for other people, then FOAF would have gone for URIs
10:17:24 <yvesr> danbri: bnodes are a pain to deal with...
10:17:44 <yvesr> q+
10:18:01 <davidwood> ack sandro
10:18:01 <Zakim> sandro, you wanted to present proposal
10:18:01 <ivan> ack sandro
10:18:06 <sandro> steveH: The assigned URIs leak out of query interface, which is what makes them useful.
10:18:27 <zwu2> zwu2 has joined #rdf-wg
10:18:31 <danbri> original statement of the foafy smushing stuff: http://lists.xml.org/archives/xml-dev/200012/msg00597.html
10:18:44 <yvesr> sandro: Long discussion on the semantic-web list a couple of weeks ago - a proposal was done that adress everyone's requeirements
10:19:09 <yvesr> sandro: pick one of two uri pattern choices to skolemize bnodes
10:19:29 <yvesr> sandro: http://... if you want to dereference, or tag:...
10:20:03 <yvesr> sandro: if you encounter one of those uris, it's machine generated
10:20:17 <yvesr> sandro: those uris can be considered as disposable
10:20:19 <danbri> so the first dozen or so FOAF files used genid: as a URI scheme, eg. http://svn.foaf-project.org/foaftown/2010/allfactoids/copies/danbri/danbri-foaf.rdf ... about="genid:poulter" etc
10:21:00 <FabGandon> yvesr: how do you know they are machine generated?
10:21:13 <PatH> it is always valid to 'deskolemize', so we dont need to say anything about that.
10:21:20 <FabGandon> SteveH: because they have genid
10:21:39 <yvesr> danbri: reserved uri pattern - genid in the uri means that it is machine generated
10:21:42 <sandro> 1. If you're going to Skolemize, use a URI like this:
10:21:42 <sandro> - http://example.org/.well-known/genid/[whatever]
10:21:42 <sandro> - tag:example.org,2011/.well-known/genid/[whatever]
10:21:42 <sandro> 2. If you encounter one of these URIs:
10:21:42 <sandro>
10:21:43 <sandro> - you know it's machine generated
10:21:45 <sandro> - consider it more disposable, more mergeable
10:22:08 <PatH> +1 to speaker. genid is better.
10:22:11 <gavinc> eg: generate-id() in XPath/XSLT
10:22:12 <sandro> We mean LITERALLY the string "genid".
10:22:13 <yvesr> SteveH: Prefers genid over bnodes
10:22:40 <PatH> s/speaker/stevenh
10:22:43 <yvesr> SteveH: you might want to use "genids" to identify graphs
10:22:51 <davidwood> ?
10:22:53 <davidwood> q?
10:22:57 <yvesr> sandro: Use "genid" or "gensym"?
10:23:00 <davidwood> ack pfps
10:23:00 <Zakim> pfps, you wanted to say that such RDF stores aren't really doing anything 'wrong'
10:23:05 <ivan> ack pfps
10:23:49 <davidwood> q+ to mention the use of made-up ids as a pattern to replace bnodes
10:24:07 <yvesr> JFB: bnodes are stronger - they can never be used in another graph
10:24:18 <yvesr> SteveH: this is already dropped in sparql-update
10:24:53 <yvesr> pfps: Technically, it is not a valid entailment
10:25:24 <ivan> q+
10:25:35 <danbri> related prev discussion: sergey melnik tried to create a canonical URIs for bnode/anon resources - http://lists.w3.org/Archives/Public/www-rdf-interest/1999Dec/0046.html
10:25:59 <sandro> pfps: As long as these are fresh, you wont get any incorrect inferences.
10:26:20 <yvesr> pfps: SPARQL-update validates the leaky bnodes, what this proposal says is that graph stores are able to make that transformation
10:26:25 <sandro> pfps: This says an RDF store is entitled to change bnodes like this.
10:27:05 <davidwood> ack PatH
10:27:08 <sandro> pfps: "RDF graphs stores can, on their own recognisance, do this transformation"
10:27:37 <yvesr> PatH: the fact that such uris can leak out is a good thing
10:27:51 <yvesr> PatH: We don't have to worry about leakage
10:27:52 <sandro> q?
10:28:22 <davidwood> ack yvesr
10:28:51 <zwu2> cannot hear much
10:28:55 <PatH> zakim, mute me
10:28:55 <Zakim> PatH should now be muted
10:29:19 <PatH> sound is very patchy.
10:29:25 <PatH> better
10:31:07 <davidwood> ack davidwood
10:31:07 <Zakim> davidwood, you wanted to mention the use of made-up ids as a pattern to replace bnodes
10:31:31 <yvesr> yvesr: RDFa creates lots of bnodes in the wild
10:31:56 <yvesr> yvesr: and sometimes there are things that you can't identify, or don't want to mint a URI for (e.g. transient things)
10:32:01 <danbri> ivan, in your homepage you have <div id="container" about="http://www.ivan-herman.net/foaf#me" typeof="foaf:Person dc:Agent"> .... that's the verbose aspect. But maybe you could use a relative URI at least?
10:32:22 <yvesr> davidwood: I don't think there is soemthing wrong with bnodes, and it's fine to skolemize them
10:32:37 <yvesr> s/soemthing/something/
10:33:04 <yvesr> davidwood: Machines should do the job, transparently
10:33:40 <sandro> q?
10:33:45 <davidwood> ack ivan
10:33:45 <sandro> q+ to draft proposal
10:33:50 <yvesr> SteveH: what you want is a bnode syntax, not a bnode semantics
10:34:14 <yvesr> ivan: I can understand that a number of people would want to derefence these things
10:34:19 <PatH> sandro, type it.
10:34:21 <yvesr> ivan: what happens when you derefence them?
10:34:24 <sandro> PROPOSAL: It's okay for systems to Skolemize bnodes, replacing them with IRIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. Must be reg'd with IETF.
10:34:33 <yvesr> ivan: what advice do you give, and how are people to set it up?
10:34:57 <yvesr> ivan: the first uri pattern is an http:// uri, and needs to be dereferencable - what does it do?
10:34:58 <PatH> should be fine for these to give 404s.
10:35:03 <davidwood> SteveH: Yes, I want the usefulness of bnode semantics with a simple, automated bnode syntax assistance.
10:35:29 <yvesr> ivan: do we want to get this reflected in various syntaxes?
10:35:48 <davidwood> q?
10:36:20 <yvesr> SteveH: what we would do in 4store would be to generate bnode skolems based on a prefix
10:36:32 <yvesr> SteveH: prefix is defined in configuration
10:36:52 <yvesr> SteveH: accessible as any other identifier in the store
10:37:30 <yvesr> ivan: you're using your SPARQL engine as a tool - the W3C needs to provide a global mechanism for what happens when you derefence a http://...genid... uri
10:37:35 <PatH> sandro, if these are supposed to refer to non-information resources, then according to http-range-14, they ought to give a 303 redirect. Can they have a # ending to remove this requirement?
10:38:22 <yvesr> q+
10:38:58 <yvesr> ivan: Linked Data people don't want to have bnodes in their graph
10:39:19 <yvesr> pfps: there's no way to make them happy
10:39:35 <yvesr> ivan: there is a way to set up a simple service somewhere that would do the job
10:39:41 <sandro> PatH, how about if it's http[s]://[domain]/.well-known/genid/[locally-uniq-id]#
10:40:13 <PatH> fine with me, as long as doesnt require a 303 mechanism
10:40:18 <davidwood> q+ to discuss broadness of skolemization (stores, validation, services, etc)
10:40:23 <yvesr> SteveH: if you dereference a bnode, one thing you could do is to just say 'this is a bnode'
10:40:42 <davidwood> ack sandro
10:40:42 <Zakim> sandro, you wanted to draft proposal
10:40:56 <sandro> PROPOSAL: It's okay for systems to Skolemize bnodes, replacing them with IRIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id]# or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. Must be reg'd with IETF.
10:41:00 <danbri> q+ to express risk of single point of failure / keeping a bnode-description-service secure is nontrivial, costly work
10:41:38 <yvesr> sandro: the hash is to stay clear of httpRange-14
10:41:52 <gavinc> Annoyed but not strong/formal objection to using tag: --0?
10:41:58 <yvesr> sandro:
10:42:02 <PatH> +1 danbri, should not presume a service of any kind.
10:42:07 <yvesr> SteveH: i can think of lots of reasons not to do that
10:42:15 <sandro> gavinc, why does the tag bother you? what would you prefer?
10:42:40 <yvesr> davidwood: uri lookups cost time and money
10:42:50 <gavinc> tag was designed specificly for HUMAN generated uniqueness
10:42:50 <davidwood> ack yvesr
10:43:04 <gavinc> q+
10:43:05 <danbri> (re bit.ly / tinyurl analogy, ... it's taking us a month of HTTP requests to bit.ly to expand otherwise mysterious shortlinks from a twitter crawl, ... they only allow 2 lookups / second ... single points of control worrying)
10:44:22 <pchampin> shouldn't we add "fresh IRI" in Sandro's proposal?
10:44:41 <sandro> yvesr: I don't like Skolem ids leaking out.
10:44:54 <danbri> LOD community have established the convention than any party can invent HTTP URIs freely, for anything and anyone; so why not just generate LOD URIs or uuid: URIs? I don't see this proposal adding value to those options
10:44:56 <FabGandon> WRT the service approach, beyond the risk of single point of failure it is a point of centralization in the model and in general centralization is not good for web arch IMHO
10:44:58 <PatH> all specifically RDF uses dont require dereferencing. Seems like main purpose of these being recognizable is to AVOID dereferencing them.
10:45:37 <davidwood> ack gavinc
10:45:39 <zwu2> q+
10:45:42 <ivan> ack gavinc
10:45:45 <sandro> sandro: Maybe "*if* you're going to skolemize, you SHOULD use one of these two forms"
10:46:23 <PatH> disagree. should be free to skolemize any way you like, as long as it is 'frtesh'
10:46:24 <yvesr> gavinc: seems very wrong to use tag uris
10:46:29 <PatH> fresh
10:46:50 <yvesr> gavinc: is UUID terrible?
10:47:16 <yvesr> SteveH: minting a new UUID for all bnodes is not very affordable
10:47:27 <yvesr> gavinc: we got rid of all bnodes at o'reilly because of that
10:47:28 <davidwood> Sandro thinks yes, UUIDs doesn't allow you to use genie
10:47:40 <davidwood> s/genie/genid/
10:47:49 <yvesr> q?
10:48:27 <yvesr> ivan: is it true that the tag: scheme says 'it is for humans'?
10:48:51 <yvesr> gavinc: the generation mechanism needs to happen by humans
10:48:58 <davidwood> ack davidwood
10:48:58 <Zakim> davidwood, you wanted to discuss broadness of skolemization (stores, validation, services, etc)
10:49:11 <zwu2> zakim, unmute me
10:49:11 <Zakim> zwu2 should no longer be muted
10:49:25 <yvesr> davidwood: There is opportunity to use skolemisation in quite a lot of places, not only in stores
10:49:50 <yvesr> davidwood: input, output, validation process, skolemization services
10:49:52 <pchampin> q+ to talk about the fresh URIs and them leaking from the store
10:50:14 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they SHOULD use URIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id]# or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
10:50:14 <davidwood> q?
10:50:15 <yvesr> davidwood: if you're doing skolemization, you SHOULD do it in the way we're defining
10:50:22 <danbri> ack danbri
10:50:22 <Zakim> danbri, you wanted to express risk of single point of failure / keeping a bnode-description-service secure is nontrivial, costly work
10:50:22 <davidwood> ack danbri
10:50:35 <davidwood> zakim, close the queue
10:50:35 <Zakim> ok, davidwood, the speaker queue is closed
10:50:44 <PatH> prposal. it is permissible to replace bnodes by URIs provided that the URIs are 'fresh', ie not used in any other rdf graph. It is recommended to include a string /genid/. one way is sandro's prposal.
10:50:59 <danbri> q-
10:51:04 <yvesr> ivan: Would that effect any of the syntaxes, and how?
10:51:07 <PatH> q+
10:51:07 <yvesr> SteveH: it wouldn't
10:51:08 <danbri> I defer; question withdrawn
10:51:15 <yvesr> SteveH: it wouldn't be the parser's job to do it
10:51:22 <yvesr> SteveH: it doesn't have enough information
10:51:33 <yvesr> ivan: for RDFa, it would make sense - and it might make sense for Turtle files too
10:51:38 <mischat_> mischat_ has joined #rdf-wg
10:51:49 <yvesr> ivan: many people use the square brackets - lazyness
10:51:50 <danbri> ( I assume args for the skolem function is not just the textual input, but also the base URI...)
10:52:06 <yvesr> ivan: i should be able to tell the parser to mint me some URIs for those
10:52:23 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they SHOULD use fresh URIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
10:52:24 <davidwood> +1 to PatH's proposal
10:52:32 <davidwood> ack zwu
10:52:39 <yvesr> SteveH: reverse transformation - output documents *with* bnodes
10:53:08 <mischat_> Webr3 about?
10:53:12 <yvesr> zwu2: if you have one triple in a store, :john :friendOf _:a
10:53:16 <PatH> steveh, it is always valid to 'deskolemize' with bnodes.
10:53:24 <yvesr> zwu2: you would get back a skolemized bnode
10:53:31 <mischat_> webr3, if you are about join #rdf-json
10:53:36 <yvesr> zwu2: if we're using that skolemized bnode as a query
10:53:44 <yvesr> are we supposed to return :john or not?
10:53:49 <yvesr> zwu2: are we supposed to return :john or not?
10:53:52 <yvesr> SteveH: yes
10:54:08 <PatH> yes. once it is a uri, you can do this.
10:54:09 <yvesr> davidwood: if identifiers leak out to the outside world, it maintains validity
10:54:31 <yvesr> ivan: if i use the bnode filter operation in a SPARQL query, what happens?
10:54:37 <yvesr> ivan: does it match the skolemized bnode?
10:54:47 <yvesr> SteveH: that's an issue for us
10:54:49 <PatH> zakim, unmute me.
10:54:49 <Zakim> PatH should no longer be muted
10:54:56 <yvesr> SteveH: we need to define if they count as bnodes or not
10:55:12 <yvesr> ivan: as a user, who doesn't understand this stuff, i would expect the bnode function to work
10:55:21 <yvesr> SteveH: in 4store, it would answer true
10:55:39 <yvesr> SteveH: it only gets skolemized on the export
10:55:47 <yvesr> SteveH: internal consistency
10:55:47 <ivan> q?
10:55:48 <davidwood> ack pchampin
10:55:49 <Zakim> pchampin, you wanted to talk about the fresh URIs and them leaking from the store
10:55:53 <ivan> ack pchampin
10:56:34 <yvesr> pchampin: We shoudl specify what is ok for the system to do
10:56:39 <PatH> az, no problem
10:56:43 <yvesr> pchampin: We should specify what the system would return
10:56:44 <SteveH> AZ, that wouldn't be legal RDF syntax, though you could write it by hand
10:56:57 <davidwood> PatH, can you please resend your proposal?
10:56:58 <yvesr> pfps: Troubles finding the SPARQL bnode definition
10:57:25 <danbri> pat hayes
10:57:40 <SteveH> http://www.w3.org/TR/rdf-sparql-query/#func-isBlank
10:57:49 <SteveH> ...the BNODE() function actually mints bNodes
10:57:50 <yvesr> PatH: genid SHOULD be in the URI but not absolutely required
10:57:58 <SteveH> but I think it was understood what was being discussed
10:58:07 <yvesr> PatH: it should be possible for people to invent URIs and use them
10:58:15 <yvesr> PatH: they could use software to do that automatically
10:59:08 <yvesr> PatH: We should not allow skolems that are specific to a single query
10:59:24 <sandro> PatH: Note that Skolemization is not valid in an antecedent (eg query).
10:59:31 <sandro> SteveH: that's fine.
10:59:40 <PatH> prposal. it is permissible to replace bnodes by URIs provided that the URIs are 'fresh', ie not used in any other rdf graph. It is recommended to include a string /genid/. one way is sandro's prposal.
10:59:46 <yvesr> SteveH: the skolemization process has to be stable
11:00:00 <yvesr> davidwood: Can we get consensus around this proposal?
11:00:19 <yvesr> davidwood: are there concerns around sandro's mandated use?
11:00:43 <yvesr> davidwood: if you're going to skolemize, you need to use a globally unique URI
11:00:49 <sandro> freshness is iffy -- since you want stability....
11:00:52 <yvesr> davidwood: and we encourage you to do it in a way
11:01:46 <danbri> -1 where did 'allowed' enter the rdf universe?
11:01:49 <zwu2> as long as generated uri is fresh to the triple store, it is good enough
11:01:54 <yvesr> -1 as well
11:02:01 <danbri> -> say what it means, not what people can/can't do
11:02:22 <PatH> must be fresh, should include /genid/
11:02:47 <yvesr> sandro: MAY is you're allowed to
11:02:58 <yvesr> pfps: SHOULD is you should do it, unless there's a very good reason not to
11:03:16 <PatH> sandro, why is freshness "iffy"
11:03:37 <danbri> proposed: "A graph transformed such that each bnode is replaced with a fresh bnode [meeting some constraints], ... then that new graph is true under the same conditions of the original."
11:03:40 <danbri> q+ to propose
11:04:10 <danbri> we are not the SPARQL WG
11:04:12 <yvesr> davidwood: if systems are going to leak bnodes, they must use fresh uris
11:04:52 <yvesr> SteveH: consistent mapping between internal representation and external id
11:05:02 <zwu2> so we can reuse "fresh" uris
11:05:11 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
11:05:20 <yvesr> danbri: we're not the SPARQL working group - so I think this language inappropriate
11:05:33 <yvesr> danbri: we should instead say something about graph structures
11:06:11 <yvesr> ivan: current RDF documents already talk about skolemization
11:06:31 <yvesr> ivan: the only thing we're saying here is that if it is used, you should use this pattern
11:06:52 <danbri> http://www.w3.org/TR/rdf-mt/#prf
11:06:54 <yvesr> pfps: RDF Semantics talk about skolemization
11:07:51 <yvesr> sandro: you need a web service to do the skolemization
11:08:00 <PatH> wha?
11:08:05 <yvesr> ???
11:08:18 <danbri> madness!!!
11:08:18 <yvesr> SteveH: you can't guarantee uniqueness
11:08:30 <danbri> (that's a technical term, no disrespect intended)
11:09:12 <PatH> call it 'bnode purging' and people will love it.
11:09:16 <yvesr> sandro: tag: skolemized bnode are more horrible than bnode
11:09:35 <danbri> PatH, can it be couched more declaratively? this 'should' stuff worries me
11:09:40 <JFB> RDF Semantics talks about Skolemization in Appendix A. Its notion of freshness is "fresh in the current graph"
11:09:42 <yvesr> ivan: the R2RML folks are fighting with the same problem
11:09:46 <PatH> danbri, yes.
11:10:01 <yvesr> ivan: what happens when the DB doesn't have a (publicly exposable) primary key
11:10:13 <PatH> jfb, no, that is not what was intended.
11:10:14 <pchampin> s/the DB/a table in the DB/
11:10:19 <sandro> PatH, in "you need a web service to do the skolemization" , I mean to be particularly useful, and make people happy you did the Skolemization....
11:10:45 <danbri> sandro, what are you seeing as the args to the skolemisation function? not just a document + base_uri?
11:10:49 <yvesr> ivan: if we come up with this note, we need to send it to the R2RML group - potential first users
11:11:17 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
11:11:37 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use a fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
11:11:44 <sandro> objections from danbri and yves.
11:11:49 <PatH> unhappy with 'disposable'
11:12:13 <yvesr> danbri: very short URIs are important to me
11:12:19 <yvesr> danbri: don't force me to use this long pattern
11:12:25 <sandro> danbri: short URIs are important to me. don't force me to do it this way.
11:12:41 <yvesr> SteveH: uri pattern is quite verbose
11:12:45 <PatH> and would prefer to just say 'SHOULD include string /genid/'
11:12:49 <danbri> sorry - am sounding grumpier than I am. This could be a useful pattern for some.
11:12:50 <sandro> SteveH: for the non-deref form I prefer something smaller.
11:13:08 <zwu2> how about genid:local_unique_id
11:13:14 <yvesr> danbri: if we cut the proposal to the first MUST, any objections?
11:13:35 <PatH> and sandro's particular form offered as an offtheshelf solution.
11:13:39 <yvesr> all: what does disposable mean?
11:13:44 <yvesr> pfps: all pragmatics from here
11:13:54 <PatH> +1
11:14:20 <yvesr> sandro: you can skolemize, at some cost
11:14:33 <danbri> when you said "You're changing the data", that's in the right direction pfps
11:14:56 <PatH> you always can skolemize. It is not valid, but it preserves satisfiability.
11:15:02 <yvesr> sandro: proposition restrcited to MUST is actually stronger - want to expose the fact that it has been skolemized
11:15:36 <yvesr> sandro: genid:... would be good, but needs to be pushed through the IETF
11:15:54 <yvesr> ivan: this is a pain
11:16:11 <yvesr> sandro: don't want to be stuck in the IETF
11:16:24 <zwu2> you guys are not hungry, are you?
11:16:25 <danbri> the crux seems to be 'is it still in some appropriate equivalence class of graphs from the original? or has it been inappropriately interfered with..."
11:16:43 <PatH> why do we need to involve the IETF???
11:17:00 <gavinc> scheme registration :(
11:17:03 <yvesr> PatH, for a potential new uri scheme for those skolems
11:17:09 <pchampin> PatH: if we want a genid: URI scheme
11:17:11 <pfps> if we want to use URIs of the form genid:... we need to get approval
11:17:20 <PatH> screw a new scheme. they are just uris.
11:17:42 <yvesr> SteveH: are the two graphs the same? the skolemized and the original one?
11:17:53 <ivan> Pat, the issue is that the proposed URI-s are ugly and long...
11:18:01 <PatH> we need pertmission to include some text inside a URI??
11:18:30 <sandro> we need permission to say that all URIs containing certain text have a certain meaning, Pat.
11:18:34 <PatH> ivan, that is another issue.
11:18:35 <yvesr> you can't project from skolemized to original, but you can the other way around
11:18:52 <yvesr> FabGandon: you can't project from skolemized to original, but you can the other way around
11:18:59 <PatH> we artent saying anything about meaning, sandro.
11:19:17 <PatH> we are just making them recognizable.
11:19:58 <PatH> dawn is breaking here.
11:20:04 <yvesr> davidwood: if we're close to a solution, let's keep on on that
11:21:04 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, without doing damage to the graph, they MUST use a fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id] (or, someday, genid:...). Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
11:21:31 <FabGandon> yvesr: still not happy with the SHOULD part
11:21:40 <PatH> -1 to that. way too restricting. overkill.
11:21:53 <FabGandon> ... not confortable with specifying a URI parttern.
11:22:00 <pchampin> still uncomfortable with the "disposable" part; I don't know what that means
11:22:05 <zwu2> +0
11:22:13 <FabGandon> ivan: happier with IETF pattern
11:22:15 <PatH> agree with fabgandon
11:22:45 <FabGandon> Fabien happier with genid:
11:23:07 <PatH> we do not need to get IETF involved.
11:23:35 <pchampin> PatH: if we want genid: URIs, we do
11:23:39 <Zakim> -zwu2
11:23:42 <PatH> have a good lunch, guys.
11:23:55 <Zakim> -PatH
11:23:59 <AZ> enjoy your meal
11:24:04 <Zakim> -AZ
11:24:18 <PatH> pchampin: I do not neeed he IETF t put 'gnid' into a URI name.
11:24:41 <PatH> Anyway, back to email :-)
11:25:09 <gavinc> about:, irc:, javascript:, jar:, rsync:, ssh:, ... need the IETF is a nice idea, the world doesn't exactly agree ;)
11:25:33 <gavinc> heck, if WHATWG has its way with the IETF ... no comment
11:25:54 <Zakim> -gavinc
11:31:13 <mischat__> mischat__ has joined #rdf-wg
11:58:16 <cmatheus> cmatheus has joined #rdf-wg
12:02:18 <mbrunati> mbrunati has joined #rdf-wg
12:02:23 <Guus> Guus has joined #rdf-wg
12:02:29 <ivan> -> http://www.w3.org/mid/4DA6A6AD.70205@deri.org -> Antoine's objection to yesterday's resolution
12:02:55 <ivan> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0307.html instead
12:03:00 <cygri> cygri has joined #rdf-wg
12:03:02 <danbri> 404
12:03:04 <danbri> ah
12:03:19 <ivan> -> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0309.html Lee's reply
12:03:38 <AlexHall> AlexHall has joined #rdf-wg
12:05:51 <gavinc> zakim, code?
12:05:51 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), gavinc
12:06:18 <danbri> zakim, who is on the phone?
12:06:18 <Zakim> On the phone I see Meeting_Room
12:06:19 <mischat> can people here the room ?
12:06:19 <sandro> zakim, who is on the call?
12:06:19 <Zakim> On the phone I see Meeting_Room
12:06:23 <mischat> s/here/hear/
12:06:27 <Zakim> +gavinc
12:06:53 <sandro> topic: Debrief Breakouts
12:07:03 <sandro> subtopic: JSON Breakout Debrief
12:07:34 <cmatheus> scribe:cmatheus
12:07:34 <cmatheus> cygri: talked about note to enumerate problem JSON space
12:07:51 <cmatheus> three examples; linked data, BBC, NYT
12:08:01 <Zakim> + +1.443.212.aabb
12:08:16 <ivan> q+
12:08:25 <cmatheus> part of problem: data always connected to some api
12:08:31 <AlexHall> zakim, +1.443.212.aabb is me
12:08:31 <Zakim> +AlexHall; got it
12:08:47 <cmatheus> linked data approach provides tools but its complicated
12:09:30 <cmatheus> talked about focusing on simple actions a json developer might want to take: enumerate instances, describe instance
12:10:21 <cmatheus> mischat: will also enlist help form rdfa TF
12:10:26 <ivan> q+
12:10:35 <ivan> zakim, open queue
12:10:35 <Zakim> ok, ivan, the speaker queue is open
12:10:39 <ivan> q+
12:10:48 <ivan> ack
12:10:49 <Guus> q?
12:10:54 <davidwood> ack ivan
12:11:37 <Zakim> +??P18
12:11:48 <cmatheus> ivan: discussion with Sandro about rdf web app working group (rdfa wg)
12:11:58 <webr3> Zakim, I am ??P18
12:11:58 <Zakim> +webr3; got it
12:12:30 <cmatheus> ivan: their intention is for low level things to be hidden from JS user
12:12:53 <cmatheus> whatever comes out of that group should be coordinated
12:13:04 <cmatheus> need to keep groups in sync
12:13:33 <cmatheus> guus: does this mean our use case numbver one is being done by rdfs wg?
12:13:43 <cmatheus> ivan: it's in the bin
12:13:56 <danbri> 'in the bin?' = trash?
12:14:13 <webr3> next week..
12:14:26 <cmatheus> according to plan rdfa api will be published next week
12:14:41 <cmatheus> this group should look at that document
12:14:56 <Steven> Steven has joined #rdf-wg
12:15:05 <cmatheus> guus: reporting of second breakout?
12:15:22 <sandro> subtopic: Report of Skolemization Breakout
12:15:40 <cmatheus> steveh: problem is if you have bnodes and you want to run a query to get them out there's no way to do that.
12:15:58 <cmatheus> plan is to provide a standard skolemize method to let you get them out
12:16:16 <cmatheus> everyone agreed this was good
12:16:35 <sandro> SteveH: If you query a sparql store and get bnodes out, there's no way to ask about them. We'd like to stdize a way to allow those bnodes to be given lables (be IRI nodes) so you can ask more. The sticky part is about indicating which nodes started out live as bnodes.
12:16:39 <LeeF> LeeF has joined #rdf-wg
12:16:44 <cmatheus> sticky part whether it's desirable to have a way to tell that these started out as bnodes.
12:17:19 <Zakim> +LeeF
12:18:02 <cmatheus> guus: is there consensus that you should be able to tell that they were blank nodes?
12:18:44 <Zakim> +AZ
12:18:46 <Steven> -> http://www.w3.org/2011/04/14-rdf-json-minutes.html Minutes of JSON breakout
12:18:53 <cmatheus> davidwood: core issue: how are people external to the skolem process able to tell they were bnodes.
12:18:57 <danbri> (@cygri, I made a twitter list with rdfwg members, from your post - https://twitter.com/#!/danbri/rdfwg )
12:19:45 <cmatheus> question to peter: do you object to there being a way to be able to tell that these are bnodes?
12:19:53 <sandro> davidwood: Peter, do you object to there being a mechanism for indicating skolem nodes?
12:20:07 <sandro> Peter: I object to it being mandated.
12:20:16 <cmatheus> peter: against it being manditory
12:20:34 <cmatheus> as a consum I don't need to know whether someone skolemized.
12:20:40 <sandro> peter: As a consumer, I don't need to know, in all cases, whether Skolemization was done. It would be nice to know, but it's not even a should.
12:20:58 <gavinc> +q to ask if isBlank() behavior should stay the same with skolemized or non skolemized?
12:20:59 <cmatheus> it's nice if we all did it or all agreed on doing it.
12:21:18 <danbri> so was this skolemised? http://data.linkedmdb.org/page/film/2014 ... who cares!
12:21:24 <sandro> SteveH: I want to be able to mint URIs that are skolem constants for bnodes such that when I get them back I can tell they were bnodes?
12:21:55 <cmatheus> steveh: if the producer gets the bnodes back should they be able to tell if they were created as bnodes? different from having any user being able to tell.
12:22:20 <cmatheus> davidwood: in short, we were not able to get consensus
12:22:23 <gavinc> -q
12:22:31 <cmatheus> guus: will leave it open for the moment
12:22:38 <sandro> danbri, there are several practical situations when I would care, yes.
12:23:07 <cmatheus> guus: turning to clean up
12:23:15 <SteveH> danbri, if someone does INSERT DATA { <http://data.linkedmdb.org/page/film/2014> ... } and it's ont of my bNodes, I really need to be able to tell
12:23:24 <SteveH> otherwise it will screw up the data
12:23:58 <cmatheus> sandro: yesterday issue 10: deprecated, will use archaic
12:24:13 <cmatheus> issues on xs:string, containers
12:24:57 <cmatheus> next item for today: reification
12:25:04 <cmatheus> this is issue-25
12:25:35 <cmatheus> propse that we leave this until after we have a replacement for it
12:26:08 <cmatheus> issue-26: trivial, rdfxml syntax has two ways to state subject: rdf:about and rdf:id
12:26:08 <trackbot> ISSUE-26 Should we deprecate rdf:ID on RDF/XML node elements? (use rdf:about instead) notes added
12:26:26 <cmatheus> proposal to mark idea as archaic
12:26:47 <cmatheus> Steveh: it can be usefull to use rdf:id to ensure you don't reuse an id
12:26:56 <sandro> SteveH: rdf:ID can be useful to find times when you accidentally use it twice....
12:26:59 <cmatheus> (since rdf:id's must be unique)
12:27:08 <AlexHall> do most rdf/xml parsers enforce the uniqueness of rdf:ID?
12:27:08 <cmatheus> guus: no objection to marking archaic
12:27:40 <cmatheus> cygri: I would argue against it. it's a minor issue. fixes a minor problem among the many rdf has.
12:27:51 <cmatheus> if this is the only change let's not go there
12:28:00 <gavinc> Googling for rdf:ID lists documents which give conflicting advice on using it vs. rdf:about
12:28:17 <cmatheus> sandro: wouldn't suggest that we go to much lenght to fix, but would recommend author's not to suggest using rdf:id
12:28:52 <danbri> http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-ID-xml-base
12:28:58 <cmatheus> guus: there is a cost involved to learning to use rdf:id vs. rdf:about
12:29:03 <danbri> "So for example if rdf:ID="name", that would be equivalent to rdf:about="#name". rdf:ID provides an additional check since the same name can only appear once in the scope of an xml:base value (or document, if none is given), so is useful for defining a set of distinct, related terms relative to the same RDF URI reference."
12:29:32 <cmatheus> danbri: rdf:node_id are for bnodes
12:29:34 <danbri> q+
12:30:25 <cmatheus> sandro: no body advocating rdf:id is a good thing just that it's not worth doing much about it
12:30:53 <sandro> PROPOSED: We don't think people should be using rdf:ID, but maybe it's not worth expressing this sentiment in any documents.
12:31:28 <webr3> so why not just deprecate it?
12:31:35 <cmatheus> guus: no one arguing for keeping it
12:31:42 <sandro> webr3, lots of people just gave their reasons.
12:31:46 <sandro> q?
12:31:47 <davidwood> davidwood has joined #rdf-wg
12:31:54 <davidwood> q?
12:31:59 <cmatheus> ivan: I would not touch rdf/xml
12:32:10 <pchampin> @web3: we deprecated the term 'deprecate' yesterday :)
12:32:13 <SteveH> http://www.google.com/search?q=%22rdf%3AID%22 suggests we should keep it
12:32:17 <cmatheus> if we begin to do something with it we will have to do a serious job
12:32:56 <cmatheus> danbri: rdf spec grammar, rdf:id can be used to check name reuse
12:33:12 <sandro> danbri: By saying anything, we complicated the RDF environment.
12:33:16 <cmatheus> if we say anything at all we add complexity to rdf environment.
12:33:24 <pfps> q+
12:33:35 <cmatheus> guus: propose we do not change
12:33:40 <ivan> ack danbri
12:33:42 <ivan> ack pfps
12:33:46 <sandro> PROPOSED: Close ISSUE-26 doing nothing.
12:33:49 <cmatheus> pfps: because it is being used we should do something about it
12:33:57 <LeeF> ISSUE-26?
12:33:57 <trackbot> ISSUE-26 -- Should we deprecate rdf:ID on RDF/XML node elements? (use rdf:about instead) -- open
12:33:57 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/26
12:34:07 <gavinc> I think my objection to rdf:ID is what happens if your xml:base ends with a / ;)
12:34:29 <gavinc> the issue is "appending the attribute value to the result of appending "#""
12:34:38 <NickH> Why is getting rid of rdf:ID more effort than getting rid of XMLLiteral / xsd:String etc?
12:34:42 <cmatheus> davidwood: why if it caused confusion and we agree we shouldn't use it, why should we continue to accept it?
12:34:49 <danbri> q+ to propose that we replace rdf:about and rdf:resource with rdf:uri, i.e. <foaf:Person rdf:uri="#me"><foaf:homepage rdf:uri="/"></foaf:Person>
12:34:55 <cmatheus> marking it archaic is not removing it
12:35:11 <sandro> PROPOSED: Close ISSUE-26 doing nothing.
12:35:12 <NickH> sorry for the inaccuracy
12:35:18 <danbri> q-
12:35:36 <ivan> +1
12:35:38 <cygri> +1
12:35:39 <SteveH> +1
12:35:40 <danbri> +1
12:35:41 <pfps> +0
12:35:41 <AZ> +1
12:35:42 <pchampin> +1
12:35:42 <mbrunati> 1
12:35:43 <gavinc> -0
12:35:43 <cmatheus>cmatheus::+1
12:35:44 <sandro> +0 (I understand)
12:35:44 <webr3> +0
12:35:47 <JFB> +1/3
12:35:51 <davidwood> +0
12:35:57 <mischat> +1
12:36:00 <NickH> Why is marking rdf:ID as archaic more effort than marking XMLLiteral / xsd:String etc archaic?
12:36:05 <FabGandon> +2/3
12:36:07 <sandro> RESOLVED: Close ISSUE-26 doing nothing.
12:36:33 <davidwood> NickH: Because marking rdf:ID as archaic would require a change to the RDF/XML document.
12:36:34 <cmatheus> sandro: rdf:value
12:36:49 <cmatheus> all I can say, mark it as archaic
12:36:51 <danbri> NickH - because those are *vocabulary* constructs which affect the entire ecosystem - rdfa, turtle, json, sparql, owl...
12:37:01 <sandro> SteveH: I like rdf:value
12:37:05 <sandro> Guus: I like it too!
12:37:07 <cmatheus> FabGandon: it's in a best practice note
12:37:26 <LeeF> SCOVO uses rdf:value (for better or for worse)
12:37:26 <NickH> danbri / davidwood thanks
12:37:33 <webr3> I like rdf:value just wish it was defined more clearly
12:37:39 <LeeF> (http://sw.joanneum.at/scovo/schema.html)
12:37:53 <sandro> Guus: In representation of museum data, we annotate with a bnode structure and then use a rdf:value for what's really pointed to.
12:37:54 <cmatheus> guus: example of its use: have things about values such as its dimension
12:38:13 <gavinc> +q Dublin Core also uses it
12:38:13 <danbri> rdf:value was partly from reification, and partly for n-ary -> http://lists.w3.org/Archives/Public/semantic-web/2010Jul/0252.html
12:38:26 <gavinc> +q to talk mention that Dublin Core also uses it
12:38:29 <sandro> guus: Lots of people use this pattern, effectively.
12:38:41 <danbri> it's a bit like toString()
12:38:45 <FabGandon> Note 3 in SWBPWG http://www.w3.org/TR/swbp-n-aryRelations/#sec-notes
12:38:46 <cmatheus> guus: this is a property that points to the value
12:38:54 <cmatheus> it's highly deployed in some communities
12:39:39 <LeeF> Even if it was the most hated thing in the spec, I don't think we ought to deprecate it if it's as widely in use as it appears.
12:39:53 <danbri> re weights-and-measures, http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ uses it for exactly that -- search for <n:units rdf:resource="http://www.nist.gov/units/Pounds"/>
12:39:54 <cmatheus> Steveh: done work with numeric data, want to be able to lterals as subjects in a sense
12:40:00 <yvesr> SteveH, was it signal processign related stuff?
12:40:09 <yvesr> SteveH, had to do the same for this kind of things
12:40:10 <cmatheus> ivan: when you need to add a unit to a value this is perhaps the best way to do it
12:40:16 <sandro> PROPOSED: Close ISSUE-27 doing nothing (not marking rdf:value as archaic).
12:40:20 <gavinc> -q
12:40:21 <pfps> -1
12:40:21 <webr3> +1
12:40:22 <SteveH> yvesr, no, demographics
12:40:23 <cmatheus> danbri: was in the original recommendation for that purpose
12:40:23 <LeeF> +1
12:40:24 <ivan> +1
12:40:26 <gavinc> +1
12:40:30 <AZ> +0
12:40:33 <SteveH> yvesr, but I think it might also be used in LV2
12:40:35 <pchampin> q?
12:40:37 <gavinc> +q to talk mention that Dublin Core also uses it
12:40:39 <davidwood> +1
12:40:40 <cmatheus> cygri: would like evidence on its deployment
12:40:42 <mbrunati> +1
12:40:43 <SteveH> yvesr, for presets and defaults
12:40:55 <FabGandon> +1/2
12:40:58 <cmatheus> pfps: I've seen it. always badly.
12:41:03 <sandro> pfps: Every single case where I've seen it used, it's used badly.
12:41:05 <cmatheus> danbri: how could you tell?
12:41:27 <cmatheus> pfps: there's always a back handed agreement for how it is used
12:41:30 <sandro> pfps: ... where there is a backhanded agreement about what it really means, and where the meaning is really different in every case.
12:41:39 <cmatheus> ivan: this can be done because it is an open ended property
12:41:48 <cmatheus> pfps: destroys the utility of rdf
12:42:00 <cmatheus> rdf:value is used as a local property
12:42:06 <webr3> +1 pfps
12:42:15 <cmatheus> cygri: where used they should have defined a local property
12:42:21 <cmatheus> guus: that's not true
12:42:22 <webr3> it's centered on out of band knowledge about the data
12:42:22 <AZ> +1 cygri
12:42:30 <sandro> cygri: I would argue that every time it's used, a local property should be defined for that.
12:42:37 <cmatheus> rdf:value is for something where we don't have a solution
12:42:56 <cmatheus> steveh: like rdfs:label -- it's a handy thing to have around
12:43:00 <webr3> rdfs:label is a typed link, rdf:value is untyped
12:43:05 <sandro> issue-27
12:43:09 <sandro> issue-27?
12:43:10 <trackbot> ISSUE-27 -- Should we deprecate rdf:value? -- open
12:43:10 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/27
12:43:31 <sandro> http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue
12:43:36 <cmatheus> guus: rdf:label points to a string instead of name and rdf:value points to the value
12:43:48 <cmatheus> same kind of function as rdf:label
12:43:51 <mischat> ?q
12:43:56 <danbri> ±0
12:44:16 <danbri> http://www.w3.org/TR/rdf-schema/#ch_value "rdf:value has no meaning on its own. It is provided as a piece of vocabulary that may be used in idioms such as illustrated in example 16 of the RDF primer [RDF-PRIMER]. Despite the lack of formal specification of the meaning of this property, there is value in defining it to encourage the use of a common idiom in examples of this kind."
12:44:18 <cmatheus> pfps: don't mark it as archaic but realize you're making a bad mistake
12:44:20 <LeeF> Can we put an action to address this in the updated primer?
12:44:22 <danbri> ie. RDFS current encourages its use
12:44:33 <cmatheus> sandro: do you want document to say something about it?
12:44:42 <gavinc> Does Dublin Core do it wrong? http://dublincore.org/documents/dc-rdf-notes/
12:44:54 <cmatheus> pfps: no. every time it's been used its been used badly.
12:45:05 <webr3> pfps +1
12:45:10 <sandro> pfps: Every time I've seen rdf:value it's been bad practice, destroying the "beauty" of RDF.
12:45:19 <webr3> it's like <a href="boo">, untyped
12:45:19 <pchampin> @sandro the example in the RDF primer is a bad one :-( (weight)
12:45:30 <cmatheus> pfps: rdf:value is the same as rdf:thispropertydoesn'tmeana*?/thing
12:45:35 <davidwood> davidwood has joined #rdf-wg
12:45:38 <cmatheus> sandro: is this resolved?
12:45:47 <sandro> pfps: I'm not formally objecting to this proposal.
12:45:59 <Zakim> -Meeting_Room
12:46:00 <webr3> should it a couple of new properties be defined for common uses of rdf:value ..
12:46:03 <gavinc> ah
12:46:08 <gavinc> and there goes the phone
12:46:09 <Steven> zakim, who is noisy?
12:46:10 <cmatheus> cygri: is there some text on good use of rdf:value?
12:46:11 <danbri> q+ to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.
12:46:17 <sandro> Guus: I disagree with Peter's characterization
12:46:22 <Zakim> Steven, listening for 10 seconds I heard sound from the following: gavinc (4%)
12:46:23 <sandro> davidwood: As do I.
12:46:42 <cmatheus> I would disagree with some of the things in the Primer
12:46:45 <sandro> cygri: The use for units of measure is extremely questionable.
12:47:06 <Steven> zakim, code?
12:47:06 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Steven
12:47:08 <cmatheus> there's a lot of work on how to measure units of measure, they come up with different solutions
12:47:13 <gavinc> No, I can not hear.
12:47:35 <cmatheus> Sandro: meeting room got hung up on
12:47:53 <sandro> s/Sandor/Sandro/
12:48:12 <Zakim> +Meeting_Room
12:48:50 <cmatheus> cygri: if you just use rdf:value and have addition properties hanging off of value telling you what the value means, that's bad
12:49:48 <yvesr> :fft rdf:value "..."
12:50:03 <cmatheus> the Primer leads people into bad modeling and we should do something about it
12:50:11 <sandro> cygri: The primer gives bad modeling advice, and I don't like that.
12:50:14 <pchampin> +1 cygri
12:50:16 <yvesr> :fft :derived_from :signal .
12:50:20 <yvesr> all good practice, imho
12:50:21 <cmatheus> guus: we can close this and open a new issue about the Primer
12:50:25 <NickH> yvesr: so avoid repeating very large literal values?
12:50:30 <cmatheus> cygri: okay
12:50:37 <yvesr> NickH, yep
12:50:49 <gavinc> -q
12:50:53 <yvesr> s/yvesr:/yvesr,/
12:51:19 <davidwood> davidwood has joined #rdf-wg
12:51:22 <sandro> PROPOSED: Close ISSUE-27, not marking rdf:value as archaic, but with the understand that the modeling advice in RDF Primer will be revisited.
12:51:26 <yvesr> +1
12:51:28 <ivan> +1
12:51:37 <danbri> q?
12:51:39 <danbri> ack danbri
12:51:39 <Zakim> danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.
12:51:44 <gavinc> +1
12:51:47 <danbri> ahh, i forgot already
12:51:49 <cygri> -0
12:51:59 <davidwood> Dublin Core uses rdf:value in the same manner as the examples in the RDF spec. I think it is therefore compliant.
12:52:00 <AZ> +0
12:52:00 <danbri> action danbri danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.
12:52:00 <trackbot> Created ACTION-33 - Danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value. [on Dan Brickley - due 2011-04-21].
12:52:05 <pchampin> +1
12:52:27 <cmatheus> sandro: can put an Action on Richard to review primer
12:52:58 <cmatheus> cygri: I think there is a technical issue about a bug in the rdf Primer about advice on use of rdf:value
12:53:23 <cmatheus> guus: could result in Primer ignoring rdf:value
12:53:33 <sandro> RESOLVED: Close ISSUE-27, not marking rdf:value as archaic, but with the understand that the modeling advice in RDF Primer will be revisited.
12:54:17 <cmatheus> sandro: only plan to spend another 35 minutes here
12:54:28 <cmatheus> those were all the ones marked as Archic
12:54:43 <cmatheus> s/Archic/Archaic/
12:54:43 <FabGandon> issue-6?
12:54:43 <trackbot> ISSUE-6 -- Handling RDF Errata -- open
12:54:43 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/6
12:55:03 <FabGandon> issue-7?
12:55:04 <trackbot> ISSUE-7 -- Leftover issues from the RDF Core WG -- open
12:55:04 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/7
12:55:12 <cmatheus> ivan: issue 6: handling of Errata
12:55:14 <mischat> http://www.w3.org/2001/sw/RDFCore/errata
12:55:29 <cmatheus> we have to have a mechanism not to forget these
12:55:30 <davidwood> davidwood has joined #rdf-wg
12:55:38 <mischat> this related to danbri's suggestion of going through the archives
12:55:46 <mischat> s/related/relates/
12:56:01 <cmatheus> nothing earthshakingly major
12:56:24 <cmatheus> issue-7: some issues left open from previous working group
12:56:24 <trackbot> ISSUE-7 Leftover issues from the RDF Core WG notes added
12:56:45 <mischat> http://www.w3.org/2000/03/rdf-tracking/#/%23futures
12:56:53 <cmatheus> danbri: brief comment on list
12:57:07 <cmatheus> some were engineering hacks, left for next group
12:57:20 <webr3> +1
12:57:21 <cmatheus> ivan: we still need to go through them
12:57:34 <cmatheus> davidwood: propose a telecom to discuss these
12:57:40 <yvesr> http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects :)
12:57:47 <cmatheus> pfps: someone should go through them ahead of time
12:57:59 <cmatheus> davidwood: I volunteer to do that
12:58:17 <cmatheus> ivan: IRI versus URI story
12:58:18 <sandro> ACTION: wood prepare resolutions to dispose of each of the leftover items, http://www.w3.org/2000/03/rdf-tracking/#/%23futures
12:58:18 <trackbot> Created ACTION-34 - Prepare resolutions to dispose of each of the leftover items, http://www.w3.org/2000/03/rdf-tracking/#/%23futures [on David Wood - due 2011-04-21].
12:58:25 <cmatheus> frankly I am lost with the details
12:58:53 <gavinc> Jeremy had something on what needed to be updated with the IRIs, but I seem to have miss placed it.
12:58:54 <cmatheus> Andy and Eric know a lot about that
12:58:59 <FabGandon> issue-8?
12:58:59 <trackbot> ISSUE-8 -- Incorporate IRI-s into the RDF documents -- open
12:58:59 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/8
12:59:40 <cmatheus> sandro: we want to look at every where we say something about URI and replace it with IRI
12:59:53 <ivan> The IRI Spec[1] is from 2005, and it may be necessary to retrofit it to RDF. Eg, what is the relationship between "http://xn--rsum-bpad.example.org/" and "http://xn--rsum-bpad.example.org/"? Are they the same resource or not? Note that SPARQL has something on that[2]...
13:00:39 <gavinc> Jeremy thought there were a few when we spoke about it. But again, I've missplaced the record of that conversation
13:00:51 <sandro> "http://résumé.example.org" and "http://xn--rsum-bpad.example.org"?
13:01:03 <cmatheus> ivan: (showing on the screen an issue with url's in irc)
13:01:37 <cmatheus> are the displayed iri's refereing to same resource or not?
13:02:10 <cmatheus> cygri: two iri's are identifcal if the characters are the same, except in a number of cases...
13:02:24 <cmatheus> s/identifcal/identical/
13:02:25 <davidwood> q+
13:02:58 <cmatheus> the one uri can be normalized into the other
13:03:25 <cmatheus> guus: if it's a problem we can flag it but's it's not in the realm of where we should go
13:03:44 <mischat> http://www.w3.org/TR/sparql11-query/#syntaxTerms
13:03:47 <cmatheus> mischat: if we go this way we will need to have best practise note on this
13:03:53 <cmatheus> sandro: example?
13:03:55 <sandro> mischat: back-tick is valid in URI-References but not IRIs.
13:04:08 <cmatheus> mischat: a back tick. caused our app to go down.
13:04:25 <cmatheus> davidwood: I've seen issues with that, I think it was with back tick.
13:04:36 <gavinc> for reference, IRI spec: http://www.ietf.org/rfc/rfc3987
13:04:46 <cmatheus> guus: objet to description of issues -- it's outside of scope
13:05:11 <pchampin> from the charter (required section): Clarify the usage of IRI references for RDF resources
13:05:18 <cmatheus> mischat: rdf group was guessing at what iris would look like
13:05:32 <cmatheus> davidwood: issue from implementation standdpoint
13:05:50 <ivan> q+
13:06:00 <cmatheus> when trying to index rdf, if you have to do a lot of checking, implementers will screem, Talis for one.
13:06:00 <ivan> ack davidwood
13:06:27 <cmatheus> if we said an iri and uri were equivalent that would cause serious practical problems
13:06:43 <cmatheus> steveH: I understand what you're saying but don't understand the technical problem
13:07:04 <gavinc> +q
13:07:15 <cmatheus> davidwood: when ingesting rdf you must say whether this uri is equivalent to some other uri's in your system
13:07:15 <sandro> SteveH: Every triplestore I know just uses utf-8, so the question is which chars are allowed.
13:07:29 <cmatheus> steveh: it just changes your grammar
13:07:35 <cmatheus> davidwood: you may be right
13:07:42 <cmatheus> SteveH: I'm pretty sure I am
13:07:43 <ivan> ack davidwood
13:07:47 <sandro> SteveH: SPARQL says they have to be the same normalized utf-8 byte string.
13:07:50 <mischat> q+
13:07:54 <cmatheus> davidwood: I'm talking about in SPARQL
13:08:00 <cmatheus> the specs say different things
13:08:07 <cmatheus> cygri: I don't think they do
13:08:23 <cmatheus> in RDF world things are conistent
13:08:37 <cmatheus> s/sconistent/consistent/
13:08:51 <mischat> i don't think they are consistent, you can a SPARQL INSERT triples which you cant CONSTRUCT as valid RDF/XML
13:08:55 <cmatheus> there's no way you can align this with the rest of the web architecture
13:09:08 <SteveH> mischat, no you cant
13:09:08 <cmatheus> but can give recommendations.
13:09:16 <SteveH> mischat, oh, wait, not maybe that's right
13:09:18 <sandro> cygri: We can (and should) give recommendations to publishers about how to mint URIs to avoid these problems, like don't say :80 and dont use uppercase URI scheme or host names.
13:09:22 <mischat> it is right SteveH
13:09:26 <cmatheus> if you avoid certain things then you will get same result
13:09:32 <davidwood> correction: I was *not* talking about SPARQL, but Turtle or other forms of ingesting into a store, and then only in the case where we decided that a given IRI was equivalent to a different character string URI.
13:09:35 <cmatheus> worth writing up as an aid to users of rdf
13:09:51 <davidwood> q?
13:09:52 <cmatheus> ivan: this discussion went beyond what I intended
13:09:57 <davidwood> ack ivan
13:10:38 <cmatheus> but look what happend when we just but the same iri's through two different systems and got very different results
13:10:48 <cmatheus> this is something we need to address
13:10:49 <gavinc> I think the section in question is: http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref
13:10:56 <cmatheus> guus: this is not something we're going to solve
13:11:12 <mischat> this is the IRI RFC http://www.ietf.org/rfc/rfc3987.txt
13:11:19 <gavinc> The RFC lists a set of normalization methods http://www.ietf.org/rfc/rfc3987
13:11:29 <cmatheus> ivan: why? there is a document that says how to implement a system that will do the right thing
13:11:45 <Guus> q?
13:11:46 <cmatheus> davidwood: what is the sate of iri's in the standard (RC)
13:11:58 <cmatheus> cygri: it's implemented in all browsers
13:12:19 <davidwood> ack gavinc
13:12:24 <cmatheus> davidwood: that's different from the state of the standard
13:13:01 <cmatheus> gavinc: we went through this a month ago but I can't find the work we did -- not sure if it got lost in the shuffle
13:13:15 <cmatheus> we didn't think the spec was as brioken as some of the people are saying
13:13:22 <cmatheus> sorry, I don't remember the details
13:13:36 <sandro> davidwood, it's a PROPOSED STANDARD, per http://www.rfc-editor.org/rfcxx00.html#STDbySTD
13:13:48 <sandro> (like almost everything)
13:14:17 <cmatheus> mischat: the issue I have is I can issert certain triples, with content with a back tick, and then retrive it and I get something different.
13:14:50 <cmatheus> ivan: there are cetrtain charcters that you cannot put into a xml doc, but in turtle it would not be a problem
13:14:54 <sandro> (although URI RFC-3986 is actually a "STANDARD" STD-66 )
13:15:05 <cmatheus> pfps: turtle is currently stuck at uri's
13:15:45 <Guus> q?
13:15:54 <cmatheus> gavinc: I don't think turtle is cemented to uris
13:16:03 <davidwood> IRIs seem to be an IETF standards-track (but not standard) RFC (3987), which does not expire. There is a newer proposal, which will expire in Sep 2011 (https://datatracker.ietf.org/doc/draft-ietf-iri-3987bis/)
13:16:07 <cmatheus> gramar refers to iris
13:16:08 <Guus> ack mischat
13:16:37 <cmatheus> sandor: we should revisit this when Eric and Andy (perhaps Jeremy) are around
13:16:43 <cmatheus> ivan: issue 9
13:16:54 <sandro> s/sandor/sandro/
13:17:01 <cmatheus> small thing for Pat and Peter from der Horst
13:17:04 <cygri> davidwood: that's the same as the URI RFC
13:17:18 <cmatheus> an obvious thing that the editor has to take care of
13:17:30 <cmatheus> issue 11, more complicated
13:17:40 <davidwood> davidwood has joined #rdf-wg
13:18:19 <cmatheus> docs published by other wg's that extended the rdf semantics or contained elements related to rdf semantics
13:18:45 <cmatheus> implementors focusing on rdf have to visit all docs
13:19:07 <cmatheus> rdf plain literal added vocabulary
13:19:32 <cmatheus> POWDER likewise
13:19:46 <FabGandon> issue-11?
13:19:46 <trackbot> ISSUE-11 -- Reconciliation of various, semantics-oriented documents with the core RDF ones -- open
13:19:46 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/11
13:20:14 <cmatheus> SPARQL 1.1 has Entailment Regimes
13:20:25 <cmatheus> something we should look at
13:20:36 <cmatheus> guus: is there anything we need to do now
13:20:36 <danbri> ( @davidwood, i made a first cut at suggesting closure of the old RDFCore issues: http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0317.html )
13:20:42 <cmatheus> ivan: probably not
13:20:56 <cmatheus> guus: let's leave this open but ensure it gets resolved
13:21:07 <cmatheus> ivan: string literals handled
13:21:31 <cmatheus> xml literals discussed and still open
13:21:36 <cmatheus> that's all
13:23:31 <cmatheus> ivan: (discussion about POWDER extension to rdf schema...)
13:24:10 <cmatheus> guus: bad idea that there are many different groups dealing with these issues
13:25:22 <cmatheus> ivan: not proposing to do any extra work -- need to make references to the other sources of relevant information
13:25:45 <cmatheus> guus: if we need to do more than references than this needs to be handled at a higher organizational level
13:26:16 <cmatheus> guus: suggest 20 minute break
13:26:20 <davidwood> davidwood has joined #rdf-wg
13:26:40 <cmatheus> in final session. short planning round for next F2F
13:26:52 <cmatheus> will come back and discuss document set
13:27:11 <cmatheus> and candidate docs
13:27:13 <davidwood> danbri: Thanks. That list is very helpful. I'll start with your list and see if I have any different ideas. I plan to add that discussion to the agenda for next Wed.
13:27:21 <Zakim> -webr3
13:27:38 <gavinc> ?
13:27:42 <gavinc> I heard my name?
13:28:00 <Zakim> -AlexHall
13:28:07 <gavinc> or not ;)
13:33:58 <manu> manu has joined #rdf-wg
13:36:25 <mischat> this is the excerpt from the IRI rfc which highlights my issue with roundtripping RDF
13:36:26 <mischat> http://pastebin.com/ZiQHQ2ab
13:39:42 <Zakim> +zwu2
13:40:07 <zwu2> zwu2 has joined #rdf-wg
13:42:26 <zwu2> zwu2 has joined #rdf-wg
13:48:11 <Zakim> + +1.443.212.aacc
13:48:18 <FabGandon> I wonder if it wouldn't be an easyer position to consider that every IRI loaded in a triple store is first turned into its ASCII version and then treated as the URI before including the character by character comparison.
13:48:50 <AlexHall> zakim, +1.443.212.aacc is me
13:48:50 <Zakim> +AlexHall; got it
13:49:25 <gavinc> No, the spec is already clear that URIs are unicode
13:49:44 <gavinc> "A URI reference within an RDF graph (an RDF URI reference) is a Unicode string"
13:50:40 <mbrunati> mbrunati has joined #rdf-wg
13:50:46 <cygri> scribe: cygri
13:50:51 <cygri> scribenick: cygri
13:50:53 <FabGandon> still we could have the transformation before and always work on the transformed version, no?
13:51:04 <zwu2> zakim, mute me
13:51:04 <Zakim> zwu2 should now be muted
13:51:24 <cygri> Topic: Next F2F meeting
13:52:08 <cygri> guus: there's pressure towards balance between european and north american locations
13:52:01 <cygri> LeeF: I'd recommend considering the sort of 2-site w/ video conference F2F that has been successful for SPARQL WG.
13:52:15 <cygri> ... The problem is that for time zones that only really works for US East Coast + UK (or so)
13:52:23 <cygri> ivan: W3C will have technical plenary week
13:52:33 <cygri> ... where several WGs meet
13:52:32 <cygri> ... http://www.w3.org/2011/11/TPAC/
13:52:45 <cygri> ... Santa Clara Marriott, Santa Clara, California, (Silicon Valley) USA 31 October to 4 November 2011
13:52:48 <Souri> Souri has joined #rdf-wg
13:53:10 <cygri> ... I try to convince the RDF apps WG to have their F2F there
13:53:38 <cygri> ... downside is that it's the week after ISWC
13:54:09 <cygri> davidwood: we might want to have the F2F meetings earlier rather than later
13:54:47 <cygri> ivan: july/august not a good time for europeans
13:54:54 <MacTed> MacTed has joined #rdf-wg
13:56:31 <cygri> guus: suppose we would do it at TPAC, for whom would that be an obstacle?
13:57:17 <cygri> SteveH: time difference is a problem
13:58:09 <cygri> davidwood: I question whether we should have a west coast f2f
13:57:47 <gavinc> Sigh.
13:58:11 <cygri> zwu2: CA in US sounds great
13:58:26 <cygri> sandro: how about right before ISWC?
13:59:03 <Zakim> + +1.603.897.aadd
13:59:31 <Souri> zakim, aadd is me
13:59:31 <Zakim> +Souri; got it
13:59:57 <cygri> ivan: other WGs: sparql, rdb2rdf, provenance, government linked data
14:00:05 <zwu2_> zwu2_ has joined #rdf-wg
14:00:38 <cygri> steveh: east coast much easier than west coast
14:00:54 <cygri> sandro: i'm happy to host at W3C, if i can find a room
14:01:02 <cygri> s/W3C/MIT/
14:01:17 <cygri> pfps: happy to host at bell labs
14:01:56 <cygri> guus: so, east coast location, 1st half of october?
14:02:21 <cygri> pfps: better earlier, end of september (more distance to tpac)
14:02:44 <cygri> guus: week of 26th september?
14:02:54 <cygri> SteveH: clash with SemTech London
14:03:11 <cygri> FabGandon: week of 12th of september?
14:04:03 <cygri> SteveH: we could host at Garlik
14:04:16 <cygri> pfps: find someone at oxford?
14:06:11 <cygri> guus: week of 3rd october, boston?
14:06:33 <cygri> sandro: remote participants, are you likely to be able to make this?
14:04:18 <cygri> gavinc: MIT sounds better then Europe
14:06:16 <cygri> ... TPAC sounds the best still
14:06:57 <cygri> ... I can travel if it's in the US; europe less likely
14:06:25 <danbri> (I don't know what I can attend nor where, but prefer east coast as most plausible)
14:07:04 <sandro> zakim, who is on the call?
14:07:04 <Zakim> On the phone I see gavinc, LeeF, AZ, Meeting_Room, zwu2 (muted), AlexHall, Souri
14:07:12 <cygri> LeeF: Yes
14:07:44 <cygri> ... Possibly if it were scheduled with our input :)
14:07:57 <cygri> ... The challenge this time was the date being picked without input, and hving existingcommitments
14:07:13 <cygri> Souri: East Coast is the best for me. Europe is doubtful.
14:07:19 <zwu2_> zakim, unmute me
14:07:19 <Zakim> sorry, zwu2_, I do not know which phone connection belongs to you
14:07:20 <davidwood> davidwood has joined #rdf-wg
14:07:58 <cygri> davidwood: to the remote americans: would you be able to come to a f2f in europe in the future?
14:08:00 <cygri> zwu2: CA is fine. East coast will do too
14:08:06 <cygri> AlexHall: No, I don't anticipate being able to travel to Europe
14:08:17 <cygri> souri: east cost is best, europe problematic
14:08:29 <cygri> AZ: I don't know if will be able to come to the US
14:08:40 <cygri> ... My situation after August is quite unclear
14:08:56 <cygri> davidwood: this tells me we should alternate meetings between europe and US
14:09:04 <cygri> ivan: tpac still best
14:09:37 <cygri> guus: i'll set up a poll
14:09:59 <cygri> Souri: We had a very good setup for SPARQL f2f last time using video connections between Cambridge/MIT and Oxford.
14:10:21 <cygri> ACTION: guus to set up poll regarding F2F date
14:10:21 <trackbot> Created ACTION-35 - Set up poll regarding F2F date [on Guus Schreiber - due 2011-04-21].
14:10:26 <cygri> gavinc: 2 video remote sites would also be excellent
14:11:59 <cygri> guus: options will be: US east cost: Boston or Murray Hill
14:12:07 <cygri> ... and TPAC
14:12:29 <zwu2_> is CA a choice at all?
14:13:00 <gavinc> CA, US ... not CA Canada
14:12:53 <gavinc> well
14:12:43 <gavinc> TPAC is CA
14:13:11 <zwu2_> yes CA, US
14:12:40 <cygri> Topic: Scribing
14:12:53 <cygri> sandro: would be helpful if scribes could use topics and subtopics
14:12:53 <cygri> (IRC commands for scribe are “Topic: xyz” and “Subtopic: xyzxyz”)
14:13:10 <mischat> http://www.w3.org/2011/rdf-wg/meeting/2011-04-13 and http://www.w3.org/2011/rdf-wg/meeting/2011-04-14
14:14:19 <cygri> Topic: RDF document set and finding editors
14:14:29 <cygri> guus: this was on telecon agenda for a long time
14:14:43 <cygri> ... strong preference for not creating completely new set of docs
14:14:50 <cygri> ... but update the existing RDF Core documents
14:15:03 <cygri> ... have new editors and update these documents
14:15:25 <cygri> sandro: seems to depend on how big the changes are
14:15:49 <cygri> guus: for instance RDF Concepts would have to add sections on terminology and other things
14:16:04 <cygri> ... hopefully not too many changes to RDF Semantics
14:16:11 <davidwood> davidwood has joined #rdf-wg
14:16:12 <cygri> ... primer should be completely new rewritten version
14:16:19 <cygri> ... test cases we have to see
14:16:51 <cygri> ivan: test cases were REC in 2004. i don't see why they should be
14:17:16 <cygri> .. formally, would that mean we re-use the same short names?
14:17:31 <cygri> ... so would they formally be new versions of the same documents?
14:18:30 <cygri> cygri: we should use the same short names to avoid having multiple REC documents floating around
14:18:35 <cygri> ivan: what does SPARQL do?
14:18:36 <Zakim> -AZ
14:18:48 <cygri> steveh: (scribe got lost. not yet decided?)
14:18:57 <Zakim> +AZ
14:19:15 <cygri> guus: good guideline: substantial changes => new short name
14:19:28 <cygri> steveh: in SPARQL isn't decided yet
14:19:43 <cygri> sandro: OWL rewrote everything and new short names
14:19:50 <cygri> davidwood: that was not a good idea
14:20:07 <cygri> guus: i don't hear objections, so let's work on that assumption
14:20:16 <sandro> sandro: sounds like we're just talking about 2nd editions of Recs, not new Recs.
14:20:40 <cygri> Subtopic: RDF Concepts
14:20:41 <cygri> guus: these are lots of documents
14:21:01 <cygri> ... RDF Concepts. main change will be graph terminology
14:21:40 <cygri> ivan: and archaization? and XMLLiteral?
14:22:37 <cygri> cygri: i can be editor on that one
14:22:41 <cygri> davidwood: me too
14:22:41 <sandro> guus: eds, Richard and David
14:22:45 <cygri> Subtopic: RDF Semantics
14:22:48 <cygri> guus: RDF Semantics
14:23:29 <cygri> ... ideal would be pfps and PatH
14:23:35 <cygri> pfps: ok
14:23:35 <Zakim> -AZ
14:23:40 <sandro> ACTION: guus to ask Pat to be an editor of RDF Semantics
14:23:41 <trackbot> Created ACTION-36 - Ask Pat to be an editor of RDF Semantics [on Guus Schreiber - due 2011-04-21].
14:24:00 <cygri> Subtopic: RDF Schema
14:24:15 <cygri> guus: RDF Schema
14:24:29 <sandro> Guus: DanBri, will you edit RDF Vocab?
14:24:36 <cygri> danbri: ok
14:24:45 <cygri> sandro: can we change the name to "RDF Schema"?
14:24:57 <sandro> ISSUE: Should we change the title of rdf-schema to use the word "Schema" ?
14:24:57 <trackbot> Created ISSUE-36 - Should we change the title of rdf-schema to use the word "Schema" ? ; please complete additional details at http://www.w3.org/2011/rdf-wg/track/issues/36/edit .
14:25:00 <cygri> Subtopic: Turtle Syntax
14:25:31 <cygri> guus: Turtle
14:25:39 <cygri> ivan: EricP has volunteered to do that
14:26:38 <cygri> mischat: i'm willing to help but might not be able to help much with syntax/grammar
14:27:00 <cygri> ivan: amount of work on turtle might not be much
14:27:13 <cygri> gavinc: I'd be happy to provide test cases?
14:28:43 <cygri> mischat: i'll take it into consideration. if andy wants do do it, i won't feel bad
14:29:02 <cygri> guus: we need to publish FPWDs soon. turtle obvious candidate
14:29:56 <cygri> ... mid-june should be doable
14:27:19 <danbri> I guess the concept we're going for is "2nd Edition" for most of these? sandro/ivan - is that defined in http://www.w3.org/2005/07/pubrules somewhere?
14:27:45 <sandro> danbri, yes.
14:28:11 <sandro> danbri, I've never done it myself, but I've seen it.
14:30:00 <cygri> Subtopic: N-Triples Syntax
14:30:32 <cygri> guus: possible other documents: n-triples
14:31:08 <cygri> sandro: n-triples might be appendix of turtle, or appendix of test cases
14:31:15 <Steven> Steven has joined #rdf-wg
14:31:21 <cygri> guus: might be a separate piece of work anyways
14:31:29 <cygri> ... spread out the responsibilities
14:31:58 <cygri> mischat: AndyS's page http://www.w3.org/2011/rdf-wg/wiki/N-Triples-Format
14:32:01 <cygri> cygri: andy did a wiki page on n-triples
14:33:06 <zwu2_> zakim, unmute me
14:33:06 <Zakim> sorry, zwu2_, I do not know which phone connection belongs to you
14:34:00 <cygri> sandro: zwu2, can you be ed of n-triples to make sure nothing bad happens to it?
14:34:02 <cygri> zwu2: i can do that
14:34:08 <zwu2_> zakim, who is here
14:34:09 <Zakim> zwu2_, you need to end that query with '?'
14:34:14 <zwu2_> zakim, who is here?
14:34:14 <Zakim> On the phone I see gavinc, LeeF, Meeting_Room, zwu2, AlexHall, Souri
14:34:20 <sandro> sandro: does it matter to you, Zhe, whether you are credited as an editor for that work?
14:34:27 <sandro> Zhe: I'm okay either way there.
14:35:21 <cygri> Souri: I can help on the n-triples -- my org (Oracle) has heavy investment on n-triples
14:34:48 <danbri> (asking informally, I'm told that "Second Editions" typically get their own short-name in /TR/ --- but to check with the webmaster team)
14:35:22 <cygri> Subtopic: RDF/JSON
14:35:23 <cygri> guus: json
14:35:24 <cygri> davidwood: i'll take an action to ask talis about a possible editor for the json rdf-to-rdf thing
14:35:28 <ivan> zakim, who is here?
14:35:28 <Zakim> On the phone I see gavinc, LeeF, Meeting_Room, zwu2, AlexHall, Souri
14:35:43 <zwu2_> q-
14:36:01 <cygri> cygri: souri just volunteered to help on n-triples
14:36:15 <cygri> guus: anyone else for rdf/json?
14:36:33 <cygri> ivan: only other person i can think of is tomayac
14:36:47 <sandro> action: wood to ask Talis to provide an editor for JSON
14:36:47 <trackbot> Created ACTION-37 - Ask Talis to provide an editor for JSON [on David Wood - due 2011-04-21].
14:36:56 <cygri> ... asking him would be a good idea
14:37:13 <cygri> action: ivan to ask thomas about RDF/JSON editorship
14:37:13 <trackbot> Created ACTION-38 - Ask thomas about RDF/JSON editorship [on Ivan Herman - due 2011-04-21].
14:38:00 <cygri> Subtopic: JSON Recipes Note
14:38:10 <cygri> guus: JSON recipes note
14:38:43 <cygri> ... we had some volunteers: mishat, NickH, mbrunati
14:38:50 <cygri> ... and i'll volunteer one of my postdocs
14:38:58 <cygri> yvesr: i want to contribute to that note as well
14:39:28 <cygri> s/mishat/mischat/
14:39:35 <cygri> Subtopic: RDF Primer
14:39:37 <cygri> guus: rdf primer
14:39:42 <cygri> ... i volunteer
14:39:54 <cygri> LeeF: I would like to devote time to the rdf primer, though not necessarily as an editor.
14:39:59 <cygri> FabGandon: me
14:40:05 <cygri> pchampin: me
14:40:18 <cygri> cmatheus: me
14:40:56 <cygri> ivan: we need one, max two people to lead it, and perhaps a larger number of contributors
14:43:03 <mischat> :)
14:43:27 <davidwood> davidwood: Guus and Fabian to edit the Primer, with many contributors expected.
14:43:39 <cygri> cygri: so primer will have guus, FabGandon as lead editors, with possibly many contributors
14:44:00 <cygri> Subtopic: TriG/N-Quads Syntax
14:45:45 <cygri> cygri: on TriG/N-Quads, probably not a new doc but part of turtle ... i can help there
14:46:00 <cygri> Subtopic: RDF/XML Syntax
14:46:16 <cygri> ivan: RDF/XML ... we may not touch it at all, but might want to check with henry
14:47:33 <cygri> sandro: henry made clear that he won't do the RDF/XML work himself
14:47:48 <cygri> ... are there errata against RDF/XML?
14:48:24 <cygri> FabGandon: i'm happy to apply the errata
14:46:18 <zwu2_> I don't hate rdf/xml at all
14:46:52 <zwu2_> I just don't write manually in rdf/xml much
14:46:59 <mischat> i am a bit of a fan, it has the most robust tooling
14:47:10 <mischat> i dont like writing any rdf by hand
14:47:27 <sandro> I happily misread that, mischat, as the most robust trolling.
14:47:42 <AlexHall> the problem with rdf/xml is when newcomers confuse the xml syntax with the rdf semantics
14:47:48 <danbri> (btw re Turtle, http://www.w3.org/DesignIssues/N3Alternatives might be interesting)
14:49:44 <yvesr> AlexHall, and people using xpath on rdf/xml
14:49:52 <yvesr> caused us so much problems at the BBC
14:50:06 <yvesr> you change serialiser, and you end up breaking applications
14:50:09 <zwu2_> tricky to use xpath I guess
14:50:32 <yvesr> maybe an xpath-able version of rdf/xml would be in order? don't know though...
14:50:33 <gavinc> zwu, tricky is an understatement
14:50:40 <zwu2_> :)
14:51:38 <AlexHall> yvesr, it's in the charter as a time-permitting feature
14:49:00 <cygri> Subtopic: Tools for editors
14:49:56 <davidwood> q?
14:50:23 <cygri> danbri: practicalities around CVS access? use mercurial?
14:50:58 <cygri> sandro: four options: 1. edit xhtml in cvs; 2. use xmlspec
14:51:10 <danbri> w3c mercurial repo: https://dvcs.w3.org/hg/
14:51:48 <cygri> ... 3. respec (an html5 and js thing)
14:50:48 <danbri> danbri: http://dev.w3.org/2009/dap/ReSpec.js/documentation.html
14:52:28 <cygri> ivan: respec works well for me
14:53:21 <cygri> ... only downside: we have to transform old docs into respec. initial price.
14:53:34 <pchampin> pchampin: the Media Annotation WG uses respec for the API document
14:53:41 <pchampin> pchampin: http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html
14:53:53 <cygri> sandro: 4th option: use the wiki. there's a script to put stuff from xhtml into the wiki, and another for the way back
14:54:12 <danbri> I was thinking more about the testcases repository (as a consensus documentation tool / decision record) -> should that be w3c cvs datespace again, or mercurial?
14:55:21 <cygri> ivan: (more respec advocacy)
14:55:51 <cygri> sandro: if we don't use my code, i won't do the pubs
14:55:59 <cygri> FabGandon: upside of using the wiki: no cvs
14:56:11 <cygri> ivan: downside is that ppl hate wiki markup
14:56:34 <cygri> sandro: i should look at respec and look at how it handles [something]
14:56:38 <sandro> ACTION: sandro look at respec's handling of references
14:56:38 <trackbot> Created ACTION-39 - Look at respec's handling of references [on Sandro Hawke - due 2011-04-21].
14:57:05 <cygri> SteveH: don't use xmlspec
14:57:36 <cygri> ... especially if only small changes, just do them in xht�ml
14:58:10 <mischat> mischat: votes for a distributed version control system instead of a centralised one
14:59:17 <Souri> Souri: based upon my R2RML editing experience: +1 for option 1 (edit xhtml in cvs); +0.5 for option 4 (wiki)
14:57:35 <danbri> so should RDFS spec be in HTML/RDFa? if so, which vocabulary terms should it include RDF claims about? rdf+rdfs?
14:59:19 <danbri> http://www.w3.org/blog/systeam/2010/06/16/why_we_chose_mercurial_as_our_dvcs/
14:59:20 <cygri> Topic: AOB
14:59:59 <sandro> sandro: (discussion of whether emacs can reify skolemized bnodes....)
15:00:03 <yvesr> yvesr: (in rdf/xml...)
15:02:01 <Zakim> -gavinc
15:02:02 <sandro> Bye remote folks!
15:02:06 <zwu2_> bye and have a safe trip home!
15:02:17 <manu> Have a safe trip back home to everyone there - :)
15:02:31 <Zakim> -zwu2
15:02:38 <AlexHall> AlexHall has left #rdf-wg
15:02:39 <Zakim> -AlexHall
15:02:46 <cygri> guus: adjourned
15:02:57 <cygri> trackbot, generate minutes
15:02:57 <trackbot> Sorry, cygri, I don't understand 'trackbot, generate minutes'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
15:03:11 <cygri> RRSAgent, generate minutes
15:03:11 <RRSAgent> I have made the request to generate http://www.w3.org/2011/04/14-rdf-wg-minutes.html cygri
15:03:14 <Zakim> -Souri
15:03:54 <Zakim> -LeeF
# SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00001723
</nowiki></pre>

Chatlog 2011-04-14

Fgandon — Thu, 14 Apr 2011 14:20:08 GMT

Fgandon:

{{chatlog|rrsagent=http://www.w3.org/2011/04/14-rdf-wg-irc.txt|chatlog={{fullurl:{{PAGENAME}}}}}}
<pre><nowiki>
<sandro> Guest: Paul Groth
<sandro> Guest: Steven Pemberton
<sandro> Present: Ivan, Mischa, Dan_Brickley, Matheus, Peter, Jan, Baget, Humfrey, Yves, Cygri, Champin, Fabien, Steve, Matteo, Sandro, Wood, Guus
<sandro> Remote: AZ, Gavin, Zhe, Corby, MacTed, Pat, Tom, AlexHall, webr3, LeeF
02:28:54 <MacTed> MacTed has joined #rdf-wg
05:17:45 <mbrunati> mbrunati has joined #rdf-wg
05:21:57 <mbrunati> mbrunati has joined #rdf-wg
05:22:16 <mbrunati> mbrunati has left #rdf-wg
06:21:58 <pgroth> pgroth has joined #rdf-wg
06:47:46 <pgroth_> pgroth_ has joined #rdf-wg
06:51:46 <tomlurge> tomlurge has joined #rdf-wg
07:11:44 <danbri> danbri has joined #rdf-wg
07:13:25 <OlivierCorby> OlivierCorby has joined #rdf-wg
07:18:50 <FabGandon> FabGandon has joined #rdf-wg
07:20:56 <ivan> ivan has joined #rdf-wg
07:21:03 <tomayac> tomayac has joined #rdf-wg
07:21:55 <tomayac> bonjour monsieur!
07:24:23 <pgroth> pgroth has joined #rdf-wg
07:30:32 <AZ> AZ has joined #rdf-wg
07:31:34 <mbrunati> mbrunati has joined #rdf-wg
07:32:13 <pchampin> pchampin has joined #rdf-wg
07:33:17 <tomayac> "the conference is restricted at this time" => have the dial-in details changed? using rdfwg1# code
07:34:05 <FabGandon> should work but we haven't called yet and a number of participants are still missing in the room
07:34:26 <tomayac> 9:30 sharp-ish ;-)
07:34:27 <PatH> PatH has joined #rdf-wg
07:39:52 <Guus> Guus has joined #rdf-wg
07:40:04 <SteveH> SteveH has joined #rdf-wg
07:40:19 <Steven_> Steven_ has joined #rdf-wg
07:40:29 <Steven_> zakim, list
07:40:29 <Zakim> I see SW_RDFWG(RDFWG1)2:00AM active and no others scheduled to start in the next 15 minutes
07:40:43 <mischat> mischat has joined #rdf-wg
07:40:49 <FabGandon> we will have to do an adhoc teleconf the teleconf chanel is not available for today
07:41:10 <pfps> pfps has joined #rdf-wg
07:41:13 <Steven_> zakim, code?
07:41:13 <Zakim> the conference code is 733941 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Steven_
07:41:38 <FabGandon> trying again...
07:41:39 <cmatheus> cmatheus has joined #rdf-wg
07:41:40 <Steven_> zakim, who is on the call?
07:41:40 <Zakim> On the phone I see OlivierCorby, OlivierCorby.a, OlivierCorby.aa, OlivierCorby.aaa
07:41:41 <cygri> cygri has joined #rdf-wg
07:41:55 <davidwood> davidwood has joined #rdf-wg
07:42:13 <PatH> Same message here
07:42:23 <tomayac> same here
07:42:45 <davidwood> We're working on it - please stand by
07:42:56 <Steven_> zakim, room for 15 for 600 minutes?
07:42:58 <Zakim> ok, Steven_; conference Team_(rdf-wg)07:42Z scheduled with code 26631 (CONF1) for 600 minutes until 1742Z
07:43:06 <davidwood> We'll announce a new dial in code shortly
07:43:12 <FabGandon> dial 26631
07:43:18 <davidwood> PLEASE USE CONFERENCE CODE 26631
07:43:35 <Steven_> Steven_ has changed the topic to: CODE is 26631
07:43:41 <davidwood> Sorry for the confusion. Our bridge was not configured as we expected.
07:44:04 <Steven_> zakim, who is on the call?
07:44:04 <Zakim> On the phone I see OlivierCorby, OlivierCorby.a, OlivierCorby.aa, OlivierCorby.aaa
07:44:21 <NickH> Good Morning!
07:44:25 <Steven_> zakim, this is rdf-wg
07:44:25 <Zakim> Steven_, this was SW_RDFWG(RDFWG1)2:00AM
07:44:27 <Zakim> ok, Steven_; that matches Team_(rdf-wg)07:42Z
07:44:33 <Steven_> zakim, who is on the call?
07:44:34 <Zakim> On the phone I see Meeting_Room, PatH, tomayac, OlivierCorby
07:44:40 <OlivierCorby> Hi, phone is ok now
07:44:48 <Zakim> +AZ
07:45:46 <PatH> Sound quality is rather poor today
07:45:50 <FabGandon> scribe: Fabien
07:46:31 <gavinc> gavinc has joined #rdf-wg
07:46:40 <FabGandon> guus: identifying the 4 issues to be discussed
07:46:50 <Steven> 30, 31, 15
07:46:51 <FabGandon> ... 5 30 31 and 15
07:46:57 <gavinc> zakim, the code is?
07:46:57 <Zakim> I don't understand your question, gavinc.
07:47:01 <JFB> JFB has joined #rdf-wg
07:47:03 <Steven> zakim, code?
07:47:03 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Steven
07:47:32 <FabGandon> cygri: 31 is a bit out of the list
07:47:52 <mischat> http://www.w3.org/2011/rdf-wg/track/issues/30
07:48:06 <FabGandon> davidwood: sugest we start with issue 30
07:48:06 <Zakim> +gavinc
07:48:07 <FabGandon> Topic: Aligning SPARQL notions and RDF 1.1 g-* notions.
07:48:18 <FabGandon> ISSUE-30: How does SPARQL's notion of RDF dataset relate our notion of multiple graphs?
07:48:18 <trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added
07:48:20 <Steven> s/sugest/suggest/
07:49:47 <mischat> http://www.w3.org/TR/rdf-sparql-query/#rdfDataset <-- sparql dataset as per rdf sparql query 1.0
07:50:23 <FabGandon> Cygri : SPARQL defines Dataset as data data model used in SPARQL query i.e. collection of graph = one default graph and a set of named graphs <IRI,Graph>
07:50:33 <tomayac> AZ: +1, sound is low quality :-(
07:50:47 <mischat> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal
07:51:19 <FabGandon> ... they use the term named graph and it is a g-snap in our terminology because immutable
07:51:50 <pchampin> http://www.w3.org/TR/2009/WD-sparql11-update-20091022/#sec_graphStore
07:52:37 <PatH> +q
07:52:43 <FabGandon> ... graph store :"unlike an RDF dataset, named graphs can be added to or deleted from a graph store"
07:53:03 <FabGandon> ivan: the mutability is on the store not on the graph
07:53:47 <pchampin> pchampin has joined #rdf-wg
07:53:49 <FabGandon> ... are the graphs explicitly immutable ?
07:53:51 <PatH> sound quality is poor but usable
07:54:26 <FabGandon> cygri : the spec are not specific on this ; not really addressed
07:54:57 <Guus> q?
07:55:17 <FabGandon> ivan: IMO the dataset is a set of g-boxes
07:55:38 <Guus> zakim, who is here?
07:55:38 <Zakim> On the phone I see Meeting_Room, PatH, tomayac, OlivierCorby, AZ, gavinc
07:55:52 <FabGandon> cygri: the evaluation of a SPARQL query is defined against an immutable dataset
07:56:00 <gavinc> gavinc has joined #rdf-wg
07:56:09 <davidwood> q+ to discuss graph store relationships to g-boxes and g-snaps.
07:56:34 <ivan> q?
07:56:39 <ivan> ack PatH
07:56:42 <davidwood> ack PatH
07:56:47 <FabGandon> PatH: we shouldn’t be agnostic we should say what the graph is e.g. we should say it is a g-box that has a name
07:57:25 <FabGandon> cygri: SPARQL uses the term named graph, the IRI is the name for the graph in SPARQL
07:57:56 <FabGandon> /me scribe lost
07:57:59 <mischat> PatH: there is no need to introduce confusion
07:57:59 <AZ> We can certainly see a SPARQL dataset as a snapshot of the graph store (the graph store is mutable but the snapshot is fixed to define what's the result of a query)
07:58:47 <FabGandon> PatH: RDF should specify the semantic of names if there is to be an interpretation of that name
07:59:14 <FabGandon> ... if we don't we leave the question open to endless discussions.
07:59:53 <davidwood> +1 to PatH, in that if we define what we mean we won't have misunderstandings as we do with "information resource" or "what *is* RDF".
08:00:41 <JFB> +1 to PatH: if there is some specifing meaning to names, it must be formalized in RDF Semantics
08:00:42 <FabGandon> PatH: we need to declare in a declarative text what the interpretation is for the IRI naming a graph.
08:01:34 <FabGandon> cygri: Can we use the name of doc as the name of graph.
08:01:44 <FabGandon> PatH: we can't prevent that
08:02:06 <pchampin> q+
08:03:10 <ivan> ack davidwood
08:03:10 <Zakim> davidwood, you wanted to discuss graph store relationships to g-boxes and g-snaps.
08:03:57 <FabGandon> davidwood: several graph stores are maintainers of g-boxes implemented as multiple reader single writer
08:04:38 <FabGandon> ... when a query comes in they generate sets of g-snaps from the current state of the g-boxes.
08:05:12 <FabGandon> SteveH: yes that's what happens.
08:05:30 <PatH> we have yet to specify what a g-box is semantically. We will have to speak of states and g-snaps there.
08:05:40 <FabGandon> davidwood: SPARQL queries are dealing with a sub-set of our world.
08:06:08 <ivan> q?
08:06:22 <PatH> in otherr words, this box/snap issue will have to be dealt with there in any case.
08:06:29 <ivan> ack pchampin
08:06:31 <sandro> guus: When you do a SPARQL Query, you are querying at a point in time, so you are querying against the set of g-snaps which is the current contents of those g-boxes.
08:06:32 <FabGandon> Guus: at that point there is no conflict between our view and SPARQL
08:06:40 <davidwood> PatH: Yes
08:06:56 <davidwood> Yes, there is no conflict.
08:07:02 <PatH> who is speaking?
08:07:23 <PatH> ta
08:07:40 <sandro> pchampin: I want to be able to use my own arbitrary data as the "graph" name in SPARQL.
08:08:00 <FabGandon> pchampin: I feel uncomfortable with fixing the semantics of the relation name of graphs and the store ; it depends on my use of the quadstore
08:08:54 <sandro> q?
08:08:57 <FabGandon> cygri: I don’t see this machinery as answering a large demand ; I don’t feel there is a huge demand on fixing that semantics
08:09:10 <PatH> +q
08:09:27 <FabGandon> ... what do we gain from defining the interpretation of named graphs ?
08:09:56 <pchampin> sometimes, I name a graph in my quad store with the URI of the g-box this graph comes from,
08:10:08 <pchampin> sometimes, I name it with the URI of the resource it is about
08:10:09 <ivan> ack PatH
08:10:09 <FabGandon> danbri: are tou confortable with the level of interoperability that would set?
08:10:36 <sandro> +1 danbri we need more interop between datastores (there is breakage when people use different styles of URIs)
08:10:39 <sandro> q+
08:11:10 <pfps> I don't know how the RDF semantics is going to speak to things like timestamping downloads of RDF documents.
08:11:38 <FabGandon> PatH: defining the semantics will not have so much implication on the implementation that seems to be feared. The idea is not to interfere with the machinery.
08:11:42 <davidwood> ack PatH
08:11:46 <danbri> it's something like a lack of mechanism for saying how *my* sparql store is managed. One might use 'the URI I fetched = the graph URI', another uses a uuid: per-transaction, and a table-of-contents history graph. Sure I can send SPARQL queries across both at same time, but the results might be barely meaningful.
08:11:47 <davidwood> ack sandro
08:13:10 <FabGandon> sandro: the machinery will complain for instance if I use the URI of a graph to identify a person and these classes are disjoint.
08:13:59 <danbri> PatH, the triples could have semantics, but their bundling and tagging with graph URIs could lack semantics
08:14:03 <pchampin> q+ to talk about named graphs in SPARQL endpoints
08:14:10 <FabGandon> SteveH: there are many use cases where we don't want to do some logical inference on top of RDF.
08:14:53 <pchampin> +1 danbri: I write no *triple* stating that a person is a graph :-)
08:15:01 <sandro> Pat: It violates the semantics of the language to have the name of a graph also be the name of a person.
08:15:15 <FabGandon> cygri: How does the fact of using a URI for a graph and a person raises a problem in SPARQL?
08:15:20 <AZ> A name can name several things, like in OWL 2 DL, a name can name a class and a property
08:15:35 <sandro> q+
08:15:38 <pgroth> could we do both? a name and a tag?
08:15:40 <AZ> and classes are disjoint from properties in OWL 2 DL
08:15:42 <FabGandon> PatH: lets not call it the names then.
08:15:48 <Guus> q?
08:16:20 <sandro> q+ to return to danbri's question
08:16:43 <sandro> +1 pat
08:16:51 <FabGandon> pfps: RDF is agnostic as to the use of the same IRI to name a graph or a person.
08:16:51 <ivan> ack pchampin
08:16:51 <Zakim> pchampin, you wanted to talk about named graphs in SPARQL endpoints
08:17:21 <sandro> pchampin: I'm using the "graph id" as merely a "tag"
08:17:38 <FabGandon> pchampin: ok to say it’s not really a name but merely a tag.
08:18:07 <sandro> +100000 the world here would be MUST CLEARER if SPARQL forced you to only use graph IDs that you own!!
08:18:14 <sandro> s/MUST/MUCH/
08:18:24 <cygri> sandro -100000
08:18:29 <davidwood> ack sandro
08:18:29 <Zakim> sandro, you wanted to return to danbri's question
08:18:56 <pfps> sandro - so you think that you shouldn't use "anyone else's" IRIs in a named graph?
08:19:03 <cygri> q+ to disagree with sandro -- web crawling use case
08:19:34 <FabGandon> sandro: I wish SPARQL restricted you to use only URIs that you own i.e. use graphs in a domain you control
08:20:01 <danbri> sandro, that feels to me like having the SQL spec specify that you can only store things that are true
08:20:09 <pchampin> I sure was not suggesting to restrict SPARQL... :-/
08:20:35 <pchampin> just pointing out that its flexibility allows for different practices... beyong "naming according to Pat"
08:20:41 <FabGandon> cygri: strong use case again that : when you crawl the web you want to use the URI from where you got the data.
08:20:42 <Guus> q?
08:20:51 <Guus> ack cygri
08:20:51 <Zakim> cygri, you wanted to disagree with sandro -- web crawling use case
08:21:01 <yvesr> q?
08:21:17 <FabGandon> sandro: it may be more efficient but you create interoperability problems.
08:21:30 <pgroth> q+
08:21:34 <sandro> Utility is at odds with Interoperability.
08:21:37 <PatH> hard to hear..
08:21:44 <sandro> Local utility vs Global utility.
08:21:53 <yvesr> another use case is ACL on quad stores
08:22:06 <davidwood> ack pgroth
08:22:15 <FabGandon> pchampin: not suggesting restricting what SPARQL allows to do ; just advocating flexibility.
08:22:41 <cygri> q+ to talk about n3
08:22:44 <FabGandon> pgroth: I wonder if we don't need a typing mechanism.
08:22:44 <sandro> pgroth: There's "naming graph" and there's graph tags.
08:22:51 <ivan> q?
08:22:55 <ivan> ack cygri
08:22:55 <Zakim> cygri, you wanted to talk about n3
08:23:39 <FabGandon> cygri: if you want a graph associated with a URI in N3 you need to put a predicate in-between.
08:23:57 <pfps> q+
08:24:09 <danbri> q: is this OK SPARQL? http://pastebin.com/raw.php?i=TaJVsste
08:24:18 <pgroth> q+
08:24:19 <FabGandon> ... there is something in the middle that indicates the relation, don't restrict that because in SPARQL it is not restricted.
08:24:40 <Guus> ack pfps
08:24:47 <pgroth> ack pgroth
08:25:19 <yvesr> danbri, i guess it would - why wouldn't it?
08:25:42 <FabGandon> pfps: in RDF everything is a resources: a graph must be an resource or not ; how can we disconnect graph from that if we name them with IRI?
08:26:01 <danbri> q+ to try http://pastebin.com/raw.php?i=TaJVsste
08:26:07 <davidwood> q?
08:26:24 <pchampin> q+
08:26:52 <FabGandon> Guus: we need to identify the things we do agree on.
08:26:55 <davidwood> ack danbri
08:26:55 <Zakim> danbri, you wanted to try http://pastebin.com/raw.php?i=TaJVsste
08:26:59 <ivan> ack danbri
08:27:14 <PatH> sounds like a sparql RDF dataset is not a collection of named graphs. Which surprises me, but I can live with.
08:27:20 <FabGandon> danbri: I want to talk about this test case http://pastebin.com/raw.php?i=TaJVsste
08:28:14 <FabGandon> ... this is a SPARQL query querying different databases.
08:28:36 <FabGandon> ... can we name graphs with mailto:bla@bla.bla
08:28:38 <PatH> but see what pat just wrote.
08:29:07 <PatH> +q
08:29:08 <FabGandon> yes we can
08:29:37 <FabGandon> davidwood: some people say we should always use http://
08:29:55 <FabGandon> danbri: there is a drift from using http:// URIs
08:30:07 <FabGandon> SteveH: I don't see anything wrong with that.
08:30:25 <sandro> sandro: This is just neats vs scruffies --- the graph might be a (scruffy) tag, or might be a name of a proper RDF graph.
08:30:29 <FabGandon> danbri: what about the provenance perspective?
08:30:34 <pfps> well, a SPARQL RDF dataset is defined as potentially containing "named graphs" as this is the first (as far as I know) W3C mention of "named graph", then SPARQL wins and SPARQL RDF datasets have named graphs
08:30:40 <Guus> q?
08:31:10 <pfps> the upshot of this is that the RDF WG may need a new name for what we have been calling named graphs
08:31:27 <FabGandon> pgroth: we care about pointing at a resource or at a graph talking about a resource.
08:31:37 <FabGandon> ... we need to be able to point at the content.
08:32:04 <PatH> pfps, suggest rather we keep named graphs but allow datasets to be something else.
08:32:30 <danbri> so my example lets me represent the (likely derrived from other stuff) info that Pat says Guus is the name of the holder of his homepage
08:32:47 <ivan> ack pchampin
08:32:52 <pfps> then we need to quickly get SPARQL not to "use up" this name - oops too late, named graphs is already in SPARQL 1.0
08:33:06 <Guus> q?
08:33:08 <davidwood> q?
08:33:40 <pgroth> i like the idea of a default interpretation
08:33:47 <FabGandon> pchampin: graphs are resources they need naming and not necessarily a named attached to a SPARQL endpoint.
08:33:51 <pgroth> that the iri is the name of the graph
08:34:10 <SteveH> q+ to talk about <uri> :relation <graph>
08:34:33 <FabGandon> pfps: do RDF graphs have to be resources ?
08:34:55 <danbri> http://www.w3.org/TR/rdf-mt/#gloss ''Resource (n.)(as used in RDF)(i) An entity; anything in the universe. (ii) As a class name: the class of everything; the most inclusive category possible.''
08:35:09 <PatH> aaaargh. what are 'levels'????
08:35:16 <FabGandon> cygri: graphs are in the abstract syntax; resources are in the model theory
08:36:18 <FabGandon> pchampin: graphs are resources
08:36:23 <sandro> pfps: We have A and Not-A (where A=Graphs are Resources)
08:36:24 <ivan> ack PatH
08:36:25 <davidwood> ack PAtH
08:36:32 <pfps> s/are/must be/
08:37:20 <sandro> pat: Of COURSE graphs are resources. The model theory clearly says everything is a resource.
08:37:24 <cygri> q+
08:37:26 <JFB> +1 everything is a resource, if I am, why wouldn't a graph be ?
08:37:28 <FabGandon> PatH: there are no such notions of levels ; thats not the pb.
08:37:45 <cygri> q-
08:37:50 <pchampin> +1
08:37:54 <sandro> pat: We could say that SPARQL Datasets are about tagged graphs NOT naming.
08:37:55 <SteveH> +1
08:37:57 <sandro> +1 pat
08:37:59 <mischat> +1
08:38:00 <danbri> +1
08:38:12 <yvesr> +1
08:38:24 <danbri> q+ to suggest [eventual] best practice note on how *in practice* people are associating URIs with bundles-of-triples
08:38:34 <FabGandon> ... if we say we tag graphs and not we name then we can stop arguing
08:39:02 <AZ> But then, how one talks about a graph in triples?
08:39:27 <ivan> q?
08:39:29 <FabGandon> davidwood: I need a clarification on the difference between the name and a tag.
08:39:30 <ivan> ack SteveH
08:39:30 <Zakim> SteveH, you wanted to talk about <uri> :relation <graph>
08:40:14 <FabGandon> PatH: the difference is in the relation, tag is neutral.
08:40:16 <danbri> 'bundles'
08:40:30 <pgroth> why can't we have a default interpretation
08:40:31 <pgroth> ?
08:40:48 <sandro> possible consensus: SPARQL "named graphs" are not "named" in the logical sense.
08:40:58 <cygri> +1 ivan
08:40:59 <danbri> pgroth, because there are multiple equally respectable default db management habits
08:41:27 <gavinc> FROM NAMED
08:42:01 <sandro> :'(''
08:42:20 <FabGandon> ivan: we don't have much choice, the term "named graph" is already used in the whole SPARQL community.
08:42:40 <pgroth> danbri, but default doesn't mean you have to
08:43:14 <sandro> sandro: Can we at least tell people this is a misleading name?
08:43:19 <SteveH> +1
08:43:37 <davidwood> ack SteveH
08:43:56 <PatH> potentially misleading
08:44:02 <danbri> From a SPARQL perspective, it is legitimate to (a) tag graph-bundles with URI the triples were dereferenced from (b) to tag graph-bundles with URI for the party who made the claim (c) or a trasaction ID, eg. uuid:
08:44:13 <sandro> More Consensus: SPARQL "named graphs" are not necessarily "named" in the logical sense, or RDF graphs.
08:44:25 <sandro> * FabGandon we have "tagged boxes" and we will call them "named graphs"
08:44:38 <pchampin> q+ to raise some concern about the semantics of NQuads, then
08:44:49 <davidwood> ack danbri
08:44:49 <Zakim> danbri, you wanted to suggest [eventual] best practice note on how *in practice* people are associating URIs with bundles-of-triples
08:44:56 <PatH> can we introduce the terminology of "sparql naming"
08:45:12 <davidwood> q+ to as about naming of RDF
08:45:26 <FabGandon> danbri: may be we should first document the current uses of "named graphs"
08:45:40 <mischat> q+ to ask about the difference in FROM NAMED and the GRAPH URI
08:45:52 <yvesr> +1
08:45:57 <sandro> +1 danbri: document the common practices for using sparql graphs names.
08:45:58 <PatH> I dont want to start policing sparql usage.
08:46:09 <FabGandon> ... I have three in mind but may be we should have a wiki page to collect them
08:46:12 <davidwood> No, we certainly don't
08:46:13 <SteveH> q?
08:46:13 <danbri> path --- absolutely not policing, but documenting
08:46:17 <yvesr> PatH, not policing, surevying what's actually happening
08:46:18 <PatH> just keep terminology clean
08:46:22 <PatH> OK
08:46:27 <danbri> -- so we can send SPARQL queries that use GRAPH to services managed in a certain fashion
08:46:51 <FabGandon> pchampin: NQuads is used to dump a full store
08:46:55 <danbri> eg. see http://pastebin.com/TaJVsste ... maybe you have a DB I could usefully send that query to; but maybe Ivan's SPARQL db is managed with a different GRAPH/URI policy
08:46:59 <ivan> q?
08:47:02 <danbri> ...so naming those deployment patterns
08:47:02 <mischat> i do think that best practices for linked data re: graphs and named graphs
08:47:03 <Guus> ack davidwood
08:47:03 <Zakim> davidwood, you wanted to as about naming of RDF
08:47:03 <ivan> ack pchampin
08:47:05 <FabGandon> ivan: NQuad is juts syntax
08:47:06 <Zakim> pchampin, you wanted to raise some concern about the semantics of NQuads, then
08:47:20 <danbri> FDR!
08:47:39 <FabGandon> davidwood: concerned about redefining everything.
08:48:09 <FabGandon> sandro: SPARQL named graphs has little to do with named g-boxes.
08:48:13 <ivan> ack mischat
08:48:13 <Zakim> mischat, you wanted to ask about the difference in FROM NAMED and the GRAPH URI
08:48:23 <FabGandon> Guss: SPARQL is agnostic about.
08:49:04 <FabGandon> mischat: It is nice that SPARQL doesn’t force you to use the URL of the doc for the named graph.
08:49:23 <sandro> steve: FROM NAMES pulls a graph from some undefined place and puts it in the set of named graphs, but... [lost]
08:49:30 <sandro> s/NAMES/NAMED/
08:49:32 <Zakim> -OlivierCorby
08:50:05 <FabGandon> SteveH: the exact behavior of the default graph changes from store to store.
08:50:20 <Zakim> + +34.92.38.aaaa
08:50:25 <cygri> +1 mischat
08:50:32 <yvesr> +1
08:50:42 <danbri> yup
08:50:52 <OlivierCorby> Zakim, aaaa is me
08:50:52 <Zakim> +OlivierCorby; got it
08:50:59 <FabGandon> mischat: the best practices could be in a note and not in rec.
08:51:28 <Guus> q?
08:51:54 <FabGandon> davidwood: we don't want to get in the way of LOD
08:51:57 <raphael> raphael has joined #rdf-wg
08:52:22 <pchampin> q?
08:53:06 <FabGandon> ivan: too early to phrase it as a resolution ?
08:53:11 <sandro> PROPOSED: Close ISSUE-30 saying that SPARQL Datasets and Named Graphs have no strict or formal connection to a logic of RDF "naming" of Graphs.
08:53:29 <pfps> PROPOSED the upcoming notion of multiple graphs is not necessarily the same as named graphs in SPARQL
08:53:49 <danbri> perhaps - SPARQL quads are not the kinds of thing that can be interpreted as True vs False; RDF WG quads might or might not add more...
08:54:11 <PatH> suggest that the key point is that just because sparql uses a uri to, um, identify a graph, it does not mean that the uri can be used to refer to the graph in an rdf triple.
08:54:52 <FabGandon> ivan: we currently have no formal connection between the name and the graph in RDF
08:54:53 <danbri> ie. we can ask if the triple "uri-for-guus :homepage http://www.cs.vu.nl/~guus/" is true or not; but we can't yet ask if the quad "{uri-for-graph} uri-for-guus :homepage http://www.cs.vu.nl/~guus/" is true or false
08:55:32 <AZ> PatH +1
08:55:42 <danbri> (path, +1 to what?)
08:55:53 <FabGandon> Guss: who agrees with PatH ?
08:56:13 <AZ> +1
08:56:26 <FabGandon> PatH: you can use the URI but there is no guaranty that it refers to the graph.
08:56:27 <sandro> sandro: Pat means "refer" in a model theory sense, not a computer science sense.
08:57:05 <gavinc> So what does: SELECT ?s WHERE {GRAPH ?s { ?s ?p ?o }} end up meaning in this case?
08:57:17 <FabGandon> yvesr: we don't know what a multiple graph is and therefore can we talk about it in a resolution?
08:57:56 <zwu2> zwu2 has joined #rdf-wg
08:58:15 <Steven> s/Guss/Guus/
08:58:25 <FabGandon> ivan: when we have clarified notions then we can come back to that question.
08:58:28 <yvesr> we can't resolve an issue where half of the question is still undefined
08:58:56 <PatH> i like 'thruth'
08:59:07 <FabGandon> ... the issue should be postponed.
08:59:11 <danbri> quadly thruthyness
08:59:22 <ivan> rrsagent, pointer?
08:59:22 <RRSAgent> See http://www.w3.org/2011/04/14-rdf-wg-irc#T08-59-22
08:59:22 <PatH> :-)
08:59:32 <FabGandon> Guus: we can close that issue and open and more precise one.
08:59:37 <zwu2> Sandro, I got "conference restricted at this time" from zakim
08:59:37 <JFB> +1 for semantics of a predicate that would capture SPARQL's behaviour, but we're not ready yet for that
08:59:54 <yvesr> issue-30 might be dependent on issue-15
08:59:55 <sandro> zakim, what is the code?
08:59:55 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), sandro
09:00:01 <zwu2> thanks
09:00:20 <sandro> sorry, zwu2 we had to use a different code.
09:00:35 <Zakim> +zwu2
09:00:36 <FabGandon> pchampin: this question is linked to issue 15 http://www.w3.org/2011/rdf-wg/track/issues/15
09:00:44 <sandro> issue-15?
09:00:44 <trackbot> ISSUE-15 -- What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc -- open
09:00:44 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/15
09:00:45 <mischat> again, you could have a best practices document stating how you can use named graphs in a quad store in a truthy way, but neither rdf nor sparql mandates this, but it would be a good thing for quad store/linked data interoperability -- would be a good note for a primer
09:00:49 <zwu2> zakim, mute me
09:00:49 <Zakim> zwu2 should now be muted
09:01:49 <PatH> zakim, mute me
09:01:49 <Zakim> PatH should now be muted
09:02:00 <FabGandon> Guus: 30 is about alignment with SPARQL and 15 is about our internal changes to RDF.
09:02:31 <FabGandon> ... in solving issue 15 we should not conflict with SPARQL.
09:02:37 <PatH> yes, fine
09:02:53 <PatH> yes,
09:03:14 <PatH> sorry cant unmute but agree with what you are saying
09:03:26 <FabGandon> Guus: we should remove dataset from issue 15 this is addressed in issue 30
09:03:47 <sandro> PROPOSED: ISSUE-15 is about our internal notions of multiple graphs, while ISSUE-30 is about how that related to SPARQL's notion. We do not expect the association of IRIs and graphs in SPARQL datasets to be RDF's identification/reference relationship.
09:03:47 <PatH> zakim, unmute me
09:03:47 <Zakim> PatH should no longer be muted
09:04:03 <FabGandon> davidwood: etc. is not precise enough , issue 15 should be rephrased properly
09:04:28 <PatH> zakim, mute me
09:04:28 <Zakim> PatH should now be muted
09:04:48 <danbri> proposed: "While it is attractive to seek more clarity on relationship between some graph of triples and URIs they're tagged with, ... we note that SPARQL deployments have assigned URIs in a variety of ways, each of which being useful and compliant. There may be value in documenting these deployment styles (e.g. URIs for docs, abstract graphs, human sources or transaction IDs) so that SPARQL stores and serializations of URI-tagged triples can b
09:04:48 <danbri> e made more richly interoperable."
09:05:02 <FabGandon> Guus: we should start with defining our own terminology before aligning with SPARQL.
09:05:11 <cygri> proposed: "Named Graphs in SPARQL “loosely associate” IRIs and graphs. They do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."
09:06:20 <FabGandon> ISSUE-30: cygri proposes "Named Graphs in SPARQL “loosely associate” IRIs and graphs. They do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."
09:06:20 <trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added
09:06:30 <PatH> zakim, unmute me
09:06:30 <Zakim> PatH should no longer be muted
09:06:35 <PatH> q+
09:06:44 <ivan> ack PatH
09:06:46 <davidwood> ack PatH
09:07:12 <danbri> i tried ' each of which being useful and compliant' instead of 'loosly' (above)
09:07:23 <sandro> "are simple associations"
09:07:35 <AZ> Maybe: "Named Graphs in SPARQL associate IRIs and graphs *but* they do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."
09:07:42 <FabGandon> PatH: don't like the word "loosely" prefer : temporary
09:08:13 <PatH> zakim, mute me
09:08:13 <Zakim> PatH should now be muted
09:08:14 <sandro> PROPOSED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not necessarily establish graphs as referents of IRIs
09:08:35 <AZ> I would not put the necessarily there
09:08:51 <mischat> SteveH: sparql uses the verb "graph" to talk about arbitrary graphs and the "named graphs" for graphs which which can be fetched via http, or is that just my pov?
09:09:03 <sandro> PROPOSED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily "name" graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs
09:09:10 <sandro> +1
09:09:14 <pfps> +1
09:09:15 <cygri> +1 sandro
09:09:16 <AZ> +1
09:09:16 <mbrunati> +1
09:09:20 <pchampin> +1
09:09:23 <davidwood> +1
09:09:24 <cmatheus> +1
09:09:26 <yvesr> +1
09:09:27 <danbri> +1
09:09:32 <zwu2> +0
09:09:33 <NickH> +1
09:09:38 <SteveH> +1
09:09:51 <mischat> +1
09:10:04 <mischat> any objections for this being added as a note to issue-30 ?
09:10:04 <FabGandon> ISSUE-30: Proposed WG position : Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs.
09:10:04 <trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added
09:10:07 <sandro> RESOLVED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily "name" graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs (relevant to ISSUE-30)
09:10:31 <cygri> ISSUE-15?
09:10:31 <trackbot> ISSUE-15 -- What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc -- open
09:10:31 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/15
09:10:56 <PatH> +1 also my vote
09:11:11 <FabGandon> davidwood: moving to ISSUE 15 ; let's try to rephrase it.
09:11:41 <AZ> AZ: isn't it implicitly asking "how" one can associate a URI to a g-* ?
09:12:00 <PatH> propose, uri always refers to g-box, but some boxes are immutable.
09:12:12 <pgroth> agree with pat
09:12:16 <FabGandon> sandro: g-boxes, g-snap, g-text could be named
09:12:48 <PatH> because a snap is always a state (of a box) rather than a resource uin its own right.
09:12:48 <FabGandon> ivan: can we have a predicate to say this IRI identifies this g-box ?
09:13:15 <pgroth> although i need to refer to a g-snap
09:13:51 <pchampin> PatH: can't a number have a URI ??
09:14:06 <FabGandon> pgroth: would that prevent you to refer to a particular state of a box ?
09:14:22 <PatH> dont think it can be done just using a predicate unless we endow that predicate with spoecial semantic force.
09:14:31 <Guus> q?
09:14:37 <danbri> (around foaf/webid/foaf+ssl and so on, we'll start seeing people identifying concrete sets of well known triples by hash of their encoding, eg. the triples W3C served for the RDF ns for the last 5 years)
09:15:00 <FabGandon> ivan: the snap vs. box is exactly about mutability
09:15:03 <pchampin> PatH??: <someuri> owl:sameas 42
09:15:57 <PatH> sure, that is ok, but states are transient.
09:16:28 <FabGandon> davidwood: if a g-box is a resource than we can talk about it.
09:16:30 <PatH> zakim, unmute me
09:16:30 <Zakim> PatH should no longer be muted
09:16:49 <sandro> q+ to say the difference
09:16:59 <FabGandon> pgroth: so what is a snap then if not an immutable box ?
09:17:07 <PatH> q+
09:17:22 <pchampin> q+
09:17:29 <FabGandon> sandro: another difference is equality.
09:17:45 <gavinc> The NAME is not part of the g-snap
09:17:49 <pgroth> q+
09:17:54 <danbri> sandro, does that work ok w/ bnodes? do we have samegraphness defined adequately for graphs w/ bnodes?
09:18:14 <FabGandon> davidwood: two g-snaps may have the same content and still be different snaps.
09:18:27 <FabGandon> ... we haven't decided on that yet.
09:18:50 <sandro> danbri, yes, but you also have to allow bnodes to be shared between graphs.
09:18:51 <FabGandon> ... it depends on how we resolve issue 15
09:18:53 <SteveH> q+ to ask Sandro about why two g-boxes can't be equal [unless I got the wrong end of the stick]
09:19:16 <gavinc> ... I don't think g-snaps had names?
09:19:21 <cygri> q+
09:19:42 <PatH> stephen, two anythings cannot be equal.
09:19:47 <yvesr> q?
09:19:54 <davidwood> ack sandro
09:19:54 <Zakim> sandro, you wanted to say the difference
09:19:55 <sandro> ack sandro
09:19:57 <ivan> ack sandro
09:19:58 <davidwood> ack PatH
09:20:03 <danbri> (sandro, eg. if there is an rdf/xml file bundled with Jena that is packaged old version of DC schema; and the similar-but-different triples we get from a DCMI namespace URI fetch ... )
09:20:39 <FabGandon> PatH: The guiding abstraction should be the REST model
09:21:54 <FabGandon> davidwood: reprensentations are not resources by default
09:22:04 <davidwood> ack pchampin
09:22:08 <ivan> ack PatH
09:22:13 <sandro> it's the g-text that's the representation, not the g-snap.
09:22:29 <FabGandon> sandro: the representation is the g-text, a string
09:22:33 <danbri> PatH, does "is not a resource" there mean "not a Web/http resource" rather than "is not a resource-considered-as-synonym-for-thing"?
09:22:46 <danbri> (if you can channel for timbl...)
09:22:46 <FabGandon> pchampin: the g-snap is the state of the resource
09:22:51 <yvesr> g-box - resource ; g-snap - state ; g-text : representation
09:22:58 <pgroth> g-box = resource, g-snap = content negotiation, g-text = state serlization
09:22:58 <PatH> sorry, sandro is right. but the snap is an abstraction/parsing of the text.
09:23:01 <mischat> g-snap is information resource at time T ?
09:23:10 <davidwood> ack pgroth
09:23:15 <ivan> ack pgroth
09:23:30 <PatH> and so is similarly unidentifiable.
09:23:36 <JFB> g-snap: state of the resource or state of the representation ?
09:23:48 <PatH> yes, sandro is right.
09:23:54 <yvesr> pgroth: i don't agree - g-snap != content-negotiation
09:23:54 <pchampin> @JFB: state of the resource
09:24:06 <yvesr> s/pgroth:/pgroth,/
09:24:17 <FabGandon> cygri: you can't talk about the representation.
09:24:49 <sandro> q?
09:24:56 <PatH> danbri, i want those to be the same sense of resource
09:25:15 <FabGandon> davidwood: a representation is not a resource but with an additional step you can choose to make an identifier for that representation and talk about it.
09:25:28 <pchampin> data: URIs ?
09:25:34 <pchampin> I mean "data colon URIs"
09:25:38 <davidwood> ack SteveH
09:25:38 <Zakim> SteveH, you wanted to ask Sandro about why two g-boxes can't be equal [unless I got the wrong end of the stick]
09:25:38 <ivan> q?
09:25:43 <ivan> ack SteveH
09:25:45 <PatH> pat is drinking tea at 4.25 am
09:27:03 <ivan> q?
09:27:16 <ivan> q+
09:27:18 <sandro> sandro: Two g-boxes remain distinct even though their contents/state might happen to be the same at some point in time.
09:27:42 <FabGandon> q?
09:27:51 <PatH> sandro, sorry to introduce extra confusion.
09:28:31 <sandro> q?
09:28:33 <PatH> +1 to pfps
09:28:37 <sandro> q+ to talk about use cases
09:28:54 <FabGandon> pfps: We could say we don’t change the semantics, Quads are syntax
09:29:06 <cygri> q?
09:29:34 <mischat> i like the idea that RDF semantics not changing, and using quads as syntax, +1 to pfps
09:29:44 <PatH> i think there are now also quints, sexts, etc..
09:29:45 <danbri> I can't understand how the same meeting can, 30 mins ago, accept resources=all things in the universe, yet 5 mins ago, deny that the stuff you get back from an HTTP request is a resource. Ug.
09:30:01 <sandro> pchampin, you're right, I think, that data: URIs give us identifiers for representations / g-texts.
09:30:23 <Guus> q?
09:30:25 <danbri> (even without handy URIs they're still things and therefore Resources in rdfsemantics sense)
09:30:27 <FabGandon> ... RDF semantics defines the meaning of the underlying data structure but not augmented with a semantics for datasets.
09:30:29 <pchampin> a+
09:30:33 <pchampin> q+
09:30:47 <Guus> ack cygri
09:30:48 <sandro> danbri, we didn't agree with that -- it was just claimed and ignored. :-)
09:31:17 <davidwood> ack ivan
09:31:47 <pfps> so, after all the stuff that I said, I still remain agnostic as to which direction to go
09:32:34 <FabGandon> ivan: if we have predicates to link IRI and g-* we need to define them in the RDF semantics
09:33:14 <PatH> yes, we do. so the semantics will have to deal with the *-ideas.
09:33:36 <PatH> yes, exactly.
09:33:47 <FabGandon> pfps: if you want to talk about this inside the RDF voc you have to define it in the RDF semantics indeed.
09:33:59 <PatH> +1
09:34:06 <pfps> from an OWL perspective, the "don't change the semantics view" is very seductive
09:34:25 <SteveH> also from the DB implementors view
09:34:42 <PatH> extend does not imply change, hoever.
09:34:45 <sandro> ISSUE: Should there be an rdf:Graph construct, or something like that?
09:34:46 <trackbot> Created ISSUE-35 - Should there be an rdf:Graph construct, or something like that? ; please complete additional details at http://www.w3.org/2011/rdf-wg/track/issues/35/edit .
09:34:46 <FabGandon> Guus: should there be an rdf:Graph primitive ?
09:35:00 <sandro> (from Guus and David -- I don't understand the question.)
09:35:07 <PatH> +q
09:35:08 <Guus> q?
09:35:15 <Guus> q?
09:35:23 <davidwood> ack sandro
09:35:23 <Zakim> sandro, you wanted to talk about use cases
09:35:30 <ivan> ack sandro
09:35:40 <FabGandon> pfps: if g-boxes just want to have fun they need to be in the semantics.
09:36:13 <cygri> q+
09:37:06 <FabGandon> sandro: one of the scenarios is "annotating graphs" e.g. be able to select a part of graph state things about it.
09:37:11 <ivan> ack pchampin
09:37:12 <davidwood> ack pchampin
09:37:30 <sandro> Zakim, close the queue
09:37:30 <Zakim> ok, sandro, the speaker queue is closed
09:37:40 <davidwood> THE QUEUE IS CLOSED FOR THIS SESSION
09:38:24 <davidwood> ack PatH
09:38:26 <FabGandon> pchampin: we need a vocabulary for the g-* e.g. just to be about to talk about them when we load them.
09:38:28 <ivan> ack PatH
09:39:44 <FabGandon> PatH: if the notion of g-box is important then the semantics has to clarify that notion it does need to be a revolution.
09:39:52 <pfps> perhaps, but by this same argument, the semantics should specify what happens when you go an HTTP get on a URL
09:40:07 <mischat> i am not sure about the adoption rate of '<> rdf:type rdf:Statement.' , do people even ever use them ...
09:40:09 <davidwood> ack cygri
09:40:11 <ivan> ack cygri
09:40:19 <PatH> not that bad, peter...
09:40:58 <sandro> PROPOSED: We aligned g-* with REST, where g-box=information resource, g-snap=state of the resource, g-text=representation of the state of the resource
09:41:07 <FabGandon> cygri: documenting the alignment with REST may be useful for us but not in the deliverables ; it is too complex and time-consuming.
09:41:25 <pchampin> PatH: re what Fabien scribed, shouldn't it be "does NOT need" ?
09:41:35 <PatH> disagree with fabgandon
09:42:02 <FabGandon> ivan: would lead to endless discussions.
09:42:18 <sandro> PROPOSED: We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource, g-text=representation of the state of the resource
09:42:53 <pchampin> NB: a predicate would not state the relation between a URI and a graph, but between a resource (identified by a URI) and a graph
09:43:07 <FabGandon> my mistake s/ clarify that notion it does need to be a revolution/ clarify that notion it does not need to be a revolution/
09:43:22 <PatH> i think wewill be doing the world a disservice if we leave ambiguity and confusion. That is what the last RDF WG did, but there is a decade of practice now to guide us.
09:43:33 <mischat> sandro, perhaps s/state of the resource/state of the resource at time t/
09:43:35 <pfps> do we have a failrly coherent document that describes REST?
09:43:58 <sandro> PROPOSED: We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource (at time t), g-text=representation of the state of the resource (at time t)
09:44:03 <PatH> zakim, mute me
09:44:03 <Zakim> PatH should now be muted
09:44:21 <sandro> +1
09:44:22 <pfps> NB: I do understand that coherency is rather absent in the REST universe.
09:44:24 <davidwood> +1
09:44:26 <SteveH> +1
09:44:30 <gavinc> +1
09:44:31 <PatH> +1
09:44:33 <zwu2> +1
09:44:35 <Zakim> -AZ
09:44:36 <danbri> -1
09:44:40 <AZ> +1
09:44:51 <JFB> +1
09:44:54 <AZ> zakim voted against me!
09:44:57 <mbrunati> +1
09:45:06 <ivan> 0
09:45:14 <sandro> (clarify -- this is only for the subset of IRs that can be respresented in RDF.)
09:45:18 <pfps> +.5 as I'm not exactly sure just what REST is
09:45:24 <JFB> @AZ yes, found that surprising
09:45:24 <PatH> az, that will teach you to make lumpy custard.
09:45:46 <Zakim> +AZ
09:46:02 <NickH> +1 (but agree that REST isn't very well specified)
09:46:09 <yvesr> +1
09:46:12 <FabGandon> danbri: some environments don’t have a notion of REST.
09:46:13 <pchampin> -1
09:46:43 <FabGandon> Guus: we are only considering the notions behind REST.
09:46:57 <danbri> REST is good, but it doesn't seem a 1:1 relationship to me
09:47:07 <sandro> pchampin, my concern is that we might be missing some more complicated resources whose state is not represented by a graph, because it's not just time.
09:47:12 <sandro> s/,/:/
09:47:16 <SteveH> +1 to danbri, but I don't think it detracts from the analogy
09:47:19 <PatH> seems to me that if its not related to restthen I dont know why we even have these distinctions ourselves.
09:47:21 <pchampin> e.g. authentication, etc
09:47:33 <SteveH> pchampin, right, or cookies for e.g.
09:47:34 <cygri> good point pchampin. language negotiation etc
09:47:43 <danbri> maybe i'm pulling Web-derrived data from a local Lucene store; from Mahout clustering, or prolog, doing stuff in code and stuffing bits into graphs with URI tags. REST is in the environment but the data flow is much more complex than fetch'n'store
09:47:46 <pchampin> yes, this too
09:48:02 <sandro> guus: two groups; (1) json, (2) skolemization
09:48:13 <tomayac> json += tomayac
09:48:19 <PatH> will skolem have a phone link?
09:48:39 <FabGandon> ISSUE-15: Text to be further discussed : "We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource (at time t), g-text=representation of the state of the resource (at time t)"
09:48:39 <trackbot> ISSUE-15 What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc notes added
09:48:44 <danbri> SteveH, sure, considered as an analogy it can be instructive (and in fact I'm trying to extend REST concepts a bit more into XMPP message types)
09:49:13 <PatH> zakim, unmute me
09:49:13 <Zakim> PatH should no longer be muted
09:49:14 <AZ> if there is a phone link then I'll join the skolem
09:49:24 <pfps> skolem will be here - same phone - restart in 15 min
09:49:29 <PatH> skolem for me if possible.
09:49:40 <PatH> OK.
09:49:42 <JFB> @AZ same room for DSkolem, so same phone should work
09:49:54 <FabGandon> PatH, yes skolem stays in this room
09:49:54 <Zakim> -PatH
09:49:56 <Zakim> -AZ
09:50:07 <Zakim> -OlivierCorby
09:50:11 <Zakim> -zwu2
10:03:49 <Zakim> +AZ
10:09:29 <pfps> Topic: skolemization (whatever that is!)
10:09:36 <tomayac> is there a dial-in no. for json?
10:09:49 <pfps> no dialin for json yet
10:09:56 <Zakim> +zwu2
10:09:56 <davidwood> davidwood has joined #rdf-wg
10:10:00 <pfps> and there won't be one
10:10:02 <sandro> no dialin for json ever, sorry.
10:10:05 <davidwood> zakim, who is on the phone?
10:10:05 <Zakim> On the phone I see Meeting_Room, tomayac, gavinc, AZ, zwu2
10:10:09 <zwu2> zakim, mute me
10:10:09 <Zakim> zwu2 should now be muted
10:10:40 <Zakim> +PatH
10:10:52 <PatH> zakim, mute me
10:10:52 <Zakim> PatH should now be muted
10:11:02 <mischat> tomayac: do you want to be dialled in ?
10:11:12 <yvesr> scribe: yvesr
10:11:12 <danbri> so - what are we skolemising and why?
10:11:19 <mischat> do JSON people want to call in
10:11:20 <sandro> topic: Skolemization Breakout
10:11:21 <pgroth> the skolemization has taken over this chat room
10:11:27 <pfps> The problem, as I see it, is that RDF stores hold blank nodes, but they have problems sending identifiers for these blank nodes out in response to queries and getting them back.
10:11:29 <mischat> yeah we are about to set up a voice thing
10:11:31 <mischat> i sec
10:11:40 <yvesr> SteveH: long-standing issue in the way bnodes are defined
10:11:49 <yvesr> SteveH: close-enough to existential variables in rdf
10:12:02 <yvesr> SteveH: most implementations turn it into an internal identifier
10:12:05 <sandro> SteveH: I have a longstanding issue who how bnodes are defined, as existential variables. But the reality is that all the triplestores turn it into an internal identifier.
10:12:13 <yvesr> SteveH: turning them into 'skolems'
10:12:21 <cygri> (JSON breakout is happening over in the #rdf-json channel)
10:12:46 <sandro> pfps: So far, they havent' done anything wrong.
10:13:09 <Zakim> -tomayac
10:13:13 <yvesr> SteveH: 2 problems - 1) bnodes in the wild (when there shouldn't be) and 2) people deliberately writing them (i.e. FOAF)
10:13:27 <danbri> q+ to account for the foaf case
10:13:42 <PatH> there is also a strong deprtecation of bnode use in the linked data community.
10:13:44 <sandro> SteveH: But sometimes you encounter bnodes in the wild, where it would be nice to have URIs, as in foaf. In practice it's annoying.
10:13:46 <yvesr> SteveH: in FOAF, you end up using inverse functional properties to identify individuals
10:13:54 <davidwood> Zakim, open the queue
10:13:54 <Zakim> ok, davidwood, the speaker queue is open
10:14:09 <danbri> q+ to account for the foaf case
10:14:24 <sandro> q+ to present proposal
10:14:43 <yvesr> SteveH: People are missing a feature from relational databases (not assigning an explicit primary key)
10:15:03 <yvesr> SteveH: some triple stores have internal uri schems to talk about bnodes
10:15:12 <sandro> SteveH: Folks also have internal URI schemes for talking about bnodes. People really want this for SPARQL round-tripping.
10:15:14 <davidwood> ack danbri
10:15:14 <Zakim> danbri, you wanted to account for the foaf case
10:15:15 <yvesr> SteveH: those can surface in query results - and can be used in queries
10:15:18 <pfps> q+
10:15:28 <PatH> q+
10:15:38 <pfps> q+ to say that such RDF stores aren't really doing anything 'wrong'
10:15:48 <yvesr> danbri: There's a reason for the FOAF choice - leading to anonymous resources
10:16:02 <yvesr> danbri: no owl:sameAs, not clear what to do with resources
10:16:19 <yvesr> danbri: identifying people with properties was a pragmatic decision
10:16:44 <yvesr> davidwood: how would you do it today?
10:17:07 <yvesr> danbri: if you were in a position to assign uris for other people, then FOAF would have gone for URIs
10:17:24 <yvesr> danbri: bnodes are a pain to deal with...
10:17:44 <yvesr> q+
10:18:01 <davidwood> ack sandro
10:18:01 <Zakim> sandro, you wanted to present proposal
10:18:01 <ivan> ack sandro
10:18:06 <sandro> steveH: The assigned URIs leak out of query interface, which is what makes them useful.
10:18:27 <zwu2> zwu2 has joined #rdf-wg
10:18:31 <danbri> original statement of the foafy smushing stuff: http://lists.xml.org/archives/xml-dev/200012/msg00597.html
10:18:44 <yvesr> sandro: Long discussion on the semantic-web list a couple of weeks ago - a proposal was done that adress everyone's requeirements
10:19:09 <yvesr> sandro: pick one of two uri pattern choices to skolemize bnodes
10:19:29 <yvesr> sandro: http://... if you want to dereference, or tag:...
10:20:03 <yvesr> sandro: if you encounter one of those uris, it's machine generated
10:20:17 <yvesr> sandro: those uris can be considered as disposable
10:20:19 <danbri> so the first dozen or so FOAF files used genid: as a URI scheme, eg. http://svn.foaf-project.org/foaftown/2010/allfactoids/copies/danbri/danbri-foaf.rdf ... about="genid:poulter" etc
10:21:00 <FabGandon> yvesr: how do you know they are machine generated?
10:21:13 <PatH> it is always valid to 'deskolemize', so we dont need to say anything about that.
10:21:20 <FabGandon> SteveH: because they have genid
10:21:39 <yvesr> danbri: reserved uri pattern - genid in the uri means that it is machine generated
10:21:42 <sandro> 1. If you're going to Skolemize, use a URI like this:
10:21:42 <sandro> - http://example.org/.well-known/genid/[whatever]
10:21:42 <sandro> - tag:example.org,2011/.well-known/genid/[whatever]
10:21:42 <sandro> 2. If you encounter one of these URIs:
10:21:42 <sandro>
10:21:43 <sandro> - you know it's machine generated
10:21:45 <sandro> - consider it more disposable, more mergeable
10:22:08 <PatH> +1 to speaker. genid is better.
10:22:11 <gavinc> eg: generate-id() in XPath/XSLT
10:22:12 <sandro> We mean LITERALLY the string "genid".
10:22:13 <yvesr> SteveH: Prefers genid over bnodes
10:22:40 <PatH> s/speaker/stevenh
10:22:43 <yvesr> SteveH: you might want to use "genids" to identify graphs
10:22:51 <davidwood> ?
10:22:53 <davidwood> q?
10:22:57 <yvesr> sandro: Use "genid" or "gensym"?
10:23:00 <davidwood> ack pfps
10:23:00 <Zakim> pfps, you wanted to say that such RDF stores aren't really doing anything 'wrong'
10:23:05 <ivan> ack pfps
10:23:49 <davidwood> q+ to mention the use of made-up ids as a pattern to replace bnodes
10:24:07 <yvesr> JFB: bnodes are stronger - they can never be used in another graph
10:24:18 <yvesr> SteveH: this is already dropped in sparql-update
10:24:53 <yvesr> pfps: Technically, it is not a valid entailment
10:25:24 <ivan> q+
10:25:35 <danbri> related prev discussion: sergey melnik tried to create a canonical URIs for bnode/anon resources - http://lists.w3.org/Archives/Public/www-rdf-interest/1999Dec/0046.html
10:25:59 <sandro> pfps: As long as these are fresh, you wont get any incorrect inferences.
10:26:20 <yvesr> pfps: SPARQL-update validates the leaky bnodes, what this proposal says is that graph stores are able to make that transformation
10:26:25 <sandro> pfps: This says an RDF store is entitled to change bnodes like this.
10:27:05 <davidwood> ack PatH
10:27:08 <sandro> pfps: "RDF graphs stores can, on their own recognisance, do this transformation"
10:27:37 <yvesr> PatH: the fact that such uris can leak out is a good thing
10:27:51 <yvesr> PatH: We don't have to worry about leakage
10:27:52 <sandro> q?
10:28:22 <davidwood> ack yvesr
10:28:51 <zwu2> cannot hear much
10:28:55 <PatH> zakim, mute me
10:28:55 <Zakim> PatH should now be muted
10:29:19 <PatH> sound is very patchy.
10:29:25 <PatH> better
10:31:07 <davidwood> ack davidwood
10:31:07 <Zakim> davidwood, you wanted to mention the use of made-up ids as a pattern to replace bnodes
10:31:31 <yvesr> yvesr: RDFa creates lots of bnodes in the wild
10:31:56 <yvesr> yvesr: and sometimes there are things that you can't identify, or don't want to mint a URI for (e.g. transient things)
10:32:01 <danbri> ivan, in your homepage you have <div id="container" about="http://www.ivan-herman.net/foaf#me" typeof="foaf:Person dc:Agent"> .... that's the verbose aspect. But maybe you could use a relative URI at least?
10:32:22 <yvesr> davidwood: I don't think there is soemthing wrong with bnodes, and it's fine to skolemize them
10:32:37 <yvesr> s/soemthing/something/
10:33:04 <yvesr> davidwood: Machines should do the job, transparently
10:33:40 <sandro> q?
10:33:45 <davidwood> ack ivan
10:33:45 <sandro> q+ to draft proposal
10:33:50 <yvesr> SteveH: what you want is a bnode syntax, not a bnode semantics
10:34:14 <yvesr> ivan: I can understand that a number of people would want to derefence these things
10:34:19 <PatH> sandro, type it.
10:34:21 <yvesr> ivan: what happens when you derefence them?
10:34:24 <sandro> PROPOSAL: It's okay for systems to Skolemize bnodes, replacing them with IRIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. Must be reg'd with IETF.
10:34:33 <yvesr> ivan: what advice do you give, and how are people to set it up?
10:34:57 <yvesr> ivan: the first uri pattern is an http:// uri, and needs to be dereferencable - what does it do?
10:34:58 <PatH> should be fine for these to give 404s.
10:35:03 <davidwood> SteveH: Yes, I want the usefulness of bnode semantics with a simple, automated bnode syntax assistance.
10:35:29 <yvesr> ivan: do we want to get this reflected in various syntaxes?
10:35:48 <davidwood> q?
10:36:20 <yvesr> SteveH: what we would do in 4store would be to generate bnode skolems based on a prefix
10:36:32 <yvesr> SteveH: prefix is defined in configuration
10:36:52 <yvesr> SteveH: accessible as any other identifier in the store
10:37:30 <yvesr> ivan: you're using your SPARQL engine as a tool - the W3C needs to provide a global mechanism for what happens when you derefence a http://...genid... uri
10:37:35 <PatH> sandro, if these are supposed to refer to non-information resources, then according to http-range-14, they ought to give a 303 redirect. Can they have a # ending to remove this requirement?
10:38:22 <yvesr> q+
10:38:58 <yvesr> ivan: Linked Data people don't want to have bnodes in their graph
10:39:19 <yvesr> pfps: there's no way to make them happy
10:39:35 <yvesr> ivan: there is a way to set up a simple service somewhere that would do the job
10:39:41 <sandro> PatH, how about if it's http[s]://[domain]/.well-known/genid/[locally-uniq-id]#
10:40:13 <PatH> fine with me, as long as doesnt require a 303 mechanism
10:40:18 <davidwood> q+ to discuss broadness of skolemization (stores, validation, services, etc)
10:40:23 <yvesr> SteveH: if you dereference a bnode, one thing you could do is to just say 'this is a bnode'
10:40:42 <davidwood> ack sandro
10:40:42 <Zakim> sandro, you wanted to draft proposal
10:40:56 <sandro> PROPOSAL: It's okay for systems to Skolemize bnodes, replacing them with IRIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id]# or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. Must be reg'd with IETF.
10:41:00 <danbri> q+ to express risk of single point of failure / keeping a bnode-description-service secure is nontrivial, costly work
10:41:38 <yvesr> sandro: the hash is to stay clear of httpRange-14
10:41:52 <gavinc> Annoyed but not strong/formal objection to using tag: --0?
10:41:58 <yvesr> sandro:
10:42:02 <PatH> +1 danbri, should not presume a service of any kind.
10:42:07 <yvesr> SteveH: i can think of lots of reasons not to do that
10:42:15 <sandro> gavinc, why does the tag bother you? what would you prefer?
10:42:40 <yvesr> davidwood: uri lookups cost time and money
10:42:50 <gavinc> tag was designed specificly for HUMAN generated uniqueness
10:42:50 <davidwood> ack yvesr
10:43:04 <gavinc> q+
10:43:05 <danbri> (re bit.ly / tinyurl analogy, ... it's taking us a month of HTTP requests to bit.ly to expand otherwise mysterious shortlinks from a twitter crawl, ... they only allow 2 lookups / second ... single points of control worrying)
10:44:22 <pchampin> shouldn't we add "fresh IRI" in Sandro's proposal?
10:44:41 <sandro> yvesr: I don't like Skolem ids leaking out.
10:44:54 <danbri> LOD community have established the convention than any party can invent HTTP URIs freely, for anything and anyone; so why not just generate LOD URIs or uuid: URIs? I don't see this proposal adding value to those options
10:44:56 <FabGandon> WRT the service approach, beyond the risk of single point of failure it is a point of centralization in the model and in general centralization is not good for web arch IMHO
10:44:58 <PatH> all specifically RDF uses dont require dereferencing. Seems like main purpose of these being recognizable is to AVOID dereferencing them.
10:45:37 <davidwood> ack gavinc
10:45:39 <zwu2> q+
10:45:42 <ivan> ack gavinc
10:45:45 <sandro> sandro: Maybe "*if* you're going to skolemize, you SHOULD use one of these two forms"
10:46:23 <PatH> disagree. should be free to skolemize any way you like, as long as it is 'frtesh'
10:46:24 <yvesr> gavinc: seems very wrong to use tag uris
10:46:29 <PatH> fresh
10:46:50 <yvesr> gavinc: is UUID terrible?
10:47:16 <yvesr> SteveH: minting a new UUID for all bnodes is not very affordable
10:47:27 <yvesr> gavinc: we got rid of all bnodes at o'reilly because of that
10:47:28 <davidwood> Sandro thinks yes, UUIDs doesn't allow you to use genie
10:47:40 <davidwood> s/genie/genid/
10:47:49 <yvesr> q?
10:48:27 <yvesr> ivan: is it true that the tag: scheme says 'it is for humans'?
10:48:51 <yvesr> gavinc: the generation mechanism needs to happen by humans
10:48:58 <davidwood> ack davidwood
10:48:58 <Zakim> davidwood, you wanted to discuss broadness of skolemization (stores, validation, services, etc)
10:49:11 <zwu2> zakim, unmute me
10:49:11 <Zakim> zwu2 should no longer be muted
10:49:25 <yvesr> davidwood: There is opportunity to use skolemisation in quite a lot of places, not only in stores
10:49:50 <yvesr> davidwood: input, output, validation process, skolemization services
10:49:52 <pchampin> q+ to talk about the fresh URIs and them leaking from the store
10:50:14 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they SHOULD use URIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id]# or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
10:50:14 <davidwood> q?
10:50:15 <yvesr> davidwood: if you're doing skolemization, you SHOULD do it in the way we're defining
10:50:22 <danbri> ack danbri
10:50:22 <Zakim> danbri, you wanted to express risk of single point of failure / keeping a bnode-description-service secure is nontrivial, costly work
10:50:22 <davidwood> ack danbri
10:50:35 <davidwood> zakim, close the queue
10:50:35 <Zakim> ok, davidwood, the speaker queue is closed
10:50:44 <PatH> prposal. it is permissible to replace bnodes by URIs provided that the URIs are 'fresh', ie not used in any other rdf graph. It is recommended to include a string /genid/. one way is sandro's prposal.
10:50:59 <danbri> q-
10:51:04 <yvesr> ivan: Would that effect any of the syntaxes, and how?
10:51:07 <PatH> q+
10:51:07 <yvesr> SteveH: it wouldn't
10:51:08 <danbri> I defer; question withdrawn
10:51:15 <yvesr> SteveH: it wouldn't be the parser's job to do it
10:51:22 <yvesr> SteveH: it doesn't have enough information
10:51:33 <yvesr> ivan: for RDFa, it would make sense - and it might make sense for Turtle files too
10:51:38 <mischat_> mischat_ has joined #rdf-wg
10:51:49 <yvesr> ivan: many people use the square brackets - lazyness
10:51:50 <danbri> ( I assume args for the skolem function is not just the textual input, but also the base URI...)
10:52:06 <yvesr> ivan: i should be able to tell the parser to mint me some URIs for those
10:52:23 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they SHOULD use fresh URIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
10:52:24 <davidwood> +1 to PatH's proposal
10:52:32 <davidwood> ack zwu
10:52:39 <yvesr> SteveH: reverse transformation - output documents *with* bnodes
10:53:08 <mischat_> Webr3 about?
10:53:12 <yvesr> zwu2: if you have one triple in a store, :john :friendOf _:a
10:53:16 <PatH> steveh, it is always valid to 'deskolemize' with bnodes.
10:53:24 <yvesr> zwu2: you would get back a skolemized bnode
10:53:31 <mischat_> webr3, if you are about join #rdf-json
10:53:36 <yvesr> zwu2: if we're using that skolemized bnode as a query
10:53:44 <yvesr> are we supposed to return :john or not?
10:53:49 <yvesr> zwu2: are we supposed to return :john or not?
10:53:52 <yvesr> SteveH: yes
10:54:08 <PatH> yes. once it is a uri, you can do this.
10:54:09 <yvesr> davidwood: if identifiers leak out to the outside world, it maintains validity
10:54:31 <yvesr> ivan: if i use the bnode filter operation in a SPARQL query, what happens?
10:54:37 <yvesr> ivan: does it match the skolemized bnode?
10:54:47 <yvesr> SteveH: that's an issue for us
10:54:49 <PatH> zakim, unmute me.
10:54:49 <Zakim> PatH should no longer be muted
10:54:56 <yvesr> SteveH: we need to define if they count as bnodes or not
10:55:12 <yvesr> ivan: as a user, who doesn't understand this stuff, i would expect the bnode function to work
10:55:21 <yvesr> SteveH: in 4store, it would answer true
10:55:39 <yvesr> SteveH: it only gets skolemized on the export
10:55:47 <yvesr> SteveH: internal consistency
10:55:47 <ivan> q?
10:55:48 <davidwood> ack pchampin
10:55:49 <Zakim> pchampin, you wanted to talk about the fresh URIs and them leaking from the store
10:55:53 <ivan> ack pchampin
10:56:34 <yvesr> pchampin: We shoudl specify what is ok for the system to do
10:56:39 <PatH> az, no problem
10:56:43 <yvesr> pchampin: We should specify what the system would return
10:56:44 <SteveH> AZ, that wouldn't be legal RDF syntax, though you could write it by hand
10:56:57 <davidwood> PatH, can you please resend your proposal?
10:56:58 <yvesr> pfps: Troubles finding the SPARQL bnode definition
10:57:25 <danbri> pat hayes
10:57:40 <SteveH> http://www.w3.org/TR/rdf-sparql-query/#func-isBlank
10:57:49 <SteveH> ...the BNODE() function actually mints bNodes
10:57:50 <yvesr> PatH: genid SHOULD be in the URI but not absolutely required
10:57:58 <SteveH> but I think it was understood what was being discussed
10:58:07 <yvesr> PatH: it should be possible for people to invent URIs and use them
10:58:15 <yvesr> PatH: they could use software to do that automatically
10:59:08 <yvesr> PatH: We should not allow skolems that are specific to a single query
10:59:24 <sandro> PatH: Note that Skolemization is not valid in an antecedent (eg query).
10:59:31 <sandro> SteveH: that's fine.
10:59:40 <PatH> prposal. it is permissible to replace bnodes by URIs provided that the URIs are 'fresh', ie not used in any other rdf graph. It is recommended to include a string /genid/. one way is sandro's prposal.
10:59:46 <yvesr> SteveH: the skolemization process has to be stable
11:00:00 <yvesr> davidwood: Can we get consensus around this proposal?
11:00:19 <yvesr> davidwood: are there concerns around sandro's mandated use?
11:00:43 <yvesr> davidwood: if you're going to skolemize, you need to use a globally unique URI
11:00:49 <sandro> freshness is iffy -- since you want stability....
11:00:52 <yvesr> davidwood: and we encourage you to do it in a way
11:01:46 <danbri> -1 where did 'allowed' enter the rdf universe?
11:01:49 <zwu2> as long as generated uri is fresh to the triple store, it is good enough
11:01:54 <yvesr> -1 as well
11:02:01 <danbri> -> say what it means, not what people can/can't do
11:02:22 <PatH> must be fresh, should include /genid/
11:02:47 <yvesr> sandro: MAY is you're allowed to
11:02:58 <yvesr> pfps: SHOULD is you should do it, unless there's a very good reason not to
11:03:16 <PatH> sandro, why is freshness "iffy"
11:03:37 <danbri> proposed: "A graph transformed such that each bnode is replaced with a fresh bnode [meeting some constraints], ... then that new graph is true under the same conditions of the original."
11:03:40 <danbri> q+ to propose
11:04:10 <danbri> we are not the SPARQL WG
11:04:12 <yvesr> davidwood: if systems are going to leak bnodes, they must use fresh uris
11:04:52 <yvesr> SteveH: consistent mapping between internal representation and external id
11:05:02 <zwu2> so we can reuse "fresh" uris
11:05:11 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
11:05:20 <yvesr> danbri: we're not the SPARQL working group - so I think this language inappropriate
11:05:33 <yvesr> danbri: we should instead say something about graph structures
11:06:11 <yvesr> ivan: current RDF documents already talk about skolemization
11:06:31 <yvesr> ivan: the only thing we're saying here is that if it is used, you should use this pattern
11:06:52 <danbri> http://www.w3.org/TR/rdf-mt/#prf
11:06:54 <yvesr> pfps: RDF Semantics talk about skolemization
11:07:51 <yvesr> sandro: you need a web service to do the skolemization
11:08:00 <PatH> wha?
11:08:05 <yvesr> ???
11:08:18 <danbri> madness!!!
11:08:18 <yvesr> SteveH: you can't guarantee uniqueness
11:08:30 <danbri> (that's a technical term, no disrespect intended)
11:09:12 <PatH> call it 'bnode purging' and people will love it.
11:09:16 <yvesr> sandro: tag: skolemized bnode are more horrible than bnode
11:09:35 <danbri> PatH, can it be couched more declaratively? this 'should' stuff worries me
11:09:40 <JFB> RDF Semantics talks about Skolemization in Appendix A. Its notion of freshness is "fresh in the current graph"
11:09:42 <yvesr> ivan: the R2RML folks are fighting with the same problem
11:09:46 <PatH> danbri, yes.
11:10:01 <yvesr> ivan: what happens when the DB doesn't have a (publicly exposable) primary key
11:10:13 <PatH> jfb, no, that is not what was intended.
11:10:14 <pchampin> s/the DB/a table in the DB/
11:10:19 <sandro> PatH, in "you need a web service to do the skolemization" , I mean to be particularly useful, and make people happy you did the Skolemization....
11:10:45 <danbri> sandro, what are you seeing as the args to the skolemisation function? not just a document + base_uri?
11:10:49 <yvesr> ivan: if we come up with this note, we need to send it to the R2RML group - potential first users
11:11:17 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
11:11:37 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use a fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id]. Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
11:11:44 <sandro> objections from danbri and yves.
11:11:49 <PatH> unhappy with 'disposable'
11:12:13 <yvesr> danbri: very short URIs are important to me
11:12:19 <yvesr> danbri: don't force me to use this long pattern
11:12:25 <sandro> danbri: short URIs are important to me. don't force me to do it this way.
11:12:41 <yvesr> SteveH: uri pattern is quite verbose
11:12:45 <PatH> and would prefer to just say 'SHOULD include string /genid/'
11:12:49 <danbri> sorry - am sounding grumpier than I am. This could be a useful pattern for some.
11:12:50 <sandro> SteveH: for the non-deref form I prefer something smaller.
11:13:08 <zwu2> how about genid:local_unique_id
11:13:14 <yvesr> danbri: if we cut the proposal to the first MUST, any objections?
11:13:35 <PatH> and sandro's particular form offered as an offtheshelf solution.
11:13:39 <yvesr> all: what does disposable mean?
11:13:44 <yvesr> pfps: all pragmatics from here
11:13:54 <PatH> +1
11:14:20 <yvesr> sandro: you can skolemize, at some cost
11:14:33 <danbri> when you said "You're changing the data", that's in the right direction pfps
11:14:56 <PatH> you always can skolemize. It is not valid, but it preserves satisfiability.
11:15:02 <yvesr> sandro: proposition restrcited to MUST is actually stronger - want to expose the fact that it has been skolemized
11:15:36 <yvesr> sandro: genid:... would be good, but needs to be pushed through the IETF
11:15:54 <yvesr> ivan: this is a pain
11:16:11 <yvesr> sandro: don't want to be stuck in the IETF
11:16:24 <zwu2> you guys are not hungry, are you?
11:16:25 <danbri> the crux seems to be 'is it still in some appropriate equivalence class of graphs from the original? or has it been inappropriately interfered with..."
11:16:43 <PatH> why do we need to involve the IETF???
11:17:00 <gavinc> scheme registration :(
11:17:03 <yvesr> PatH, for a potential new uri scheme for those skolems
11:17:09 <pchampin> PatH: if we want a genid: URI scheme
11:17:11 <pfps> if we want to use URIs of the form genid:... we need to get approval
11:17:20 <PatH> screw a new scheme. they are just uris.
11:17:42 <yvesr> SteveH: are the two graphs the same? the skolemized and the original one?
11:17:53 <ivan> Pat, the issue is that the proposed URI-s are ugly and long...
11:18:01 <PatH> we need pertmission to include some text inside a URI??
11:18:30 <sandro> we need permission to say that all URIs containing certain text have a certain meaning, Pat.
11:18:34 <PatH> ivan, that is another issue.
11:18:35 <yvesr> you can't project from skolemized to original, but you can the other way around
11:18:52 <yvesr> FabGandon: you can't project from skolemized to original, but you can the other way around
11:18:59 <PatH> we artent saying anything about meaning, sandro.
11:19:17 <PatH> we are just making them recognizable.
11:19:58 <PatH> dawn is breaking here.
11:20:04 <yvesr> davidwood: if we're close to a solution, let's keep on on that
11:21:04 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, without doing damage to the graph, they MUST use a fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id] (or, someday, genid:...). Such IRIs are considered more disposable. "genid" to be reg'd with IETF.
11:21:31 <FabGandon> yvesr: still not happy with the SHOULD part
11:21:40 <PatH> -1 to that. way too restricting. overkill.
11:21:53 <FabGandon> ... not confortable with specifying a URI parttern.
11:22:00 <pchampin> still uncomfortable with the "disposable" part; I don't know what that means
11:22:05 <zwu2> +0
11:22:13 <FabGandon> ivan: happier with IETF pattern
11:22:15 <PatH> agree with fabgandon
11:22:45 <FabGandon> Fabien happier with genid:
11:23:07 <PatH> we do not need to get IETF involved.
11:23:35 <pchampin> PatH: if we want genid: URIs, we do
11:23:39 <Zakim> -zwu2
11:23:42 <PatH> have a good lunch, guys.
11:23:55 <Zakim> -PatH
11:23:59 <AZ> enjoy your meal
11:24:04 <Zakim> -AZ
11:24:18 <PatH> pchampin: I do not neeed he IETF t put 'gnid' into a URI name.
11:24:41 <PatH> Anyway, back to email :-)
11:25:09 <gavinc> about:, irc:, javascript:, jar:, rsync:, ssh:, ... need the IETF is a nice idea, the world doesn't exactly agree ;)
11:25:33 <gavinc> heck, if WHATWG has its way with the IETF ... no comment
11:25:54 <Zakim> -gavinc
11:31:13 <mischat__> mischat__ has joined #rdf-wg
11:58:16 <cmatheus> cmatheus has joined #rdf-wg
12:02:18 <mbrunati> mbrunati has joined #rdf-wg
12:02:23 <Guus> Guus has joined #rdf-wg
12:02:29 <ivan> -> http://www.w3.org/mid/4DA6A6AD.70205@deri.org -> Antoine's objection to yesterday's resolution
12:02:55 <ivan> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0307.html instead
12:03:00 <cygri> cygri has joined #rdf-wg
12:03:02 <danbri> 404
12:03:04 <danbri> ah
12:03:19 <ivan> -> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0309.html Lee's reply
12:03:38 <AlexHall> AlexHall has joined #rdf-wg
12:05:51 <gavinc> zakim, code?
12:05:51 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), gavinc
12:06:18 <danbri> zakim, who is on the phone?
12:06:18 <Zakim> On the phone I see Meeting_Room
12:06:19 <mischat> can people here the room ?
12:06:19 <sandro> zakim, who is on the call?
12:06:19 <Zakim> On the phone I see Meeting_Room
12:06:23 <mischat> s/here/hear/
12:06:27 <Zakim> +gavinc
12:06:53 <sandro> topic: Debrief Breakouts
12:07:03 <sandro> subtopic: JSON Breakout Debrief
12:07:34 <cmatheus> cygri: talked about note to enumerate problem JSON space
12:07:51 <cmatheus> three examples; linked data, BBC, NYT
12:08:01 <Zakim> + +1.443.212.aabb
12:08:16 <ivan> q+
12:08:25 <cmatheus> part of problem: data always connected to some api
12:08:31 <AlexHall> zakim, +1.443.212.aabb is me
12:08:31 <Zakim> +AlexHall; got it
12:08:47 <cmatheus> linked data approach provides tools but its complicated
12:09:30 <cmatheus> talked about focusing on simple actions a json developer might want to take: enumerate instances, describe instance
12:10:21 <cmatheus> mischat: will also enlist help form rdfa TF
12:10:26 <ivan> q+
12:10:35 <ivan> zakim, open queue
12:10:35 <Zakim> ok, ivan, the speaker queue is open
12:10:39 <ivan> q+
12:10:48 <ivan> ack
12:10:49 <Guus> q?
12:10:54 <davidwood> ack ivan
12:11:37 <Zakim> +??P18
12:11:48 <cmatheus> ivan: discussion with Sandro about rdf web app working group (rdfa wg)
12:11:58 <webr3> Zakim, I am ??P18
12:11:58 <Zakim> +webr3; got it
12:12:30 <cmatheus> ivan: their intention is for low level things to be hidden from JS user
12:12:53 <cmatheus> whatever comes out of that group should be coordinated
12:13:04 <cmatheus> need to keep groups in sync
12:13:33 <cmatheus> guus: does this mean our use case numbver one is being done by rdfs wg?
12:13:43 <cmatheus> ivan: it's in the bin
12:13:56 <danbri> 'in the bin?' = trash?
12:14:13 <webr3> next week..
12:14:26 <cmatheus> according to plan rdfa api will be published next week
12:14:41 <cmatheus> this group should look at that document
12:14:56 <Steven> Steven has joined #rdf-wg
12:15:05 <cmatheus> guus: reporting of second breakout?
12:15:22 <sandro> subtopic: Report of Skolemization Breakout
12:15:40 <cmatheus> steveh: problem is if you have bnodes and you want to run a query to get them out there's no way to do that.
12:15:58 <cmatheus> plan is to provide a standard skolemize method to let you get them out
12:16:16 <cmatheus> everyone agreed this was good
12:16:35 <sandro> SteveH: If you query a sparql store and get bnodes out, there's no way to ask about them. We'd like to stdize a way to allow those bnodes to be given lables (be IRI nodes) so you can ask more. The sticky part is about indicating which nodes started out live as bnodes.
12:16:39 <LeeF> LeeF has joined #rdf-wg
12:16:44 <cmatheus> sticky part whether it's desirable to have a way to tell that these started out as bnodes.
12:17:19 <Zakim> +LeeF
12:18:02 <cmatheus> guus: is there consensus that you should be able to tell that they were blank nodes?
12:18:44 <Zakim> +AZ
12:18:46 <Steven> -> http://www.w3.org/2011/04/14-rdf-json-minutes.html Minutes of JSON breakout
12:18:53 <cmatheus> davidwood: core issue: how are people external to the skolem process able to tell they were bnodes.
12:18:57 <danbri> (@cygri, I made a twitter list with rdfwg members, from your post - https://twitter.com/#!/danbri/rdfwg )
12:19:45 <cmatheus> question to peter: do you object to there being a way to be able to tell that these are bnodes?
12:19:53 <sandro> davidwood: Peter, do you object to there being a mechanism for indicating skolem nodes?
12:20:07 <sandro> Peter: I object to it being mandated.
12:20:16 <cmatheus> peter: against it being manditory
12:20:34 <cmatheus> as a consum I don't need to know whether someone skolemized.
12:20:40 <sandro> peter: As a consumer, I don't need to know, in all cases, whether Skolemization was done. It would be nice to know, but it's not even a should.
12:20:58 <gavinc> +q to ask if isBlank() behavior should stay the same with skolemized or non skolemized?
12:20:59 <cmatheus> it's nice if we all did it or all agreed on doing it.
12:21:18 <danbri> so was this skolemised? http://data.linkedmdb.org/page/film/2014 ... who cares!
12:21:24 <sandro> SteveH: I want to be able to mint URIs that are skolem constants for bnodes such that when I get them back I can tell they were bnodes?
12:21:55 <cmatheus> steveh: if the producer gets the bnodes back should they be able to tell if they were created as bnodes? different from having any user being able to tell.
12:22:20 <cmatheus> davidwood: in short, we were not able to get consensus
12:22:23 <gavinc> -q
12:22:31 <cmatheus> guus: will leave it open for the moment
12:22:38 <sandro> danbri, there are several practical situations when I would care, yes.
12:23:07 <cmatheus> guus: turning to clean up
12:23:15 <SteveH> danbri, if someone does INSERT DATA { <http://data.linkedmdb.org/page/film/2014> ... } and it's ont of my bNodes, I really need to be able to tell
12:23:24 <SteveH> otherwise it will screw up the data
12:23:58 <cmatheus> sandro: yesterday issue 10: deprecated, will use archaic
12:24:13 <cmatheus> issues on xs:string, containers
12:24:57 <cmatheus> next item for today: reification
12:25:04 <cmatheus> this is issue-25
12:25:35 <cmatheus> propse that we leave this until after we have a replacement for it
12:26:08 <cmatheus> issue-26: trivial, rdfxml syntax has two ways to state subject: rdf:about and rdf:id
12:26:08 <trackbot> ISSUE-26 Should we deprecate rdf:ID on RDF/XML node elements? (use rdf:about instead) notes added
12:26:26 <cmatheus> proposal to mark idea as archaic
12:26:47 <cmatheus> Steveh: it can be usefull to use rdf:id to ensure you don't reuse an id
12:26:56 <sandro> SteveH: rdf:ID can be useful to find times when you accidentally use it twice....
12:26:59 <cmatheus> (since rdf:id's must be unique)
12:27:08 <AlexHall> do most rdf/xml parsers enforce the uniqueness of rdf:ID?
12:27:08 <cmatheus> guus: no objection to marking archaic
12:27:40 <cmatheus> cygri: I would argue against it. it's a minor issue. fixes a minor problem among the many rdf has.
12:27:51 <cmatheus> if this is the only change let's not go there
12:28:00 <gavinc> Googling for rdf:ID lists documents which give conflicting advice on using it vs. rdf:about
12:28:17 <cmatheus> sandro: wouldn't suggest that we go to much lenght to fix, but would recommend author's not to suggest using rdf:id
12:28:52 <danbri> http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-ID-xml-base
12:28:58 <cmatheus> guus: there is a cost involved to learning to use rdf:id vs. rdf:about
12:29:03 <danbri> "So for example if rdf:ID="name", that would be equivalent to rdf:about="#name". rdf:ID provides an additional check since the same name can only appear once in the scope of an xml:base value (or document, if none is given), so is useful for defining a set of distinct, related terms relative to the same RDF URI reference."
12:29:32 <cmatheus> danbri: rdf:node_id are for bnodes
12:29:34 <danbri> q+
12:30:25 <cmatheus> sandro: no body advocating rdf:id is a good thing just that it's not worth doing much about it
12:30:53 <sandro> PROPOSED: We don't think people should be using rdf:ID, but maybe it's not worth expressing this sentiment in any documents.
12:31:28 <webr3> so why not just deprecate it?
12:31:35 <cmatheus> guus: no one arguing for keeping it
12:31:42 <sandro> webr3, lots of people just gave their reasons.
12:31:46 <sandro> q?
12:31:47 <davidwood> davidwood has joined #rdf-wg
12:31:54 <davidwood> q?
12:31:59 <cmatheus> ivan: I would not touch rdf/xml
12:32:10 <pchampin> @web3: we deprecated the term 'deprecate' yesterday :)
12:32:13 <SteveH> http://www.google.com/search?q=%22rdf%3AID%22 suggests we should keep it
12:32:17 <cmatheus> if we begin to do something with it we will have to do a serious job
12:32:56 <cmatheus> danbri: rdf spec grammar, rdf:id can be used to check name reuse
12:33:12 <sandro> danbri: By saying anything, we complicated the RDF environment.
12:33:16 <cmatheus> if we say anything at all we add complexity to rdf environment.
12:33:24 <pfps> q+
12:33:35 <cmatheus> guus: propose we do not change
12:33:40 <ivan> ack danbri
12:33:42 <ivan> ack pfps
12:33:46 <sandro> PROPOSED: Close ISSUE-26 doing nothing.
12:33:49 <cmatheus> pfps: because it is being used we should do something about it
12:33:57 <LeeF> ISSUE-26?
12:33:57 <trackbot> ISSUE-26 -- Should we deprecate rdf:ID on RDF/XML node elements? (use rdf:about instead) -- open
12:33:57 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/26
12:34:07 <gavinc> I think my objection to rdf:ID is what happens if your xml:base ends with a / ;)
12:34:29 <gavinc> the issue is "appending the attribute value to the result of appending "#""
12:34:38 <NickH> Why is getting rid of rdf:ID more effort than getting rid of XMLLiteral / xsd:String etc?
12:34:42 <cmatheus> davidwood: why if it caused confusion and we agree we should use it why should continue to accept it?
12:34:49 <danbri> q+ to propose that we replace rdf:about and rdf:resource with rdf:uri, i.e. <foaf:Person rdf:uri="#me"><foaf:homepage rdf:uri="/"></foaf:Person>
12:34:55 <cmatheus> marking it archaic is not removing it
12:35:11 <sandro> PROPOSED: Close ISSUE-26 doing nothing.
12:35:12 <NickH> cmatheus: sorry for the inaccuracy
12:35:18 <danbri> q-
12:35:36 <ivan> +1
12:35:38 <cygri> +1
12:35:39 <SteveH> +1
12:35:40 <danbri> +1
12:35:41 <pfps> +0
12:35:41 <AZ> +1
12:35:42 <pchampin> +1
12:35:42 <mbrunati> 1
12:35:43 <gavinc> -0
12:35:43 <cmatheus> +1
12:35:44 <sandro> +0 (I understand)
12:35:44 <webr3> +0
12:35:47 <JFB> +1/3
12:35:51 <davidwood> +0
12:35:57 <mischat> +1
12:36:00 <NickH> Why is marking rdf:ID as archaic more effort than marking XMLLiteral / xsd:String etc archaic?
12:36:05 <FabGandon> +2/3
12:36:07 <sandro> RESOLVED: Close ISSUE-26 doing nothing.
12:36:33 <davidwood> NickH: Because marking rdf:ID as archaic would require a change to the RDF/XML document.
12:36:34 <cmatheus> sandro: rdf:value
12:36:49 <cmatheus> all I can say, mark it as archaic
12:36:51 <danbri> NickH - because those are *vocabulary* constructs which affect the entire ecosystem - rdfa, turtle, json, sparql, owl...
12:37:01 <sandro> SteveH: I like rdf:value
12:37:05 <sandro> Guus: I like it too!
12:37:07 <cmatheus> FabGandon: it's in a best practice note
12:37:26 <LeeF> SCOVO uses rdf:value (for better or for worse)
12:37:26 <NickH> danbri / davidwood thanks
12:37:33 <webr3> I like rdf:value just wish it was defined more clearly
12:37:39 <LeeF> (http://sw.joanneum.at/scovo/schema.html)
12:37:53 <sandro> Guus: In representation of museum data, we annotate with a bnode structure and then use a rdf:value for what's really pointed to.
12:37:54 <cmatheus> guus: example of its use: have things about values such as its dimension
12:38:13 <gavinc> +q Dublin Core also uses it
12:38:13 <danbri> rdf:value was partly from reification, and partly for n-ary -> http://lists.w3.org/Archives/Public/semantic-web/2010Jul/0252.html
12:38:26 <gavinc> +q to talk mention that Dublin Core also uses it
12:38:29 <sandro> guus: Lots of people use this pattern, effectively.
12:38:41 <danbri> it's a bit like toString()
12:38:45 <FabGandon> Note 3 in SWBPWG http://www.w3.org/TR/swbp-n-aryRelations/#sec-notes
12:38:46 <cmatheus> guus: this is a property that points to the value
12:38:54 <cmatheus> it's highly deployed in some communities
12:39:39 <LeeF> Even if it was the most hated thing in the spec, I don't think we ought to deprecate it if it's as widely in use as it appears.
12:39:53 <danbri> re weights-and-measures, http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ uses it for exactly that -- search for <n:units rdf:resource="http://www.nist.gov/units/Pounds"/>
12:39:54 <cmatheus> Steveh: done work with numeric data, want to be able to lterals as subjects in a sense
12:40:00 <yvesr> SteveH, was it signal processign related stuff?
12:40:09 <yvesr> SteveH, had to do the same for this kind of things
12:40:10 <cmatheus> ivan: when you need to add a unit to a value this is perhaps the best way to do it
12:40:16 <sandro> PROPOSED: Close ISSUE-27 doing nothing (not marking rdf:value as archaic).
12:40:20 <gavinc> -q
12:40:21 <pfps> -1
12:40:21 <webr3> +1
12:40:22 <SteveH> yvesr, no, demographics
12:40:23 <cmatheus> danbri: was in the original recommendation for that purpose
12:40:23 <LeeF> +1
12:40:24 <ivan> +1
12:40:26 <gavinc> +1
12:40:30 <AZ> +0
12:40:33 <SteveH> yvesr, but I think it might also be used in LV2
12:40:35 <pchampin> q?
12:40:37 <gavinc> +q to talk mention that Dublin Core also uses it
12:40:39 <davidwood> +1
12:40:40 <cmatheus> cygri: would like evidence on its deployment
12:40:42 <mbrunati> +1
12:40:43 <SteveH> yvesr, for presets and defaults
12:40:55 <FabGandon> +1/2
12:40:58 <cmatheus> pfps: I've seen it. always badly.
12:41:03 <sandro> pfps: Every single case where I've seen it used, it's used badly.
12:41:05 <cmatheus> danbri: how could you tell?
12:41:27 <cmatheus> pfps: there's always a back handed agreement for how it is used
12:41:30 <sandro> pfps: ... where there is a backhanded agreement about what it really means, and where the meaning is really different in every case.
12:41:39 <cmatheus> ivan: this can be done because it is an open ended property
12:41:48 <cmatheus> pfps: destroys the utility of rdf
12:42:00 <cmatheus> rdf:value is used as a local property
12:42:06 <webr3> +1 pfps
12:42:15 <cmatheus> cygri: where used should have defined a local property
12:42:21 <cmatheus> guus: that's not tru
12:42:22 <webr3> it's centered on out of band knowledge about the data
12:42:22 <AZ> +1 cygri
12:42:30 <sandro> cygri: I would argue that every time it's used, a local property should be defined for that.
12:42:37 <cmatheus> rdf:value is for something where we don't have a solution
12:42:56 <cmatheus> steveh: like rdfs:label -- it's a handy thing to have around
12:43:00 <webr3> rdfs:label is a typed link, rdf:value is untyped
12:43:05 <sandro> issue-27
12:43:09 <sandro> issue-27?
12:43:10 <trackbot> ISSUE-27 -- Should we deprecate rdf:value? -- open
12:43:10 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/27
12:43:31 <sandro> http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue
12:43:36 <cmatheus> guus: rdf:label points to string instead of name and rdf:value points to the value
12:43:48 <cmatheus> same kind of function as rdf:label
12:43:51 <mischat> ?q
12:43:56 <danbri> ±0
12:44:16 <danbri> http://www.w3.org/TR/rdf-schema/#ch_value "rdf:value has no meaning on its own. It is provided as a piece of vocabulary that may be used in idioms such as illustrated in example 16 of the RDF primer [RDF-PRIMER]. Despite the lack of formal specification of the meaning of this property, there is value in defining it to encourage the use of a common idiom in examples of this kind."
12:44:18 <cmatheus> pfps: don't mark it as archaic but realize you're making a bad mistake
12:44:20 <LeeF> Can we put an action to address this in the updated primer?
12:44:22 <danbri> ie. RDFS current encourages its use
12:44:33 <cmatheus> sandro: do you want document to same something about it?
12:44:42 <gavinc> Does Dublin Core do it wrong? http://dublincore.org/documents/dc-rdf-notes/
12:44:54 <cmatheus> pfps: no. every time it's been used its been used badly.
12:45:05 <webr3> pfps +1
12:45:10 <sandro> pfps: Every time I've seen rdf:value it's been bad practice, destroying the "beauty" of RDF.
12:45:19 <webr3> it's like <a href="boo">, untyped
12:45:19 <pchampin> @sandro the example in the RDF primer is a bad one :-( (weight)
12:45:30 <cmatheus> pfps: rdf:value is the same as rdf:thispropertydoesn'tmeana*?/thing
12:45:35 <davidwood> davidwood has joined #rdf-wg
12:45:38 <cmatheus> sandro: is this resolved?
12:45:47 <sandro> pfps: I'm not formally objecting to this proposal.
12:45:59 <Zakim> -Meeting_Room
12:46:00 <webr3> should it a couple of new properties be defined for common uses of rdf:value ..
12:46:03 <gavinc> ah
12:46:08 <gavinc> and there goes the phone
12:46:09 <Steven> zakim, who is noisy?
12:46:10 <cmatheus> cygri: is there some text on good use of rdf:value?
12:46:11 <danbri> q+ to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.
12:46:17 <sandro> Guus: I disagree with Peter's characterization
12:46:22 <Zakim> Steven, listening for 10 seconds I heard sound from the following: gavinc (4%)
12:46:23 <sandro> davidwood: As do I.
12:46:42 <cmatheus> I would disagree with some of the things in the Primer
12:46:45 <sandro> cygri: The use for units of measure is extremely questionable.
12:47:06 <Steven> zakim, code?
12:47:06 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Steven
12:47:08 <cmatheus> there's a lot of work on how to measure units of measure, they come up with different solutions
12:47:13 <gavinc> No, I can not hear.
12:47:35 <cmatheus> Sandor: meeting room got hung up on
12:47:53 <sandro> s/Sandor/Sandro/
12:48:12 <Zakim> +Meeting_Room
12:48:50 <cmatheus> cygri: if you just use rdf:value and have addition properties hanging of value telling you what the value means that's bad
12:49:48 <yvesr> :fft rdf:value "..."
12:50:03 <cmatheus> the Primer leads people into bad modeling and we should do something about it
12:50:11 <sandro> cygri: The primer gives bad modeling advice, and I don't like that.
12:50:14 <pchampin> +1 cygri
12:50:16 <yvesr> :fft :derived_from :signal .
12:50:20 <yvesr> all good practice, imho
12:50:21 <cmatheus> guus: we can close this and open a new issue about the Primer
12:50:25 <NickH> yvesr: so avoid repeating very large literal values?
12:50:30 <cmatheus> cygri: okay
12:50:37 <yvesr> NickH, yep
12:50:49 <gavinc> -q
12:50:53 <yvesr> s/yvesr:/yvesr,/
12:51:19 <davidwood> davidwood has joined #rdf-wg
12:51:22 <sandro> PROPOSED: Close ISSUE-27, not marking rdf:value as archaic, but with the understand that the modeling advice in RDF Primer will be revisited.
12:51:26 <yvesr> +1
12:51:28 <ivan> +1
12:51:37 <danbri> q?
12:51:39 <danbri> ack danbri
12:51:39 <Zakim> danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.
12:51:44 <gavinc> +1
12:51:47 <danbri> ahh, i forgot already
12:51:49 <cygri> -0
12:51:59 <davidwood> Dublin Core uses rdf:value in the same manner as the examples in the RDF spec. I think it is therefore compliant.
12:52:00 <AZ> +0
12:52:00 <danbri> action danbri danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.
12:52:00 <trackbot> Created ACTION-33 - Danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value. [on Dan Brickley - due 2011-04-21].
12:52:05 <pchampin> +1
12:52:27 <cmatheus> sandro: can put an Action on Richard to review primer
12:52:58 <cmatheus> cygri: I think there is a technical issue about a bug in the rdf Primer about advice on us eof rdf:value
12:53:23 <cmatheus> guus: could result in Primer ignoring rdf:value
12:53:33 <sandro> RESOLVED: Close ISSUE-27, not marking rdf:value as archaic, but with the understand that the modeling advice in RDF Primer will be revisited.
12:54:17 <cmatheus> sandro: plan to spend another 35 minutes here
12:54:28 <cmatheus> those were all the ones marked as Archic
12:54:43 <cmatheus> s/Archic/Archaic/
12:54:43 <FabGandon> issue-6?
12:54:43 <trackbot> ISSUE-6 -- Handling RDF Errata -- open
12:54:43 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/6
12:55:03 <FabGandon> issue-7?
12:55:04 <trackbot> ISSUE-7 -- Leftover issues from the RDF Core WG -- open
12:55:04 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/7
12:55:12 <cmatheus> ivan: issue 6: � handling of Errata
12:55:14 <mischat> http://www.w3.org/2001/sw/RDFCore/errata
12:55:29 <cmatheus> we have to have a mechanism not to forget these
12:55:30 <davidwood> davidwood has joined #rdf-wg
12:55:38 <mischat> this related to danbri's suggestion of going through the archives
12:55:46 <mischat> s/related/relates/
12:56:01 <cmatheus> nothing earthshakingly major
12:56:24 <cmatheus> issue-7: some issues left open from previous working group
12:56:24 <trackbot> ISSUE-7 Leftover issues from the RDF Core WG notes added
12:56:45 <mischat> http://www.w3.org/2000/03/rdf-tracking/#/%23futures
12:56:53 <cmatheus> danbri: brief comment on list
12:57:07 <cmatheus> some were engineering hacks, left for next group
12:57:20 <webr3> +1
12:57:21 <cmatheus> ivan: we still need to go through them
12:57:34 <cmatheus> davidwood: propose a telecom to discuss these
12:57:40 <yvesr> http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects :)
12:57:47 <cmatheus> pfps: someone should go through them ahead of time
12:57:59 <cmatheus> davidwood: I volunteer to do that
12:58:17 <cmatheus> ivan: IRI versus URI story
12:58:18 <sandro> ACTION: wood prepare resolutions to dispose of each of the leftover items, http://www.w3.org/2000/03/rdf-tracking/#/%23futures
12:58:18 <trackbot> Created ACTION-34 - Prepare resolutions to dispose of each of the leftover items, http://www.w3.org/2000/03/rdf-tracking/#/%23futures [on David Wood - due 2011-04-21].
12:58:25 <cmatheus> frankly I am lost with the details
12:58:53 <gavinc> Jeremy had something on what needed to be updated with the IRIs, but I seem to have miss placed it.
12:58:54 <cmatheus> Andy and Eric know a lot about that
12:58:59 <FabGandon> issue-8?
12:58:59 <trackbot> ISSUE-8 -- Incorporate IRI-s into the RDF documents -- open
12:58:59 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/8
12:59:40 <cmatheus> sandro: we want to take out every we say about URI and replace with IRI
12:59:53 <ivan> The IRI Spec[1] is from 2005, and it may be necessary to retrofit it to RDF. Eg, what is the relationship between "http://xn--rsum-bpad.example.org/" and "http://xn--rsum-bpad.example.org/"? Are they the same resource or not? Note that SPARQL has something on that[2]...
13:00:39 <gavinc> Jeremy thought there were a few when we spoke about it. But again, I've missplaced the record of that conversation
13:00:51 <sandro> "http://résumé.example.org" and "http://xn--rsum-bpad.example.org"?
13:01:03 <cmatheus> ivan: (issue with url's in irc)
13:01:37 <cmatheus> are the displayed iri's refereing to same resource or not
13:02:10 <cmatheus> cygri: two iri's are identifcal if the characters are the same, except in a number of cases...
13:02:24 <cmatheus> s/identifcal/identical/
13:02:25 <davidwood> q+
13:02:58 <cmatheus> the one uri can be normalized into the other
13:03:25 <cmatheus> guus: if it's a problem we can flag it but's it's not in the realm of where we should go
13:03:44 <mischat> http://www.w3.org/TR/sparql11-query/#syntaxTerms
13:03:47 <cmatheus> mischat: if we go this way we will need to have best practise note on this
13:03:53 <cmatheus> sandro: example?
13:03:55 <sandro> mischat: back-tick is valid in URI-References but not IRIs.
13:04:08 <cmatheus> mischat: a back tick. caused out app to go down.
13:04:25 <cmatheus> davidwood: I've seen issues with that, I think it was with back tick.
13:04:36 <gavinc> for reference, IRI spec: http://www.ietf.org/rfc/rfc3987
13:04:46 <cmatheus> guus: objet to description of issues -- it's outside of scope
13:05:11 <pchampin> from the charter (required section): Clarify the usage of IRI references for RDF resources
13:05:18 <cmatheus> mischat: rdf group was guessing at what iris would look like
13:05:32 <cmatheus> davidwood: issue from implementation standdpoint
13:05:50 <ivan> q+
13:06:00 <cmatheus> when trying to index rdf, if you have to do a lot of checking, implementers will screem, Talis for one.
13:06:00 <ivan> ack davidwood
13:06:27 <cmatheus> if we said an iri and uri were equivalent that would cause serious practical problems
13:06:43 <cmatheus> steveH: I understand what you're saying but don't understand the technical problem
13:07:04 <gavinc> +q
13:07:15 <cmatheus> davidwood: when ingesting rdf must say whether this uri ir equivalent to some other uri's in your system
13:07:15 <sandro> SteveH: Every triplestore I know just uses utf-8, so the question is which chars are allowed.
13:07:29 <cmatheus> steveh: it just changes your grammar
13:07:35 <cmatheus> davidwood: you may be right
13:07:42 <cmatheus> SteveH: I'm pretty sure I am
13:07:43 <ivan> ack davidwood
13:07:47 <sandro> SteveH: SPARQL says they have to be the same normalized utf-8 byte string.
13:07:50 <mischat> q+
13:07:54 <cmatheus> davidwood: I'm talking about in SPARQL
13:08:00 <cmatheus> the specs say different things
13:08:07 <cmatheus> cygri: I don't think they do
13:08:23 <cmatheus> in RDF world things are conistent
13:08:37 <cmatheus> s/sconistent/consistent/
13:08:51 <mischat> i don't think they are consistent, you can a SPARQL INSERT triples which you cant CONSTRUCT as valid RDF/XML
13:08:55 <cmatheus> there's no way you can align this with the rest of the web architecture
13:09:08 <SteveH> mischat, no you cant
13:09:08 <cmatheus> but can give recommendations.
13:09:16 <SteveH> mischat, oh, wait, not maybe that's right
13:09:18 <sandro> cygri: We can (and should) give recommendations to publishers about how to mint URIs to avoid these problems, like don't say :80 and dont use uppercase URI scheme or host names.
13:09:22 <mischat> it is right SteveH
13:09:26 <cmatheus> if you avoid certain things then you will get same result
13:09:32 <davidwood> correction: I was *not* talking about SPARQL, but Turtle or other forms of ingesting into a store, and then only in the case where we decided that a given IRI was equivalent to a different character string URI.
13:09:35 <cmatheus> worth writing up as an aid to users of rdf
13:09:51 <davidwood> q?
13:09:52 <cmatheus> ivan: this discussion went beyond what I intended
13:09:57 <davidwood> ack ivan
13:10:38 <cmatheus> but look what happend when we just but the same iri's through two different systems and got very different results
13:10:48 <cmatheus> this is something we need to address
13:10:49 <gavinc> I think the section in question is: http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref
13:10:56 <cmatheus> guus: this is not something we're going to solve
13:11:12 <mischat> this is the IRI RFC http://www.ietf.org/rfc/rfc3987.txt
13:11:19 <gavinc> The RFC lists a set of normalization methods http://www.ietf.org/rfc/rfc3987
13:11:29 <cmatheus> ivan: why? there is a document that says how to implement a system that will do the right thing
13:11:45 <Guus> q?
13:11:46 <cmatheus> davidwood: what is the sate of iri's in the standard (RC)
13:11:58 <cmatheus> cygri: it's implemented in all browsers
13:12:19 <davidwood> ack gavinc
13:12:24 <cmatheus> davidwood: that's different from the state of the standard
13:13:01 <cmatheus> gavinc: we went through this a month ago but I can't find the work we did -- not sure if it got lost in the shuffle
13:13:15 <cmatheus> we didn't think the spec was as brioken as some of the people are saying
13:13:22 <cmatheus> sorry, I don't remember the details
13:13:36 <sandro> davidwood, it's a PROPOSED STANDARD, per http://www.rfc-editor.org/rfcxx00.html#STDbySTD
13:13:48 <sandro> (like almost everything)
13:14:17 <cmatheus> mischat: the issue I have is I can issert certain triples, with content with a back tick, and then retrive it I get something different.
13:14:50 <cmatheus> ivan: there are cetrtain charcters that you cannot put into a xml doc, but in turtle it would be a problem
13:14:54 <sandro> (although URI RFC-3986 is actually a "STANDARD" STD-66 )
13:15:05 <cmatheus> pfps: turtle currently stuck at uri's
13:15:45 <Guus> q?
13:15:54 <cmatheus> gavinc: I don't think turtle is cemented to uris
13:16:03 <davidwood> IRIs seem to be an IETF standards-track (but not standard) RFC (3987), which does not expire. There is a newer proposal, which will expire in Sep 2011 (https://datatracker.ietf.org/doc/draft-ietf-iri-3987bis/)
13:16:07 <cmatheus> gramar refers to iris
13:16:08 <Guus> ack mischat
13:16:37 <cmatheus> sandor: revisit when Eric and Andy (perhaps Jeremy) are around
13:16:43 <cmatheus> ivan: issue 9
13:16:54 <sandro> s/sandor/sandro/
13:17:01 <cmatheus> small thing for Pat and Peter from der Horst
13:17:04 <cygri> davidwood: that's the same as the URI RFC
13:17:18 <cmatheus> an obvious thing that the editor has to take care of
13:17:30 <cmatheus> issue 11, more complicated
13:17:40 <davidwood> davidwood has joined #rdf-wg
13:18:19 <cmatheus> docs published by other wg's that extended the rdf semantics or contained element related to rdf semantics
13:18:45 <cmatheus> implementors focusing on rdf have to visit all docs
13:19:07 <cmatheus> rdf plain literal added vocabulary
13:19:32 <cmatheus> POWDER likewise
13:19:46 <FabGandon> issue-11?
13:19:46 <trackbot> ISSUE-11 -- Reconciliation of various, semantics-oriented documents with the core RDF ones -- open
13:19:46 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/11
13:20:14 <cmatheus> SPARQL 1.1 has Entailment Regimes
13:20:25 <cmatheus> something we should look at
13:20:36 <cmatheus> guus: is there anything we need to do now
13:20:36 <danbri> ( @davidwood, i made a first cut at suggesting closure of the old RDFCore issues: http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0317.html )
13:20:42 <cmatheus> ivan: probably not
13:20:56 <cmatheus> guus: let's leave this open but ensure it gets resolved
13:21:07 <cmatheus> ivan: string literals handled
13:21:31 <cmatheus> xml literals discussed and still open
13:21:36 <cmatheus> that's all
13:23:31 <cmatheus> ivan: (discuss about POWDER extension to rdf schema...)
13:24:10 <cmatheus> guus: bad idea that there are many different groups dealing with these issues
13:25:22 <cmatheus> ivan: not proposing to do any extra work -- need to make references to the other sources of relevant information
# SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00001432
</nowiki></pre>

F2F1

Fgandon — Wed, 16 Mar 2011 15:12:15 GMT

Fgandon:

;Date
:13-14 April 2011
;Location
: Amsterdam, The Netherlands ([http://homepages.cwi.nl/~steven/amsterdam.html a guide])
;Agenda
:tbd
;Venue
:[http://www.cwi.nl CWI]; See [http://www.cwi.nl/general/Address separate page] for directions, or the [http://homepages.cwi.nl/~steven/amsterdam.html pages on Amsterdam] done by Steven Pemberton
;Hotel Recommendations
:[[ftf-amsterdam-hotels|Hotel info]]

; Intent to attend (you must sign up to get internet access, food, ...)
: David Wood
: Ivan Herman
: Richard Cyganiak
: Matteo Brunati
: Sandro Hawke
: Steve Harris
: Guus Schreiber
: Jean-Francois Baget
: Mischa Tuffield
: Nicholas Humfrey
: Yves Raimond
: Thomas Steiner
: Dieter Fensel (trying to reschulde another meeting; will know soon)
: Fabien Gandon
; Intent to attend remotely
: Antoine Zimmermann
: Peter F. Patel-Schneider (maybe in person, but not yet determined)
: Axel Polleres
: Gavin Carothers (Time zones likely to be challenging)
: Lee Feigenbaum
: Manu Sporny
: Scott Bauer

; Regrets
: Andy Seaborne

F2F1

Fgandon — Wed, 16 Mar 2011 15:11:50 GMT

Fgandon:

;Date
:13-14 April 2011
;Location
: Amsterdam, The Netherlands ([http://homepages.cwi.nl/~steven/amsterdam.html a guide])
;Agenda
:tbd
;Venue
:[http://www.cwi.nl CWI]; See [http://www.cwi.nl/general/Address separate page] for directions, or the [http://homepages.cwi.nl/~steven/amsterdam.html pages on Amsterdam] done by Steven Pemberton
;Hotel Recommendations
:[[ftf-amsterdam-hotels|Hotel info]]

; Intent to attend (you must sign up to get internet access, food, ...)
: David Wood
: Ivan Herman
: Richard Cyganiak
: Matteo Brunati
: Sandro Hawke
: Steve Harris
: Guus Schreiber
: Jean-Francois Baget
: Mischa Tuffield
: Nicholas Humfrey
: Yves Raimond
: Thomas Steiner
: Dieter Fensel (trying to reschulde another meeting; will know soon)
; Intent to attend remotely
: Antoine Zimmermann
: Peter F. Patel-Schneider (maybe in person, but not yet determined)
: Axel Polleres
: Gavin Carothers (Time zones likely to be challenging)
: Lee Feigenbaum
: Manu Sporny
: Scott Bauer
: Fabien Gandon

; Regrets
: Andy Seaborne

TF-Graphs

Fgandon — Wed, 02 Mar 2011 16:32:42 GMT

Fgandon: /* Participants */

= Task Force "Graphs" =

== Use Cases ==
Member [[TF-Graphs-UC|Use Cases]] for graphs, graph identifiers, etc.

== Material ==

[http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items#Graph_Identification Suggestions called "Graph Identification" from Stanford Workshop] are reproduced below.

=====Pros=====
* widely used by the community
* part of SPARQL already
* numerous use cases
* clarify confusion in implementation

=====Cons=====
* adds complication and may not solve the issue nevertheless
* complicates the RDF model (potentially)
* risks with backward compatibility should be assessed (e.g., syntax)
* does it need standardization?

=====Proposals=====
* Named graphs, provenance and trust , Jeremy Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler, WWW 2005, http://www.w3.org/2009/12/rdf-ws/p613.pdf, http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/carroll-ISWC2004.pdf
* Quadstores in general
* ODM RDF Metamodel (see http://www.omg.org/spec/ODM/1.0/, section 10.5, derived from Carroll et al.)
* Michel Chein and Marie-Laure Mugnier. Positive nested conceptual graphs. In Proceedings of ICCS '97, volume 1257 of LNAI, pages 95-109, Springer, 1997. (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.3644) ; Nested Graphs: A Graph-based Knowledge Representation Model with FOL Semantics (1998) ( http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.5256 )
* SPARQL Specifications ([http://www.w3.org/TR/rdf-sparql-query/#rdfDataset RDF Datasets]) and related to that, [http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop/AxelWishlist Axel's proposal] to base the work on RDF Datasets (see IRC)
* Notation 3, Tim Berners-Lee, 1998 http://www.w3.org/DesignIssues/Notation3
* ideas from the Topic Maps work (see also SWBPD WG note, http://www.w3.org/TR/rdftm-survey/)
* “Triplesets: Tagging and Grouping in RDF Datasets”, http://www.w3.org/2009/12/rdf-ws/papers/ws24, Atanas Kiryakov, Vassil Momtchev
* hypergraphs (as a general mathematical domain)

=====Technical Issues=====
* mutual roles of quads vs. singleton named graphs vs. named graphs
* extension the RDF(S) semantics?
* new RDF(S) terms? rdf:Graph, rdf:subGraphOf, rdf:equivalentGraph, etc.
* syntax (TRIG, [http://www.w3.org/Submission/rdfsource/ INRIA Member submission], [http://www.springerlink.com/content/wh8x37j46n941427/ Web, Graphs and Semantics] , n3)
* graph inclusion, can named graphs share triples
* whether blank nodes can be shared among multiple graphs
* whether blank nodes can be used as graph names
* named graphs do not fully replace reification
* how would follow your nose apply to named graphs?
* relationships to SPARQL
* effects on the SW stack
* how does it influence the OWL semantics?

== Participants ==

* [http://www.w3.org/2011/rdf-wg/wiki/User:Lfeigenb Lee Feigenbaum]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Rcygania2 Richard Cyganiak]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Fgandon Fabien Gandon]

TF-Graphs-UC

Fgandon — Tue, 01 Mar 2011 17:31:51 GMT

Fgandon: /* Graph URIs as Locations */

= Graph Use Cases =

=== Storage Use Cases ===
===== Organizing Information =====
When storing RDF information in a graph store, we would like to organize related information into separate graphs. Each graph must be identified with a URI to facilitate retrieval.
===== Slicing datasets according to multiple dimensions =====
Within the [http://www.bbc.co.uk BBC], we want to slice large RDF datasets according to multiple dimensions: statements about individual programmes, access control, 'ownership' of the data (what product owns/maintains what set of triples), versioning, etc. All those graphs are potentially overlapping or contained within each other. Those issues are very common in large organisations using a single, centralised, triple store.

===== Permissions =====
Another purpose in storing RDF content in different graphs is to enforce a permissions model so that sensitive information is not accessed by unauthorized users.
===== Graph Changes Over Time =====
When storing graph information retrieved from a URL external to an application, it becomes important to store snapshots of the location over time. When these graph snapshots are taken, it is useful to annotate each snapshot with information such as retrieval time, HTTP Headers used, HTTP Response returned, and other such items that may have affected the contents of the graph snapshot.

Here is a quick JSON-LD (assuming g-snap support) example showing two graph snapshots. The home page changes between the two snapshots:

G-SNAP #1:
<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://linkedin.com/in/manusporny>"
}
"dc:date": "2010-04-18T01:24Z"
}
</pre>

G-SNAP #2:
<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
}
"dc:date": "2011-02-01T18:32Z"
}
</pre>

A more complex example involves supporting decentralized product listings via [http://payswarm.com/ PaySwarm]. That is, in PaySwarm products for sale (access to particular post in a blog, or a particular Web App) are expressed in a decentralized manner on a website. The expression of what is for sale is encapsulated in a graph of information about the asset for sale, pricing information and licensing information that is associated with the sale. The combination of this information is effectively an offer of sale:

<pre>
{
"@": "http://wordpress.payswarm.dev/?p=65#listing",
"a": ["gr:Offering", "ps:Listing"],
"com:payee":
[{
"@": "http://wordpress.payswarm.dev/?p=65#listing-payee",
"a": "com:Payee",
"com:currency": "USD",
"com:destination": "https://payswarm.com/i/johnsmith/accounts/1",
"com:rate": "0.05",
"com:rateType": "<com:FlatAmount>",
"rdfs:comment": "Payment for Intro Blog Article by John Smith."
}],
"com:payeeRule":
[{
"a": "com:PayeeRule",
"com:destinationOwnerType": "<ps:Authority>",
"com:maximumRate": "10",
"com:rateType": "<com:InclusivePercentage>"
}],
"ps:assetHash": "905ab5980931053792fc63e40fb4afd0a2f55e02",
"ps:forAsset": "http://wordpress.payswarm.dev/?p=65#asset",
"ps:license": "http://payswarm.com/licenses/blogging",
"ps:licenseHash": "0d8866836917f8ef58af44accb6efab9a10610ad",
"ps:validFrom": "2011-02-26T00:00:00+0000^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"ps:validUntil": "2011-02-27T00:00:00+0000^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"ps:signature":
{
"a": "ps:JsonldSignature",
"dc:created": "2011-02-26T00:00:00Z^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"dc:creator": "https://payswarm.com/i/johnsmith/keys/4",
"ps:signatureValue": "hluj7gTcjGOhxAfTmr04DXZNYwErXKcNBWqwYnjZCxAPlkl7EUl6L7aS0xENmGe3n3VZebWq9mnPH/mv05tzxUYOi6/ssZG+WFNUXFWRA9u+2AdJL5b07U9s51j3tKG6CRB5wGN6w3MPvgM0TspM+VUGHwsR9ePAfpCuFql9zH4="
}
}
</pre>

Note the "ps:validFrom" and "ps:vaildUntil" dates - that information changes once a day. Since that information in the graph changes, the signatures on the graph change as well. Because of the daily changes, it is important that one is able to track snapshots of this graph as it changes from day to day. Storing this data in a graph store is particularly challenging w/o the fundamental concept of a graph snapshot (Graph Literal).

===== Dependencies e.g. trace inferences and their results =====
Using identifying graphs that where consumed and produced by an inference one can can trace the inferences that enriched a triple store to undo some reasoning for instance when the store is updated.
<pre>
:G1 { :Tom ex:manage :ACompany }

:G2 { :Tom rdf:type ex:Manager }

:G2 ex:deducedFrom :G1
</pre>

=== Query Use Cases ===
While query services are not explicitly addressed in the RDF spec, SPARQL does make use of graph IRIs and we should ensure that the semantics of graph identifiers are compatible with the way in which RDF datasets are defined by SPARQL.
===== Find Information In a Graph =====
When a query service processes a query containing a graph identifier, it must resolve the graph identifier to some collection of materialized RDF content that will be returned in the result set.
===== Computed Graphs =====
Often, graphs exposed by a query service are not present in any sort of physical storage, but rather their contents are computed at query time. Examples include:
* A federated query service may define a graph URI to be the union of graphs accessible through other query services.
* A service that does RDB to RDF mapping via [http://www.w3.org/TR/r2rml/ R2RML] may dynamically compute RDF results based on SQL results at query time.
===== Graph URIs as Locations =====
In the situation where a query service is presented with a graph identifier that is not present in local storage, the query service may wish to resolve the graph URI as a URL and make a request to that URL (possibly with conneg) for a document that serializes the content of that graph.

NB: It is important to consider what the linked data "Follow your nose" approach means for identified graphs.

===== Contextual constraints in queries =====
In e-Science projects we can use identified graphs to represent and query contextual metadata. For instance, evidence-based reasoning requires being able to differentiate assertions considered as universally true and assertions which are concurrent hypothesis or interpretations. One can use identified graphs when annotating experiments (e.g. in biology) or analysis (e.g. in geology). Identified graphs are used to represent different contexts within which alternative metadata can be described.

Identifying the graphs also allows us to hierarchically organize the RDF datasets, based on RDFS entailment. When considering RDF datasets as contexts, the root of the hierarchy contains the triples that are true in any context below it i.e. any other node of the hierarchy entails it. The other nodes of the hierarchy represent specific contexts; each one recursively inherits and adds to the triples of its ancestors. Each node then provides a different context for querying and reasoning. When a hypothesis is tested (as a SPARQL query), the context of the test is specified by the identifier of the graph to be used.

A special case is the introduction of temporal or geographical aspects in querying and reasoning over the triple store: a query may be solved considering only the assertions that are true in a specific range of time or geographical area.

A way to address this family of scenarios is to allow a basic algebra of sets over the identified graphs. For instance to allowing to assert inclusion.

<pre>
:G1 { http://dbpedia.org/page/Nice geo:lat 43.703392 ;
geo:long 7.266274 . }

:G2 ex:includes :G1
:G2 { http://dbpedia.org/page/Nice ex:belongsTo http://dbpedia.org/page/France }

:G3 ex:includes :G1
:G3 { http://dbpedia.org/page/Nice ex:belongsTo http://dbpedia.org/page/Italy }

</pre>

=== Provenance Use Cases ===
===== Digital Signatures on Graphs =====

There are a number of ways to create digital signatures on RDF graphs. Often, you do not want to co-mingle the signature information and the graph. Co-mingling signature information in a graph requires the software to use an algorithm to clean the graph in order to generate the signature hash for verification purposes. It also means that it becomes very difficult to sign a graph containing a digital signature at the top-most level. In order to express a digital signature on a graph of information, the idea of a Graph Literal becomes useful. Take the following as an example of a JSON-LD graph that we would like to digitally sign:

<pre>
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
}
</pre>

One could sign the graph above by adding a few triples to the graph:

<pre>
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>",
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
}
</pre>

However, nobody else could sign that graph without introducing ambiguity as to who signed the graph first. That is, the second signer couldn't sign the initial signer's signature. Therefore, having the concept of a graph snapshot which can be annotated in the same way that triples are annotated becomes very useful. The first signature could be performed like so:

<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
}
</pre>

The example above separates the signature from the data that is being signed, which is good design. The second signature could be performed like so:

<pre>
{
"@":
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
"dc:date": "2011-02-26T22:18Z"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://authority.payswarm.com/webid#key-873>",
"sig:signatureValue": "kMzVmMVDIyOWM32MzI4ZDY3NjI4mQ3OOGQzNGNTIyZTkQzNmExMgoYz="
}
}
</pre>

Note that a "dc:date" has been associated with the initial signed graph. Using this technique, one could verify that:

# The initial graph was signed by a primary author.
# The initial graph w/ signature was annotated and signed by a secondary author.

This is useful when dealing with web-of-trust issues such as trusting graphs which have been cached by third parties. This happens when product listings are cached by companies like Google and then proxied by 3rd parties. You want to ensure that the initial product listing is valid per the asset owner, and that the state of the cache has been verified by Google. This prevents a nefarious proxy of meddling with the information that will be used to perform a financial transaction.

===== Capture elements of the production context =====
A graph may be produced through a variety of means and in very different contexts. For instance it could be the result of some natural language processing or other extractions techniques.
An identified graph may be linked to the context in which it was produced (source, properties, etc.)

<pre>
:G1 { http://dbpedia.org/page/Antibes geo:lat 43.580833 ;
geo:long 7.123889 .
}
:G1 ex:extractedFrom http://en.wikipedia.org/wiki/Antibes
:G1 dc:date "2010-11-12"^^xsd:date
</pre>

== Separate Ontology Use Case ==

This use case is derived from a proposal to have OWL annotations that
can be collected together into a separate ontology (and that might even
be able to affect the main ontology). The proposal itself can be seen
at http://www.w3.org/2007/OWL/wiki/Annotation_System however this "use
case" is somewhat of a modification of the suggestions in the proposal.

The basic need is to be able to generate multiple ontologies from a
single OWL document. One ontology is the ontology that corresponds to
the main information in the document. The other ontology (or
ontologies) would sit alongside the main ontology. These secondary
ontologies might be used to store and reason about things like
provenance or certainty.

Aside from the ability to have multiple ontologies be generated from a
single document, there is the need to be able to have syntactic entities
in the main document show up as semantic entities in the secondary
ontologies. Note that this does *not* directly require reflection, as
the syntactic entities don't have their semantic import in the secondary
ontologies. Any semantic relationship between the main ontology and
secondary ontologies is mediated by relationships outside the formalism
semantics, again so that there is no need for reflection or reification
or ....

So far this is about (OWL) ontologies, not graphs, but it can be turned
into a use case for referenceable graphs either by replacing OWL
ontologies by RDF graphs or by considering RDF graph naming as the
syntactic mechanism for separate ontologies in the RDF encoding of OWL.

== General Annotation Framework ==

As mentionned above, there are use cases for temporal annotation (a graph is valid during a certain time frame), provenance, etc. We want to support reasoning based on these annotation, using a generic approach as defined in <ref name=r1>U. Straccia, N. Lopes, G. Lukacsy, A. Polleres. A General Framework for Representing and Reasoning with Annotated Semantic Web Data. In ''Proceedings of the Twenty-Fourth AAAI Conference on Artificial Intelligence (AAAI-10)'', AAAI Press, 2010. http://axel.deri.ie/publications/stra-etal-2010AAAI.pdf</ref><ref name=r2>N. Lopes, A. Zimmermann, A. Hogan, G. Lukácsy, A. Polleres, U. Straccia, S. Decker. RDF Needs Annotations. In ''RDF Next Steps'', June 2010. http://www.w3.org/2009/12/rdf-ws/papers/ws09</ref><ref name=r3>N. Lopes, A. Polleres, U. Straccia, A. Zimmermann, AnQL: SPARQLing Up Annotated RDFS. In ''Proceedings of the International Semantic Web Conference (ISWC-10)'', no. 6496 in Lecture Notes in Computer Science, Springer-Verlag, 2010, pp.518–533. http://iswc2010.semanticweb.org/pdf/51.pdf</ref>. For instance, in the temporal setting (i.e., where graphs or triples are annotated with time-frames), if:

<pre>
ex:chadhurley rdf:type ex:YoutubeEmployee . [2005,2010]
</pre>

(that, the triple holds at least between 2005 and 2010) and:

<pre>
ex:YoutubeEmployee rdf:type ex:GoogleEmployee . [2006,2011]
</pre>

then:

<pre>
ex:chadhurley rdf:type ex:GoogleEmployee . [2006,2010]
</pre>

If annotations exist in a dataset, one can query for them, asking for instance when a triple holds (e.g., "who was a GoogleEmployee and when?").
This generalises to other types of annotations, as described in <ref name=r1/><ref name=r2/><ref name=r3/>. E.g., with provenance annotation:

<pre>
foaf:Person rdfs:subClassOf foaf:Agent . foaf:
ex:chadhurley rdf:type foaf:Person . dbpedia:
</pre>

one can infer:

<pre>
ex:chadhurley rdf:type foaf:Agen . foaf: \and dbpedia:
</pre>

A typical use case for including provenance in the data is when exchanging datasets coming from multiple sources. This is for instance done for the Billion Triple Challenge, which in fact does not provide a billion triples but a billion quadruple, so that sources are identified.

Following the same generic framework, it is also possible to deal with fuzzy, probabilistic and uncertain information, e.g.,:

<pre>
ex:pictureAreaXYZ rdf:type ex:HumanFace . 0.82
ex:HumanFace rdfs:subClassOf ex:Ellipse . 0.75
</pre>

Fuzzy-annotated RDF are likely to be produced automatically by tools relying on statistical data or heuristic-based algorithm. Terminological statements with uncertainty are very common outputs of ontology matching algorithms.

In all these situations, identifying the triples or graphs to which attach the annotations is necessary.

<references/>

TF-Graphs-UC

Fgandon — Tue, 01 Mar 2011 17:31:37 GMT

Fgandon: /* Graph URIs as Locations */

= Graph Use Cases =

=== Storage Use Cases ===
===== Organizing Information =====
When storing RDF information in a graph store, we would like to organize related information into separate graphs. Each graph must be identified with a URI to facilitate retrieval.
===== Slicing datasets according to multiple dimensions =====
Within the [http://www.bbc.co.uk BBC], we want to slice large RDF datasets according to multiple dimensions: statements about individual programmes, access control, 'ownership' of the data (what product owns/maintains what set of triples), versioning, etc. All those graphs are potentially overlapping or contained within each other. Those issues are very common in large organisations using a single, centralised, triple store.

===== Permissions =====
Another purpose in storing RDF content in different graphs is to enforce a permissions model so that sensitive information is not accessed by unauthorized users.
===== Graph Changes Over Time =====
When storing graph information retrieved from a URL external to an application, it becomes important to store snapshots of the location over time. When these graph snapshots are taken, it is useful to annotate each snapshot with information such as retrieval time, HTTP Headers used, HTTP Response returned, and other such items that may have affected the contents of the graph snapshot.

Here is a quick JSON-LD (assuming g-snap support) example showing two graph snapshots. The home page changes between the two snapshots:

G-SNAP #1:
<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://linkedin.com/in/manusporny>"
}
"dc:date": "2010-04-18T01:24Z"
}
</pre>

G-SNAP #2:
<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
}
"dc:date": "2011-02-01T18:32Z"
}
</pre>

A more complex example involves supporting decentralized product listings via [http://payswarm.com/ PaySwarm]. That is, in PaySwarm products for sale (access to particular post in a blog, or a particular Web App) are expressed in a decentralized manner on a website. The expression of what is for sale is encapsulated in a graph of information about the asset for sale, pricing information and licensing information that is associated with the sale. The combination of this information is effectively an offer of sale:

<pre>
{
"@": "http://wordpress.payswarm.dev/?p=65#listing",
"a": ["gr:Offering", "ps:Listing"],
"com:payee":
[{
"@": "http://wordpress.payswarm.dev/?p=65#listing-payee",
"a": "com:Payee",
"com:currency": "USD",
"com:destination": "https://payswarm.com/i/johnsmith/accounts/1",
"com:rate": "0.05",
"com:rateType": "<com:FlatAmount>",
"rdfs:comment": "Payment for Intro Blog Article by John Smith."
}],
"com:payeeRule":
[{
"a": "com:PayeeRule",
"com:destinationOwnerType": "<ps:Authority>",
"com:maximumRate": "10",
"com:rateType": "<com:InclusivePercentage>"
}],
"ps:assetHash": "905ab5980931053792fc63e40fb4afd0a2f55e02",
"ps:forAsset": "http://wordpress.payswarm.dev/?p=65#asset",
"ps:license": "http://payswarm.com/licenses/blogging",
"ps:licenseHash": "0d8866836917f8ef58af44accb6efab9a10610ad",
"ps:validFrom": "2011-02-26T00:00:00+0000^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"ps:validUntil": "2011-02-27T00:00:00+0000^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"ps:signature":
{
"a": "ps:JsonldSignature",
"dc:created": "2011-02-26T00:00:00Z^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"dc:creator": "https://payswarm.com/i/johnsmith/keys/4",
"ps:signatureValue": "hluj7gTcjGOhxAfTmr04DXZNYwErXKcNBWqwYnjZCxAPlkl7EUl6L7aS0xENmGe3n3VZebWq9mnPH/mv05tzxUYOi6/ssZG+WFNUXFWRA9u+2AdJL5b07U9s51j3tKG6CRB5wGN6w3MPvgM0TspM+VUGHwsR9ePAfpCuFql9zH4="
}
}
</pre>

Note the "ps:validFrom" and "ps:vaildUntil" dates - that information changes once a day. Since that information in the graph changes, the signatures on the graph change as well. Because of the daily changes, it is important that one is able to track snapshots of this graph as it changes from day to day. Storing this data in a graph store is particularly challenging w/o the fundamental concept of a graph snapshot (Graph Literal).

===== Dependencies e.g. trace inferences and their results =====
Using identifying graphs that where consumed and produced by an inference one can can trace the inferences that enriched a triple store to undo some reasoning for instance when the store is updated.
<pre>
:G1 { :Tom ex:manage :ACompany }

:G2 { :Tom rdf:type ex:Manager }

:G2 ex:deducedFrom :G1
</pre>

=== Query Use Cases ===
While query services are not explicitly addressed in the RDF spec, SPARQL does make use of graph IRIs and we should ensure that the semantics of graph identifiers are compatible with the way in which RDF datasets are defined by SPARQL.
===== Find Information In a Graph =====
When a query service processes a query containing a graph identifier, it must resolve the graph identifier to some collection of materialized RDF content that will be returned in the result set.
===== Computed Graphs =====
Often, graphs exposed by a query service are not present in any sort of physical storage, but rather their contents are computed at query time. Examples include:
* A federated query service may define a graph URI to be the union of graphs accessible through other query services.
* A service that does RDB to RDF mapping via [http://www.w3.org/TR/r2rml/ R2RML] may dynamically compute RDF results based on SQL results at query time.
===== Graph URIs as Locations =====
In the situation where a query service is presented with a graph identifier that is not present in local storage, the query service may wish to resolve the graph URI as a URL and make a request to that URL (possibly with conneg) for a document that serializes the content of that graph.

NB: It is important to consider what the linked data "Follow your nose" approach means for identified graphs�

===== Contextual constraints in queries =====
In e-Science projects we can use identified graphs to represent and query contextual metadata. For instance, evidence-based reasoning requires being able to differentiate assertions considered as universally true and assertions which are concurrent hypothesis or interpretations. One can use identified graphs when annotating experiments (e.g. in biology) or analysis (e.g. in geology). Identified graphs are used to represent different contexts within which alternative metadata can be described.

Identifying the graphs also allows us to hierarchically organize the RDF datasets, based on RDFS entailment. When considering RDF datasets as contexts, the root of the hierarchy contains the triples that are true in any context below it i.e. any other node of the hierarchy entails it. The other nodes of the hierarchy represent specific contexts; each one recursively inherits and adds to the triples of its ancestors. Each node then provides a different context for querying and reasoning. When a hypothesis is tested (as a SPARQL query), the context of the test is specified by the identifier of the graph to be used.

A special case is the introduction of temporal or geographical aspects in querying and reasoning over the triple store: a query may be solved considering only the assertions that are true in a specific range of time or geographical area.

A way to address this family of scenarios is to allow a basic algebra of sets over the identified graphs. For instance to allowing to assert inclusion.

<pre>
:G1 { http://dbpedia.org/page/Nice geo:lat 43.703392 ;
geo:long 7.266274 . }

:G2 ex:includes :G1
:G2 { http://dbpedia.org/page/Nice ex:belongsTo http://dbpedia.org/page/France }

:G3 ex:includes :G1
:G3 { http://dbpedia.org/page/Nice ex:belongsTo http://dbpedia.org/page/Italy }

</pre>

=== Provenance Use Cases ===
===== Digital Signatures on Graphs =====

There are a number of ways to create digital signatures on RDF graphs. Often, you do not want to co-mingle the signature information and the graph. Co-mingling signature information in a graph requires the software to use an algorithm to clean the graph in order to generate the signature hash for verification purposes. It also means that it becomes very difficult to sign a graph containing a digital signature at the top-most level. In order to express a digital signature on a graph of information, the idea of a Graph Literal becomes useful. Take the following as an example of a JSON-LD graph that we would like to digitally sign:

<pre>
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
}
</pre>

One could sign the graph above by adding a few triples to the graph:

<pre>
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>",
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
}
</pre>

However, nobody else could sign that graph without introducing ambiguity as to who signed the graph first. That is, the second signer couldn't sign the initial signer's signature. Therefore, having the concept of a graph snapshot which can be annotated in the same way that triples are annotated becomes very useful. The first signature could be performed like so:

<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
}
</pre>

The example above separates the signature from the data that is being signed, which is good design. The second signature could be performed like so:

<pre>
{
"@":
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
"dc:date": "2011-02-26T22:18Z"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://authority.payswarm.com/webid#key-873>",
"sig:signatureValue": "kMzVmMVDIyOWM32MzI4ZDY3NjI4mQ3OOGQzNGNTIyZTkQzNmExMgoYz="
}
}
</pre>

Note that a "dc:date" has been associated with the initial signed graph. Using this technique, one could verify that:

# The initial graph was signed by a primary author.
# The initial graph w/ signature was annotated and signed by a secondary author.

This is useful when dealing with web-of-trust issues such as trusting graphs which have been cached by third parties. This happens when product listings are cached by companies like Google and then proxied by 3rd parties. You want to ensure that the initial product listing is valid per the asset owner, and that the state of the cache has been verified by Google. This prevents a nefarious proxy of meddling with the information that will be used to perform a financial transaction.

===== Capture elements of the production context =====
A graph may be produced through a variety of means and in very different contexts. For instance it could be the result of some natural language processing or other extractions techniques.
An identified graph may be linked to the context in which it was produced (source, properties, etc.)

<pre>
:G1 { http://dbpedia.org/page/Antibes geo:lat 43.580833 ;
geo:long 7.123889 .
}
:G1 ex:extractedFrom http://en.wikipedia.org/wiki/Antibes
:G1 dc:date "2010-11-12"^^xsd:date
</pre>

== Separate Ontology Use Case ==

This use case is derived from a proposal to have OWL annotations that
can be collected together into a separate ontology (and that might even
be able to affect the main ontology). The proposal itself can be seen
at http://www.w3.org/2007/OWL/wiki/Annotation_System however this "use
case" is somewhat of a modification of the suggestions in the proposal.

The basic need is to be able to generate multiple ontologies from a
single OWL document. One ontology is the ontology that corresponds to
the main information in the document. The other ontology (or
ontologies) would sit alongside the main ontology. These secondary
ontologies might be used to store and reason about things like
provenance or certainty.

Aside from the ability to have multiple ontologies be generated from a
single document, there is the need to be able to have syntactic entities
in the main document show up as semantic entities in the secondary
ontologies. Note that this does *not* directly require reflection, as
the syntactic entities don't have their semantic import in the secondary
ontologies. Any semantic relationship between the main ontology and
secondary ontologies is mediated by relationships outside the formalism
semantics, again so that there is no need for reflection or reification
or ....

So far this is about (OWL) ontologies, not graphs, but it can be turned
into a use case for referenceable graphs either by replacing OWL
ontologies by RDF graphs or by considering RDF graph naming as the
syntactic mechanism for separate ontologies in the RDF encoding of OWL.

== General Annotation Framework ==

As mentionned above, there are use cases for temporal annotation (a graph is valid during a certain time frame), provenance, etc. We want to support reasoning based on these annotation, using a generic approach as defined in <ref name=r1>U. Straccia, N. Lopes, G. Lukacsy, A. Polleres. A General Framework for Representing and Reasoning with Annotated Semantic Web Data. In ''Proceedings of the Twenty-Fourth AAAI Conference on Artificial Intelligence (AAAI-10)'', AAAI Press, 2010. http://axel.deri.ie/publications/stra-etal-2010AAAI.pdf</ref><ref name=r2>N. Lopes, A. Zimmermann, A. Hogan, G. Lukácsy, A. Polleres, U. Straccia, S. Decker. RDF Needs Annotations. In ''RDF Next Steps'', June 2010. http://www.w3.org/2009/12/rdf-ws/papers/ws09</ref><ref name=r3>N. Lopes, A. Polleres, U. Straccia, A. Zimmermann, AnQL: SPARQLing Up Annotated RDFS. In ''Proceedings of the International Semantic Web Conference (ISWC-10)'', no. 6496 in Lecture Notes in Computer Science, Springer-Verlag, 2010, pp.518–533. http://iswc2010.semanticweb.org/pdf/51.pdf</ref>. For instance, in the temporal setting (i.e., where graphs or triples are annotated with time-frames), if:

<pre>
ex:chadhurley rdf:type ex:YoutubeEmployee . [2005,2010]
</pre>

(that, the triple holds at least between 2005 and 2010) and:

<pre>
ex:YoutubeEmployee rdf:type ex:GoogleEmployee . [2006,2011]
</pre>

then:

<pre>
ex:chadhurley rdf:type ex:GoogleEmployee . [2006,2010]
</pre>

If annotations exist in a dataset, one can query for them, asking for instance when a triple holds (e.g., "who was a GoogleEmployee and when?").
This generalises to other types of annotations, as described in <ref name=r1/><ref name=r2/><ref name=r3/>. E.g., with provenance annotation:

<pre>
foaf:Person rdfs:subClassOf foaf:Agent . foaf:
ex:chadhurley rdf:type foaf:Person . dbpedia:
</pre>

one can infer:

<pre>
ex:chadhurley rdf:type foaf:Agen . foaf: \and dbpedia:
</pre>

A typical use case for including provenance in the data is when exchanging datasets coming from multiple sources. This is for instance done for the Billion Triple Challenge, which in fact does not provide a billion triples but a billion quadruple, so that sources are identified.

Following the same generic framework, it is also possible to deal with fuzzy, probabilistic and uncertain information, e.g.,:

<pre>
ex:pictureAreaXYZ rdf:type ex:HumanFace . 0.82
ex:HumanFace rdfs:subClassOf ex:Ellipse . 0.75
</pre>

Fuzzy-annotated RDF are likely to be produced automatically by tools relying on statistical data or heuristic-based algorithm. Terminological statements with uncertainty are very common outputs of ontology matching algorithms.

In all these situations, identifying the triples or graphs to which attach the annotations is necessary.

<references/>

TF-Graphs-UC

Fgandon — Tue, 01 Mar 2011 17:24:09 GMT

Fgandon: /* Trace inferences and their results */

= Graph Use Cases =

=== Storage Use Cases ===
===== Organizing Information =====
When storing RDF information in a graph store, we would like to organize related information into separate graphs. Each graph must be identified with a URI to facilitate retrieval.
===== Slicing datasets according to multiple dimensions =====
Within the [http://www.bbc.co.uk BBC], we want to slice large RDF datasets according to multiple dimensions: statements about individual programmes, access control, 'ownership' of the data (what product owns/maintains what set of triples), versioning, etc. All those graphs are potentially overlapping or contained within each other. Those issues are very common in large organisations using a single, centralised, triple store.

===== Permissions =====
Another purpose in storing RDF content in different graphs is to enforce a permissions model so that sensitive information is not accessed by unauthorized users.
===== Graph Changes Over Time =====
When storing graph information retrieved from a URL external to an application, it becomes important to store snapshots of the location over time. When these graph snapshots are taken, it is useful to annotate each snapshot with information such as retrieval time, HTTP Headers used, HTTP Response returned, and other such items that may have affected the contents of the graph snapshot.

Here is a quick JSON-LD (assuming g-snap support) example showing two graph snapshots. The home page changes between the two snapshots:

G-SNAP #1:
<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://linkedin.com/in/manusporny>"
}
"dc:date": "2010-04-18T01:24Z"
}
</pre>

G-SNAP #2:
<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
}
"dc:date": "2011-02-01T18:32Z"
}
</pre>

A more complex example involves supporting decentralized product listings via [http://payswarm.com/ PaySwarm]. That is, in PaySwarm products for sale (access to particular post in a blog, or a particular Web App) are expressed in a decentralized manner on a website. The expression of what is for sale is encapsulated in a graph of information about the asset for sale, pricing information and licensing information that is associated with the sale. The combination of this information is effectively an offer of sale:

<pre>
{
"@": "http://wordpress.payswarm.dev/?p=65#listing",
"a": ["gr:Offering", "ps:Listing"],
"com:payee":
[{
"@": "http://wordpress.payswarm.dev/?p=65#listing-payee",
"a": "com:Payee",
"com:currency": "USD",
"com:destination": "https://payswarm.com/i/johnsmith/accounts/1",
"com:rate": "0.05",
"com:rateType": "<com:FlatAmount>",
"rdfs:comment": "Payment for Intro Blog Article by John Smith."
}],
"com:payeeRule":
[{
"a": "com:PayeeRule",
"com:destinationOwnerType": "<ps:Authority>",
"com:maximumRate": "10",
"com:rateType": "<com:InclusivePercentage>"
}],
"ps:assetHash": "905ab5980931053792fc63e40fb4afd0a2f55e02",
"ps:forAsset": "http://wordpress.payswarm.dev/?p=65#asset",
"ps:license": "http://payswarm.com/licenses/blogging",
"ps:licenseHash": "0d8866836917f8ef58af44accb6efab9a10610ad",
"ps:validFrom": "2011-02-26T00:00:00+0000^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"ps:validUntil": "2011-02-27T00:00:00+0000^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"ps:signature":
{
"a": "ps:JsonldSignature",
"dc:created": "2011-02-26T00:00:00Z^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"dc:creator": "https://payswarm.com/i/johnsmith/keys/4",
"ps:signatureValue": "hluj7gTcjGOhxAfTmr04DXZNYwErXKcNBWqwYnjZCxAPlkl7EUl6L7aS0xENmGe3n3VZebWq9mnPH/mv05tzxUYOi6/ssZG+WFNUXFWRA9u+2AdJL5b07U9s51j3tKG6CRB5wGN6w3MPvgM0TspM+VUGHwsR9ePAfpCuFql9zH4="
}
}
</pre>

Note the "ps:validFrom" and "ps:vaildUntil" dates - that information changes once a day. Since that information in the graph changes, the signatures on the graph change as well. Because of the daily changes, it is important that one is able to track snapshots of this graph as it changes from day to day. Storing this data in a graph store is particularly challenging w/o the fundamental concept of a graph snapshot (Graph Literal).

===== Dependencies e.g. trace inferences and their results =====
Using identifying graphs that where consumed and produced by an inference one can can trace the inferences that enriched a triple store to undo some reasoning for instance when the store is updated.
<pre>
:G1 { :Tom ex:manage :ACompany }

:G2 { :Tom rdf:type ex:Manager }

:G2 ex:deducedFrom :G1
</pre>

=== Query Use Cases ===
While query services are not explicitly addressed in the RDF spec, SPARQL does make use of graph IRIs and we should ensure that the semantics of graph identifiers are compatible with the way in which RDF datasets are defined by SPARQL.
===== Find Information In a Graph =====
When a query service processes a query containing a graph identifier, it must resolve the graph identifier to some collection of materialized RDF content that will be returned in the result set.
===== Computed Graphs =====
Often, graphs exposed by a query service are not present in any sort of physical storage, but rather their contents are computed at query time. Examples include:
* A federated query service may define a graph URI to be the union of graphs accessible through other query services.
* A service that does RDB to RDF mapping via [http://www.w3.org/TR/r2rml/ R2RML] may dynamically compute RDF results based on SQL results at query time.
===== Graph URIs as Locations =====
In the situation where a query service is presented with a graph identifier that is not present in local storage, the query service may wish to resolve the graph URI as a URL and make a request to that URL (possibly with conneg) for a document that serializes the content of that graph.
===== Contextual constraints in queries =====
In e-Science projects we can use identified graphs to represent and query contextual metadata. For instance, evidence-based reasoning requires being able to differentiate assertions considered as universally true and assertions which are concurrent hypothesis or interpretations. One can use identified graphs when annotating experiments (e.g. in biology) or analysis (e.g. in geology). Identified graphs are used to represent different contexts within which alternative metadata can be described.

Identifying the graphs also allows us to hierarchically organize the RDF datasets, based on RDFS entailment. When considering RDF datasets as contexts, the root of the hierarchy contains the triples that are true in any context below it i.e. any other node of the hierarchy entails it. The other nodes of the hierarchy represent specific contexts; each one recursively inherits and adds to the triples of its ancestors. Each node then provides a different context for querying and reasoning. When a hypothesis is tested (as a SPARQL query), the context of the test is specified by the identifier of the graph to be used.

A special case is the introduction of temporal or geographical aspects in querying and reasoning over the triple store: a query may be solved considering only the assertions that are true in a specific range of time or geographical area.

A way to address this family of scenarios is to allow a basic algebra of sets over the identified graphs. For instance to allowing to assert inclusion.

<pre>
:G1 { http://dbpedia.org/page/Nice geo:lat 43.703392 ;
geo:long 7.266274 . }

:G2 ex:includes :G1
:G2 { http://dbpedia.org/page/Nice ex:belongsTo http://dbpedia.org/page/France }

:G3 ex:includes :G1
:G3 { http://dbpedia.org/page/Nice ex:belongsTo http://dbpedia.org/page/Italy }

</pre>

=== Provenance Use Cases ===
===== Digital Signatures on Graphs =====

There are a number of ways to create digital signatures on RDF graphs. Often, you do not want to co-mingle the signature information and the graph. Co-mingling signature information in a graph requires the software to use an algorithm to clean the graph in order to generate the signature hash for verification purposes. It also means that it becomes very difficult to sign a graph containing a digital signature at the top-most level. In order to express a digital signature on a graph of information, the idea of a Graph Literal becomes useful. Take the following as an example of a JSON-LD graph that we would like to digitally sign:

<pre>
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
}
</pre>

One could sign the graph above by adding a few triples to the graph:

<pre>
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>",
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
}
</pre>

However, nobody else could sign that graph without introducing ambiguity as to who signed the graph first. That is, the second signer couldn't sign the initial signer's signature. Therefore, having the concept of a graph snapshot which can be annotated in the same way that triples are annotated becomes very useful. The first signature could be performed like so:

<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
}
</pre>

The example above separates the signature from the data that is being signed, which is good design. The second signature could be performed like so:

<pre>
{
"@":
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
"dc:date": "2011-02-26T22:18Z"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://authority.payswarm.com/webid#key-873>",
"sig:signatureValue": "kMzVmMVDIyOWM32MzI4ZDY3NjI4mQ3OOGQzNGNTIyZTkQzNmExMgoYz="
}
}
</pre>

Note that a "dc:date" has been associated with the initial signed graph. Using this technique, one could verify that:

# The initial graph was signed by a primary author.
# The initial graph w/ signature was annotated and signed by a secondary author.

This is useful when dealing with web-of-trust issues such as trusting graphs which have been cached by third parties. This happens when product listings are cached by companies like Google and then proxied by 3rd parties. You want to ensure that the initial product listing is valid per the asset owner, and that the state of the cache has been verified by Google. This prevents a nefarious proxy of meddling with the information that will be used to perform a financial transaction.

===== Capture elements of the production context =====
A graph may be produced through a variety of means and in very different contexts. For instance it could be the result of some natural language processing or other extractions techniques.
An identified graph may be linked to the context in which it was produced (source, properties, etc.)

<pre>
:G1 { http://dbpedia.org/page/Antibes geo:lat 43.580833 ;
geo:long 7.123889 .
}
:G1 ex:extractedFrom http://en.wikipedia.org/wiki/Antibes
:G1 dc:date "2010-11-12"^^xsd:date
</pre>

== Separate Ontology Use Case ==

This use case is derived from a proposal to have OWL annotations that
can be collected together into a separate ontology (and that might even
be able to affect the main ontology). The proposal itself can be seen
at http://www.w3.org/2007/OWL/wiki/Annotation_System however this "use
case" is somewhat of a modification of the suggestions in the proposal.

The basic need is to be able to generate multiple ontologies from a
single OWL document. One ontology is the ontology that corresponds to
the main information in the document. The other ontology (or
ontologies) would sit alongside the main ontology. These secondary
ontologies might be used to store and reason about things like
provenance or certainty.

Aside from the ability to have multiple ontologies be generated from a
single document, there is the need to be able to have syntactic entities
in the main document show up as semantic entities in the secondary
ontologies. Note that this does *not* directly require reflection, as
the syntactic entities don't have their semantic import in the secondary
ontologies. Any semantic relationship between the main ontology and
secondary ontologies is mediated by relationships outside the formalism
semantics, again so that there is no need for reflection or reification
or ....

So far this is about (OWL) ontologies, not graphs, but it can be turned
into a use case for referenceable graphs either by replacing OWL
ontologies by RDF graphs or by considering RDF graph naming as the
syntactic mechanism for separate ontologies in the RDF encoding of OWL.

== General Annotation Framework ==

As mentionned above, there are use cases for temporal annotation (a graph is valid during a certain time frame), provenance, etc. We want to support reasoning based on these annotation, using a generic approach as defined in <ref name=r1>U. Straccia, N. Lopes, G. Lukacsy, A. Polleres. A General Framework for Representing and Reasoning with Annotated Semantic Web Data. In ''Proceedings of the Twenty-Fourth AAAI Conference on Artificial Intelligence (AAAI-10)'', AAAI Press, 2010. http://axel.deri.ie/publications/stra-etal-2010AAAI.pdf</ref><ref name=r2>N. Lopes, A. Zimmermann, A. Hogan, G. Lukácsy, A. Polleres, U. Straccia, S. Decker. RDF Needs Annotations. In ''RDF Next Steps'', June 2010. http://www.w3.org/2009/12/rdf-ws/papers/ws09</ref><ref name=r3>N. Lopes, A. Polleres, U. Straccia, A. Zimmermann, AnQL: SPARQLing Up Annotated RDFS. In ''Proceedings of the International Semantic Web Conference (ISWC-10)'', no. 6496 in Lecture Notes in Computer Science, Springer-Verlag, 2010, pp.518–533. http://iswc2010.semanticweb.org/pdf/51.pdf</ref>. For instance, in the temporal setting (i.e., where graphs or triples are annotated with time-frames), if:

<pre>
ex:chadhurley rdf:type ex:YoutubeEmployee . [2005,2010]
</pre>

(that, the triple holds at least between 2005 and 2010) and:

<pre>
ex:YoutubeEmployee rdf:type ex:GoogleEmployee . [2006,2011]
</pre>

then:

<pre>
ex:chadhurley rdf:type ex:GoogleEmployee . [2006,2010]
</pre>

If annotations exist in a dataset, one can query for them, asking for instance when a triple holds (e.g., "who was a GoogleEmployee and when?").
This generalises to other types of annotations, as described in <ref name=r1/><ref name=r2/><ref name=r3/>. E.g., with provenance annotation:

<pre>
foaf:Person rdfs:subClassOf foaf:Agent . foaf:
ex:chadhurley rdf:type foaf:Person . dbpedia:
</pre>

one can infer:

<pre>
ex:chadhurley rdf:type foaf:Agen . foaf: \and dbpedia:
</pre>

A typical use case for including provenance in the data is when exchanging datasets coming from multiple sources. This is for instance done for the Billion Triple Challenge, which in fact does not provide a billion triples but a billion quadruple, so that sources are identified.

Following the same generic framework, it is also possible to deal with fuzzy, probabilistic and uncertain information, e.g.,:

<pre>
ex:pictureAreaXYZ rdf:type ex:HumanFace . 0.82
ex:HumanFace rdfs:subClassOf ex:Ellipse . 0.75
</pre>

Fuzzy-annotated RDF are likely to be produced automatically by tools relying on statistical data or heuristic-based algorithm. Terminological statements with uncertainty are very common outputs of ontology matching algorithms.

In all these situations, identifying the triples or graphs to which attach the annotations is necessary.

<references/>

TF-Graphs-UC

Fgandon — Tue, 01 Mar 2011 16:42:50 GMT

Fgandon: /* Contextual constraints in queries */

= Graph Use Cases =

=== Storage Use Cases ===
===== Organizing Information =====
When storing RDF information in a graph store, we would like to organize related information into separate graphs. Each graph must be identified with a URI to facilitate retrieval.
===== Slicing datasets according to multiple dimensions =====
Within the [http://www.bbc.co.uk BBC], we want to slice large RDF datasets according to multiple dimensions: statements about individual programmes, access control, 'ownership' of the data (what product owns/maintains what set of triples), versioning, etc. All those graphs are potentially overlapping or contained within each other. Those issues are very common in large organisations using a single, centralised, triple store.

===== Permissions =====
Another purpose in storing RDF content in different graphs is to enforce a permissions model so that sensitive information is not accessed by unauthorized users.
===== Graph Changes Over Time =====
When storing graph information retrieved from a URL external to an application, it becomes important to store snapshots of the location over time. When these graph snapshots are taken, it is useful to annotate each snapshot with information such as retrieval time, HTTP Headers used, HTTP Response returned, and other such items that may have affected the contents of the graph snapshot.

Here is a quick JSON-LD (assuming g-snap support) example showing two graph snapshots. The home page changes between the two snapshots:

G-SNAP #1:
<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://linkedin.com/in/manusporny>"
}
"dc:date": "2010-04-18T01:24Z"
}
</pre>

G-SNAP #2:
<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
}
"dc:date": "2011-02-01T18:32Z"
}
</pre>

A more complex example involves supporting decentralized product listings via [http://payswarm.com/ PaySwarm]. That is, in PaySwarm products for sale (access to particular post in a blog, or a particular Web App) are expressed in a decentralized manner on a website. The expression of what is for sale is encapsulated in a graph of information about the asset for sale, pricing information and licensing information that is associated with the sale. The combination of this information is effectively an offer of sale:

<pre>
{
"@": "http://wordpress.payswarm.dev/?p=65#listing",
"a": ["gr:Offering", "ps:Listing"],
"com:payee":
[{
"@": "http://wordpress.payswarm.dev/?p=65#listing-payee",
"a": "com:Payee",
"com:currency": "USD",
"com:destination": "https://payswarm.com/i/johnsmith/accounts/1",
"com:rate": "0.05",
"com:rateType": "<com:FlatAmount>",
"rdfs:comment": "Payment for Intro Blog Article by John Smith."
}],
"com:payeeRule":
[{
"a": "com:PayeeRule",
"com:destinationOwnerType": "<ps:Authority>",
"com:maximumRate": "10",
"com:rateType": "<com:InclusivePercentage>"
}],
"ps:assetHash": "905ab5980931053792fc63e40fb4afd0a2f55e02",
"ps:forAsset": "http://wordpress.payswarm.dev/?p=65#asset",
"ps:license": "http://payswarm.com/licenses/blogging",
"ps:licenseHash": "0d8866836917f8ef58af44accb6efab9a10610ad",
"ps:validFrom": "2011-02-26T00:00:00+0000^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"ps:validUntil": "2011-02-27T00:00:00+0000^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"ps:signature":
{
"a": "ps:JsonldSignature",
"dc:created": "2011-02-26T00:00:00Z^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"dc:creator": "https://payswarm.com/i/johnsmith/keys/4",
"ps:signatureValue": "hluj7gTcjGOhxAfTmr04DXZNYwErXKcNBWqwYnjZCxAPlkl7EUl6L7aS0xENmGe3n3VZebWq9mnPH/mv05tzxUYOi6/ssZG+WFNUXFWRA9u+2AdJL5b07U9s51j3tKG6CRB5wGN6w3MPvgM0TspM+VUGHwsR9ePAfpCuFql9zH4="
}
}
</pre>

Note the "ps:validFrom" and "ps:vaildUntil" dates - that information changes once a day. Since that information in the graph changes, the signatures on the graph change as well. Because of the daily changes, it is important that one is able to track snapshots of this graph as it changes from day to day. Storing this data in a graph store is particularly challenging w/o the fundamental concept of a graph snapshot (Graph Literal).

===== Trace inferences and their results =====
Using identifying graphs that where consumed and produced by an inference one can can trace the inferences that enriched a triple store to undo some reasoning for instance when the store is updated.
<pre>
:G1 { :Tom ex:manage :ACompany }

:G2 { :Tom rdf:type ex:Manager }

:G2 ex:deducedFrom :G1
</pre>

=== Query Use Cases ===
While query services are not explicitly addressed in the RDF spec, SPARQL does make use of graph IRIs and we should ensure that the semantics of graph identifiers are compatible with the way in which RDF datasets are defined by SPARQL.
===== Find Information In a Graph =====
When a query service processes a query containing a graph identifier, it must resolve the graph identifier to some collection of materialized RDF content that will be returned in the result set.
===== Computed Graphs =====
Often, graphs exposed by a query service are not present in any sort of physical storage, but rather their contents are computed at query time. Examples include:
* A federated query service may define a graph URI to be the union of graphs accessible through other query services.
* A service that does RDB to RDF mapping via [http://www.w3.org/TR/r2rml/ R2RML] may dynamically compute RDF results based on SQL results at query time.
===== Graph URIs as Locations =====
In the situation where a query service is presented with a graph identifier that is not present in local storage, the query service may wish to resolve the graph URI as a URL and make a request to that URL (possibly with conneg) for a document that serializes the content of that graph.
===== Contextual constraints in queries =====
In e-Science projects we can use identified graphs to represent and query contextual metadata. For instance, evidence-based reasoning requires being able to differentiate assertions considered as universally true and assertions which are concurrent hypothesis or interpretations. One can use identified graphs when annotating experiments (e.g. in biology) or analysis (e.g. in geology). Identified graphs are used to represent different contexts within which alternative metadata can be described.

Identifying the graphs also allows us to hierarchically organize the RDF datasets, based on RDFS entailment. When considering RDF datasets as contexts, the root of the hierarchy contains the triples that are true in any context below it i.e. any other node of the hierarchy entails it. The other nodes of the hierarchy represent specific contexts; each one recursively inherits and adds to the triples of its ancestors. Each node then provides a different context for querying and reasoning. When a hypothesis is tested (as a SPARQL query), the context of the test is specified by the identifier of the graph to be used.

A special case is the introduction of temporal or geographical aspects in querying and reasoning over the triple store: a query may be solved considering only the assertions that are true in a specific range of time or geographical area.

A way to address this family of scenarios is to allow a basic algebra of sets over the identified graphs. For instance to allowing to assert inclusion.

<pre>
:G1 { http://dbpedia.org/page/Nice geo:lat 43.703392 ;
geo:long 7.266274 . }

:G2 ex:includes :G1
:G2 { http://dbpedia.org/page/Nice ex:belongsTo http://dbpedia.org/page/France }

:G3 ex:includes :G1
:G3 { http://dbpedia.org/page/Nice ex:belongsTo http://dbpedia.org/page/Italy }

</pre>

=== Provenance Use Cases ===
===== Digital Signatures on Graphs =====

There are a number of ways to create digital signatures on RDF graphs. Often, you do not want to co-mingle the signature information and the graph. Co-mingling signature information in a graph requires the software to use an algorithm to clean the graph in order to generate the signature hash for verification purposes. It also means that it becomes very difficult to sign a graph containing a digital signature at the top-most level. In order to express a digital signature on a graph of information, the idea of a Graph Literal becomes useful. Take the following as an example of a JSON-LD graph that we would like to digitally sign:

<pre>
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
}
</pre>

One could sign the graph above by adding a few triples to the graph:

<pre>
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>",
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
}
</pre>

However, nobody else could sign that graph without introducing ambiguity as to who signed the graph first. That is, the second signer couldn't sign the initial signer's signature. Therefore, having the concept of a graph snapshot which can be annotated in the same way that triples are annotated becomes very useful. The first signature could be performed like so:

<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
}
</pre>

The example above separates the signature from the data that is being signed, which is good design. The second signature could be performed like so:

<pre>
{
"@":
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
"dc:date": "2011-02-26T22:18Z"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://authority.payswarm.com/webid#key-873>",
"sig:signatureValue": "kMzVmMVDIyOWM32MzI4ZDY3NjI4mQ3OOGQzNGNTIyZTkQzNmExMgoYz="
}
}
</pre>

Note that a "dc:date" has been associated with the initial signed graph. Using this technique, one could verify that:

# The initial graph was signed by a primary author.
# The initial graph w/ signature was annotated and signed by a secondary author.

This is useful when dealing with web-of-trust issues such as trusting graphs which have been cached by third parties. This happens when product listings are cached by companies like Google and then proxied by 3rd parties. You want to ensure that the initial product listing is valid per the asset owner, and that the state of the cache has been verified by Google. This prevents a nefarious proxy of meddling with the information that will be used to perform a financial transaction.

===== Capture elements of the production context =====
A graph may be produced through a variety of means and in very different contexts. For instance it could be the result of some natural language processing or other extractions techniques.
An identified graph may be linked to the context in which it was produced (source, properties, etc.)

<pre>
:G1 { http://dbpedia.org/page/Antibes geo:lat 43.580833 ;
geo:long 7.123889 .
}
:G1 ex:extractedFrom http://en.wikipedia.org/wiki/Antibes
:G1 dc:date "2010-11-12"^^xsd:date
</pre>

== Separate Ontology Use Case ==

This use case is derived from a proposal to have OWL annotations that
can be collected together into a separate ontology (and that might even
be able to affect the main ontology). The proposal itself can be seen
at http://www.w3.org/2007/OWL/wiki/Annotation_System however this "use
case" is somewhat of a modification of the suggestions in the proposal.

The basic need is to be able to generate multiple ontologies from a
single OWL document. One ontology is the ontology that corresponds to
the main information in the document. The other ontology (or
ontologies) would sit alongside the main ontology. These secondary
ontologies might be used to store and reason about things like
provenance or certainty.

Aside from the ability to have multiple ontologies be generated from a
single document, there is the need to be able to have syntactic entities
in the main document show up as semantic entities in the secondary
ontologies. Note that this does *not* directly require reflection, as
the syntactic entities don't have their semantic import in the secondary
ontologies. Any semantic relationship between the main ontology and
secondary ontologies is mediated by relationships outside the formalism
semantics, again so that there is no need for reflection or reification
or ....

So far this is about (OWL) ontologies, not graphs, but it can be turned
into a use case for referenceable graphs either by replacing OWL
ontologies by RDF graphs or by considering RDF graph naming as the
syntactic mechanism for separate ontologies in the RDF encoding of OWL.

== General Annotation Framework ==

As mentionned above, there are use cases for temporal annotation (a graph is valid during a certain time frame), provenance, etc. We want to support reasoning based on these annotation, using a generic approach as defined in <ref name=r1>U. Straccia, N. Lopes, G. Lukacsy, A. Polleres. A General Framework for Representing and Reasoning with Annotated Semantic Web Data. In ''Proceedings of the Twenty-Fourth AAAI Conference on Artificial Intelligence (AAAI-10)'', AAAI Press, 2010. http://axel.deri.ie/publications/stra-etal-2010AAAI.pdf</ref><ref name=r2>N. Lopes, A. Zimmermann, A. Hogan, G. Lukácsy, A. Polleres, U. Straccia, S. Decker. RDF Needs Annotations. In ''RDF Next Steps'', June 2010. http://www.w3.org/2009/12/rdf-ws/papers/ws09</ref><ref name=r3>N. Lopes, A. Polleres, U. Straccia, A. Zimmermann, AnQL: SPARQLing Up Annotated RDFS. In ''Proceedings of the International Semantic Web Conference (ISWC-10)'', no. 6496 in Lecture Notes in Computer Science, Springer-Verlag, 2010, pp.518–533. http://iswc2010.semanticweb.org/pdf/51.pdf</ref>. For instance, in the temporal setting (i.e., where graphs or triples are annotated with time-frames), if:

<pre>
ex:chadhurley rdf:type ex:YoutubeEmployee . [2005,2010]
</pre>

(that, the triple holds at least between 2005 and 2010) and:

<pre>
ex:YoutubeEmployee rdf:type ex:GoogleEmployee . [2006,2011]
</pre>

then:

<pre>
ex:chadhurley rdf:type ex:GoogleEmployee . [2006,2010]
</pre>

If annotations exist in a dataset, one can query for them, asking for instance when a triple holds (e.g., "who was a GoogleEmployee and when?").
This generalises to other types of annotations, as described in <ref name=r1/><ref name=r2/><ref name=r3/>. E.g., with provenance annotation:

<pre>
foaf:Person rdfs:subClassOf foaf:Agent . foaf:
ex:chadhurley rdf:type foaf:Person . dbpedia:
</pre>

one can infer:

<pre>
ex:chadhurley rdf:type foaf:Agen . foaf: \and dbpedia:
</pre>

A typical use case for including provenance in the data is when exchanging datasets coming from multiple sources. This is for instance done for the Billion Triple Challenge, which in fact does not provide a billion triples but a billion quadruple, so that sources are identified.

Following the same generic framework, it is also possible to deal with fuzzy, probabilistic and uncertain information, e.g.,:

<pre>
ex:pictureAreaXYZ rdf:type ex:HumanFace . 0.82
ex:HumanFace rdfs:subClassOf ex:Ellipse . 0.75
</pre>

Fuzzy-annotated RDF are likely to be produced automatically by tools relying on statistical data or heuristic-based algorithm. Terminological statements with uncertainty are very common outputs of ontology matching algorithms.

In all these situations, identifying the triples or graphs to which attach the annotations is necessary.

<references/>

TF-Graphs-UC

Fgandon — Tue, 01 Mar 2011 16:23:54 GMT

Fgandon: /* Query Use Cases */

= Graph Use Cases =

=== Storage Use Cases ===
===== Organizing Information =====
When storing RDF information in a graph store, we would like to organize related information into separate graphs. Each graph must be identified with a URI to facilitate retrieval.
===== Slicing datasets according to multiple dimensions =====
Within the [http://www.bbc.co.uk BBC], we want to slice large RDF datasets according to multiple dimensions: statements about individual programmes, access control, 'ownership' of the data (what product owns/maintains what set of triples), versioning, etc. All those graphs are potentially overlapping or contained within each other. Those issues are very common in large organisations using a single, centralised, triple store.

===== Permissions =====
Another purpose in storing RDF content in different graphs is to enforce a permissions model so that sensitive information is not accessed by unauthorized users.
===== Graph Changes Over Time =====
When storing graph information retrieved from a URL external to an application, it becomes important to store snapshots of the location over time. When these graph snapshots are taken, it is useful to annotate each snapshot with information such as retrieval time, HTTP Headers used, HTTP Response returned, and other such items that may have affected the contents of the graph snapshot.

Here is a quick JSON-LD (assuming g-snap support) example showing two graph snapshots. The home page changes between the two snapshots:

G-SNAP #1:
<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://linkedin.com/in/manusporny>"
}
"dc:date": "2010-04-18T01:24Z"
}
</pre>

G-SNAP #2:
<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
}
"dc:date": "2011-02-01T18:32Z"
}
</pre>

A more complex example involves supporting decentralized product listings via [http://payswarm.com/ PaySwarm]. That is, in PaySwarm products for sale (access to particular post in a blog, or a particular Web App) are expressed in a decentralized manner on a website. The expression of what is for sale is encapsulated in a graph of information about the asset for sale, pricing information and licensing information that is associated with the sale. The combination of this information is effectively an offer of sale:

<pre>
{
"@": "http://wordpress.payswarm.dev/?p=65#listing",
"a": ["gr:Offering", "ps:Listing"],
"com:payee":
[{
"@": "http://wordpress.payswarm.dev/?p=65#listing-payee",
"a": "com:Payee",
"com:currency": "USD",
"com:destination": "https://payswarm.com/i/johnsmith/accounts/1",
"com:rate": "0.05",
"com:rateType": "<com:FlatAmount>",
"rdfs:comment": "Payment for Intro Blog Article by John Smith."
}],
"com:payeeRule":
[{
"a": "com:PayeeRule",
"com:destinationOwnerType": "<ps:Authority>",
"com:maximumRate": "10",
"com:rateType": "<com:InclusivePercentage>"
}],
"ps:assetHash": "905ab5980931053792fc63e40fb4afd0a2f55e02",
"ps:forAsset": "http://wordpress.payswarm.dev/?p=65#asset",
"ps:license": "http://payswarm.com/licenses/blogging",
"ps:licenseHash": "0d8866836917f8ef58af44accb6efab9a10610ad",
"ps:validFrom": "2011-02-26T00:00:00+0000^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"ps:validUntil": "2011-02-27T00:00:00+0000^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"ps:signature":
{
"a": "ps:JsonldSignature",
"dc:created": "2011-02-26T00:00:00Z^^<http://www.w3.org/2001/XMLSchema#dateTime>",
"dc:creator": "https://payswarm.com/i/johnsmith/keys/4",
"ps:signatureValue": "hluj7gTcjGOhxAfTmr04DXZNYwErXKcNBWqwYnjZCxAPlkl7EUl6L7aS0xENmGe3n3VZebWq9mnPH/mv05tzxUYOi6/ssZG+WFNUXFWRA9u+2AdJL5b07U9s51j3tKG6CRB5wGN6w3MPvgM0TspM+VUGHwsR9ePAfpCuFql9zH4="
}
}
</pre>

Note the "ps:validFrom" and "ps:vaildUntil" dates - that information changes once a day. Since that information in the graph changes, the signatures on the graph change as well. Because of the daily changes, it is important that one is able to track snapshots of this graph as it changes from day to day. Storing this data in a graph store is particularly challenging w/o the fundamental concept of a graph snapshot (Graph Literal).

===== Trace inferences and their results =====
Using identifying graphs that where consumed and produced by an inference one can can trace the inferences that enriched a triple store to undo some reasoning for instance when the store is updated.
<pre>
:G1 { :Tom ex:manage :ACompany }

:G2 { :Tom rdf:type ex:Manager }

:G2 ex:deducedFrom :G1
</pre>

=== Query Use Cases ===
While query services are not explicitly addressed in the RDF spec, SPARQL does make use of graph IRIs and we should ensure that the semantics of graph identifiers are compatible with the way in which RDF datasets are defined by SPARQL.
===== Find Information In a Graph =====
When a query service processes a query containing a graph identifier, it must resolve the graph identifier to some collection of materialized RDF content that will be returned in the result set.
===== Computed Graphs =====
Often, graphs exposed by a query service are not present in any sort of physical storage, but rather their contents are computed at query time. Examples include:
* A federated query service may define a graph URI to be the union of graphs accessible through other query services.
* A service that does RDB to RDF mapping via [http://www.w3.org/TR/r2rml/ R2RML] may dynamically compute RDF results based on SQL results at query time.
===== Graph URIs as Locations =====
In the situation where a query service is presented with a graph identifier that is not present in local storage, the query service may wish to resolve the graph URI as a URL and make a request to that URL (possibly with conneg) for a document that serializes the content of that graph.
===== Contextual constraints in queries =====
In e-Science projects we can use identified graphs to represent and query contextual metadata. For instance, evidence-based reasoning requires being able to differentiate assertions considered as universally true and assertions which are concurrent hypothesis or interpretations. One can use identified graphs when annotating experiments (e.g. in biology) or analysis (e.g. in geology). Identified graphs are used to represent different contexts within which alternative metadata can be described.

Identifying the graphs also allows us to hierarchically organize the RDF datasets, based on RDFS entailment. When considering RDF datasets as contexts, the root of the hierarchy contains the triples that are true in any context below it i.e. any other node of the hierarchy entails it. The other nodes of the hierarchy represent specific contexts; each one recursively inherits and adds to the triples of its ancestors. Each node then provides a different context for querying and reasoning. When a hypothesis is tested (as a SPARQL query), the context of the test is specified by the identifier of the graph to be used.

A special case is the introduction of temporal or geographical aspects in querying and reasoning over the triple store: a query may be solved considering only the assertions that are true in a specific range of time or geographical area.

=== Provenance Use Cases ===
===== Digital Signatures on Graphs =====

There are a number of ways to create digital signatures on RDF graphs. Often, you do not want to co-mingle the signature information and the graph. Co-mingling signature information in a graph requires the software to use an algorithm to clean the graph in order to generate the signature hash for verification purposes. It also means that it becomes very difficult to sign a graph containing a digital signature at the top-most level. In order to express a digital signature on a graph of information, the idea of a Graph Literal becomes useful. Take the following as an example of a JSON-LD graph that we would like to digitally sign:

<pre>
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
}
</pre>

One could sign the graph above by adding a few triples to the graph:

<pre>
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>",
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
}
</pre>

However, nobody else could sign that graph without introducing ambiguity as to who signed the graph first. That is, the second signer couldn't sign the initial signer's signature. Therefore, having the concept of a graph snapshot which can be annotated in the same way that triples are annotated becomes very useful. The first signature could be performed like so:

<pre>
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
}
</pre>

The example above separates the signature from the data that is being signed, which is good design. The second signature could be performed like so:

<pre>
{
"@":
{
"@":
{
"a": "<foaf:Person>",
"foaf:name": "Manu Sporny",
"foaf:homepage": "<http://manu.sporny.org/>"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://manu.sporny.org/webid#key-5>",
"sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
}
"dc:date": "2011-02-26T22:18Z"
},
"sig:signature:
{
"a": "<sig:JsonldSignature>",
"sig:signer": "<http://authority.payswarm.com/webid#key-873>",
"sig:signatureValue": "kMzVmMVDIyOWM32MzI4ZDY3NjI4mQ3OOGQzNGNTIyZTkQzNmExMgoYz="
}
}
</pre>

Note that a "dc:date" has been associated with the initial signed graph. Using this technique, one could verify that:

# The initial graph was signed by a primary author.
# The initial graph w/ signature was annotated and signed by a secondary author.

This is useful when dealing with web-of-trust issues such as trusting graphs which have been cached by third parties. This happens when product listings are cached by companies like Google and then proxied by 3rd parties. You want to ensure that the initial product listing is valid per the asset owner, and that the state of the cache has been verified by Google. This prevents a nefarious proxy of meddling with the information that will be used to perform a financial transaction.

===== Capture elements of the production context =====
A graph may be produced through a variety of means and in very different contexts. For instance it could be the result of some natural language processing or other extractions techniques.
An identified graph may be linked to the context in which it was produced (source, properties, etc.)

<pre>
:G1 { http://dbpedia.org/page/Antibes geo:lat 43.580833 ;
geo:long 7.123889 .
}
:G1 ex:extractedFrom http://en.wikipedia.org/wiki/Antibes
:G1 dc:date "2010-11-12"^^xsd:date
</pre>

== Separate Ontology Use Case ==

This use case is derived from a proposal to have OWL annotations that
can be collected together into a separate ontology (and that might even
be able to affect the main ontology). The proposal itself can be seen
at http://www.w3.org/2007/OWL/wiki/Annotation_System however this "use
case" is somewhat of a modification of the suggestions in the proposal.

The basic need is to be able to generate multiple ontologies from a
single OWL document. One ontology is the ontology that corresponds to
the main information in the document. The other ontology (or
ontologies) would sit alongside the main ontology. These secondary
ontologies might be used to store and reason about things like
provenance or certainty.

Aside from the ability to have multiple ontologies be generated from a
single document, there is the need to be able to have syntactic entities
in the main document show up as semantic entities in the secondary
ontologies. Note that this does *not* directly require reflection, as
the syntactic entities don't have their semantic import in the secondary
ontologies. Any semantic relationship between the main ontology and
secondary ontologies is mediated by relationships outside the formalism
semantics, again so that there is no need for reflection or reification
or ....

So far this is about (OWL) ontologies, not graphs, but it can be turned
into a use case for referenceable graphs either by replacing OWL
ontologies by RDF graphs or by considering RDF graph naming as the
syntactic mechanism for separate ontologies in the RDF encoding of OWL.

TF-Graphs-UC

Fgandon — Tue, 01 Mar 2011 16:15:52 GMT

Fgandon: /* Capture elements of the production context */

TF-Graphs-UC

Fgandon — Tue, 01 Mar 2011 16:14:09 GMT

Fgandon: /* Provenance Use Cases */

TF-Graphs-UC

Fgandon — Tue, 01 Mar 2011 16:02:05 GMT

Fgandon: /* Trace inferences and their results */

TF-Graphs-UC

Fgandon — Tue, 01 Mar 2011 16:01:53 GMT

Fgandon: /* Trace inferences and their results */

TF-Graphs-UC

Fgandon — Tue, 01 Mar 2011 15:58:19 GMT

Fgandon: /* Storage Use Cases */

TF-Graphs

Fgandon — Fri, 18 Feb 2011 09:52:55 GMT

Fgandon: /* Material */

= Task Force "Graphs" =

== Material ==

[http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items#Graph_Identification Suggestions called "Graph Identification" from Stanford Workshop] are reproduced below.

=====Pros=====
* widely used by the community
* part of SPARQL already
* numerous use cases
* clarify confusion in implementation

=====Cons=====
* adds complication and may not solve the issue nevertheless
* complicates the RDF model (potentially)
* risks with backward compatibility should be assessed (e.g., syntax)
* does it need standardization?

=====Proposals=====
* Named graphs, provenance and trust , Jeremy Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler, WWW 2005, http://www.w3.org/2009/12/rdf-ws/p613.pdf, http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/carroll-ISWC2004.pdf
* Quadstores in general
* ODM RDF Metamodel (see http://www.omg.org/spec/ODM/1.0/, section 10.5, derived from Carroll et al.)
* Michel Chein and Marie-Laure Mugnier. Positive nested conceptual graphs. In Proceedings of ICCS '97, volume 1257 of LNAI, pages 95-109, Springer, 1997. (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.3644) ; Nested Graphs: A Graph-based Knowledge Representation Model with FOL Semantics (1998) ( http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.5256 )
* SPARQL Specifications ([http://www.w3.org/TR/rdf-sparql-query/#rdfDataset RDF Datasets]) and related to that, [http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop/AxelWishlist Axel's proposal] to base the work on RDF Datasets (see IRC)
* Notation 3, Tim Berners-Lee, 1998 http://www.w3.org/DesignIssues/Notation3
* ideas from the Topic Maps work (see also SWBPD WG note, http://www.w3.org/TR/rdftm-survey/)
* “Triplesets: Tagging and Grouping in RDF Datasets”, http://www.w3.org/2009/12/rdf-ws/papers/ws24, Atanas Kiryakov, Vassil Momtchev
* hypergraphs (as a general mathematical domain)

=====Technical Issues=====
* mutual roles of quads vs. singleton named graphs vs. named graphs
* extension the RDF(S) semantics?
* new RDF(S) terms? rdf:Graph, rdf:subGraphOf, rdf:equivalentGraph, etc.
* syntax (TRIG, [http://www.w3.org/Submission/rdfsource/ INRIA Member submission], [http://www.springerlink.com/content/wh8x37j46n941427/ Web, Graphs and Semantics] , n3)
* graph inclusion, can named graphs share triples
* whether blank nodes can be shared among multiple graphs
* whether blank nodes can be used as graph names
* named graphs do not fully replace reification
* how would follow your nose apply to named graphs?
* relationships to SPARQL
* effects on the SW stack

TF-Graphs

Fgandon — Fri, 18 Feb 2011 09:52:18 GMT

Fgandon: /* Material */

= Task Force "Graphs" =

== Material ==

[http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items#Graph_Identification Suggestions called "Graph Identification" from Stanford Workshop] are reproduced below.

=====Pros=====
* widely used by the community
* part of SPARQL already
* numerous use cases
* clarify confusion in implementation

=====Cons=====
* adds complication and may not solve the issue nevertheless
* complicates the RDF model (potentially)
* risks with backward compatibility should be assessed (e.g., syntax)
* does it need standardization?

====Proposals====
* Named graphs, provenance and trust , Jeremy Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler, WWW 2005, http://www.w3.org/2009/12/rdf-ws/p613.pdf, http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/carroll-ISWC2004.pdf
* Quadstores in general
* ODM RDF Metamodel (see http://www.omg.org/spec/ODM/1.0/, section 10.5, derived from Carroll et al.)
* Michel Chein and Marie-Laure Mugnier. Positive nested conceptual graphs. In Proceedings of ICCS '97, volume 1257 of LNAI, pages 95-109, Springer, 1997. (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.3644) ; Nested Graphs: A Graph-based Knowledge Representation Model with FOL Semantics (1998) ( http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.5256 )
* SPARQL Specifications ([http://www.w3.org/TR/rdf-sparql-query/#rdfDataset RDF Datasets]) and related to that, [http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop/AxelWishlist Axel's proposal] to base the work on RDF Datasets (see IRC)
* Notation 3, Tim Berners-Lee, 1998 http://www.w3.org/DesignIssues/Notation3
* ideas from the Topic Maps work (see also SWBPD WG note, http://www.w3.org/TR/rdftm-survey/)
* “Triplesets: Tagging and Grouping in RDF Datasets”, http://www.w3.org/2009/12/rdf-ws/papers/ws24, Atanas Kiryakov, Vassil Momtchev
* hypergraphs (as a general mathematical domain)

====Technical Issues====
* mutual roles of quads vs. singleton named graphs vs. named graphs
* extension the RDF(S) semantics?
* new RDF(S) terms? rdf:Graph, rdf:subGraphOf, rdf:equivalentGraph, etc.
* syntax (TRIG, [http://www.w3.org/Submission/rdfsource/ INRIA Member submission], [http://www.springerlink.com/content/wh8x37j46n941427/ Web, Graphs and Semantics] , n3)
* graph inclusion, can named graphs share triples
* whether blank nodes can be shared among multiple graphs
* whether blank nodes can be used as graph names
* named graphs do not fully replace reification
* how would follow your nose apply to named graphs?
* relationships to SPARQL
* effects on the SW stack

TF-Graphs

Fgandon — Fri, 18 Feb 2011 09:51:57 GMT

Fgandon: /* Material */

= Task Force "Graphs" =

== Material ==

[http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items#Graph_Identification Suggestions called "Graph Identification" from Stanford Workshop] are reproduced below.

=====Pros=====
* widely used by the community
* part of SPARQL already
* numerous use cases
* clarify confusion in implementation

====Cons====
* adds complication and may not solve the issue nevertheless
* complicates the RDF model (potentially)
* risks with backward compatibility should be assessed (e.g., syntax)
* does it need standardization?

====Proposals====
* Named graphs, provenance and trust , Jeremy Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler, WWW 2005, http://www.w3.org/2009/12/rdf-ws/p613.pdf, http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/carroll-ISWC2004.pdf
* Quadstores in general
* ODM RDF Metamodel (see http://www.omg.org/spec/ODM/1.0/, section 10.5, derived from Carroll et al.)
* Michel Chein and Marie-Laure Mugnier. Positive nested conceptual graphs. In Proceedings of ICCS '97, volume 1257 of LNAI, pages 95-109, Springer, 1997. (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.3644) ; Nested Graphs: A Graph-based Knowledge Representation Model with FOL Semantics (1998) ( http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.5256 )
* SPARQL Specifications ([http://www.w3.org/TR/rdf-sparql-query/#rdfDataset RDF Datasets]) and related to that, [http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop/AxelWishlist Axel's proposal] to base the work on RDF Datasets (see IRC)
* Notation 3, Tim Berners-Lee, 1998 http://www.w3.org/DesignIssues/Notation3
* ideas from the Topic Maps work (see also SWBPD WG note, http://www.w3.org/TR/rdftm-survey/)
* “Triplesets: Tagging and Grouping in RDF Datasets”, http://www.w3.org/2009/12/rdf-ws/papers/ws24, Atanas Kiryakov, Vassil Momtchev
* hypergraphs (as a general mathematical domain)

====Technical Issues====
* mutual roles of quads vs. singleton named graphs vs. named graphs
* extension the RDF(S) semantics?
* new RDF(S) terms? rdf:Graph, rdf:subGraphOf, rdf:equivalentGraph, etc.
* syntax (TRIG, [http://www.w3.org/Submission/rdfsource/ INRIA Member submission], [http://www.springerlink.com/content/wh8x37j46n941427/ Web, Graphs and Semantics] , n3)
* graph inclusion, can named graphs share triples
* whether blank nodes can be shared among multiple graphs
* whether blank nodes can be used as graph names
* named graphs do not fully replace reification
* how would follow your nose apply to named graphs?
* relationships to SPARQL
* effects on the SW stack

TF-Graphs

Fgandon — Fri, 18 Feb 2011 09:49:20 GMT

Fgandon: /* Proposals */

= Task Force "Graphs" =

== Material ==

[http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items#Graph_Identification Suggestions called "Graph Identification" from Stanford Workshop] are reproduced below.

====Pros====
* widely used by the community
* part of SPARQL already
* numerous use cases
* clarify confusion in implementation

====Cons====
* adds complication and may not solve the issue nevertheless
* complicates the RDF model (potentially)
* risks with backward compatibility should be assessed (e.g., syntax)
* does it need standardization?

====Proposals====
* Named graphs, provenance and trust , Jeremy Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler, WWW 2005, http://www.w3.org/2009/12/rdf-ws/p613.pdf, http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/carroll-ISWC2004.pdf
* Quadstores in general
* ODM RDF Metamodel (see http://www.omg.org/spec/ODM/1.0/, section 10.5, derived from Carroll et al.)
* Michel Chein and Marie-Laure Mugnier. Positive nested conceptual graphs. In Proceedings of ICCS '97, volume 1257 of LNAI, pages 95-109, Springer, 1997. (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.3644) ; Nested Graphs: A Graph-based Knowledge Representation Model with FOL Semantics (1998) ( http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.5256 )
* SPARQL Specifications ([http://www.w3.org/TR/rdf-sparql-query/#rdfDataset RDF Datasets]) and related to that, [http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop/AxelWishlist Axel's proposal] to base the work on RDF Datasets (see IRC)
* Notation 3, Tim Berners-Lee, 1998 http://www.w3.org/DesignIssues/Notation3
* ideas from the Topic Maps work (see also SWBPD WG note, http://www.w3.org/TR/rdftm-survey/)
* “Triplesets: Tagging and Grouping in RDF Datasets”, http://www.w3.org/2009/12/rdf-ws/papers/ws24, Atanas Kiryakov, Vassil Momtchev
* hypergraphs (as a general mathematical domain)

====Technical Issues====
* mutual roles of quads vs. singleton named graphs vs. named graphs
* extension the RDF(S) semantics?
* new RDF(S) terms? rdf:Graph, rdf:subGraphOf, rdf:equivalentGraph, etc.
* syntax (TRIG, [http://www.w3.org/Submission/rdfsource/ INRIA Member submission], [http://www.springerlink.com/content/wh8x37j46n941427/ Web, Graphs and Semantics] , n3)
* graph inclusion, can named graphs share triples
* whether blank nodes can be shared among multiple graphs
* whether blank nodes can be used as graph names
* named graphs do not fully replace reification
* how would follow your nose apply to named graphs?
* relationships to SPARQL
* effects on the SW stack

TF-Graphs

Fgandon — Fri, 18 Feb 2011 09:47:38 GMT

Fgandon: /* Material */

= Task Force "Graphs" =

== Material ==

[http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items#Graph_Identification Suggestions called "Graph Identification" from Stanford Workshop] are reproduced below.

====Pros====
* widely used by the community
* part of SPARQL already
* numerous use cases
* clarify confusion in implementation

====Cons====
* adds complication and may not solve the issue nevertheless
* complicates the RDF model (potentially)
* risks with backward compatibility should be assessed (e.g., syntax)
* does it need standardization?

====Proposals====
* Named graphs, provenance and trust , Jeremy Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler, WWW 2005, http://www.w3.org/2009/12/rdf-ws/p613.pdf,
http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/carroll-ISWC2004.pdf
* Quadstores in general
* ODM RDF Metamodel (see http://www.omg.org/spec/ODM/1.0/, section 10.5, derived from Carroll et al.)
* Michel Chein and Marie-Laure Mugnier. Positive nested conceptual graphs. In Proceedings of ICCS '97, volume 1257 of LNAI, pages 95-109, Springer, 1997. (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.3644) ; Nested Graphs: A Graph-based Knowledge Representation Model with FOL Semantics (1998) ( http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.5256 )
* SPARQL Specifications ([http://www.w3.org/TR/rdf-sparql-query/#rdfDataset RDF Datasets]) and related to that, [http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop/AxelWishlist Axel's proposal] to base the work on RDF Datasets (see IRC)
* Notation 3, Tim Berners-Lee, 1998 http://www.w3.org/DesignIssues/Notation3
* ideas from the Topic Maps work (see also SWBPD WG note, http://www.w3.org/TR/rdftm-survey/)
* “Triplesets: Tagging and Grouping in RDF Datasets”, http://www.w3.org/2009/12/rdf-ws/papers/ws24, Atanas Kiryakov, Vassil Momtchev
* hypergraphs (as a general mathematical domain)

====Technical Issues====
* mutual roles of quads vs. singleton named graphs vs. named graphs
* extension the RDF(S) semantics?
* new RDF(S) terms? rdf:Graph, rdf:subGraphOf, rdf:equivalentGraph, etc.
* syntax (TRIG, [http://www.w3.org/Submission/rdfsource/ INRIA Member submission], [http://www.springerlink.com/content/wh8x37j46n941427/ Web, Graphs and Semantics] , n3)
* graph inclusion, can named graphs share triples
* whether blank nodes can be shared among multiple graphs
* whether blank nodes can be used as graph names
* named graphs do not fully replace reification
* how would follow your nose apply to named graphs?
* relationships to SPARQL
* effects on the SW stack

TF-Graphs

Fgandon — Fri, 18 Feb 2011 09:46:54 GMT

Fgandon: /* Material */

= Task Force "Graphs" =

== Material ==

[http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items#Graph_Identification Suggestions called "Graph Identification" from Stanford Workshop] are reproduced below.

===Pros===
* widely used by the community
* part of SPARQL already
* numerous use cases
* clarify confusion in implementation

===Cons===
* adds complication and may not solve the issue nevertheless
* complicates the RDF model (potentially)
* risks with backward compatibility should be assessed (e.g., syntax)
* does it need standardization?

===Proposals===
* Named graphs, provenance and trust , Jeremy Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler, WWW 2005, http://www.w3.org/2009/12/rdf-ws/p613.pdf,
http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/carroll-ISWC2004.pdf
* Quadstores in general
* ODM RDF Metamodel (see http://www.omg.org/spec/ODM/1.0/, section 10.5, derived from Carroll et al.)
* Michel Chein and Marie-Laure Mugnier. Positive nested conceptual graphs. In Proceedings of ICCS '97, volume 1257 of LNAI, pages 95-109, Springer, 1997. (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.3644) ; Nested Graphs: A Graph-based Knowledge Representation Model with FOL Semantics (1998) ( http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.5256 )
* SPARQL Specifications ([http://www.w3.org/TR/rdf-sparql-query/#rdfDataset RDF Datasets]) and related to that, [http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop/AxelWishlist Axel's proposal] to base the work on RDF Datasets (see IRC)
* Notation 3, Tim Berners-Lee, 1998 http://www.w3.org/DesignIssues/Notation3
* ideas from the Topic Maps work (see also SWBPD WG note, http://www.w3.org/TR/rdftm-survey/)
* “Triplesets: Tagging and Grouping in RDF Datasets”, http://www.w3.org/2009/12/rdf-ws/papers/ws24, Atanas Kiryakov, Vassil Momtchev
* hypergraphs (as a general mathematical domain)

===Technical Issues===
* mutual roles of quads vs. singleton named graphs vs. named graphs
* extension the RDF(S) semantics?
* new RDF(S) terms? rdf:Graph, rdf:subGraphOf, rdf:equivalentGraph, etc.
* syntax (TRIG, [http://www.w3.org/Submission/rdfsource/ INRIA Member submission], [http://www.springerlink.com/content/wh8x37j46n941427/ Web, Graphs and Semantics] , n3)
* graph inclusion, can named graphs share triples
* whether blank nodes can be shared among multiple graphs
* whether blank nodes can be used as graph names
* named graphs do not fully replace reification
* how would follow your nose apply to named graphs?
* relationships to SPARQL
* effects on the SW stack

TF-Graphs

Fgandon — Fri, 18 Feb 2011 09:44:23 GMT

Fgandon: /* Task Force "Graphs" */

= Task Force "Graphs" =

== Material ==

* [http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items#Graph_Identification Suggestions called "Graph Identification" from Stanford Workshop] are reproduced below:

{{CharterItem
|pro=

* widely used by the community
* part of SPARQL already
* numerous use cases
* clarify confusion in implementation

|con=

* adds complication and may not solve the issue nevertheless
* complicates the RDF model (potentially)
* risks with backward compatibility should be assessed (e.g., syntax)
* does it need standardization?

|proposals=

* Named graphs, provenance and trust , Jeremy Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler, WWW 2005, http://www.w3.org/2009/12/rdf-ws/p613.pdf,
http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/carroll-ISWC2004.pdf
* Quadstores in general
* ODM RDF Metamodel (see http://www.omg.org/spec/ODM/1.0/, section 10.5, derived from Carroll et al.)
* Michel Chein and Marie-Laure Mugnier. Positive nested conceptual graphs. In Proceedings of ICCS '97, volume 1257 of LNAI, pages 95-109, Springer, 1997. (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.3644) ; Nested Graphs: A Graph-based Knowledge Representation Model with FOL Semantics (1998) ( http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.5256 )
* SPARQL Specifications ([http://www.w3.org/TR/rdf-sparql-query/#rdfDataset RDF Datasets]) and related to that, [http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop/AxelWishlist Axel's proposal] to base the work on RDF Datasets (see IRC)
* Notation 3, Tim Berners-Lee, 1998 http://www.w3.org/DesignIssues/Notation3
* ideas from the Topic Maps work (see also SWBPD WG note, http://www.w3.org/TR/rdftm-survey/)
* “Triplesets: Tagging and Grouping in RDF Datasets”, http://www.w3.org/2009/12/rdf-ws/papers/ws24, Atanas Kiryakov, Vassil Momtchev
* hypergraphs (as a general mathematical domain)

|techIssues=

* mutual roles of quads vs. singleton named graphs vs. named graphs
* extension the RDF(S) semantics?
* new RDF(S) terms? rdf:Graph, rdf:subGraphOf, rdf:equivalentGraph, etc.
* syntax (TRIG, [http://www.w3.org/Submission/rdfsource/ INRIA Member submission], [http://www.springerlink.com/content/wh8x37j46n941427/ Web, Graphs and Semantics] , n3)
* graph inclusion, can named graphs share triples
* whether blank nodes can be shared among multiple graphs
* whether blank nodes can be used as graph names
* named graphs do not fully replace reification
* how would follow your nose apply to named graphs?
* relationships to SPARQL
* effects on the SW stack

|willingToEdit=

Axel Polleres, Thomas Lörtsch, Fabien Gandon, Elisa Kendall, Jeremy Carroll
}}

User:Fgandon

Fgandon — Tue, 15 Feb 2011 15:17:33 GMT

Fgandon: /* Fabien Gandon */

== Fabien Gandon ==
Senior Researcher at [http://en.inria.fr/ INRIA], Ph.D. and HDR in Informatics and Computer Science, vice Leader for the [http://www-sop.inria.fr/edelweiss/ Edelweiss Research team] of INRIA in the Research Center of [http://maps.google.com/maps?q=sophia+antipolis&oe=utf-8&client=firefox-a&ie=UTF8&hl=en&hq=&hnear=Sophia+Antipolis,+Valbonne,+Maritime+Alps,+Provence-Alpes-C%C3%B4te+d%27Azur,+France&t=h&z=14 Sophia-Antipolis (France)]

I have a Ph.D. and an "Habilitation à Diriger les Recherches" in Computer Science and I am a Graduated Engineer in Applied Mathematics from INSA Rouen.

Professional interests : Semantic Web, Corporate Semantic Web or Intraweb, Semantic Social Network / Semantic Analysis of Social Network, Ontologies, Knowledge Engineering and Modelling.

For more see: http://fabien.info

== Interest in RDF 1.1 ==
My main interest in the RDF 1.1 group is the extension to support "Identified Graphs".

I am the co-author with Olivier Corby of a position paper for RDF Next Step titled "Name that graph" ([http://www-sop.inria.fr/members/Fabien.Gandon/docs/NameThatGraph/ paper], [http://www.slideshare.net/fabien_gandon/name-that-graph slides]) and a W3C member submission on [http://www.w3.org/Submission/rdfsource/ RDF/XML Source Declaration].

== Past W3C activities ==
mainly in GRDDL WG, RDFa TF and a little bit in Social Web XG and SWBPD WG