Re: clear strategy for multiple AS2.0 serializations?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/29/2015 09:32 PM, ☮ elf Pavlik ☮ wrote:
> Howdy!
> 
> This email acts as sort of follow up on one I've send on Dec 1st
> and which didn't receive any replies 
> https://lists.w3.org/Archives/Public/public-socialweb/2014Dec/0002.html
>
>  I just picked up again work on automated testing of RDF based 
> serializations and just fixed errors in first three Turtle
> examples. 
> https://github.com/jasnell/w3c-socialwg-activitystreams/issues/65
> 
> It may take me some time to fix errors in most of the remaining
> Turtle examples and then check all the RDFa as well. But in the end
> we will have automated tests proving that all JSON-LD, RDFa and
> Turtle examples serialize exactly the same RDF graphs.
> 
> After that I could take a look at possibility of contributing RDFa
> and Turtle support to
> https://github.com/jasnell/activitystreams.js Porting it to ruby
> also should come as straight forward process using existing
> libraries!
> 
> Looking at latest WD 
> http://www.w3.org/TR/2015/WD-activitystreams-core-20150129/
> 
> "This specification describes a JSON-based [RFC7159] serialization 
> syntax for the Activity Vocabulary that follows the conventions
> defined by the [JSON-LD] specification. While serialization forms
> other than JSON-LD are possible, alternatives are not discussed by
> this document."
> 
> Still it provides examples in JSON-LD, Microdata, RDFa,
> Microformats and Turtle. I think we could add little more
> clarification about their purpose in the spec!

- From the perspective of the charter, those examples could be removed.
However, I see no harm done in keeping them (or in one or a series of
appendices per format) if there are objections or confusions caused in
Last Call.  Ofcourse, the Microdata/RDFa/Microformat issue remains one
of standardizaton failure insofar as the same use-case is addressed by
three conflicting syntaes, but that's beyond our WG's charter to fix :)

Nonetheless, any fans of particular syntaxes are encouraged to build
test-suites for any of them, although normatively we'll focus on JSON
for CR.

> 
> I have two questions here: * Does someone plan to create automated
> tests for Microdata and Microformat examples, similar to what I
> work on for RDFa and Turtle? * Does someone plan to contribute
> Microdata and Microformats support to activitystreams.js or any
> other AS2.0 implementation?
> 
> Personally I would recommend using RDFa over Microdata. I just
> created placeholder to capture limitations on schema.org
> extensibility related to use of Microdata. 
> https://github.com/schemaorg/schemaorg/wiki/Extension-Mechanism#limitations-of-microdata
>
>  When it comes to Microformats, I would personally see more
> interest in helping with toolchain for migrating currently deployed
> systems to RDFa.
> 
> IMO support for Microdata and Microformats might require some kind
> of recommendation for *graceful degradation*, especially if at some
> point we will get to digitally signing the content. I will happily
> see others proving me wrong here.

There is more support in the wild for both Microformats by far than
RDFa BTW, and more RDFa (due to "Like" button I believe) than
micordata. Thus, I think if we keep *any* of them, we have to keep all
three. If we have to keep one, we should probably chose microformats.
Again, people can work however they want to push their favorite syntax.

I would not think that having support for one of these syntaxes would
prevent an implementation from being conformant, but of course we
would welcome. However, an implementation that does not accept JSON
would be non-con-formant.

   cheers,
        harry

[1]http://webdatacommons.org/structureddata/#toc3


> 
> Cheers!
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUyqvVAAoJEPgwUoSfMzqcml8QAIqZQPPMVl5b+3A50SXiAgu4
OKbQwYJPPHxUQoUEF6DB+dKdzcZxus+8+APt56ymW5Q/zkgQl3hmNxLKeBsglHZH
Zd59KvfPK6ICKajghV85vG/y6Ei+XlH3yIuFd279FbqOxNntvwaBrOsMRjMeZYHm
hk4d3GG+N8yV2awuxi0o5ZVVpHXBkIlPcrspL4hcMdHGJSMrW2xTxIqs2V4Syc/O
omiGHINGpKI+kr32/N3pFYEJN4Tkff2USnTihTyMJn7cquw8hjBro9nDVXPKq0x5
GJg70UFv1sjV3N/ebdg3dakCjkyhbF0uKGmXQzuIpjcCGtRcJnwArHgaRPro26uS
9AnCis7t/ndrIp8goT91IxkCEMRDRHVV5ScMhnVzlZS50+5tO7GyKe/GJq7xK6/e
Wbz3YXPn6a3O8Vgl1G+lmS4/hvCFASl3SH4rOeoiw07UotngpnUxYpuO7QeS8O3t
uKP4ClIcgtL5ZmNa4gZ5Xdf8iMvpH4cf5M86e6Yz2dauefIkldSiPy6A7X1V1Mfp
gcsUKT6gD6KgomHctLf57Cr+2bGMQc2zo4oU0taBO5uSXM5BeNLk9HKLbVb9H+Du
k2TTlZ1xTmRirdRWb51fwbbbo0O/RXkrldnGKFXNTemv+yXY/9KuV92iisALf+Oi
eFjdaO5RluPeIQ4EMcuJ
=uJVO
-----END PGP SIGNATURE-----

Received on Thursday, 29 January 2015 21:53:34 UTC