See also: IRC log
<trackbot> Date: 25 August 2011
<manu1> Guest: Stéphane (scor) Corlosquet
<manu1> Guest: Henri (bergie) Bergius
<manu1> Guest: Niklas (lindstream) LindströmGuest: Niklas (lindstream) Lindström
<manu1> Guest: Niklas (lindstream) Lindström
<gkellogg> zakim ??P13 is me
<scribe> scribenick: Benjamin
<Knud> \me "grabbed each other's extension" - what a wonderful quote
<Knud> duh
<manu1> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Aug/0048.html
<manu1> http://www.jenitennison.com/blog/node/165
manu: Let's summarize Jeni's proposals on merging RDFa and Microdata
ivan: first issue is the
interpretation of time
... next issue is about microdata allowing link and meta
elements to be used in content
... Jeni proposes RDFa to also allow these elements
... consequently HTML+RDFa would include parts of the HTML5
content module, which is tricky
<Zakim> manu1, you wanted to comment on datetime issue
manu: there is a chance that time element is going to be replaced by data elements. Data contains machine readable values about content
ivan: hence, it is an open issue and we should leave it for now
lindstream: there is a problem with versioning issues
\me Nicklas I missed your point. Could you repeat it in log?
<lindstream> my point was that html5 is a "living spec", which supposedly won't have versioning. So the rdfa spec, having versions, might have trouble "keeping up"
<lindstream> np :)
ivan: HTML allows the use of meta only if it contains microdata content. This is a bit strange.
<manu1> ISSUE: Determine if RDFa should normatively state that <link> and <meta> elements are supported in flow content.
<trackbot> Created ISSUE-104 - Determine if RDFa should normatively state that <link> and <meta> elements are supported in flow content. ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/104/edit .
ivan: Next issue is about build
in prefixes.
... RDFa has such a mechanism
... Next issue is about the itemref functionality
<manu1> ISSUE: Should RDFa support something like Microdata's @itemref attribute.
<trackbot> Created ISSUE-105 - Should RDFa support something like Microdata's @itemref attribute. ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/105/edit .
<manu1> ISSUE: Should RDFa support the creation of ordered lists?
<trackbot> Created ISSUE-106 - Should RDFa support the creation of ordered lists? ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/106/edit .
ivan: There is an issue about the
creation of ordered lists in RDFa
... The next issue for us is about using the src attribute
<manu1> ISSUE: Determine if @src attribute should be viewed in the object position instead of the subject position.
<trackbot> Created ISSUE-107 - Determine if @src attribute should be viewed in the object position instead of the subject position. ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/107/edit .
manu: the concern about this is backward compatability.
<gkellogg> @src is often a problem for example markup, one of the things I noted that people often get wrong.
ivan: Jeni mentions link
relations, which relates to the use of terms in RDFa1.1
... we might revise which terms are relevant or not
<manu1> ISSUE: Refine/deprecate Link relations for the RDFa 1.1 Default Profile.
<trackbot> Created ISSUE-108 - Refine/deprecate Link relations for the RDFa 1.1 Default Profile. ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/108/edit .
ivan: at the moment the RDFa HTML default profile still contains all tokens, which we should look at again
lindstream: Jeni's problem was about the implied subject, when using these link relations.
<Zakim> manu1, you wanted to say we've discussed this before.
<ShaneM> Remember that ARIA cares about some of those relationships.
ivan: someone should lookup the list of necessary tokens in RDFa
manu: link relaitonships concern the HTML integration and should not be defined in RDFa core
<lindstream> one example raising the subject issue is: rel="stylesheet alternate"
bergie: We should spend more explanations on these tokens and their relation to subjects
<lindstream> for the record: one way out of this "mess" *might* be the idea of letting @property capture @href/@resource if present...
ivan: these are the issues we can extract from Jeni's blog
manu: That is four new
issues.
... Any other concerns about Jeni'
manu: writeup?
<manu1> http://www.w3.org/2010/02/rdfa/track/issues/103
<ivan> ISSUE-103?
<trackbot> ISSUE-103 -- Should RDFa Processors preserve @vocab declarations in the default graph? -- open
<trackbot> http://www.w3.org/2010/02/rdfa/track/issues/103
<ivan> rdfa:has-vocab
<lindstream> .. or rdfa:usesVocab ?
ivan: first thing is that the term i used in the mail was not good -- rdfa:hasVocab
<ivan> <uriofrdfasource> a rdfa:source ;
<MacTed> provenance :-)
<lindstream> if used, it should be rdfa:Source (uppercase 'S')
ivan: other thing is that a link from triples to the original source is missing. Some people complained about that.
<manu1> So, the current proposal seems to be: <current-document> rdfa:hasVocabulary <iri-to-vocab> .
<lindstream> np; short version: I'm beginning to agree with Ivan's suggestion
<Zakim> manu1, you wanted to discuss an issue
<manu1> foo:bar
<manu1> vocab1 vocab2
<lindstream> vocab1:bar or vocab2:bar :)
<gkellogg> vocab1 { dc:title rdfs:subPropertyOf rdfs:label } vocab2 { dc:title rdfs:subPropertyOf something else}
<gkellogg> … expands all use of dc:title within document
<Zakim> ShaneM, you wanted to say ask why the rdfs claim would matter?
Shane: initially, rdfs expansion was not in scope of the RDFa processor?
<ShaneM> Benjamin: and it still is not
<lindstream> RDFS uses multiple inheritance FTW ;)
<MacTed> +1
manu: finally, there is no issue with the current proposal
ivan: let's accept the proposal
<gkellogg> Also generate <> a rdfa:Source when @vocab encountered?
<MacTed> +1 uses
<manu1> PROPOSAL: Generate a triple in the default graph when the @vocab attribute is processed: <current-document> rdfa:usesVocabulary <iri-to-vocab> .
<ivan> +1
<manu1> +1
<gkellogg> +1
<bergie> +1
<MacTed> +1
<ShaneM> +1
+1
<lindstream> +1
<Knud> +1
<manu1> RESOLVED: Generate a triple in the default graph when the @vocab attribute is processed: <current-document> rdfa:usesVocabulary <iri-to-vocab> .
<lindstream> and +1 to Gregg's "also rdfa:Source"
<ivan> <uriofdocument> a rdfa:Source .
manu: Why is the triple useful?
<ShaneM> You need to know provenance. I agree
ivan: At the moment there is no
way to make preserve any provenance information
... in terms of indexing, the index should contain links to
originating sources
<lindstream> rdfa:Source will mean e.g. "this resource is data markup using RDFa"
MacTed: That's also how we do it in our product.
<MacTed> a look at an example... http://linkeddata.uriburner.com/about/html/http://linkeddata.uriburner.com/about/id/entity/http/cprtheory.referata.com/wiki/Main_Page
manu: it is not related to the vocab attribute
MacTed: It's about this is document the processor extracted RDFa from
<lindstream> btw, rdfa:Source should be a subClassOf (e.g.) foaf:Document
ShaneM: It is a provenance concern
MacTed: The minimum that I need is, this is document were I got the data from.
<lindstream> .. *if* we got data from it? (Even just from rel stylesheet?)
manu: That means in every default
graph of an RDFa processor a triple shuld exist that says where
the data comes from
... But if we merge two graphs, such triples become useless
MacTed: Of course you have to add graph identifiers
<lindstream> quads are beyond the scope of this issue...
<MacTed> <current graph> foaf:primaryTopic <parsed-document>
<lindstream> .. are we at risk of conflating documents and graphs here?
<ivan> <base>
<MacTed> <graphURI> foaf:primaryTopic <htmlURI>
<gkellogg> Then we'd need to make assertions about graphs, which requires quads
<MacTed> <> foaf:primaryTopic <htmlURI>
<MacTed> I'm also in Provenance WG... :-)
<MacTed> (which call starts in 5 minutes)
<ShaneM> Bless you. someone has to do it.
http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html
<MacTed> <> describes <sourceURI>
<gkellogg> Only different if document has html>head>base?
<lindstream> ... while graph identifiers enable us to "have turtles all the way down", we're within the RDFa "turtle" and should stay here.
<bergie> so, my proposal was not to set a source URI for a given graph, since the graph itself doesn't have an identifier
<bergie> but instead to just say "this subject has data coming from this RDFa document"
<ShaneM> I agree with Ted that this is a significant terminology issue.
<ShaneM> I also agree that we should have a way to reference our 'graph' in notation.
<lindstream> +1 on "output graph". But let's *not* talk about identifiers for graphs in RDFa..
<manu1> ISSUE: Resolve differences terminology for 'default graph' and 'output graph'.
<trackbot> Created ISSUE-109 - Resolve differences terminology for 'default graph' and 'output graph'. ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/109/edit .
ivan: processors may have difficulties in generating such provenance triples because of the lack of names for originating graphs. We don't have a mechansim to name the output graph
<bergie> +1 lindstream, on both points
manu: This is end of the call. We need to define additional issues
<manu1> ISSUE: Should RDFa Processor output a triple for the source of a graph?
<trackbot> Created ISSUE-110 - Should RDFa Processor output a triple for the source of a graph? ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/110/edit .
<scor> The Definitive Guide to Drupal 7 book was published by Apress: http://definitivedrupal.org/ - one of the chapters I contributed is on Drupal and the Semantic Web, Linked Data and RDFa 1.0 (namespaces, prefixes, CURIEs, etc...)
<bergie> scor: congrats about the book! hopefully the Drupal 8 edition will be able to talk about VIE as well :-)
<scor> bergie: thanks. sure! I still need to take a closer look at VIE though :)
<bergie> scor: if you need any help or info, just ping me
<scor> alright will do!