Hi,
Simon's post below got me thinking .... this is a terrific opportunity
to install a Javascript RDF/LOD parser library as standard issue in
SMW's resources list. To encourage growth of shared JS libraries, client
extensions shouldn't have to worry about loading an RDF/LOD javascript
library as a MediaWiki resource. At best an extension should name the
parser(s) which are its dependencies and SMW handles the rest or at
worst use the default "RDFJS" library which SMW loads. And SMW should
load client extensions' javascript modules itself -- it must be as easy
as pie to add new modules that are downloaded by SMW.
But which would be that 'default' RDFJS parser?
While N3, the "lightning fast, asynchronous, streaming RDF (parser) for
JavaScript" [1] appears a most modern choice, I think Tim Berner Lee's
/rdflib.js/ [2] is better for the SMW community. /rdflib.js/ can parse
RDF/XML (an obsolete syntax), Turtle (modern syntax), N3 (dated syntax)
and RDFa [3]. Also, /rdflib.js/ appears to have some reasoning/logic
too, unlike the N3 package.
RDFa is mighty interesting as one thinks of client-level integration of
Wikidata ("multilingual ground facts") with a page's semantic data;
Wikidata is/can emit HTML pages annotated with RDFa attributes so it's
obviously useful to have this parser in the javascript resources loaded
by SMW.
/john
[1] https://github.com/RubenVerborgh/N3.js
[2] https://github.com/linkeddata/rdflib.js
[3] http://www.w3.org/TR/rdfa-syntax/
See also:
http://www.w3.org/community/rdfjs/wiki/Comparison_of_RDFJS_libraries
On 8/13/2015 3:22 PM, John McClure wrote:
Hi Simon
The gist of the idea is the following: SMW could (?) support a
convenient document oriented (JSON) data structure in addition
to its graph oriented structure, by the introduction of a
simple new feature: The ability to give subobjects a custom
property name in addition to the default internal property
"Has subobject". [1]
It's the right approach many times to work with a page's data in client
javascript; alternatives are not always workable (see [2] and
Special:ExportRDF?syntax=turtle). Turtle syntax [3], when paired with a
fairly simple JS parser, would be another approach for SMW to send data
to the browser -- the idea being a page's semantic data is carried in a
single javascript variable that's parsed on the client. JSON syntax does
save this parsing step on the javascript client but it does tie the smw
interface to a specific language. Anyway a magic word would be cool to
self-identify pages for which a known JS variable is to be generated
with Turtle content.
Client JS software can today use smw's API [4] to retrieve turtle syntax
for page properties although I'm hardly an expert at this. Regardless of
syntax, it's always nice to see visualizations of smw data ... suggest
you also consider smw's namespace [5] for the base set of 'built-in'
json property names javascript code might reference.
best regards/john
[2] https://semantic-mediawiki.org/wiki/Help:JSON_format
[3] http://www.w3.org/2010/01/Turtle/
[4]
https://semantic-mediawiki.org/wiki/Semantic_MediaWiki_1.5.5#Turtle_syntax_support
[5] http://semantic-mediawiki.org/swivt/1.0#
On 8/6/2015 1:09 AM, Simon Heimler wrote:
Hello there!
I've got a suggestion about supporting custom property names for subobjects,
in addition to the internal "Has subobject" property. This would allow to
structure the semantic properties of a page as a convenient (JSON) document.
Here's the full description of the idea, including an example:
[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/1104
Best,
Simon
------------------------------------------------------------------------------
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
------------------------------------------------------------------------------
_______________________________________________
Semediawiki-user mailing list
semediawiki-u...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
------------------------------------------------------------------------------
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
