tommorrisif I can work out a sane and not-too-disruptive way of adding hCard, I'll have a crack at it tomorrow. certainly, it'd make sense for node venues
tantekI'd be curious to know what functionality RDFa would add in addition to the uf2 markup - or if it's just to be multimarkup supportive and all that.
tommorrisso, a really quite fucked-up use case is there are sometimes government datasets that use some kind of unique identifier that doesn't match up to a URI. being able to express the semantics of that (that it is, say, an inverse functional property and all that kind of stuff) means you can do some sanity checking on it at a later date.
tantekwhether you use uf2 or rdfa etc. you're still going to have that same challenge of explicitly indicating alternates for the same thing, instead of possibly just having a multivalued property where different values just happen to be different languages.
tommorrisso, in the RDF output for microformats2, I'm certainly interested in preserving the language attribute information. a consumer of the data could under some circumstances make a useful inference from it.
tommorrisreal world usage that prompted this: at a meetup.com-organised event in London this week, there was some Russian guy and his profile on meetup had a name in Russian script and the Latin script version elsewhere in the profile
tommorrisfor the purposes of indieweb stuff like the indieweb-autocomplete stuff barnaby is working on, you should be able to type in either and match them. (facebook, incidentally, now let you type in a word like "mom" or "boyfriend" into search and it takes you to the right person.)
tantekpresumably, for the indieweb-autocomplete stuff, it should just auto-match *any* profile it knows about, regardless of the language of the profile
rbual42created /El_Superar_del_Apego (+4205) "El enamoramiento es una instrumento poderosa para poder entrenar con éxito cualquier tipo de paciente - desde los ejecutivos de alto nivel para los reclusos. Con el fin de llevar a cabo un encontronazo con enamoramiento, un adiestrador debe retirars" (view diff)
tommorrisI may have a crack at fixing the indieauth login to allow OpenStreetMap OAuth as an option. it'd then be the first IndieAuth provider that is on a site that is controlled by a charitable foundation rather than a Silicon Valley company.
tantekit wasn't really one issue - it was more of a conversation thread about multiple questions, and I couldn't even follow what was a question and what was a suggestion
barnabywaltersso apart from date vagueness, what is the advantage of returning strings over native objects if conversion to native objects is required in order to do the parsing in the first place?
tantekso first, there's nothing vague about the broader set of dates/times/durations that <time> and microformats allow - each is actually very specifically defined. it's not vague, the same way that 12:00 isn't vague just because it omits seconds and milliseconds.
tanteksecond, whether or not you use native objects to parse the value class pattern is an implementation detail. it's certainly not required by the value class pattern spec or parsing algorithms
barnabywaltersmy point is, most software datetime libraries assume each datetime object refers to a particular moment in time, and there is no way of expressing "a week" or "a minute" or "a second"
tantekthe point is, to do date time parsing properly and handle real world use cases (which all went into the design of the HTML5 <time> element, almost all from microformats), you have to write your own date time zone etc. parsing code.
tantekexisting language/library "support" of dates and times is sadly deficient, that's why I said you have to write your own date time zone etc. parsing code.
tantekit's also why HTML5 specifies parsing algorithms for all of the different dates / times / durations - because all previous attempts have been sadly deficient / and/or taken bad shortcuts
barnabywaltersstill, I suppose ditching php DateTime and writing something based entirely round the value-class datetime spec would make things a bit more straightforward
tantekand it would reflect actual content published by people on the web, rather than whatever legacy strings the PHP languages folks wanted to parse in the PHP DateTime object
tommorrisno, it isn't that. it's more that the mapping of OSM tags to the semantics of microformats (or microdata or RDFa etc.) isn't necessarily something they want in the core code
tommorrisit's very cowpath-pavey. so, when basically canonicalizing a set of OSM->microformats (or RDF or whatever) mappings, you need to basically do it in a way the community can change later without being programmers
tantekthe point with the "p-osm-*" properties is that now that we have a way of doing vendor/site specific properties in microformats2, we might as well use it.
ddenizcreated /tayt_modelleri (+768) "New page: 2012-2013 Bayan tayt modelleri Son 10 yılda bayanlar tarafından sıkça kullanılan bayan '''tayt modelleri''', özellikle 2012 yılında kadınların ilgi odağı olmaya baÅŸladı. Her..." (view diff)
tommorristhat's why it's a bit more complicated than just rolling it out: I need to hack together some way of allowing the community to self-describe the relation between OSM tags and microformats
tommorrisI could see people checking in to, say, "Tottenham Court Road" in London, because they may wish to signal to the world that they are flitting between shops on said street.
tantekhowever I think the semantic that those people are expressing is a particular meaning of "the area around Tottenham Court Road" rather than "anywhere on a street named Tottenham Court Road"
tantek!tell gjones I've wrapped up an answer on https://github.com/microformats/tests/issues/1 as best I could, please feel free to close it if you think the issues/questions have been answered, or preferably if there are outstanding issues/questions, please start a new github issue for each. Thanks! cc: barnabywalters
tantekedited /test-suite (+237) "/* FAQ */ clarify that native language objects are sadly deficient at representing dates/times/durations as published on the real world web." (view diff)