Hi, Thanks for the hint. I have looked into the way SMW exports to RDF. Now, the code is much shorter [1], [2]. Yet, it can be improved, but I do not fully understand all export functionality (some information in [4] would help there ;-).
I am wondering, whether it would be better to integrate RDFa output into the
separate data values. Then, one would have more control over the way RDFa is
included, and hopefully, then it would be much easier to extend the RDFa
output to Inline Queries.
Also, I still haven't found a way to inline edit RDFa (AlohaEditor [3] looks
interesting, but there is no integration in MW, yet).
Best,
Benedikt
[1]----------------------------
$text = "<span id='RDFa' about='".SMWExporter::expandURI(
'&wiki;' ).$parser->getTitle()."'".
" xmlns:wiki='".SMWExporter::expandURI( '&wiki;' )."'".
" xmlns:wikiurl='".SMWExporter::expandURI( '&wikiurl;'
)."'".
" xmlns:property='".SMWExporter::expandURI( '&property;'
)."'".
" xmlns:owl='".SMWExporter::expandURI( '&owl;' )."'".
" xmlns:rdf='".SMWExporter::expandURI( '&rdf;' )."'".
" xmlns:rdfs='".SMWExporter::expandURI( '&rdfs;' )."'".
" xmlns:swivt='".SMWExporter::expandURI( '&swivt;' )."'>".
$text;
$text = $text."</span>";
---------------------------------
[2]----------------------------
$rdfa_output="";
foreach ( $properties as $singleprop ) {
$dv = SMWParseData::addProperty( $singleprop,
$value, $valueCaption, SMWParserExtensions::$mTempParser,
$smwgStoreAnnotations && SMWParserExtensions::$mTempStoreAnnotations );
//get the URL of property
$property_string = $singleprop;
$property_string=str_replace( ' ',
'_',$property_string);
// process triples grouped by predicates
//get the proerty id
$property_id = $dv->getTypeID();
// TODO: For each property we need some data about
it
$exportdata = $dv->getExportData();
//TODO: Check for other types (as in RDFa extension)
if ($property_id == "_wpg")
{
$rdfa_output .= "<span
rel='property:".$property_string."'
resource='[wiki:".$dv->getWikiValue()."]'>".$dv->getShortWikitext( true
)."</span>";
} else {
$content =
$exportdata->getSubject()->getName();
$datatype =
$exportdata->getSubject()->getDatatype();
if (!$datatype) {
$datatype = "";
} else {
$datatype =
"datatype='".$datatype."'";
}
$rdfa_output .= "<span
property='property:".$property_string."' content='".$content."'
".$datatype.">".
$dv->getShortWikitext( true )."</span>";
}
}
$result = $rdfa_output;
----------------------------------------
[3] http://aloha-editor.org/
[4] http://semantic-mediawiki.org/wiki/Architecture_guide#RDF_export
--
Karlsruher Institut für Technologie (KIT)
Institut für Angewandte Informatik und Formale Beschreibungsverfahren (AIFB)
Benedikt Kämpgen
Wissenschaftlicher Mitarbeiter
Kaiserstraße 12
Gebäude 11.40
76131 Karlsruhe
Telefon: +49 721 608-47946 (!neu seit 1.1.2011!)
Fax: +49 721 608-46580 (!neu seit 1.1.2011!)
E-Mail: benedikt.kaemp...@kit.edu
Web: http://www.kit.edu/
KIT Universität des Landes Baden-Württemberg und
nationales Forschungszentrum in der Helmholtz-Gemeinschaft
-----Original Message-----
From: Markus Krötzsch [mailto:mar...@semantic-mediawiki.org]
Sent: Wednesday, February 16, 2011 6:04 PM
To: Benedikt Kaempgen
Cc: smw dev list
Subject: Re: [SMW-devel] Inline Editing Functionality by using RDFa
On 16/02/2011 12:46, Benedikt Kaempgen wrote:
> Hello,
>
> I now managed to include RDFa in annotations.
>
> For that, I had to modify SMW_ParserExtensions.php.
>
> First function "onInternalParseBeforeLinks" to add the namespaces: [1]
>
> And also function "parsePropertiesCallback" to surround the value output
> with RDFa: [2]
>
> I only used<div></div> to add the RDFa, which are allowed in MediaWiki
> syntax.
>
> As a side note: If I input raw RDFa (e.g. [3]) in wikitext, the RDFa
markup
> gets stripped out. The RDFa insert by the given code, however, comes
> through. I don't know why.
Good to see that this worked out so easily. But please, by all means,
use the SMW code in ./includes/export/SMW_Exporter.php and
SMWDataValue::getExportData() to obtain the RDF to export. We do not
want the RDFa feature to publish data that is different from SMW's
normal export, and we do not want to replicate the code. The code I
mentioned can be used to get the URIs for the namespaces, and to get the
RDF structure that represents arbitrary data values.
Modifications/extensions to that code might be useful to support all
your needs, but they can surely be done.
Using the SMW functions for exporting this is obviously essential for
inclusion into SMW core, but it should also make your life easier since
all the ugly encoding issues are taken care of by SMW, and since it
allows you to support all current and future SMW datatypes with the same
code. I do not know how well RDFa can represent nested RDF structures
such as those that are used for record type properties, but most cases
should be easy to handle.
Regards,
Markus
>
> Now, I am looking for an extension that provides inline editing for
> MediaWiki. It should allow to change the annotations surrounded by RDFa.
For
> saving the changes, the changed annotation and the RDFa would be given as
> parameters to a script which would use SMWWriter to do the update. Anyone
> having an idea of how to easily allow this in MW/SMW?
>
> If we can achieve this, I would then try to add RDFa to query outputs.
This
> would allow also to change annotations on queried pages.
>
> Of course, there is still the problem that SMWWriter cannot update an
> annotation if it is given through a template (amongst other reasons but
this
> is the most common one, I guess). I am wondering if one could have forms
> that directly use annotations without templates.
>
> I'd be happy to hear your opinions on this.
>
> Best,
>
> Benedikt
>
> [1]-------------------
> global $wgServer,$wgScript;
> $host_address=$wgServer.$wgScript;
> $id=1;
> $this_page = $parser->getTitle()->getFullURL();
> $text = "<div id='RDFa' about='".$this_page."'
> xmlns:wiki_".$id."='".$host_address."/'".
> "
> xmlns:wiki_".$id."_property='".$host_address."/Property:'".
> "
> xmlns:wiki_".$id."_category='".$host_address."/Category:'>".$text;
> $text = $text."</div>";
> ----------------------------------------
>
> [2]------------------------
> $rdfa_output="";
> $id=1;
> foreach ( $properties as $singleprop ) {
> $dv = SMWParseData::addProperty( $singleprop,
> $value, $valueCaption, SMWParserExtensions::$mTempParser,
> $smwgStoreAnnotations&& SMWParserExtensions::$mTempStoreAnnotations );
>
> //get the values of each property
> $propvalue = $dv;
>
> //get the URL of property
> $property_string = $singleprop;
> $property_string=str_replace( ' ',
> '_',$property_string);
> $property_output =
> "wiki_".$id."_property:".$property_string;
>
> // process triples grouped by predicates
> //get the proerty id
> $property_id = $dv->getTypeID();
> $propvalue_page_string="";
>
> //TODO: Check for other types (as in RDFa extension)
> if ($property_id == "_wpg")
> {
> $propvalue_output =
> "wiki_".$id.":".str_replace(" ","_",$propvalue->getWikiValue());
> //$rdfa_output .= "<a
> href='".$propvalue_output."' rel='".$property_output."'></a>\n";
> // resource must be CURIE and therefore
> square brackets are used
> $rdfa_output .= "<div
> rel='".$property_output."'
> resource='[".$propvalue_output."]'>".$dv->getShortWikitext( true
> )."</div>\n";
>
> } else {
> //if the value of property is not a page
> $propvalue_output =
> $propvalue->getWikiValue();
> //property is enough:<span
> property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
> $rdfa_output .= "<div
> property='".$property_output."'>".$dv->getShortWikitext( true
)."</div>\n";
> }
> }
> $result = $rdfa_output;
> -----------------------------
>
> [3]-------------------------
> <div about="http://dbpedia.org/resource/Albert_Einstein";
> xmlns="http://www.w3.org/1999/xhtml";
xmlns:foaf="http://xmlns.com/foaf/0.1/";
> xmlns:dc="http://purl.org/dc/elements/1.1/";
> xmlns:dbp="http://www.dbpedia.org/";>
> <div property="foaf:name">
> Albert Einstein
> </div>
> <div property="dc:dateOfBirth" datatype="xsd:date">
> 1879-03-14
> </div>
> <div rel="dbp:birthPlace">
> <div about="http://dbpedia.org/resource/Germany";
> property="dbp:conventionalLongName">
> Federal Republic of Germany
> </div>
> </div>
> </div>
> -------------------------------
>
> --
> Karlsruhe Institute of Technology (KIT)
> Institute of Applied Informatics and Formal Description Methods (AIFB)
>
> Benedikt Kämpgen
> Research Associate
>
> Kaiserstraße 12
> Building 11.40
> 76131 Karlsruhe, Germany
>
> Phone: +49 721 608-47946 (!new since 1 January 2011!)
> Fax: +49 721 608-46580 (!new since 1 January 2011!)
> Email: benedikt.kaemp...@kit.edu
> Web: http://www.kit.edu/
>
> KIT University of the State of Baden-Wuerttemberg and
> National Research Center of the Helmholtz Association
>
>
> -----Original Message-----
> From: Markus Krötzsch [mailto:mar...@semantic-mediawiki.org]
> Sent: Friday, February 11, 2011 10:02 AM
> To: Benedikt Kaempgen
> Cc: jmccl...@hypergrove.com; smw dev list
> Subject: Re: [SMW-devel] Inline Editing Functionality by using RDFa
>
> On 11/02/2011 08:17, Benedikt Kaempgen wrote:
>> Hi,
>>
>> The RDFa extension is fine as long as you want the semantic information
as
> RDFa available somewhere on the page.
>>
>> With Inline Editing we mean to let users directly change annotations on
> the rendered page, which would be quite convenient. This is separate of
the
> goal of having RDFa descriptions on the page. However, you can bring both
> goals together:
>>
>> If the users simply change text on the rendered page, the system cannot
> know which (and whether at all an) annotation was changed. However, if the
> changed item is surrounded by RDFa tags, the system would know, what page
> and property to update and, for instance, could forward this to SMWWriter.
>
> Exactly. I hope that reduces John's confusion. One could also add that
> it would actually be nice to have the RDFa at the same place as the
> corresponding text, since there are some browser extensions that
> highlight RDFa data sources in the document (and IMHO the main point of
> RDFa is to embed facts into document context).
>
>
>>
>> So, my goal would be to have the RDFa integrated where possible (not the
> special cases, Yaron and Markus mentioned). I think, the values do not
need
> to carry the whole triple information. For property-value-pairs of the
page,
> the page would provide the subject URI (xml:base), the values would
provide
> the property and value, only. For property-value-pairs queried from other
> pages, the query could carry the subject URI, the values could carry the
> property and values. Is there a way to do this by an extension?
>>
>
> Good news:
> * There is one unique code place through which all data values that
> appear on the page are passing, and both property and value are known at
> this point.
>
> Bad news:
> * Everything that gets inserted at this stage must be allowed in
> MediaWiki (a little less, actually, since half of the parsing is already
> through).
>
> So injecting suitable RDFa into the output would work, but only if you
> can also find a secure way that would allow normal users to do so by
> writing wiki text. Of course, namespaces could be pre-declared in the
> header to simplify this (and to restrict to statements about the wiki).
> This may or may not be difficult to solve, but there should be some
> solution. Anyway, this would give you RDFa for all link-style
> annotations on a page (adding it to #set would be easy, too, but there
> is no context in the page in this case anyway). Of course, you could
> still only edit some of these instances with SMWWriter, and there is no
> easy way of identifying them when you create the output (during link
> parsing, all information about templates is already gone).
>
> Regards,
>
> Markus
>
>>
>> --
>> Karlsruhe Institute of Technology (KIT)
>> Institute of Applied Informatics and Formal Description Methods (AIFB)
>>
>> Benedikt Kämpgen
>> Research Associate
>>
>> Kaiserstraße 12
>> Building 11.40
>> 76131 Karlsruhe, Germany
>>
>> Phone: +49 721 608-47946 (!new since 1 January 2011!)
>> Fax: +49 721 608-46580 (!new since 1 January 2011!)
>> Email: benedikt.kaemp...@kit.edu
>> Web: http://www.kit.edu/
>>
>> KIT - University of the State of Baden-Wuerttemberg and
>> National Research Center of the Helmholtz Association
>>
>> -----Original Message-----
>> From: John McClure [mailto:jmccl...@hypergrove.com]
>> Sent: Friday, February 11, 2011 1:08 AM
>> To: 'Markus Krotzsch'; Benedikt Kaempgen
>> Cc: 'smw dev list'
>> Subject: RE: [SMW-devel] Inline Editing Functionality by using RDFa
>>
>> Hi,
>> This comment confuses me a bit! Extension:RDFa uses the requested page as
>> the subject; I don't see the need to incorporate Inline Editing for
> Special
>> Pages or queries. Maybe there is a problem with the RDFa extension?? I'd
>> like to know because I was hoping to use it in the very near future.
>> Thanks,
>> John
>>
>> -----Original Message-----
>> From: Markus Krotzsch [mailto:mar...@semantic-mediawiki.org]
>> Sent: Thursday, February 10, 2011 1:06 PM
>> To: Benedikt Kaempgen
>> Cc: smw dev list
>> Subject: Re: [SMW-devel] Inline Editing Functionality by using RDFa
>>
>>
>> On 10/02/2011 16:09, Benedikt Kaempgen wrote:
>>> Hello,
>>>
>>> I would like to add Inline Editing functionality to SMW, so that users
> can
>>> edit values of properties directly when clicking on them.
>>>
>>> One way to this would be to have some RDFa surrounding the annotations
so
>>> that after a user has changed the embedded html, a script in the back
>> would
>>> know from the RDFa which page and property to update.
>>>
>>> There is an RDFa extension, however, it does not embed the RDFa but only
>>> adds it to the beginning of the page, so that the html is not linked to
>> the
>>> actual properties.
>>>
>>> I was looking to either hook into the annotation parsers ([[...::...]]
> and
>>> {{#ask...}}) or the query parsers (SMWAsk class) to add the RDFa to the
>>> wikitext/html output, but both times didn't find a suitable place to add
>> the
>>> RDFa without editing SMW core.
>>>
>>> Any ideas and comments on this would be appreciated.
>>
>> Having optional RDFa embedding in pages would be nice. It should
>> normally be added when displaying values. Then the data would appear on
>> all pages where the values are shown, whether on special pages, in
>> queries, or on the page itself. This would be nice. The problem with
>> this is that the SMW value objects do not know their subject (they
>> sometimes know their property, for typing information, but never their
>> subject). And the way they are retrieved, it may even happen that they
>> do not have a subject in all cases (e.g. when you view all values of a
>> property, then one value may belong to many subjects). So not all places
>> really would allow for proper RDFa export in the end. I am also slightly
>> concerned about the change in data model that it would imply if we
>> generally would store whole triples in single values.
>>
>> But there is currently no SMW-internal representation of a "triple" for
>> representing wiki data -- everything is lists of properties and lists of
>> values. This makes it hard to find a good place to get the information
>> from for RDFa export in a universal sense (i.e. not just on pages). But
>> if we can live without this, then one could still enable RDFa embedding
>> on the pages where the data is originally given. This would probably not
>> be very useful, since the same page already has a link to the complete
>> RDF export, but who knows. Maybe some search engines like it ...
>>
>> After this, the problem is locating the right spot for making a change,
>> as mentioned by Yaron. This amounts to something that is similar to what
>> SMWWriter attempts to do (and does successfully in many cases). So I
>> think it would be feasible in some cases, but problematic in general.
>>
>> Regards,
>>
>> Markus
>>
>>
>
----------------------------------------------------------------------------
>> --
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>> _______________________________________________
>> Semediawiki-devel mailing list
>> Semediawiki-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>>
>>
>>
>>
>>
>
----------------------------------------------------------------------------
> --
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>>
>>
>>
>> _______________________________________________
>> Semediawiki-devel mailing list
>> Semediawiki-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
>
>
----------------------------------------------------------------------------
--
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
>
>
>
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
