13:42:32 <RRSAgent> logging to http://www.w3.org/2010/07/29-rdfa-irc
RRSAgent IRC Bot: logging to http://www.w3.org/2010/07/29-rdfa-irc ←
13:54:21 <manu> trackbot, prepare telecon
(No events recorded for 11 minutes)
Manu Sporny: trackbot, prepare telecon ←
13:54:23 <trackbot> RRSAgent, make logs world
Trackbot IRC Bot: RRSAgent, make logs world ←
13:54:25 <trackbot> Zakim, this will be 7332
Trackbot IRC Bot: Zakim, this will be 7332 ←
13:54:25 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 6 minutes
Zakim IRC Bot: 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
(Scribe set to Shane McCarron)
14:00:38 <ivan> zakim, dial ivan-voip
(No events recorded for 5 minutes)
Ivan Herman: zakim, dial ivan-voip ←
14:00:39 <Zakim> ok, ivan; the call is being made
Zakim IRC Bot: ok, ivan; the call is being made ←
14:00:40 <Zakim> SW_RDFa()10:00AM has now started
Zakim IRC Bot: SW_RDFa()10:00AM has now started ←
14:00:40 <Zakim> +Ivan
Zakim IRC Bot: +Ivan ←
14:00:49 <Zakim> +manu
Zakim IRC Bot: +manu ←
14:01:52 <markbirbeck> zakim, code?
Mark Birbeck: 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
Zakim IRC Bot: 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
Zakim IRC Bot: +ShaneM ←
14:03:26 <Zakim> +??P24
Zakim IRC Bot: +??P24 ←
14:03:30 <markbirbeck> zakim, i a,
Mark Birbeck: zakim, i a, ←
14:03:30 <Zakim> I don't understand 'i a,', markbirbeck
Zakim IRC Bot: I don't understand 'i a,', markbirbeck ←
14:03:36 <markbirbeck> zakim, i am ?
Mark Birbeck: zakim, i am ? ←
14:03:37 <Zakim> +markbirbeck; got it
Zakim IRC Bot: +markbirbeck; got it ←
14:05:11 <manu> zakim, who is on the call?
Manu Sporny: zakim, who is on the call? ←
14:05:11 <Zakim> On the phone I see Ivan, manu, ShaneM, markbirbeck
Zakim IRC Bot: 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?
Manu Sporny: 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.
Manu Sporny: 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.
Mark Birbeck: 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?
Mark Birbeck: 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.
Manu Sporny: we won't resolve anythiing, but lets leave the language in the draft for review. ←
14:09:10 <ivan> q+
Ivan Herman: q+ ←
14:09:17 <manu> ack ivan
Manu Sporny: 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.
Mark Birbeck: 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.
Ivan Herman: 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?
Manu Sporny: 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.
... 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.
Mark Birbeck: 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.
Mark Birbeck: 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.
... 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.
... 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.
Manu Sporny: 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.
Mark Birbeck: 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.
... 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.
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].
Trackbot IRC Bot: 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+
Ivan Herman: q+ ←
14:17:38 <manu> ack ivan
Manu Sporny: 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.
Manu Sporny: 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?
Ivan Herman: 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.
Manu Sporny: 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.
... 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.
Ivan Herman: 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.
... 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
Ivan Herman: 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.
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.
Manu Sporny: this was introduced to support langauges like html5 where @xmlns might not be supported. ←
14:22:11 <ShaneM> ivan: withdrawn....
Ivan Herman: 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?
Mark Birbeck: 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.
Ivan Herman: 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.
Mark Birbeck: 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.
Ivan Herman: we have not deprecated @xmlns. ←
14:25:01 <ShaneM> markbirbeck: we discussed 'soft' deprecating it though.
Mark Birbeck: 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.
... 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.
... 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.
Manu Sporny: 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.
Mark Birbeck: 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+
Ivan Herman: q+ ←
14:28:11 <manu> ack ivan
Manu Sporny: ack ivan ←
14:28:21 <ShaneM> ... as a processor there could be a way to tighten this up.
... 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.
Ivan Herman: 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+
Manu Sporny: q+ ←
14:29:22 <markbirbeck> q+
Mark Birbeck: q+ ←
14:29:36 <ShaneM> ... the issue markbirbeck is raising is valid, but it is a special case of the general issue of announcement.
... 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.
Manu Sporny: 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
Manu Sporny: ack manu ←
14:30:40 <manu> ack markbirbeck
Manu Sporny: ack markbirbeck ←
14:30:43 <ShaneM> q+ to discuss missed triples
q+ to discuss missed triples ←
14:31:42 <manu> ack shanem
Manu Sporny: ack shanem ←
14:31:42 <Zakim> ShaneM, you wanted to discuss missed triples
Zakim IRC Bot: 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.
Mark Birbeck: 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+
Ivan Herman: q+ ←
14:32:08 <manu> ack ivan
Manu Sporny: 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.
Shane McCarron: 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.
Ivan Herman: 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.
Manu Sporny: I agree. ←
14:33:58 <ShaneM> ShaneM: I have no problem with that.
Shane McCarron: 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.
Ivan Herman: 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.
Manu Sporny: 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.
Mark Birbeck: there is already wording in the document that relates to this. ←
14:37:42 <markbirbeck> this is a URL - abc:def
Mark Birbeck: this is a URL - abc:def ←
14:37:45 <ShaneM> ivan: a bnode is NOT a URI.
Ivan Herman: a bnode is NOT a URI. ←
14:37:56 <ShaneM> markbirbeck: I can make up a URI... it is still a URI.
Mark Birbeck: 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.
Ivan Herman: 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
Manu Sporny: 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
http://www.w3.org/2010/02/rdfa/sources/rdfa-core/#s_blankNodes ←
14:40:58 <markbirbeck> Section 6:
Mark Birbeck: Section 6: ←
14:41:03 <markbirbeck> "a mapping to use with the '_' prefix, which is used to generate unique identifiers (for example, _:p)."
Mark Birbeck: "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.
Ivan Herman: 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."
Mark Birbeck: "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.
Manu Sporny: 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.
Mark Birbeck: 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.
Mark Birbeck: 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.
Ivan Herman: 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.
Shane McCarron: my implementation doesn't maintain the bnode. ←
14:45:25 <ShaneM> ivan: Mine doesn't either.
Ivan Herman: Mine doesn't either. ←
14:46:06 <ShaneM> ... serialization is done by the RDF processor; I don't know what it does.
... 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"
Mark Birbeck: "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.
Mark Birbeck: I can't interpret this as meaning anything other than '_' is mapped to something. ←
14:48:19 <manu> q+ to note the time
Manu Sporny: 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'
Ivan Herman: 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
Mark Birbeck: this could expand - _:a => blah:blah:zoobiea ←
14:49:01 <markbirbeck> what abou this - dc:a
Mark Birbeck: what abou this - dc:a ←
14:49:36 <ShaneM> ShaneM: _ doesn't really map to a prefix. _ maps to _ in RDF
Shane McCarron: _ 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.
Manu Sporny: 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?
... can we move on and discuss this on the list? ←
14:50:54 <ShaneM> markbirbeck: let's not change 7.4.5 now
Mark Birbeck: let's not change 7.4.5 now ←
14:51:44 <ShaneM> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/
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.
PROPOSED: 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
Ivan Herman: +1 ←
14:52:31 <manu> +1
Manu Sporny: +1 ←
14:52:50 <ShaneM> Shane: +1
Shane McCarron: +1 ←
14:52:52 <markbirbeck> +1
Mark Birbeck: +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.
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'?
Shane McCarron: doesn't an emitted bnode in RDF (like in N3) look like '_:xxxx'? ←
14:54:13 <ShaneM> markbirbeck: that's a convention.
Mark Birbeck: that's a convention. ←
14:54:36 <ShaneM> markbirbeck: internally a lot of implementations give them a URI.
Mark Birbeck: internally a lot of implementations give them a URI. ←
14:55:30 <ShaneM> ivan: Mine uses a dictionary...
Ivan Herman: Mine uses a dictionary... ←
14:56:39 <ShaneM> ShaneM: mark do you think the emitted string has to have the same suffix?
Shane McCarron: 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.
Mark Birbeck: 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
Ivan Herman: 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.
... 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 .
Ivan Herman: it is equivalent to a b _:x. _x: c d . ←
14:57:29 <ShaneM> ... in RDF/XML there is @nodeid that can define this.
... 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)
... 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.
... 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.
... 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
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 .
Trackbot IRC Bot: 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.
Shane McCarron: I think this dosen't matter to anyone outside of this group. ←
15:00:59 <manu> q+ to end the telecon
Manu Sporny: q+ to end the telecon ←
15:01:38 <manu> ack manu
Manu Sporny: ack manu ←
15:01:38 <Zakim> manu, you wanted to note the time and to end the telecon
Zakim IRC Bot: 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.
Shane McCarron: 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.
Ivan Herman: 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.
Manu Sporny: 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.
Ivan Herman: 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.
Mark Birbeck: 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.
... 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.
Ivan Herman: 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.
We might have a resolution on this, but... let's wait until the next draft to deal with it. ←
15:09:19 <Zakim> -Ivan
Zakim IRC Bot: -Ivan ←
15:09:24 <Zakim> -markbirbeck
Zakim IRC Bot: -markbirbeck ←
15:09:47 <Zakim> -manu
Zakim IRC Bot: -manu ←
15:10:01 <Zakim> -ShaneM
Zakim IRC Bot: -ShaneM ←
15:10:03 <Zakim> SW_RDFa()10:00AM has ended
Zakim IRC Bot: SW_RDFa()10:00AM has ended ←
15:10:05 <Zakim> Attendees were Ivan, manu, ShaneM, markbirbeck
Zakim IRC Bot: Attendees were Ivan, manu, ShaneM, markbirbeck ←
Formatted by CommonScribe