Was I talkling gibberish or was the RDF export question too hard? :)

On Thu, Oct 13, 2011 at 2:47 AM, Yury Katkov <katkov.ju...@gmail.com> wrote:

> Hello Markus,
> First of all, your alternative proposal looks much better than the
> original one because of more flexibility. And praise you for the great
> solution of optional naming - I hope it will be possible to implement
> it!
>
> What about RDF export and Import vocabulary features? I have really
> two questions concerning both those features:
>
> == RDFExport+RDF store question==
>
>  As far I as I can see subobjects should be turned to the blank nodes,
> shouldn't they?
>
> == Import vocabulary question ==
>
> Is it possible to map the subobject to RDF  class? That can be
> extremely useful even in simple vocabularies like FOAF.
> Here is an example: we have the wiki-page of Yury who has an online
> account in two social networks: Facebook and Vkontakte.
>
> ===Example===
> It's pretty easy to describe this fact with subobjects:
> ##### PAGE STARTS#########
> Yury has [[has account::{{#subobject:
>                                       service=http://facebook.com
>                                       accountname=ganqqwerty}}
> |facebook account]],
>                [[has account:: {{#subobject:
>                                        service=vkontakte.ru
>                                         accountname=katkov}}
> |Vkontakte.ru account]]
> #####PAGE ENDS#########
> ===RDF Export===
> If I map has account to foaf:account, map service to uring rdf export
> we will get the following (simplified)
> :Yury_id_in_wiki                 foaf:account
>  :Yury_id_in_wiki#tmpnum1 .
> :Yury_id_in_wiki#tmpnum1  foaf:accountServiceHomepage <http://facebook.com
> >
> :Yury_id_in_wiki#tmpnum1 foaf:accountName                    "ganqqwerty"
> === Problem ===
> The problem is that the property foaf:account has range
> foaf:OnlineAccount. Our RDF export now is a little bit incomplete.
>
> ===Proposal===
>
> Make it possible to assign some kind of type to the subobject and map
> those types to RDFS or OWL classes. I honestly don't know how this can
> be done - probably with the special attribute "type" or "category".
>
> The typing can be needed now only in case of RDF export. If I have a
> wiki with thousands of subobjects it would always be nice to see what
> kind of subobjects are there.
>
>
> Anyway the subobject feature will help me to tie together a bundle of
> properties in Semantic Social Profile, for example Name of the country
> of living, Name of the city of living, Street, house number as well as
> Geographic coordinates of the place where the user lives.
>
> Sorry if was late fo the discussion,
> Yury
>
> On Mon, Oct 3, 2011 at 1:02 PM, Markus Krötzsch
> <mar...@semantic-mediawiki.org> wrote:
> >
> > Following up the discussions we had at SMWCon in Berlin, we have now
> > implemented a new feature for "internal objects" in SMW. This email
> > explains this feature and starts the discussion on some open questions
> > for it to become stable.
> >
> >
> > == Goal ==
> >
> > Allow SMW annotations to refer to objects that have their own
> > property-value pairs just like wiki pages, but that do not actually have
> > an article in the wiki. This can be used to "group" property-value pairs
> > given on one page without requiring new auxiliary pages to be created.
> > It also integrates the main functionality of the Semantic Internal
> > Objects (SIO) extension into SMW.
> >
> >
> > == Feature Overview: Current Prototype Implementation ==
> >
> > SMW now has a new "subobject" feature. For example, you can use the
> > parserfunction #subobject on some page "Example page" as follows:
> >
> > {{#subobject:street address
> > | street name=Parks Road
> > | postcode=OX1 3QD
> > | city=Oxford
> > | country=UK
> > }}
> >
> > This does the following:
> >
> > (A) create a new subobject called "Example page#_anInternalId",
> > (B) assign the property values for "street name", ..., "country" to this
> > subobject,
> > (C) assign the subobject "Example page#_anInternalId" as a property
> > value for "street address" to "Example page".
> >
> > You could have achieved a similar effect as follows:
> >
> > (A') create a new page called "my auxiliary page",
> > (B') edit this new page to contain the text:
> >
> >  [[street name::Parks Road]]
> >  [[postcode::OX1 3QD]]
> >  [[city::Oxford]]
> >  [[country::UK]]
> >
> > (C') edit the page "Example page" to contain the text:
> >
> >  [[street address::my auxiliary page]]
> >
> >
> > The difference when using #subobject is that you do not create a new
> > auxiliary page. Instead, a subobject of "Example page" is created by
> > SMW. Also, the function #subobject does not display anything unless an
> > error occurred that needs to be reported.
> >
> > Subobjects are named automatically by following the schema "Parent page
> > name#_someInternalId". When subobjects are displayed to users, they thus
> > appear like links to sections within their parent page. This can happen,
> > e.g., subobjects might occur in query results (example above: {{#ask:
> > [[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by
> > this name "Parent page name#_someInternalId" in all search and export
> > interfaces in SMW. For example, one can view the data for one particular
> > subobject in Special:Browse.
> >
> > In general, subobjects should work like normal pages in most SMW
> > interfaces. The goal of this naming is to avoid any clashes with real
> > pages and with real sections in real pages while still allowing the same
> > methods to be used.
> >
> > The feature can be tested in the current SVN version but it is still
> > unstable and might change significantly (read on).
> >
> >
> > == Relation to Semantic Internal Objects ==
> >
> > The feature is very similar to the SIO extension. The difference is that
> > in SIO, the main property ("street address" above) points from the
> > subobject to the parent page. In the above example, "street address"
> > really means "has street address" while in SIO it would be used like "is
> > street address of".
> >
> > The other difference is that subobjects work with both SQL and RDF
> > stores, are exported in RDF and are compatible with interfaces like
> > Special:Browse.
> >
> >
> > == Alternative Proposal ==
> >
> > Instead of having a parser function that creates a subobject and assigns
> > it to a property as a value, one could also have a parser function that
> > only does the first thing and that *returns* a subobject for later use.
> > This would require some further changes but it might be more elegant.
> >
> > For example, a call like
> >
> > {{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }}
> >
> > would just "create" such an object and return its name (e.g.
> > "Example_page#_someId"). Then one could use this name as a value to
> > other properties, e.g.:
> >
> > [[street address::{{#subobject: street name=Parks Road
> >     | postcode=OX1 3QD
> >     | city=Oxford
> > }}]]
> >
> > One advantage of this is that one could arbitrarily nest subobjects,
> > i.e. use subobjects as property values when declaring other subobjects
> > (SMW can already do this, just the input syntax does not support it).
> > Another advantage is that subobjects could (optionally) be named instead
> > of using the name generated by SMW now. For example, one could have
> >
> > {{#subobject:department_address
> >   |street name=Parks Road | postcode=OX1 3QD| city=Oxford }}
> >
> > to create a subobject called "Example page#department_address" which
> > could be used in other annotations on *any* page (this is already
> > possible with subobjects now, but since their names are generated by SMW
> > they might not be stable over time). In this case, it might be less
> > desirable to return the name of the subobject.
> >
> > Overall, this alternative approach would allow subobjects to be used as
> > first-class citizens of the SMW data space instead of viewing them as
> > auxiliary objects for encoding compound property values.
> >
> >
> > == Request for Comments ==
> >
> > Feedback is welcome. The first question is which approach to subobjects
> > should eventually be used. The follow-up question is how the respective
> > parser function should be called. But there might also be completely
> > different comments and questions.
> >
> >
> > Cheers,
> >
> > Markus
> >
> >
> >
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure contains a
> > definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and makes
> > sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Semediawiki-devel mailing list
> > Semediawiki-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
>
> --
> Yury V. Katkov
> WikiVote! llc
>



-- 
Yury V. Katkov
WikiVote! llc
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

Reply via email to