Warning:
This wiki has been archived and is now read-only.

Chatlog 2010-07-29

From RDFa Working Group Wiki
Jump to: navigation, search

See CommonScribe Control Panel, original RRSAgent log and preview nicely formatted version.

13:42:32 <RRSAgent> RRSAgent has joined #rdfa
13:42:32 <RRSAgent> logging to http://www.w3.org/2010/07/29-rdfa-irc
13:42:35 <trackbot> trackbot has joined #rdfa
13:50:45 <ivan> ivan has joined #rdfa
13:52:28 <markbirbeck> markbirbeck has joined #rdfa
13:54:21 <manu> trackbot, prepare telecon
13:54:23 <trackbot> RRSAgent, make logs world
13:54:25 <trackbot> Zakim, this will be 7332
13:54:25 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 6 minutes
13:54:26 <trackbot> Meeting: RDFa Working Group Teleconference
13:54:26 <trackbot> Date: 29 July 2010
13:54:30 <manu> Chair: Manu
13:54:40 <manu> Present: Ivan, MarkB, Shane, Manu
13:54:46 <manu> Regrets: Knud
13:54:57 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jul/0157.html
13:55:04 <manu> Scribe: Shane
14:00:38 <ivan> zakim, dial ivan-voip
14:00:39 <Zakim> ok, ivan; the call is being made
14:00:40 <Zakim> SW_RDFa()10:00AM has now started
14:00:40 <Zakim> +Ivan
14:00:49 <Zakim> +manu
14:01:29 <ShaneM> ShaneM has joined #rdfa
14:01:52 <markbirbeck> zakim, code?
14:01:52 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), markbirbeck
14:02:55 <Zakim> +ShaneM
14:03:26 <Zakim> +??P24
14:03:30 <markbirbeck> zakim, i a,
14:03:30 <Zakim> I don't understand 'i a,', markbirbeck
14:03:36 <markbirbeck> zakim, i am ?
14:03:37 <Zakim> +markbirbeck; got it
14:05:11 <manu> zakim, who is on the call?
14:05:11 <Zakim> On the phone I see Ivan, manu, ShaneM, markbirbeck
14:05:46 <ShaneM> Scribe: ShaneM
14:06:07 <ShaneM> TOPIC: Issue 36 - default vocab in RDFa Profile Document
14:06:47 <ShaneM> manu: Should we include this in the heartbeat draft?
14:07:06 <ShaneM> manu: There would be a predicate in the RDFa Profile via which you could set the default vocabulary.
14:07:59 <ShaneM> markbirbeck: would rather we were defining tokens than setting a default vocab, but don't mind if we include it.
14:08:07 <ShaneM> markbirbeck: are we really in that much of a hurry though?
14:08:57 <ShaneM> manu: we won't resolve anythiing, but lets leave the language in the draft for review.
14:09:10 <ivan> q+
14:09:17 <manu> ack ivan
14:09:41 <ShaneM> markbirbeck: concerned that we are introducing text for which there is no resolution - hard to track features by reviewing the editor's draft all the time.
14:10:29 <ShaneM> ivan: if we do it we are more or less in sync with all the discussions we have had about core.  This would permit us to concentrate on the API because the issues against Core are all addressed.
14:11:08 <ShaneM> manu: I agree with mark in principle.  But this issue has had a lot of discssion on the list and on calls.  Would it help if we sent out a message asking for objections?
14:11:40 <ShaneM> ... there is already an issue in the tracker of course.
14:12:37 <ShaneM> markbirbeck: The issue is that not everyone has participated in the list discussion.  If we introduce things because there didn't seem to be an objection, it means we are changing the nature of how we make decisions in the working group.
14:13:05 <ShaneM> markbirbeck: On the other hand, if you are not present on a call you don't really know what happens if there is no formal resolution.
14:13:46 <ShaneM> ... if someone comes along later and raises an objection it can cause a problem because there is apparent support and momentum for the text in the spec.
14:14:32 <ShaneM> ... this is a procedural issue in the general case.  This specific thing is not terribly important.  Its the basic principle that we need to be careful with.
14:14:38 <ShaneM> manu: we can take the text out.
14:14:54 <ShaneM> markbirbeck: not necessary.  for this particular one let's just socialize it on the list and leave the text in.
14:15:05 <ShaneM> ...  going forward let's not make changes that are not tied to a resolution.
14:15:35 <ShaneM> ACTION: Manu to send out an email about the text that is the document regarding issue-36.
14:15:35 <trackbot> Created ACTION-35 - Send out an email about the text that is the document regarding issue-36. [on Manu Sporny - due 2010-08-05].
14:17:14 <ShaneM> TOPIC: Heartbeat working drafts
14:17:27 <ivan> q+
14:17:38 <manu> ack ivan
14:17:50 <ShaneM> manu: there have been no objections on the mailing list for publishing.  There were some comments from ivan but do not see any of those comments as blockers.
14:18:17 <ShaneM> ivan: Agreed.  but is the document we are publishing one that reflects the comments I made?
14:18:38 <ShaneM> manu: Shane asked me if he should address the comments and I said no because there had not been a discussion.
14:19:09 <ShaneM> ...  the comments are not controversial - its just that we had not discussed them.
14:19:39 <ShaneM> ivan: Some comments are editorial.  Editorial comments do not require discussion really.  In fact, since I am an editor I made corrections when I thought they were harmless.
14:19:54 <ShaneM> ... with the other non-editorial comments perhaps we can discuss them now.
14:20:04 <ivan> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jul/0158.html
14:21:08 <ShaneM> First question in the mail is whether we really indend to permit host languages to not support @xmlns.
14:22:05 <ShaneM> manu: this was introduced to support langauges like html5 where @xmlns might not be supported.
14:22:11 <ShaneM> ivan: withdrawn....
14:22:44 <ShaneM> markbirbeck: it does raise an interesting question - should we be precise on the processing.  If you detect @prefix in a document should you ignore @xmlns?  
14:23:28 <ShaneM> ivan: The language currently requires that you know what host language you are processing and then ignore or process @xmlns.
14:24:23 <ShaneM> markbirbeck: no - I am saying that we could define a rule where generic processing could take place regardless of what the host language says.
14:24:42 <ShaneM> ivan: we have not deprecated @xmlns. 
14:25:01 <ShaneM> markbirbeck: we discussed 'soft' deprecating it though.
14:25:21 <ShaneM> ... if I give you a document that only contains @xmlns you have no way of telling what version of RDFa is related to that document.
14:26:02 <ShaneM> ... there might be a way for us to detect that the document is RDFa 1.1.   For example if there were @prefix in a document, then the document is RDFa 1.1 (obviously) and then we should ignore @xmlns throughout the document.
14:26:49 <ShaneM> manu: all we are saying is that (potentially) HTML5+RDFa documents do not use @xmlns.  That doesn't need to effect the processing rules.  The rules just say that processors handle both and that @prefix overrides @xmlns.
14:27:35 <ShaneM> markbirbeck: the scenario I am thinking of is that authors of RDFa ignore @xmlns.  But then when you are gathering together components that USE @xmlns (e.g. SVG bits) those @xmlns should not really effect RDFa processing.
14:28:03 <ivan> q+
14:28:11 <manu> ack ivan
14:28:21 <ShaneM> ... as a processor there could be a way to tighten this up.  
14:29:16 <ShaneM> ivan: the issue is slightly more general... it is not related to @xmlns.  We need to know what the default profile is associated with the document.  Currently my processor uses the media type to decide the rules for the document being processed.
14:29:17 <manu> q+
14:29:22 <markbirbeck> q+
14:29:36 <ShaneM> ... the issue markbirbeck is raising is valid, but it is a special case of the general issue of announcement.
14:30:36 <ShaneM> manu: I would go the other way.  When a processor deals with hybird documents that contain bits that have @prefix and @xmlns you could MISS important triples.
14:30:37 <manu> ack manu
14:30:40 <manu> ack markbirbeck
14:30:43 <ShaneM> q+ to discuss missed triples
14:31:42 <manu> ack shanem
14:31:42 <Zakim> ShaneM, you wanted to discuss missed triples
14:31:42 <ShaneM> markbirbeck: the scenario I am talking about is one where HTML5+RDFa might not permit @xmlns at all.  If we are still processing it anyway, then it is not really an issue.  We would still process it in any processor.  That's fine.
14:31:48 <ivan> q+
14:32:08 <manu> ack ivan
14:32:23 <ShaneM> ShaneM: The document says that processors always handle @prefix and @xmlns regardless of what host languages permit in their content models.
14:33:51 <ShaneM> ivan: The other issue is that we don't require the default vocab is defined in an RDFa Profile.  It should say that.  
14:33:54 <ShaneM> manu: I agree.
14:33:58 <ShaneM> ShaneM: I have no problem with that.
14:36:03 <ShaneM> ivan: we do not explicitly state that if there are explicit bnodes in a document, the output might not contain that same literal string for the bnode.
14:36:19 <ShaneM> manu: the document should probably have a sentence that explains this.
14:36:44 <ShaneM> markbirbeck: there is already wording in the document that relates to this.
14:37:42 <markbirbeck> this is a URL - abc:def
14:37:45 <ShaneM> ivan: a bnode is NOT a URI.
14:37:56 <ShaneM> markbirbeck: I can make up a URI...  it is still a URI.
14:38:24 <ShaneM> ivan: This has to do with graphs.  two URIs in different graphs must by definition reference the same resource if they are the same.
14:39:14 <manu> http://www.w3.org/TR/rdfa-core/#s_blankNodes
14:39:33 <ShaneM> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/#s_blankNodes
14:40:58 <markbirbeck> Section 6:
14:41:03 <markbirbeck> "a mapping to use with the '_' prefix, which is used to generate unique identifiers (for example, _:p)."
14:41:08 <ShaneM> ivan: the suggestion is that we change the second example in section 7.4.5 so that it uses different identifiers for the bnodes and add a sentence explaining that the bnode strings might be different.
14:41:22 <markbirbeck> "the mapping to use with the '_' prefix, is not explicitly stated, but since it is used to generate bnodes, its implementation needs to be compatible with the RDF definition and rules in Referencing Blank Nodes. A document should not define a mapping for the '_' prefix. A Conforming RDFa Processor must ignore any definition of a mapping for the '_' prefix."
14:41:25 <ShaneM> manu: this is correct, but it might confuse the readers.
14:41:34 <ShaneM> markbirbeck: we can't discuss this in isolation.  Look at section 6.
14:43:49 <ShaneM> markbirbeck: Section 6 is specified the way it is to make implementation strategy clear and straightforward.  We can't change 7.4.5 without changing this too.
14:45:11 <ShaneM> ivan: I don't read section 6 as restricting the form of the generated bnode.  
14:45:19 <ShaneM> ShaneM: my implementation doesn't maintain the bnode.
14:45:25 <ShaneM> ivan: Mine doesn't either.
14:46:06 <ShaneM> ... serialization is done by the RDF processor; I don't know what it does.
14:46:51 <markbirbeck> "the mapping to use with the '_' prefix, is not explicitly stated"
14:47:44 <ShaneM> markbirbeck: I can't interpret this as meaning anything other than '_' is mapped to something.
14:48:19 <manu> q+ to note the time
14:48:34 <ShaneM> ivan: If I wrote '_:a' for a bnode the spec does not require that the emitted triples use the bnode '_:a'
14:48:34 <markbirbeck> this could expand - _:a => blah:blah:zoobiea
14:49:01 <markbirbeck> what abou this - dc:a
14:49:36 <ShaneM> ShaneM: _ doesn't really map to a prefix.  _ maps to _ in RDF
14:50:20 <ShaneM> manu: We are running out of time.  While it is important that we get this right, we obviously have lots of implementations that already doing this right from an RDF perspective.
14:50:31 <ShaneM> ... can we move on and discuss this on the list?
14:50:54 <ShaneM> markbirbeck: let's not change 7.4.5 now
14:51:44 <ShaneM> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/
14:52:23 <manu> PROPOSAL: Publish RDFa Core 1.1 and XHTML+RDFa 1.1 based on the latest editors drafts including changes agreed to on this call.
14:52:29 <ivan> +1
14:52:31 <manu> +1
14:52:50 <ShaneM> Shane: +1
14:52:52 <markbirbeck> +1
14:52:52 <manu> RESOLVED: Publish RDFa Core 1.1 and XHTML+RDFa 1.1 based on the latest editors drafts including changes agreed to on this call.
14:54:09 <ShaneM> ShaneM: doesn't an emitted bnode in RDF (like in N3) look like '_:xxxx'?
14:54:13 <ShaneM> markbirbeck: that's a convention.
14:54:36 <ShaneM> markbirbeck: internally a lot of implementations give them a URI.
14:55:30 <ShaneM> ivan: Mine uses a dictionary...
14:56:39 <ShaneM> ShaneM: mark do you think the emitted string has to have the same suffix?
14:56:54 <ShaneM> markbirbeck: there is no emitted string.  You can't serialize a bnode.  It is a convention.  
14:56:59 <ivan> a b [ c d ] . includes a blank node, too
14:57:11 <ShaneM> ... there is an unnamed thing that has the same name as some other unnamed thing.
14:57:21 <ivan> it is equivalent to a b _:x. _x: c d .
14:57:29 <ShaneM> ... in RDF/XML there is @nodeid that can define this.
14:57:59 <ShaneM> ... there are things you can talk about (URIs) and things you can't talk about (internal, anonymous identifiers)
14:58:56 <ShaneM> ... so the spec has always presented this as just another prefix so that people who are using RDFa can conceptualize the bnode more simply.
14:59:15 <ShaneM> ...  We can change this.  We can make it more complex.  But we need to change everything at once if we are going to change it.
14:59:31 <manu> ISSUE: Explanation of _:xyz pattern needs to be refined in RDFa Core
14:59:31 <trackbot> Created ISSUE-37 - Explanation of _:xyz pattern needs to be refined in RDFa Core ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/37/edit .
15:00:19 <ShaneM> ShaneM: I think this dosen't matter to anyone outside of this group.
15:00:59 <manu> q+ to end the telecon
15:01:38 <manu> ack manu
15:01:38 <Zakim> manu, you wanted to note the time and to end the telecon
15:04:07 <ShaneM> ShaneM: I think this is fine as it is.  The result is that the emitted triples are correct.
15:04:56 <ShaneM> ivan: no.  the important issue is that it implies something about the implementation that an underlying library might not support.  A processor implementor might try to rely on suffixes being the same, when in reality they don't.
15:05:13 <ShaneM> manu: we could add a section where we point out that the suffixes might not match.
15:05:25 <ShaneM> ivan: yes - but mark said that then we would be be in conflict with section 6.
15:06:21 <ShaneM> markbirbeck: what might be worth doing is ensuring that implementors know they are permitted to preserve the suffixes or not. we don't need to get all the precision of RDF.
15:06:53 <ShaneM> ... perhaps there is a simple sentence around that region (7.4.5) that points out there are potentially different implementation strategies.
15:07:27 <ShaneM> ivan: if we just change the example in 7.4.5 to show foo and bar in conjunction with the sentence above that might help.
15:09:11 <ShaneM> We might have a resolution on this, but...  let's wait until the next draft to deal with it.
15:09:19 <Zakim> -Ivan
15:09:24 <Zakim> -markbirbeck
15:09:47 <Zakim> -manu
15:10:01 <Zakim> -ShaneM
15:10:03 <Zakim> SW_RDFa()10:00AM has ended
15:10:05 <Zakim> Attendees were Ivan, manu, ShaneM, markbirbeck
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000174