On 10/31/2011 06:52 PM, Samuel Lampa wrote:
> === Q2: Status of SMWData/SMWDataItem as API? ===
>
> Also I wondered what status the SMWData/SMWDataItem classes are supposed
> to have, as a general API? ... Are they the supposed API, or is SMW
> going towards preferring to talk SPARQL with all extensions ... or even
> SMWExpElements?
>
> I ask this since it does not seem clear that I will really*need* to use
> the SMWData/SMWDataItem combo as a representation, if I do the wiki page
> updates either with the Wiki Object Model extension or an own writer class.
>
> I would still prefer to use it, if it is pushed as a preferred API for
> these kind of things, but I wondered whether that is so for the
> foreseeable future?
The thing that makes me wonder, is since we're basically talking about
two slightly different (though very much overlapping) representations:
RDF (as represented by SMWExpElement rel. classes), and Semantic
MediaWiki facts (as repr. by SMWData/SMWDataItem).
My problem, in the context of RDFIO, is that it seems I actually need
both of these to capture the information from both worlds ... since:
a. I need to store the URI:s, which only SMWExpElement classes do
b. I need to store the wiki page titles that I choose to use (as part of
RDFIO:s algorithm), which only the SMWData/SMWData combo does.
... thus it seems there's at least two options:
1. RDFIO creates an own more general data container, which wraps both
the SMWData/SMWDataItem one, and the RDF one (possibly both the
SMWExpElement one, and ARC2:s data structures), with in-built converters
between all of these,
2. SMWData/SMWDataItem classes are updated to contain the "Original
URI", and then this format will be the only needed one, in addition to
possibly the ARC2 format, just for making use of it's parsers.
Number one is the one I've been pondering so far ... I just wanted to
point out this now and ask whether there would be any interest in
storing also the original URI directly in the SMWData/SMWDataItem
classes ... (which would not need to be required, for data that has no
counterpart in the outside world, though ... or maybe can just be
prefilled with the URIResolver URI:s ... this maybe on-the-fly, in a
getter method)?
... it seems that would make the SMWData/SMWDI combo more general, and
of course would make RDFIO add a lot less overhead :")
(I know we discussed this on SMWCon already, but these things weren't
really that clear to me then, about the partly but not completely
overlap between RDF and SMW data representations ... so wanted to point
it out ... )
// Samuel
--
Samuel Lampa
---------------------------------------
Bioinformatician @ Uppsala University
Blog: http://saml.rilspace.org
---------------------------------------
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ now supports Android™ Apps
for the BlackBerry® PlayBook™. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
