#tantek*in addition* to marking those as categories
#tommorrisso, the wikipedia links, for instance, can easily be mapped to both hCard's url property and do some linked data sameAs magic to dbpedia
#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.
#tantekok, so as long as you can just specify the "url" property, you're good
#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.
#tommorris(and, yes, "it lets you describe other people's shitty data better" is hardly the most compelling use cases for upper-case SemWeb)
#tommorrisalso, an interesting issue: have we yet worked out how to do multi-lingual microformats?
#tantekwhat's the real world example you're trying to mark up?
#tantekdon't all unique identifiers match up to a URI with some made-up scheme?
#tantekmight use p-lang-fr rather than p-a-fr just because that's more "obvious" and easy to remember as a generic "here is a French language property"
#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.
#tantekand make "p-lang" indicate that it should get the language from the 'lang' attribute
#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.
#tantekbut the key here is that the "h-alts" grouping makes it clear that there is only *one* value, with multiple language expressions
#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
#tantekthat might be two whole different profiles then
#tantekif you bump things up to the page granularity, then the problem is solved
#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.)
#tantektheir (sustaining) pace of innovation is impressive
#tantekpresumably, for the indieweb-autocomplete stuff, it should just auto-match *any* profile it knows about, regardless of the language of the profile
#tantekso that should just automatically work if each profile is on its own page
#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)
#tantekthe node/venue pages you showed me looked pretty straightforward to markup
#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
#barnabywaltershow should the parser behave without understanding the types involved?
#tantekright, that's the only case where the parser *does* need to do type-specific parsing, and then combine the result back into a string
#tanteknote: prefixes != types. that's a semi-common misconception.
#tantekprefixes are merely cues for different parsing algorithms
#tantekwhich *happen* to *sometimes* overlap with some variances in typing
#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?
#tantekedited /test-suite (+1048) "stub from scratch for 2012 with some borrowed prose from before" (view diff)
#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
#barnabywaltersso is there a technical term for those non-moment times?
#tantekalways returning strings for every property greatly simplifies the JSON format that is shared
#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"
#tantekand isodatetime to mean YYYY-MM-DDTHH:MM (with optional :SS seconds and/or Z/+/-TZ)
#barnabywalterswhich I believe in the HTML5 <time> spec there is
#tanteksoftware datetime libraries are horribly inconsistent when it comes to such edges
#barnabywalterstommorris tweeted about this recently, perhaps he can express it better
#tantekand no, they don't refer to moments, they often either refer to seconds or milliseconds
#tanteke.g. epoch seconds is often supported in software libraries
#barnabywaltersvar_dump(new DateTime('2012-01-01T00:00:00') == new DateTime('2012-01-01'));
#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
#tantekthere's no documentation on the research (if any) that was used to justify what PHP DateTime object parses and what it doesn't
#barnabywaltersyes, the "this is the actual content the author authored" factor is a powerful one
#tommorristantek: the OSM community are rightfully rather conservative about what gets put on the website.
#tanteksure - that's one of the reasons we've minimized what markup you need to add to add microformats
#tantekmicroformats are the most conservative of the options as compared to RDFa or microdata for example
#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
#tantekand microformats2 makes that even *more* conservative (less makrup)
#tommorrisyup, but that's not that big of an issue
#tommorrisit's that the OSM community has a certain feeling about the "freedom to tag as you like"
#tommorrisso, for instance, there was a big debate back in the day over postal_code vs. postcode
#tanteksure that's fine, and for OSMXML they should make up whatever tags they want :)
#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
#tantekso let's just start with hCards with url, geo, name then
#tantekand postpone figuring out address-compat for later
#tommorrisI know the Wikipedia links have some special magic, for instance.
#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.
#barnabywalterswould using the -osm- prefix on the root class get around the "not everything OSM has is an h-card" issue?
#tantekI've checked into named drinking fountains (e.g. during a run in the park)
#tantekyes, you could check into a named park bench, because you could certainly create it as a venue (e.g. in foursquare)
#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"
#tantekand then when building validation functionality, if it makes sense to put hooks into the parsers to get more info, then we can discuss that then
#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)