IRC log of rdfa on 2011-05-12

Timestamps are in UTC.

13:56:52 [RRSAgent]
RRSAgent has joined #rdfa
13:56:52 [RRSAgent]
logging to
13:56:54 [trackbot]
RRSAgent, make logs world
13:56:54 [Zakim]
Zakim has joined #rdfa
13:56:56 [trackbot]
Zakim, this will be 7332
13:56:56 [Zakim]
ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 4 minutes
13:56:57 [trackbot]
Meeting: RDF Web Applications Working Group Teleconference
13:56:57 [trackbot]
Date: 12 May 2011
13:58:25 [ShaneM]
I am special stupid. I managed to schedule a customer meeting on top of this meeting. I am so sorry. the whole meeting was for issues I care about!
13:59:40 [manu]
13:59:59 [ShaneM]
I will wrap up as soon as I can.
14:00:07 [ShaneM]
(maybe they won't show)
14:00:58 [manu]
zakim, who is on the call?
14:00:58 [Zakim]
SW_RDFa()10:00AM has not yet started, manu
14:00:59 [Zakim]
On IRC I see RRSAgent, ShaneM, tomayac, MacTed, webr3, ivan, manu, manu1, trackbot
14:01:11 [ivan]
zakim, dial ivan-voip
14:01:11 [Zakim]
ok, ivan; the call is being made
14:01:36 [ivan]
zakim, who is here?
14:01:36 [Zakim]
SW_RDFa()10:00AM has not yet started, ivan
14:01:37 [Zakim]
On IRC I see RRSAgent, ShaneM, tomayac, MacTed, webr3, ivan, manu, manu1, trackbot
14:01:52 [manu]
zakim, I am ??manu
14:01:53 [Zakim]
sorry, manu, I do not see a party named '??manu'
14:06:51 [Benjamin]
Benjamin has joined #rdfa
14:07:53 [MacTed]
Zakim, code?
14:07:53 [Zakim]
the conference code is 7332 (tel:+1.617.761.6200 tel:+ tel:+44.203.318.0479), MacTed
14:08:10 [MacTed]
Zakim, this is 7332
14:08:10 [Zakim]
ok, MacTed; that matches SW_RDFa()10:00AM
14:08:11 [Benjamin]
zakim, who is on the phone
14:08:12 [Zakim]
I don't understand 'who is on the phone', Benjamin
14:08:14 [MacTed]
Zakim, who's here?
14:08:14 [Zakim]
On the phone I see hta, ??P13, Ivan, ??P28, OpenLink_Software
14:08:16 [Zakim]
On IRC I see Benjamin, Zakim, RRSAgent, ShaneM, tomayac, MacTed, webr3, ivan, manu, manu1, trackbot
14:08:22 [MacTed]
Zakim, OpenLink_Software is temporarily me
14:08:22 [Zakim]
+MacTed; got it
14:08:24 [MacTed]
Zakim, mute me
14:08:24 [Zakim]
MacTed should now be muted
14:09:00 [MacTed]
Zakim, who's noisy?
14:09:11 [Zakim]
MacTed, listening for 10 seconds I heard sound from the following: ??P28 (91%)
14:09:20 [MacTed]
Zakim, ??p28 is Benjamin
14:09:20 [Zakim]
+Benjamin; got it
14:09:24 [MacTed]
Zakim, mute Benjamin
14:09:25 [manu]
zakim, I am ??P13
14:09:26 [MacTed]
14:09:26 [Zakim]
Benjamin should now be muted
14:09:28 [Zakim]
+manu; got it
14:10:07 [Benjamin]
zakim, unmute me
14:10:07 [Zakim]
Benjamin should no longer be muted
14:10:15 [Benjamin]
zakim, mute me
14:10:15 [Zakim]
Benjamin should now be muted
14:12:59 [ivan]
scribenick: ivan
14:13:47 [ivan]
topic: congrats
14:14:09 [ivan]
manu: we had a good publication, and also a piece on the documents
14:14:10 [manu]
14:14:40 [Benjamin]
Thank you Ivan for writing this article !!!
14:15:45 [ivan]
manu: ivan, you sent an email that there is a publishing moratorium next week
14:16:07 [ivan]
... it gives us a little bit more time to review ben's document on rdf api
14:16:15 [Benjamin]
zakim, unmute me
14:16:15 [Zakim]
Benjamin should no longer be muted
14:16:15 [ivan]
... speaking of...
14:16:18 [manu]
Topic: Update on spec progress
14:17:01 [ivan]
Benjamin: I fixed the examples, changed the environment to 'Data'
14:17:06 [ivan]
... I fixed webidl
14:17:13 [ivan]
... otherwise I did not do much
14:17:14 [manu]
14:17:14 [MacTed]
fwiw, headsets usually work far better than onboard microphones/speakers
14:17:26 [ivan]
... what is left: language has to be fixed,
14:17:37 [ivan]
... we have to discuss the projection, based on the email discussion
14:17:55 [ivan]
Benjamin: I added the set method to the projection
14:18:00 [ivan]
... there are some issues on that
14:18:25 [Benjamin]
oopen issues on projections are:
14:18:32 [ivan]
14:18:37 [Benjamin]
nested projections
14:19:11 [ivan]
14:19:27 [Benjamin]
zakim, mute me
14:19:27 [Zakim]
Benjamin should now be muted
14:19:36 [manu]
ack ivan
14:19:51 [manu]
Manu: The reason we did this was...
14:20:02 [manu]
Ivan: Doing automatic projection generation is not a good idea, for all the reasons that Manu said.
14:20:40 [manu]
Ivan: Niklas wanted one more method where when one looks at a triple w/ a URIRef, then what you get back is a Projection for that object being the subject. It's strictly a one-step indirection.
14:20:55 [manu]
... it may help to get over the situation where you have the duality of string vs. object.
14:21:15 [manu]
... it helps to overcome that and this is a fairly natural thing to do. It's fairly natural when the object in question is a blank node.
14:21:16 [Benjamin]
e.g., ben = ivan.getRel("foaf:knows")
14:21:42 [manu]
Manu: What's the return type?
14:21:47 [manu]
sequence of Projections or Projection?
14:22:02 [Benjamin]
q+ do we really need this?
14:22:47 [Benjamin]
14:22:47 [ivan]
manu: we had a choice on to get the 'first' or all in a sequence
14:22:50 [manu]
ack Benjamin
14:22:51 [ivan]
... maybe that is what we need
14:22:54 [Benjamin]
zakim, unmute me
14:22:54 [Zakim]
Benjamin was not muted, Benjamin
14:23:00 [manu]
get() vs. getAll()
14:23:03 [ivan]
Benjamin: I do not really we need
14:23:16 [ivan]
... it is not a big deal to do it manually
14:23:36 [ivan]
... even in the case of a blank node you get...
14:23:37 [manu]
14:23:56 [ivan]
manu: uri for a blank node?
14:24:02 [ivan]
... we get only strings
14:24:15 [ivan]
... the projections are not for low level objects
14:24:34 [ivan]
... we cannot get the difference between an iriref and a string
14:24:47 [ivan]
... if we were able to get the difference, then you are right, it does not matter
14:24:58 [ivan]
... the reason we might want to have that
14:25:06 [tomayac]
is it an issue in practice? we had this in the json discussions as well. some serializations cared, most simply didn't...
14:25:08 [ivan]
... is that we cannot make the difference
14:25:23 [manu]
var knows = ivan.get("foaf:knows");
14:25:36 [manu]
knows == ""
14:26:01 [ivan]
ivan.get( "") would work
14:26:10 [manu]
14:26:49 [ivan]
manu: in that case we really do not need it
14:27:06 [manu]
The blank node issue...
14:27:09 [ivan]
manu: for a blank node
14:27:13 [manu]
knows == "_:bnode2"
14:27:26 [manu]
data.getProjection("_:bnode2") ??
14:27:28 [Benjamin]
why not:
14:27:28 [Benjamin]
_:bnode1 = ivan.get("foaf:knows")
14:27:28 [Benjamin]
ben = data.getProjection(_:bnode1)
14:27:36 [ivan]
14:28:01 [ivan]
manu: the reason I am afraid is when you merge multiple graph together then...
14:28:11 [ivan]
... what happens then to the bnodes
14:28:57 [ivan]
... the two graphs that are merged then things may go wrong because _:bnode1 may not point at the data you are thinking about
14:29:03 [manu]
ack ivan
14:29:11 [manu]
Ivan: That's the same issue I have w/ this.
14:29:24 [manu]
Ivan: If we have bnodes, we are going to have to deal with them...
14:29:37 [MacTed]
Zakim, unmute me
14:29:37 [Zakim]
MacTed should no longer be muted
14:29:42 [manu]
Ivan: It's a potentially dangerous thing to do.
14:29:56 [manu]
Ted: It's a guidance question...
14:30:14 [ivan]
MacTed: blank nodes exist, but if we say if you can avoid using bnodes, do so
14:30:15 [ivan]
14:30:21 [manu]
ack Ivan
14:30:28 [manu]
Ivan: I don't disagree with that, Ted
14:30:43 [Benjamin]
q+ to ask if getRel and getRev really solve this?
14:31:03 [manu]
Ivan: However, if we keep to the example of FOAF, the semantic web is full of bnodes... it's an issue that will be widespread - we should try to be as fool-proof as we can.
14:31:07 [manu]
ack Benjamin
14:31:07 [Zakim]
Benjamin, you wanted to ask if getRel and getRev really solve this?
14:31:37 [ivan]
Benjamin: if we have a subject and an object as bnodes
14:31:43 [ivan]
... it is just the same...
14:31:45 [ivan]
14:31:50 [manu]
ack ivan
14:31:51 [tomayac]
maybe stupid idea: if we have a bnode, serialize it as a JSON-LD object, run a hash function over the JSON.stringified version of it, and give the bnode a uri at{hash_result}
14:32:05 [manu]
q+ to wonder whether or not "it's the same problem w/ JavaScript"
14:32:27 [tomayac]
this would allow us to compare bnodes easily
14:33:06 [manu]
Ivan: Maybe everything will be renumbered at runtime... you can never rely on a bnode ID after a graph merge, etc.
14:33:21 [manu]
Ivan: The only thing you can ask is "is this a bnode" and "are these two bnodes the same"?
14:34:17 [ivan]
Benjamin: the only time this is an issue is at the parse,
14:34:28 [Benjamin]
zakim, mute me
14:34:28 [Zakim]
Benjamin should now be muted
14:34:36 [ivan]
manu: but at the lower level we do a bunch of graph merge
14:34:57 [manu]
Benjamin: I think we can put a warning in the document on the .parse() method because that's when this becomes an issue.
14:35:55 [manu]
Ivan: I can see that if we put a warning in the document working... this may be something we learn more about in implementations.
14:35:57 [manu]
ack manu
14:35:57 [Zakim]
manu, you wanted to wonder whether or not "it's the same problem w/ JavaScript"
14:36:26 [ivan]
manu: getRel mechanism could solve this problem, even if you do a graph merge
14:36:36 [ivan]
... if you had a programming language that was operated on references
14:37:07 [ivan]
... if you do a graph merge, the references will still be fine
14:37:13 [ivan]
14:37:47 [manu]
Manu: .getRel() could work across graph merges if we deal with languages that operate on references.
14:38:10 [manu]
Ivan: Forget about blank nodes for a while - if I have a graph and ask for a Projection, that projection is all the triples that have a common subject.
14:38:48 [manu]
... I have a reference... then I do a merge. Will the projection have to be updated? Does it give me a current snapshot into the graph, or does it give me an auto-updated item.
14:39:25 [manu]
Manu: If we deal w/ reference-based languages - we get an auto-updated item.
14:39:35 [manu]
Ivan: When we deal with things that aren't just snapshots, that's when we get in trouble.
14:40:00 [manu]
Ivan: If it is a snapshot, an implementation can optimize for it. If it's not a snapshot, every request on a projection has to go down to the graph and do a query.
14:41:27 [ivan]
manu: there is a middle ground, (a) snapshot, nothing changes (b) snapshot, number triples do not change, but the values do (c) it is not a snapshot, everything can change
14:41:27 [Benjamin]
q+ to say it has to be a snapshot.
14:41:58 [ivan]
manu: third option may become very complicated
14:42:17 [manu]
ack ivan
14:42:54 [Benjamin]
zakim, unmute me
14:42:54 [Zakim]
Benjamin should no longer be muted
14:42:58 [manu]
Ivan: We agree on option #3 and option #1, not on option #2
14:43:13 [ivan]
Benjamin: if it is not a snapshot, then we have to solve racing conditions
14:43:14 [manu]
Benjamin: if it is not a snapshot, we will have to deal with any sort of "waiting" condition.
14:43:26 [ivan]
ivan: yes, good point
14:43:45 [manu]
Ivan: This has to be very clearly documented...
14:43:58 [Zakim]
14:44:11 [ivan]
zakim, ??P36 is ShaneM
14:44:11 [Zakim]
+ShaneM; got it
14:44:13 [Benjamin]
zakim, mute me
14:44:13 [Zakim]
Benjamin should now be muted
14:44:19 [Benjamin]
zakim, unmute me
14:44:19 [Zakim]
Benjamin should no longer be muted
14:44:38 [Benjamin]
zakim, mute me
14:44:38 [Zakim]
Benjamin should now be muted
14:44:45 [Benjamin]
zakim, unmute me
14:44:45 [Zakim]
Benjamin should no longer be muted
14:44:47 [ivan]
Result of the discussion: projections are snapshots, and we do not need getRels
14:45:00 [webr3]
webr3 has joined #rdfa
14:45:06 [Benjamin]
zakim, mute me
14:45:06 [Zakim]
Benjamin should now be muted
14:45:11 [manu]
Topic: Term vs. Alias
14:45:14 [ivan]
14:45:17 [ivan]
ack Benjamin
14:45:18 [manu]
14:45:18 [Zakim]
Benjamin, you wanted to say it has to be a snapshot.
14:45:31 [MacTed]
Zakim, mute Benjamin
14:45:31 [Zakim]
Benjamin should now be muted
14:45:37 [MacTed]
14:46:43 [ivan]
Topic: term vs. alias ?
14:46:47 [manu]
Topic: Term vs. Alias
14:46:53 [manu]
14:47:00 [ivan]
14:47:02 [trackbot]
ISSUE-89 -- Decide what word we want to use to refer to the concept of RDFa terms - 'term' or 'alias' -- open
14:47:02 [trackbot]
14:47:27 [ivan]
manu: this came up because nathan used 'alias' in the last interface
14:47:50 [ivan]
... as ivan said we would have to change lots of documents if we wanted to use alias
14:48:04 [ivan]
... and, if we decide to change, how to do that
14:48:06 [ivan]
14:48:15 [MacTed]
+1 term
14:48:22 [ivan]
ShaneM: we should continue to use terms
14:48:48 [ivan]
... it has a mind share, it is already in use in the area activity as well, i do not want to reeducate them, i do no see the advantage
14:49:04 [ivan]
... alias is computer science, and term is more linguistic
14:49:10 [tomayac]
+1 for term, fwiw
14:49:11 [ivan]
... term seesm to fit in that
14:49:20 [ivan]
14:49:25 [manu]
ack ivan
14:49:53 [manu]
Ivan: I am a bit afraid that we're going to have to change all the docs/implementations/blog posts...
14:49:59 [ShaneM]
Oh yeah! And datatypes, XHTML M12N, etc. ick
14:50:07 [manu]
Ivan: There doesn't seem to be a very big advantage for making the change... it's a bit too late to make this change.
14:50:09 [manu]
14:50:23 [manu]
Ivan: Keep terms.
14:50:32 [manu]
ack ivan
14:50:37 [ivan]
manu: I had a different view on this
14:50:46 [ivan]
... last time I felt strongly to move to alias
14:51:10 [ivan]
... people would understand what alias is for, better than a term
14:51:16 [ivan]
... after all this is what we do
14:51:30 [ivan]
... it invokes more an alias than a term
14:51:33 [ivan]
14:51:36 [ivan]
ack manu
14:51:47 [ShaneM]
q+ to discuss what a term really is
14:51:48 [ivan]
manu: this is the strongest argument I have
14:52:03 [manu]
ack ivan
14:52:07 [ivan]
ack ivan
14:52:26 [manu]
Ivan: If we had this discussion a year ago, I would fully agree with you.
14:52:45 [manu]
Ivan: The argument resonates with me - it's a bit too late. We need a stronger argument now.
14:52:48 [manu]
ack ShaneM
14:52:48 [Zakim]
ShaneM, you wanted to discuss what a term really is
14:53:02 [ivan]
ShaneM: you said something I may not agree with
14:53:22 [ivan]
... it is true internally that we have a mechanism to take a string and map it to a uri
14:53:34 [ivan]
... but that is not how I explain things to people
14:53:45 [ivan]
.. it is a component of a vocabulary
14:54:07 [ivan]
... it is a term. it expands to a uri, but for our audience 'you can use this word, and means _this_'
14:54:21 [ivan]
... we would like to attract the microformat community with this
14:54:28 [ivan]
... they not care about uris
14:54:36 [ivan]
PROPOSAL: keep terms
14:54:45 [ivan]
14:54:50 [MacTed]
14:54:51 [tomayac]
14:54:58 [manu]
14:55:02 [Benjamin]
14:55:16 [manu]
RESOLVED: Keep the word 'term' - do not use the word 'alias'.
14:55:17 [ShaneM]
14:55:55 [manu]
Topic: Formulation on fragid in RDFa Core
14:56:06 [manu]
14:56:10 [ivan]
manu: this boils down removing 2 words from the spec
14:56:35 [ivan]
... the issue the tag / j rees had with the spec is that we say the word 'at present', and we should not say it
14:56:50 [ivan]
... if we do that, they are happy
14:58:17 [manu]
PROPOSAL: Remove the words "at present" when discussing fragment identifiers. The editor will create language that is in line with the TAG's request.
14:58:20 [manu]
14:58:22 [ivan]
14:58:25 [tomayac]
14:58:26 [Benjamin]
14:58:34 [ShaneM]
14:58:40 [ivan]
RESOLVED: Remove the words "at present" when discussing fragment identifiers. The editor will create language that is in line with the TAG's request.
14:59:32 [MacTed]
+1 :-)
14:59:55 [manu]
ACTION: Manu to do official 2nd LC response to ISSUE-94.
15:00:03 [trackbot]
Created ACTION-77 - Do official 2nd LC response to ISSUE-94. [on Manu Sporny - due 2011-05-19].
15:00:05 [manu]
Topic: IRI vs. URI References
15:00:33 [manu]
15:00:37 [ivan]
15:00:38 [trackbot]
ISSUE-87 -- IRIs vs URI References -- open
15:00:38 [trackbot]
15:00:54 [ivan]
manu: misha asked us to use the same terminology than the rest of the document
15:01:05 [ivan]
... ShaneM explained the reasoning on the mailing list
15:03:11 [MacTed]
I have to jump to another call... so make good decisions! :-)
15:03:14 [Zakim]
15:04:17 [ShaneM]
15:05:58 [ivan]
15:06:13 [manu]
Shane responded:
15:06:25 [manu]
Mischa's response to Shane's response:
15:06:40 [ivan]
15:07:18 [tomayac]
15:07:56 [tomayac]
manu, depends on your browser
15:08:00 [tomayac]
some show it, some hide it
15:08:10 [tomayac]
in the background they punicode it
15:08:43 [manu]
So for: www.zü does RDFa output that? Or does it output:
15:10:21 [manu]
Can RDFa output the following: <www.сделат картинки.com> ? for a subject?
15:13:15 [tomayac]
we have problems with e.g. ntriples, which only allow ascii, rdfa has no problem with it
15:14:24 [ShaneM]
tomayac: ahh
15:15:53 [manu]
ACTION: Manu to write e-mail to RDF WG chairs about ISSUE-87 - we can't go to CR without this being resolved.
15:15:53 [trackbot]
Created ACTION-78 - Write e-mail to RDF WG chairs about ISSUE-87 - we can't go to CR without this being resolved. [on Manu Sporny - due 2011-05-19].
15:17:15 [ivan]
15:18:16 [tomayac]
shouldn't we default to punycoding all IRIs, so treat them always the same. least common multiple...
15:23:29 [ShaneM]
Section 6 says "The lexical space of a CURIE is as defined in curie below. The value space is the set of URIs."
15:24:00 [Zakim]
15:24:19 [Benjamin]
15:27:40 [ShaneM]
href="http://www.сделат картинки.com/example" is what in the DOM within a browser?
15:27:56 [manu]
ShaneM: No, that's not in the DOM
15:28:29 [tomayac]
15:30:12 [tomayac]
<a href="">Schweizer Küche</a>
15:34:16 [tomayac]
<a href="">Schweizer Küche</a>
15:34:39 [ShaneM]
check this:
15:34:44 [tomayac]
my irc client punycodes... the 2nd link had a ü in it
15:35:48 [manu]
RDFa processors should allow: <a href="http://www.schweizer-kü">Schweizer Küche</a>
15:36:48 [tomayac]
hmmm, personally i expect the rdfa processors to punycode. just sayin'...
15:45:04 [Zakim]
15:45:05 [Zakim]
15:45:05 [Zakim]
15:45:07 [Zakim]
SW_RDFa()10:00AM has ended
15:45:10 [Zakim]
Attendees were hta, Ivan, MacTed, Benjamin, manu, ShaneM
15:48:06 [tomayac]
we kinda have this issue already: is NOT the same as, where is the same as
16:10:12 [manu]
tomayac, true - but I'm wondering if the decision we make would make that case even worse? or better?
16:10:39 [tomayac]
better imho, as we define a rule everyone has to accept
16:10:42 [manu]
and for that matter - what is "worse" or "better"
16:10:58 [tomayac]
we can also make the rule that everyone has to uplift (de-punycodify) their uris
16:11:17 [tomayac]
i dont really care, however, tend to downlift, as this is what browsers do
16:11:18 [manu]
does that mean punycoding? How do you think people in Japan, China, Middle East will feel if all of their domain names can't be expressed in the natural language?
16:11:44 [manu]
meaning, non-ascii is a second-class citizen in RDF?
16:11:51 [tomayac]
i agree! fair argument
16:12:06 [manu]
I do agree w/ you that it would be good to have one rule that everyone follows.
16:12:21 [tomayac]
but i'd say: it's mainly a perception thing. just as people dont look at the bits in http...
16:12:27 [manu]
I do also think that N-Triples is wrong, and so are the way that Internationalized Domain Name identifiers were done.
16:12:29 [tomayac]
...people dont directly look at triples
16:13:04 [manu]
sure, /some/ people don't look at triples... but I'm concerned about the developers that do look at triples.
16:13:10 [tomayac]
whatever way we choose, let's choose one and make it a rule everyone has to obey to
16:13:40 [tomayac]
devs will write an abstraction layer on top that allows them to see nice triples
16:13:45 [manu]
my other concern is that we can tell people to "obey this rule", but if it doesn't affect implementations (de-punycoding values)... then I don't think people will listen.
16:13:52 [tomayac]
or they think binary anyways ;-)
16:13:59 [manu]
16:14:06 [manu]
I think some developers will and some developers won't
16:14:09 [tomayac]
how about a SHOULD
16:14:23 [manu]
I'm fine w/ a MUST
16:14:27 [manu]
but I don't think people will listen
16:14:43 [tomayac]
and rdfa distillers (de)punycode silently (up or downlift, whatever we decide for)
16:14:49 [manu]
(or rather, 80% will listen, but others will not)
16:15:01 [tomayac]
16:15:12 [manu]
and that will lead to diverging implementations...
16:15:30 [manu]
so, are you saying that RDFa Processors, if upon seeing a punycoded value, will de-punycode the value?
16:15:45 [manu]
before emitting the triple?
16:15:56 [tomayac]
or the other way round, yepp. so "incorrect" triples would be auto-corrected
16:16:18 [manu]
ok, so what happens when the author intended to have the value 'punycoded' due to a reason that we cannot forsee.
16:16:38 [manu]
Their systems team has some strange requirement that "all IDNs must be punycoded" and they end up creating identifiers w/ punycoded values?
16:16:59 [manu]
(my underlying argument is that whether or not to punycode should be a decision made by the developers - not us.)
16:17:29 [tomayac]
ok, but then we live with uncertainty whether people are talking about the same, or not
16:17:37 [tomayac]
but fair point of course!
16:17:40 [manu]
yes, but it's their mistake to make :)
16:18:02 [manu]
I don't see how we could do either, without screwing someone up somewhere in the world.
16:18:17 [manu]
and ultimately, we've always settled on: Give the power to the authors.
16:18:25 [tomayac]
the best compromises are those where no one is happy
16:18:32 [tomayac]
but everyone can live with ;-)
16:18:33 [manu]
haha :)
16:18:49 [tomayac]
maybe the problem isnt that big
16:19:02 [tomayac]
a couple of owl:sameAsses here and there
16:19:06 [manu]
sure, if it were up to me I'd go back to the IDN people and tell them that they should've fixed their broken-ass system instead of introducing punycoded values.
16:19:33 [manu]
the IDN punycoded stuff is a non-solution.
16:19:52 [manu]
... and I'd tell the N-Triples people to upgrade their spec to support UTF-8
16:20:00 [tomayac]
well, we call this legacy ;-)
16:20:10 [manu]
Down with legacy!
16:21:33 [manu]
More seriously - I think the decisions that we make with RDFa should be forward-looking... not attempting to shoe-horn some badly designed legacy hack into RDFa.
16:21:58 [tomayac]
as i said, i can live with the up-lifting rule
16:22:05 [tomayac]
we just need to make it
16:22:41 [manu]
What I'd be happy with is "don't touch the sequence of characters, except when canonicalizing."
16:26:04 [MacTed]
"be liberal in what you accept, be conservative in what you generate..."
16:26:35 [MacTed]
(I think this is the first time I've encountered "punycode" ... what's that mean?)
16:27:25 [manu]
A legacy hack:
16:27:59 [manu]
The only reason the hack was put in there was so that DNS could express Internationalized names.
16:28:12 [manu]
so, rather than requiring that DNS systems upgrade to allow UTF-8
16:28:43 [manu]
they put a hack in there that is now generating these awful URLs that nobody can read
16:29:05 [manu]
it's also lead to a number of phishing attacks in browsers that don't de-punycode values before putting them in the address bar.
16:29:43 [MacTed]
well... URLs *are* supposed to be considered opaque -- so readability *should* be a null argument
16:29:54 [tomayac]
wrt to phising: this still is a problem if utf-8 were supported directly
16:30:14 [manu]
tomayac: true - but now we have 2 phising vectors instead of just 1
16:30:40 [MacTed]
ok, so punycode is not so different from percent-encoding/URL-encoding ...
16:30:41 [tomayac]
we see this in ads as well where people try to re-write iPhone with look-alike chars to trick the trademark filters...
16:31:00 [manu]
MacTed: Yes, it's just another way to do percent-encoding/URL-encoding
16:31:04 [tomayac]
it's an rfc actually:
16:31:48 [MacTed]
and we're down again to lexic vs syntactic vs semantic equivalence
16:32:52 [tomayac]
1 == true
16:32:52 [tomayac]
16:32:52 [tomayac]
1 === true
16:32:53 [tomayac]
16:33:14 [tomayac]
we need owl:reallySameAs ;-)
16:33:28 [MacTed]
*supposedly* there is only one valid string for each URI, which includes all required percent encoding and no more ... but because tools have been badly behaved for a long time, nobody's really quite sure what that string is for any complex URI
16:33:59 [MacTed]
owl:sameAs is perfectly fine as it is -- even when used incorrectly
16:34:33 [tomayac]
ask harry halpin this question
16:34:47 [MacTed]
nameA owl:sameAs nameB
16:34:48 [tomayac]
well, you didn't ask a question
16:34:56 [MacTed]
two names for same thing
16:35:25 [tomayac]
yeah, this is what i was saying above. maybe a couple of owl:sameAs between punycode uri and non-punycode uri can fix the world
16:35:28 [MacTed]
like "Ted" and "Theodore" and "Teddy" ... within a namespace
16:36:18 [MacTed]
such would help fix the world, for sure ... given good reasoning engines
16:36:39 [tomayac]
16:36:54 [manu]
"given good reasoning engines" being the operative phrase.
16:36:59 [manu]
Know of any good ones :P
16:37:31 [manu]
where good == performant, open source, good documentation
16:37:41 [tomayac]
hooray for the web of data as one, single database ;-)
16:39:38 [MacTed]
I like Virtuoso.... ;-)
16:39:57 [manu]
hehe :)
16:45:38 [ShaneM]
ShaneM has left #rdfa
17:00:46 [Zakim]
Zakim has left #rdfa
18:37:53 [ShaneM]
ShaneM has joined #rdfa
18:37:55 [ShaneM]
ShaneM has left #rdfa
18:59:54 [ShaneM]
ShaneM has joined #rdfa
19:09:41 [ShaneM]
ShaneM has joined #rdfa
19:09:45 [ShaneM]
ShaneM has left #rdfa
19:49:49 [ShaneM]
ShaneM has joined #rdfa
20:00:35 [ShaneM]
ShaneM has left #rdfa
20:19:19 [webr3]
webr3 has joined #rdfa
21:03:18 [ShaneM]
ShaneM has joined #rdfa
22:09:40 [webr3]
webr3 has joined #rdfa
22:49:08 [ShaneM]
ShaneM has joined #rdfa
23:20:03 [webr3]
webr3 has joined #rdfa
23:24:54 [ShaneM]
ShaneM has joined #rdfa
23:28:53 [ShaneM]
ShaneM has joined #rdfa