SMW Ontologies

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

SMW Ontologies

John McClure
Excellent support for semantic ontologies is fundamental to achieving
SMW's core mission -- I hope we agree about this!
Because with this goal in mind, how about an extension that does this:

 1. provides visual tools for creating inspecting & validating ontologies
    --  upgrade Halo's OntologyBrowser to MW 1.23 level as a baseline
 2. installs/pre-defines standard and or organization-specific ontologies
    -- bootstrap developers & users by hostng popular and "best
    practice" ontologies as natively as possible
 3. validates/stores and retrieves property values with faster parser
    functions
    -- allow overrides by slower Template:(dot)<ns>:<pgnm> transclusions
    for customizations
    -- bake superclass & superproperty relations into PHP code
    -- provide for translated class and property names/references via
    i18n facility
    -- maintain an on-page topic map, ie an index/navigation-map of a
    page's redirects relations subobjects and subpages
 4. adheres to model-view-controller pattern to bundle
    facts-views-provenance triplets about/on a page
    -- a 'semantic' parser function (or template) is the controller, its
    behavior somehow filtered by the page's provenance info
    -- all systemic pages are named as <page-type>:_<page-name>, eg
    :Signature:_John Henry and :Person:_John Henry
    -- resource forms are generally a redirect to a common form, since
    page-type is derivable from a pagename or its mw namespace
 5. seeks to integrate MW-Search and MW-Translation extensions with SMW
    -- leverage multi-lingual translation units & SOLR indexing model as
    low-level text subobjects (snaks?)
    -- create translation units for text and page property values

*Would such an extension be welcomed by the SMW community?*

An example pre-fill for a semantic page with a call to the 'semantic'
template/parser-function call, is below. Editors add to these.
{{semantic
|provs={{dc:coverage|{{.mw:namespace}}}}{{dc:title|@=en|@en={{.mw:title}}}}
|facts= <!-- add here, eg {{skos:altLabel|@en=some-alias}} -->
|views=<table><tr><td>{{infobox: {{.dc:type}}}}</td></tr></table>
}}

Two approaches come to mind when crafting a single, common form to
collect ontology-compliant data:
(a) with one 'smart' textarea for the {{semantic}} call, auto-completing
per ontology, page-type and property facet
(b) heavily use SF's embedded templates -- though (I've experienced) SF
limits the nbr of embedded templates allowed

With regard to which ontologies are included, I suggest rationalizing these:

  * MW & SMW -- root ontologies, re-implementing each class/property
    with a proper namespace prefix, eg mw: and smw:
  * W3 -- XML/S, XSL, RDF, OWL, SKOS, Datacube, PROVenance, FOAF, ...
  * UN/ISO -- geographic, physical & economic measures, languages,
    currencies, topic maps, ...
  * Others - DCMI, SOLR, Halo, SBVR and Hypergrove Ontology (see below), ...

By 'rationalizing' I mean identifying equivalence, subclass &
subproperty relations between all ontologies' definitions

Controlling design is the Hypergrove Ontology
-- has properties of the form /verb:preposition/ and /verb:indicative/,
e.g. "is:from", "is:at", "was:a", "has:this", "had:that", "has:a",
"has:some"
-- has singular/plural nouns defined in Concept/Category namespaces,
e.g. "Concept:Person" filters "Category:Persons"
-- has past-participles, adverbs and adjectives in a "Tag"
namespace-alias (to Category), eg "Tag:Untyped", "Tag:Frequently", "Tag:Red"
-- has certan pronouns (who, which, what, why, etc) at the base of noun
taxonomy
Requires initial lower-case property names e.g., Property:dc:type, /not
/Property:Dc:type
All predefined properties are defined as 'special' properties?

*Would this extension be welcomed by the SMW community?*
Which parts are agreeable or disagreeable to you?
Thank you for your comments!
/john
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: SMW Ontologies

Krabina Bernhard
Hi John,

as a long term user of SMW (I started in 2006), I never ran across a use case where ontologies were an issue. The benefit of SMW+ was always to support use cases, where eihter existing ontologies have to be re-used or new ones have to be discovered/built up. These use cases can be found in the scientific community mainly, I think.

In my use cases, I never had to care about ontologies, RDF or triple stores. These come as a benefit to a very flexible web database system that SMW is.

As much as I like the idea of having some of the features back that SMW+ provided, as much I have to admit that I don't really have these ontology-focuced use cases in sight.

cheers,
Bernhard

----- Am 14. Jan 2015 um 23:48 schrieb jmcclure [hidden email]:

> Excellent support for semantic ontologies is fundamental to achieving
> SMW's core mission -- I hope we agree about this!
> Because with this goal in mind, how about an extension that does this:
>
> 1. provides visual tools for creating inspecting & validating ontologies
>    --  upgrade Halo's OntologyBrowser to MW 1.23 level as a baseline
> 2. installs/pre-defines standard and or organization-specific ontologies
>    -- bootstrap developers & users by hostng popular and "best
>    practice" ontologies as natively as possible
> 3. validates/stores and retrieves property values with faster parser
>    functions
>    -- allow overrides by slower Template:(dot)<ns>:<pgnm> transclusions
>    for customizations
>    -- bake superclass & superproperty relations into PHP code
>    -- provide for translated class and property names/references via
>    i18n facility
>    -- maintain an on-page topic map, ie an index/navigation-map of a
>    page's redirects relations subobjects and subpages
> 4. adheres to model-view-controller pattern to bundle
>    facts-views-provenance triplets about/on a page
>    -- a 'semantic' parser function (or template) is the controller, its
>    behavior somehow filtered by the page's provenance info
>    -- all systemic pages are named as <page-type>:_<page-name>, eg
>    :Signature:_John Henry and :Person:_John Henry
>    -- resource forms are generally a redirect to a common form, since
>    page-type is derivable from a pagename or its mw namespace
> 5. seeks to integrate MW-Search and MW-Translation extensions with SMW
>    -- leverage multi-lingual translation units & SOLR indexing model as
>    low-level text subobjects (snaks?)
>    -- create translation units for text and page property values
>
> *Would such an extension be welcomed by the SMW community?*
>
> An example pre-fill for a semantic page with a call to the 'semantic'
> template/parser-function call, is below. Editors add to these.
> {{semantic
>|provs={{dc:coverage|{{.mw:namespace}}}}{{dc:title|@=en|@en={{.mw:title}}}}
>|facts= <!-- add here, eg {{skos:altLabel|@en=some-alias}} -->
>|views=<table><tr><td>{{infobox: {{.dc:type}}}}</td></tr></table>
> }}
>
> Two approaches come to mind when crafting a single, common form to
> collect ontology-compliant data:
> (a) with one 'smart' textarea for the {{semantic}} call, auto-completing
> per ontology, page-type and property facet
> (b) heavily use SF's embedded templates -- though (I've experienced) SF
> limits the nbr of embedded templates allowed
>
> With regard to which ontologies are included, I suggest rationalizing these:
>
>  * MW & SMW -- root ontologies, re-implementing each class/property
>    with a proper namespace prefix, eg mw: and smw:
>  * W3 -- XML/S, XSL, RDF, OWL, SKOS, Datacube, PROVenance, FOAF, ...
>  * UN/ISO -- geographic, physical & economic measures, languages,
>    currencies, topic maps, ...
>  * Others - DCMI, SOLR, Halo, SBVR and Hypergrove Ontology (see below), ...
>
> By 'rationalizing' I mean identifying equivalence, subclass &
> subproperty relations between all ontologies' definitions
>
> Controlling design is the Hypergrove Ontology
> -- has properties of the form /verb:preposition/ and /verb:indicative/,
> e.g. "is:from", "is:at", "was:a", "has:this", "had:that", "has:a",
> "has:some"
> -- has singular/plural nouns defined in Concept/Category namespaces,
> e.g. "Concept:Person" filters "Category:Persons"
> -- has past-participles, adverbs and adjectives in a "Tag"
> namespace-alias (to Category), eg "Tag:Untyped", "Tag:Frequently", "Tag:Red"
> -- has certan pronouns (who, which, what, why, etc) at the base of noun
> taxonomy
> Requires initial lower-case property names e.g., Property:dc:type, /not
> /Property:Dc:type
> All predefined properties are defined as 'special' properties?
>
> *Would this extension be welcomed by the SMW community?*
> Which parts are agreeable or disagreeable to you?
> Thank you for your comments!
> /john
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Semediawiki-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: SMW Ontologies

planetenxin
I agree with Bernhard. Even if you are working implicit with ontologies
in SMW, this is not comparable to "classical" ontology engineering with
OWL, RDF(S) and so on.

SMW's intention is to be a lightweight semantic wiki hiding most of the
ontology specific issues from users. And, from my point of view, it does
this job very well. This is the reason why we at gesinn.it use SMW for
years now in our enterprise solutions.

If you are looking for a more "standard compliant" tool, i recommend
having a look at fluidops Information Workbench [1] that is available as
Community Edition. IWB natively supports OWL, RDF, SPARQL, Sesame-API.

[1]
http://www.fluidops.com/en/portfolio/information_workbench/how_does_it_work

/Alexander

> Hi John,
>
> as a long term user of SMW (I started in 2006), I never ran across a use case where ontologies were an issue. The benefit of SMW+ was always to support use cases, where eihter existing ontologies have to be re-used or new ones have to be discovered/built up. These use cases can be found in the scientific community mainly, I think.
>
> In my use cases, I never had to care about ontologies, RDF or triple stores. These come as a benefit to a very flexible web database system that SMW is.
>
> As much as I like the idea of having some of the features back that SMW+ provided, as much I have to admit that I don't really have these ontology-focuced use cases in sight.
>
> cheers,
> Bernhard


--
________________________________________________
semantic::apps by gesinn.it
Business Applications with Semantic Mediawiki.
http://semantic-apps.com

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: SMW Ontologies

Schneider, Martin
In reply to this post by John McClure
For now, I only want to say that all my use cases are ontology-related, so it would be good to have better support there.

But I cannot say if the points from your message, John, are those which are of importance.
I don't even see how this would ease building ontologies in SMW.

But then I'm rather new to this topic (both semantic knowledge engineering and SMW).

What I am missing most is something like an IDE for SMW, like Eclipse for Java.

I'll stay tuned to this topic.

Cheers, Martin



-----Ursprüngliche Nachricht-----
Von: John McClure [mailto:[hidden email]]
Gesendet: Mittwoch, 14. Januar 2015 23:49
An: SMW user list
Betreff: [Semediawiki-user] SMW Ontologies

Excellent support for semantic ontologies is fundamental to achieving SMW's core mission -- I hope we agree about this!
Because with this goal in mind, how about an extension that does this:

 1. provides visual tools for creating inspecting & validating ontologies
    --  upgrade Halo's OntologyBrowser to MW 1.23 level as a baseline  2. installs/pre-defines standard and or organization-specific ontologies
    -- bootstrap developers & users by hostng popular and "best
    practice" ontologies as natively as possible  3. validates/stores and retrieves property values with faster parser
    functions
    -- allow overrides by slower Template:(dot)<ns>:<pgnm> transclusions
    for customizations
    -- bake superclass & superproperty relations into PHP code
    -- provide for translated class and property names/references via
    i18n facility
    -- maintain an on-page topic map, ie an index/navigation-map of a
    page's redirects relations subobjects and subpages  4. adheres to model-view-controller pattern to bundle
    facts-views-provenance triplets about/on a page
    -- a 'semantic' parser function (or template) is the controller, its
    behavior somehow filtered by the page's provenance info
    -- all systemic pages are named as <page-type>:_<page-name>, eg
    :Signature:_John Henry and :Person:_John Henry
    -- resource forms are generally a redirect to a common form, since
    page-type is derivable from a pagename or its mw namespace  5. seeks to integrate MW-Search and MW-Translation extensions with SMW
    -- leverage multi-lingual translation units & SOLR indexing model as
    low-level text subobjects (snaks?)
    -- create translation units for text and page property values

*Would such an extension be welcomed by the SMW community?*

An example pre-fill for a semantic page with a call to the 'semantic'
template/parser-function call, is below. Editors add to these.
{{semantic
|provs={{dc:coverage|{{.mw:namespace}}}}{{dc:title|@=en|@en={{.mw:title}
|}}} facts= <!-- add here, eg {{skos:altLabel|@en=some-alias}} -->
|views=<table><tr><td>{{infobox: {{.dc:type}}}}</td></tr></table>
}}

Two approaches come to mind when crafting a single, common form to collect ontology-compliant data:
(a) with one 'smart' textarea for the {{semantic}} call, auto-completing per ontology, page-type and property facet
(b) heavily use SF's embedded templates -- though (I've experienced) SF limits the nbr of embedded templates allowed

With regard to which ontologies are included, I suggest rationalizing these:

  * MW & SMW -- root ontologies, re-implementing each class/property
    with a proper namespace prefix, eg mw: and smw:
  * W3 -- XML/S, XSL, RDF, OWL, SKOS, Datacube, PROVenance, FOAF, ...
  * UN/ISO -- geographic, physical & economic measures, languages,
    currencies, topic maps, ...
  * Others - DCMI, SOLR, Halo, SBVR and Hypergrove Ontology (see below), ...

By 'rationalizing' I mean identifying equivalence, subclass & subproperty relations between all ontologies' definitions

Controlling design is the Hypergrove Ontology
-- has properties of the form /verb:preposition/ and /verb:indicative/, e.g. "is:from", "is:at", "was:a", "has:this", "had:that", "has:a", "has:some"
-- has singular/plural nouns defined in Concept/Category namespaces, e.g. "Concept:Person" filters "Category:Persons"
-- has past-participles, adverbs and adjectives in a "Tag"
namespace-alias (to Category), eg "Tag:Untyped", "Tag:Frequently", "Tag:Red"
-- has certan pronouns (who, which, what, why, etc) at the base of noun taxonomy Requires initial lower-case property names e.g., Property:dc:type, /not /Property:Dc:type All predefined properties are defined as 'special' properties?

*Would this extension be welcomed by the SMW community?* Which parts are agreeable or disagreeable to you?
Thank you for your comments!
/john
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: SMW Ontologies

John McClure
Thanks Martin for your thoughtful reply.
I agree completely that an IDE for SMW would be measurably useful to
developers and editors (eschewing the term 'user' here, per standard MW
definition that a user is someone with 'read' privledge on a wiki, not
necessarily 'edit' privledge) for obvious reasons: faster, better,
cheaper. But let's also note that by focusing our development efforts on
SMW's core mission -- semantic queries, in large part -- then we
strengthen the long-term business case for SMW itself.

SMW Ontologies /is/ an IDE (I will use these magic words in the
future!). From Wikipedia, an "IDE normally consists of a (1) source code
editor (2) build automation tools and (3) a debugger. Most modern IDEs
have (4) intelligent code completion .... Some IDEs contain a (5)
compiler, interpreter, or both ... (6) a version control system and (7)
various tools are integrated to simplify the construction of a Graphical
User Interface. Many modern IDEs also have (8) a class browser, (9) an
object browser, and (10) a class hierarchy diagram, for use in
object-oriented software development." [footnote 1]

Let's compare this definition of an IDE to what I propose.

 1. source code editor -- a 'smart textarea' is proposed to enter
    template calls for storing semantic triples
 2. build tools -- not needed in interpreted environs like PHP,
    Javascript, Parsoid and template-script
 3. debugger --templates and php code have a debug mode of output,
    storing validation errors on a page
 4. intelligent code completion -- the smart textarea would have this
    for property values & facets selection
 5. interpreter -- not an initial focus, though I envision a
    topic-map-syntax interpreter at a later time
 6. version control -- achieved per namespace prefixes -- eg owl: vs
    owl2: -- a central idea of proposal
 7. GUI builder tools -- data retrieval/formatting templates are parts
    of this proposal, plus infoboxes
 8. class browser -- this is the OntologyBrowser I mentioned
 9. object browser -- this is the OntologyBrowser I mentioned
10. class hierarchy -- this is the sum total of the numerous ontologies
    I indicated are to be installable

I want to see more than the dozen or so properties now (pitifully)
built-in to SMW; I insist on a full dictionary.
I want to make life alot easier for people crafting (semantic)
applications using SEMANTIC MediaWiki.

Hopefully my comparison clarifies that I also want to see an IDE come of
this.

thanks/john

[footnote 1] source:
http://en.wikipedia.org/wiki/Integrated_development_environment - i've
added enumerators to the quote

------------------------------------------------------------------------
On 1/15/2015 1:30 AM, Schneider, Martin wrote:

> For now, I only want to say that all my use cases are ontology-related, so it would be good to have better support there.
>
> But I cannot say if the points from your message, John, are those which are of importance.
> I don't even see how this would ease building ontologies in SMW.
>
> But then I'm rather new to this topic (both semantic knowledge engineering and SMW).
>
> What I am missing most is something like an IDE for SMW, like Eclipse for Java.
>
> I'll stay tuned to this topic.
>
> Cheers, Martin

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: SMW Ontologies

Fannon
In reply to this post by Schneider, Martin
Using an IDE / Editor for developing SMW models was an appealing idea to
me, too. Scratching my own itch, I've built a prototype Model Driven
Engineering Tool, called mobo (https://www.npmjs.com/package/mobo). Please
note that it's currently built for my own use and purposes and definitely
not stable yet.

It it much simpler in scope than your proposal (it ditches ontologies
completely, and uses a very simple object/document oriented inheritance
model), and this was a design decision. But you can use your editor,
Version Control and it has basic browsing / validating capabilities.

Bernhard and Alexander already mentioned that: Ontologies are rather
complex and the nice thing about SMW is that it hides this complexity while
still providing "basic" Semantic Web Capabilities.

What you're suggestion sound quite capable and much more aligned to current
Semantic Web Research. Have you taken a look at OntoWiki? (
http://aksw.org/Projects/OntoWiki.html). They are by no means as widely
used as SMW but they have a much higher focus on beeing "full semantic web
complient". (And I'd argue that this is exactly the reason it's not as
widely used)

Best,
Simon

2015-01-15 10:30 GMT+01:00 Schneider, Martin <[hidden email]>:

> For now, I only want to say that all my use cases are ontology-related, so
> it would be good to have better support there.
>
> But I cannot say if the points from your message, John, are those which
> are of importance.
> I don't even see how this would ease building ontologies in SMW.
>
> But then I'm rather new to this topic (both semantic knowledge engineering
> and SMW).
>
> What I am missing most is something like an IDE for SMW, like Eclipse for
> Java.
>
> I'll stay tuned to this topic.
>
> Cheers, Martin
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: John McClure [mailto:[hidden email]]
> Gesendet: Mittwoch, 14. Januar 2015 23:49
> An: SMW user list
> Betreff: [Semediawiki-user] SMW Ontologies
>
> Excellent support for semantic ontologies is fundamental to achieving
> SMW's core mission -- I hope we agree about this!
> Because with this goal in mind, how about an extension that does this:
>
>  1. provides visual tools for creating inspecting & validating ontologies
>     --  upgrade Halo's OntologyBrowser to MW 1.23 level as a baseline  2.
> installs/pre-defines standard and or organization-specific ontologies
>     -- bootstrap developers & users by hostng popular and "best
>     practice" ontologies as natively as possible  3. validates/stores and
> retrieves property values with faster parser
>     functions
>     -- allow overrides by slower Template:(dot)<ns>:<pgnm> transclusions
>     for customizations
>     -- bake superclass & superproperty relations into PHP code
>     -- provide for translated class and property names/references via
>     i18n facility
>     -- maintain an on-page topic map, ie an index/navigation-map of a
>     page's redirects relations subobjects and subpages  4. adheres to
> model-view-controller pattern to bundle
>     facts-views-provenance triplets about/on a page
>     -- a 'semantic' parser function (or template) is the controller, its
>     behavior somehow filtered by the page's provenance info
>     -- all systemic pages are named as <page-type>:_<page-name>, eg
>     :Signature:_John Henry and :Person:_John Henry
>     -- resource forms are generally a redirect to a common form, since
>     page-type is derivable from a pagename or its mw namespace  5. seeks
> to integrate MW-Search and MW-Translation extensions with SMW
>     -- leverage multi-lingual translation units & SOLR indexing model as
>     low-level text subobjects (snaks?)
>     -- create translation units for text and page property values
>
> *Would such an extension be welcomed by the SMW community?*
>
> An example pre-fill for a semantic page with a call to the 'semantic'
> template/parser-function call, is below. Editors add to these.
> {{semantic
> |provs={{dc:coverage|{{.mw:namespace}}}}{{dc:title|@=en|@en={{.mw:title}
> |}}} facts= <!-- add here, eg {{skos:altLabel|@en=some-alias}} -->
> |views=<table><tr><td>{{infobox: {{.dc:type}}}}</td></tr></table>
> }}
>
> Two approaches come to mind when crafting a single, common form to collect
> ontology-compliant data:
> (a) with one 'smart' textarea for the {{semantic}} call, auto-completing
> per ontology, page-type and property facet
> (b) heavily use SF's embedded templates -- though (I've experienced) SF
> limits the nbr of embedded templates allowed
>
> With regard to which ontologies are included, I suggest rationalizing
> these:
>
>   * MW & SMW -- root ontologies, re-implementing each class/property
>     with a proper namespace prefix, eg mw: and smw:
>   * W3 -- XML/S, XSL, RDF, OWL, SKOS, Datacube, PROVenance, FOAF, ...
>   * UN/ISO -- geographic, physical & economic measures, languages,
>     currencies, topic maps, ...
>   * Others - DCMI, SOLR, Halo, SBVR and Hypergrove Ontology (see below),
> ...
>
> By 'rationalizing' I mean identifying equivalence, subclass & subproperty
> relations between all ontologies' definitions
>
> Controlling design is the Hypergrove Ontology
> -- has properties of the form /verb:preposition/ and /verb:indicative/,
> e.g. "is:from", "is:at", "was:a", "has:this", "had:that", "has:a",
> "has:some"
> -- has singular/plural nouns defined in Concept/Category namespaces, e.g.
> "Concept:Person" filters "Category:Persons"
> -- has past-participles, adverbs and adjectives in a "Tag"
> namespace-alias (to Category), eg "Tag:Untyped", "Tag:Frequently",
> "Tag:Red"
> -- has certan pronouns (who, which, what, why, etc) at the base of noun
> taxonomy Requires initial lower-case property names e.g., Property:dc:type,
> /not /Property:Dc:type All predefined properties are defined as 'special'
> properties?
>
> *Would this extension be welcomed by the SMW community?* Which parts are
> agreeable or disagreeable to you?
> Thank you for your comments!
> /john
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Semediawiki-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Semediawiki-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: SMW Ontologies

John McClure
Hi Simon,

On 1/18/2015 12:15 AM, Simon Heimler wrote:

> Using an IDE / Editor for developing SMW models was an appealing idea
> to me, too. Scratching my own itch, I've built a prototype Model
> Driven Engineering Tool, called mobo
> (https://www.npmjs.com/package/mobo). Please note that it's currently
> built for my own use and purposes and definitely not stable yet.
>
> It it much simpler in scope than your proposal (it ditches ontologies
> completely, and uses a very simple object/document oriented
> inheritance model), and this was a design decision. But you can use
> your editor, Version Control and it has basic browsing / validating
> capabilities.
Not one to ditch ontologies, rather I appreciate their strengths during
the develoment process and beyond.
SMWOntologies is meant to speed applications development, it's a body of
practical knowledge and best practices to pre-fill an 'empty' smw
installation.
> Bernhard and Alexander already mentioned that: Ontologies are rather
> complex and the nice thing about SMW is that it hides this complexity
> while still providing "basic" Semantic Web Capabilities.
yes, smw hides the complexity of triples for those going
/template-names/ --> /form-names/ --> /property-names/. SMWOntologies is
about equipping a semantic wiki with namespace-qualified property names,
so the possibility is to go /property-names/ --> /template-names/ -->
/form-names/.  This latter approach informs/improves the former by
providing a robust dictionary of built-in class & property definitions
that can be used 'off the shelf'; or as super-classes or
super-properties; or as REDIRECT targets for an organization's elements.
> What you're suggestion sound quite capable and much more aligned to
> current Semantic Web Research. Have you taken a look at OntoWiki?
> (http://aksw.org/Projects/OntoWiki.html). They are by no means as
> widely used as SMW but they have a much higher focus on beeing "full
> semantic web complient". (And I'd argue that this is exactly the
> reason it's not as widely used)
Maybe but regardless my focus is on SMW nothing more than to improve SMW
so that it's easier for everyone.

Please remember that "ontologies" are fast-becoming the only thing to
distinguish SMW from Wikibase or Cargo.
If we ignore or don't do ontologies, then what's the point of using SMW?
Maybe you can cite some other SMW function we should beef up instead/too.
>
> Best,
> Simon

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

[SMWO] namespace: pagetype: pagename

John McClure
In reply to this post by Fannon
SMW Ontologies (SMWO) is based in part on the page-naming scheme

    wiki-namespace: pagetype: pagename

Note the _space after each colon_.  A prime advantage of this scheme is
to enable query selections forgoing examination of the set of categories
associated with a page - much faster. Other advantages include improved
& natural user comprehension of one's semantic models; easier to locate
pages of a type in AllPages; easier to move pages to/from dedicated wiki
namespaces; easier to "re-type" pages; and, very importantly, we can
automate form selection for a red-link page based on the name of the
page to create, not on the property by which it is associated to some
other page.

To-date a page's namespace has served exactly this purpose: a
Template:Page123 is clearly seen to be a template, Help:Page123 is seen
as help information, Category:Page123 is a category. The same approach
is here extended to all pages most particularly those in the Main
namespace. The 'type' of a page has a deeper use, too, as it relates to
the topic of a page, eg "Person: Someone" is distinct from "Education:
Someone" the latter containing content/triples about topic Education for
Someone -- a configuration necessary when the pages' input forms for
example are to be separately implemented or used; when a combined
datamodel is unwieldy or not possible; or when there are too many
triples to be stored should they be combined on a single page. Another
example is the need to show an image for a given page which, by this
scheme, would be implemented as File:Page123 being displayed for Page123
-- no triples lookup required at all, much faster. I call these
"affinity pages" in that they form a network of information about a
given key-title to the extent one exists in an smw-wiki, expecting it to
ultimately have impacts on page tools across the board.

With this in mind below is a proposal for semantics of some basic
elements in selected ontologies. (Note that an 'smw' ontology is
proposed which initially contains two properties.) These properties are
set by a template with the same name as the property eg {{rdf:ID}}, that
stores values in the property named 'rdf:ID'. Paired with each so-named
templates are "dot-templates" which return formatted value(s) of a
specific property, eg {{.rdf:ID}} returns the value of the 'rdf:ID'
property for the page.

      * *Property: smw:PAGENAME* = a page's pagename without either its
        namespace or pagetype, for displays. default: {{.semantic}}
      * *Property: smw:FULLPAGENAME* = a page's name (without namespace)
        for queries by pagetype &or pagename. default:{{PAGENAME}}
      * *Property: iso:name* = argument to {{DISPLAYTITLE:}} that can be
        language-specific. default: {{PAGENAME}}
      * *Property: ***iso*:variant* = names of pages that (could/do)
        #REDIRECT to the page. default: {{PAGENAME}}
      * *Property: dc:title* = language specific citation-ready titles
        for the page. default: {{.xtm:name}}
      * *Property: skos:prefLabel* = language specific common titles for
        the page. default: {{.dc:title}}
      * *Property: skos:altLabel* = language specific nicknames and
        abbreviations for the page. default:none

    Page categories are split into groups. {{PAGETYPE}} is a new magic
    word derived from parsing a pagename. The *Subject*, *Tag* and
    *Type* pagetypes referenced below are initially implemented as
    aliases of the Category namespace (note: rename SMW's "Type"
    namespace to *Datatype*) though one more of these three may be
    migrated to the Concept namespace in the future.

      * *Property: ***iso*:isa *= the page's pagetype category, normally
        a *Type* page. default: {{PAGETYPE}}
      * *Property: rdf:type* = overriding category(s) generated for the
        page's RDF datastream, normally a *Type* page. default: {{.iso:isa}}
      * *Property: rdfs:label* = language specific class name of a page.
        default: {{PAGETYPE}}
      * *Property: dc:type *= library media-type category of the page
      * *Property: dc:format *= descriptive/status categories
        (adjectives, past-participals), normally *Tag* pages. default:none
      * *Property: dc:subject *= search-keyword categories, often each a
        *Subject***page.y**default:none
      * *Property: skos:broader *= container categories, often each a
        *Subject *page.**default: {{.dc:subject}}

    Identifier properties are

      * Use *Property: ***iso*:subjectIdentifier* for the page's public
        topic map identifier. default: tbd
      * Use *Property: dc:identifier* for one or more (qualified,
        public) identifiers including urls
      * Use *Property: rdf:ID* for overriding the ID generated for the
        page's RDF Description. default: #{{FULLPAGENAMEE}}
      * Use *Property: xml:id* for overriding the id generated for a
        page's XML datastream. default: {{FULLPAGENAMEE}}

My objective here is to solicit your comments about this approach that
improve it. I realize that the barest of information for each property's
semantic is provided this moment but more will be released in near future.
thanks/john
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: SMW Ontologies

Fannon
In reply to this post by John McClure
Hello John,

Please remember that "ontologies" are fast-becoming the only thing to
> distinguish SMW from Wikibase or Cargo.
> If we ignore or don't do ontologies, then what's the point of using SMW?


​I don't think that Wikibase is an alternative to MediaWiki, since it's got
a very strict approach and is rather like managing a database. ​How it
fares against Cargo is a whole different issue ;) It would be very
interesting to have some data/statistics on how SMW is actually used (how
many people are using a SPARQL endpoint for example)

​But you're right, SMW could improve it's profile here.

Here are some ideas:

   - Your IDE/Ontology developing approach makes definately sense to me.
   It's a complex project and I wouldn't expect that too many people have the
   need for full ontologies. But if the project manages to make setting up
   your structure faster / more convenient and consistent, people will likely
   use it. I agree that ontologies are powerful, but they are also somewhat
   counter-intuitive at first contact. So having a good tool that helps
   creating them is crucial.
   - I've thought about having something like a "fact adder" additionally
   to SemanticForms / Source Editor. It could be as easy as having two fields.
   The first one autocompletes on all available attributes, the second one
   takes the value (single or multiple) and basic validation. That feature
   could fit in both with SemanticForms (producing a visible fact table) or
   the VisualEditor (annotating text).
   This would actively demonstrate the ability of SMW to handle very
   flexible, unpredicted data, because of the RDF/Graph data structure behind.
   - That said, graph-databases / structures gain popularity the last
   years. SMW has that capability from start. Maybe it would be an good idea
   to demonstrate and "advertise" that?
   - I would say that the RDF data structure, it's open W3C standard and
   good interoperability (linked-open-data, global knowledge graph) are the
   main argument for SMW. Improving the Semantic Web capabilities (even only
   under the hood) would be great here.

regards,
Simon

2015-01-22 23:20 GMT+01:00 John McClure <[hidden email]>:

>  Hi Simon,
>
> On 1/18/2015 12:15 AM, Simon Heimler wrote:
>
>  Using an IDE / Editor for developing SMW models was an appealing idea to
> me, too. Scratching my own itch, I've built a prototype Model Driven
> Engineering Tool, called mobo (https://www.npmjs.com/package/mobo).
> Please note that it's currently built for my own use and purposes and
> definitely not stable yet.
>
>  It it much simpler in scope than your proposal (it ditches ontologies
> completely, and uses a very simple object/document oriented inheritance
> model), and this was a design decision. But you can use your editor,
> Version Control and it has basic browsing / validating capabilities.
>
> Not one to ditch ontologies, rather I appreciate their strengths during
> the develoment process and beyond.
> SMWOntologies is meant to speed applications development, it's a body of
> practical knowledge and best practices to pre-fill an 'empty' smw
> installation.
>
>  Bernhard and Alexander already mentioned that: Ontologies are rather
> complex and the nice thing about SMW is that it hides this complexity while
> still providing "basic" Semantic Web Capabilities.
>
> yes, smw hides the complexity of triples for those going *template-names*
> --> *form-names* --> *property-names*.  SMWOntologies is about equipping
> a semantic wiki with namespace-qualified property names, so the possibility
> is to go *property-names* --> *template-names* --> *form-names*.  This
> latter approach informs/improves the former by providing a robust
> dictionary of built-in class & property definitions that can be used 'off
> the shelf'; or as super-classes or super-properties; or as REDIRECT targets
> for an organization's elements.
>
>  What you're suggestion sound quite capable and much more aligned to
> current Semantic Web Research. Have you taken a look at OntoWiki? (
> http://aksw.org/Projects/OntoWiki.html). They are by no means as widely
> used as SMW but they have a much higher focus on beeing "full semantic web
> complient". (And I'd argue that this is exactly the reason it's not as
> widely used)
>
> Maybe but regardless my focus is on SMW nothing more than to improve SMW
> so that it's easier for everyone.
>
> Please remember that "ontologies" are fast-becoming the only thing to
> distinguish SMW from Wikibase or Cargo.
> If we ignore or don't do ontologies, then what's the point of using SMW?
> Maybe you can cite some other SMW function we should beef up instead/too.
>
>
>  Best,
> Simon
>
>
>
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: SMW Ontologies

James HK
Dear all,

I haven't followed this thread in detail but I saw Simon made some
interesting points and while an email discussion can spark ideas and
allow a topic to evolve it is a rather difficult format to create
actionable tasks. I hope in the interest of all that [0] can be used
to gather and condense ideas.

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/757

Cheers

On 1/24/15, Simon Heimler <[hidden email]> wrote:

> Hello John,
>
> Please remember that "ontologies" are fast-becoming the only thing to
>> distinguish SMW from Wikibase or Cargo.
>> If we ignore or don't do ontologies, then what's the point of using SMW?
>
>
> ​I don't think that Wikibase is an alternative to MediaWiki, since it's got
> a very strict approach and is rather like managing a database. ​How it
> fares against Cargo is a whole different issue ;) It would be very
> interesting to have some data/statistics on how SMW is actually used (how
> many people are using a SPARQL endpoint for example)
>
> ​But you're right, SMW could improve it's profile here.
>
> Here are some ideas:
>
>    - Your IDE/Ontology developing approach makes definately sense to me.
>    It's a complex project and I wouldn't expect that too many people have
> the
>    need for full ontologies. But if the project manages to make setting up
>    your structure faster / more convenient and consistent, people will
> likely
>    use it. I agree that ontologies are powerful, but they are also somewhat
>    counter-intuitive at first contact. So having a good tool that helps
>    creating them is crucial.
>    - I've thought about having something like a "fact adder" additionally
>    to SemanticForms / Source Editor. It could be as easy as having two
> fields.
>    The first one autocompletes on all available attributes, the second one
>    takes the value (single or multiple) and basic validation. That feature
>    could fit in both with SemanticForms (producing a visible fact table) or
>    the VisualEditor (annotating text).
>    This would actively demonstrate the ability of SMW to handle very
>    flexible, unpredicted data, because of the RDF/Graph data structure
> behind.
>    - That said, graph-databases / structures gain popularity the last
>    years. SMW has that capability from start. Maybe it would be an good idea
>    to demonstrate and "advertise" that?
>    - I would say that the RDF data structure, it's open W3C standard and
>    good interoperability (linked-open-data, global knowledge graph) are the
>    main argument for SMW. Improving the Semantic Web capabilities (even only
>    under the hood) would be great here.
>
> regards,
> Simon
>
> 2015-01-22 23:20 GMT+01:00 John McClure <[hidden email]>:
>
>>  Hi Simon,
>>
>> On 1/18/2015 12:15 AM, Simon Heimler wrote:
>>
>>  Using an IDE / Editor for developing SMW models was an appealing idea to
>> me, too. Scratching my own itch, I've built a prototype Model Driven
>> Engineering Tool, called mobo (https://www.npmjs.com/package/mobo).
>> Please note that it's currently built for my own use and purposes and
>> definitely not stable yet.
>>
>>  It it much simpler in scope than your proposal (it ditches ontologies
>> completely, and uses a very simple object/document oriented inheritance
>> model), and this was a design decision. But you can use your editor,
>> Version Control and it has basic browsing / validating capabilities.
>>
>> Not one to ditch ontologies, rather I appreciate their strengths during
>> the develoment process and beyond.
>> SMWOntologies is meant to speed applications development, it's a body of
>> practical knowledge and best practices to pre-fill an 'empty' smw
>> installation.
>>
>>  Bernhard and Alexander already mentioned that: Ontologies are rather
>> complex and the nice thing about SMW is that it hides this complexity
>> while
>> still providing "basic" Semantic Web Capabilities.
>>
>> yes, smw hides the complexity of triples for those going *template-names*
>> --> *form-names* --> *property-names*.  SMWOntologies is about equipping
>> a semantic wiki with namespace-qualified property names, so the
>> possibility
>> is to go *property-names* --> *template-names* --> *form-names*.  This
>> latter approach informs/improves the former by providing a robust
>> dictionary of built-in class & property definitions that can be used 'off
>> the shelf'; or as super-classes or super-properties; or as REDIRECT
>> targets
>> for an organization's elements.
>>
>>  What you're suggestion sound quite capable and much more aligned to
>> current Semantic Web Research. Have you taken a look at OntoWiki? (
>> http://aksw.org/Projects/OntoWiki.html). They are by no means as widely
>> used as SMW but they have a much higher focus on beeing "full semantic web
>> complient". (And I'd argue that this is exactly the reason it's not as
>> widely used)
>>
>> Maybe but regardless my focus is on SMW nothing more than to improve SMW
>> so that it's easier for everyone.
>>
>> Please remember that "ontologies" are fast-becoming the only thing to
>> distinguish SMW from Wikibase or Cargo.
>> If we ignore or don't do ontologies, then what's the point of using SMW?
>> Maybe you can cite some other SMW function we should beef up instead/too.
>>
>>
>>  Best,
>> Simon
>>
>>
>>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Semediawiki-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: SMW Ontologies

John McClure
In reply to this post by Fannon
Wikibase is an important piece of software, with a size as large as SMW
(est: 1.3M LOC though ohloh underestimates SMW), and Wikibase defines a
Property namespace and now sports an empty Query namespace (think
Concept as on the rise), but to-date has no datatype for Class though
that seems imminent. Wikibase has a great reasons to use it, first
because it has multi-lingual property value support for multi-lingual
wikis, and second that it's not the prototype that SMW threatens to become.

    Right now Wikibase's 1,381 properties are 906 nouns, 475 page
    identifiers, 46 verbs, and a handful of mutts.  SMWO might gain some
    interoperability by treating the 475 identifiers as encoding schemes
    as suggested by DCMI, e.g., Identifier: ISO4217:USD per Notation:
    ISO4217. Selected Wikibase nouns might be converted from properties
    to *Type *and inserted into some reasonable noun taxonomy too.  With
    some effort Wikibase verbs can be re-implemented using semantic
    variations of /to-be/ or /to-have/, the two basic verbs first in SMWO.

Cargo is a nice enabling technology useful to the SMW system for
certain. The ultimate goal is to implement an abstraction layer so that
users aren't caring whether Wikibase or SMW is installed. Part of that
is a View: namespace which use page layouts and content substitutions
declarativly, referencing dot-templates (with property names, like
/.dc:title/) to retrieve values and triple-templates (with property
names, like /dc:title/) when storing property values.  Cargo lets us
store a view's retrieved values in an sql table named after the view,
somewhat like the Concept namespace but different because tables not
just pageids are being cached.

On 1/23/2015 11:44 PM, Simon Heimler wrote:

> Hello John,
>
>     Please remember that "ontologies" are fast-becoming the only thing
>     to distinguish SMW from Wikibase or Cargo.
>     If we ignore or don't do ontologies, then what's the point of
>     using SMW?
>
>
> ​ I don't think that Wikibase is an alternative to MediaWiki, since
> it's got a very strict approach and is rather like managing a
> database. ​How it fares against Cargo is a whole different issue ;) It
> would be very interesting to have some data/statistics on how SMW is
> actually used (how many people are using a SPARQL endpoint for example)
>
> ​ But you're right, SMW could improve it's profile here.
>
> Here are some ideas:
>
>   * Your IDE/Ontology developing approach makes definately sense to
>     me. It's a complex project and I wouldn't expect that too many
>     people have the need for full ontologies. But if the project
>     manages to make setting up your structure faster / more convenient
>     and consistent, people will likely use it. I agree that ontologies
>     are powerful, but they are also somewhat counter-intuitive at
>     first contact. So having a good tool that helps creating them is
>     crucial.
>   * I've thought about having something like a "fact adder"
>     additionally to SemanticForms / Source Editor. It could be as easy
>     as having two fields. The first one autocompletes on all available
>     attributes, the second one takes the value (single or multiple)
>     and basic validation. That feature could fit in both with
>     SemanticForms (producing a visible fact table) or the VisualEditor
>     (annotating text).
>
if the fact adder were to insert a template call anywhere it wanted
inside the {{semantic|facts=}} call on a page, that would be very nice -
there's a pile of interesting working js code (on mw 1.17) that might be
hacked that has a few Ajax calls that no doubt need fixing - it has a
nice starting interface that can be modified anyway wanted.

>
>   * This would actively demonstrate the ability of SMW to handle very
>     flexible, unpredicted data, because of the RDF/Graph data
>     structure behind.
>   * That said, graph-databases / structures gain popularity the last
>     years. SMW has that capability from start. Maybe it would be an
>     good idea to demonstrate and "advertise" that?
>   * I would say that the RDF data structure, it's open W3C standard
>     and good interoperability (linked-open-data, global knowledge
>     graph) are the main argument for SMW. Improving the Semantic Web
>     capabilities (even only under the hood) would be great here.
>
I have an idea for special pages to picture the physical wiki structure
of a page (its language-sensitive transclusions) and another to show a
"topic map" (like an index in a book) for a page and its "affinity"
subjects and pages, basically a graph of the topical knowledge there is
in a wiki, an interwiki or beyond, for a given 'primary' topic page. //

> regards,
> Simon

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

[SMWO] Page metadata & functional data

John McClure
In reply to this post by Fannon
SMWO separates a page's metadata from its functional data clearly and
cleanly.  It has a simple rule that namespace-qualified properties are
for metadata, and lexically-qualified properties are for functional
data. (Note: Datatype properties, like /smw:number/ hold raw content of
the page).  Lexically-qualified properties are actually proper
namespaces too, but are verb forms such as /is/, /was/, /will-be/,
/may-have/ and others. These verbal namespaces freely add time & deontic
dimensions (deontic: typified by modal auxiliary verbs
<http://en.wikipedia.org/wiki/Auxiliary_verb>, such as the English words
/may, can, must, ought, will, shall, need, dare, might, could, would,/
and /should/ ... especially in the Germanic languages
<http://en.wikipedia.org/wiki/Germanic_languages>) to a lexically
interesting graph, where the value of a /rdf:predicate/ first indicates
whether an /rdf:object/ is to be interpreted as a direct or as an
indirect object or as a nominative -- certainly good distinctions to
establish up front! This is why there are for some odd property names
like /is:a, was:that, will-be:for /and /has:some, had:this,
will-have:on... /similar to the appoach incidentally in the OMG's
Semantic of Business Vocabulary of Rules (SBV) ontology, but more
consistent.  Here's an example of how this works -- below, all the
dublin core (/dc:/) properties (think, rss) are for metadata about a
Census page while the /is: /elements store functional information
defining the character of the page -- SMWO systematically distinguishes
a date for the census from its date of publication, meat from metadata.
Often the semantic character of a page can be initially drawn merely by
parsing the page's name, lending further reason why patterned page-names
(pagetype: pagename) are key for the community to adopt.

The RDF's PROV namespace includes transformation descriptions that are
easy enough to implement and will be a focus soon that, together with
other namespaces, surely cover the scope of requirements for page
metadata.  Current thinking on other metadata properties:

      * *Property: smw:PAGENAME* = a page's pagename without either its
        namespace or pagetype, for displays. default: {{.semantic}}
      * *Property: smw:FULLPAGENAME* = a page's name (without namespace)
        for queries by pagetype &or pagename. default:{{PAGENAME}}
      * *Property: swb:prefLabel* = argument to {{DISPLAYTITLE:}} that
        can be language-specific. default: {{.iso:name}}
      * *Property: swb:altLabel* = a page's subtitles for displays.
        default: {{.skos:altLabel}}
      * *Property: iso:name* = argument to {{DISPLAYTITLE:}} that can be
        language-specific. default: {{PAGENAME}}
      * *Property: ***iso*:variant* = names of pages that (could/do)
        #REDIRECT to the page. default: {{PAGENAME}}
      * *Property: dc:title* = language specific citation-ready titles
        for the page. default: {{.xtm:name}}
      * *Property: skos:prefLabel* = language specific common titles for
        the page. default: {{.dc:title}}
      * *Property: skos:altLabel* = language specific nicknames and
        abbreviations for the page. default: {{.skos:altLabel}}

    Page categories are split into groups. {{PAGETYPE}} is a new magic
    word derived from parsing a pagename. The *Subject*, *Tag* and
    *Type* pagetypes referenced below are initially implemented as
    aliases of the Category namespace (note: rename SMW's "Type"
    namespace to *Datatype*) though one more of these three may be
    migrated to the Concept namespace in the future.

      * *Property: swb****:instance_of *= the page's pagetype category,
        normally a *Type* page. default: {{PAGETYPE}}
      * *Property: swb****:subclass_of *= the page's parent type
        category, normally a *Type* page. default: {{.swb:subclass_of}}
      * *Property: ***iso*:isa *= the page's pagetype category, normally
        a *Type* page. default: {{PAGETYPE}}
      * *Property: rdf:type* = overriding category(s) generated for the
        page's RDF datastream, normally a *Type* page. default: {{.iso:isa}}
      * *Property: rdfs:label* = language specific class name of a page.
        default: {{PAGETYPE}}
      * *Property: dc:type *= descriptive/status categories (adjectives,
        past-participals), normally *Tag* pages
      * *Property: dc:format *= library media-type category of the page,
        normally a *Type* page. default: {{.dc:format}}
      * *Property: dc:subject *= search-keyword categories, often each a
        *Subject***page.y**default:none
      * *Property: skos:broader *= container categories, often each a
        *Subject *page.**default: {{.dc:subject}}

    Identifier properties are

      * Use *Property: ***iso*:subjectIdentifier* for the page's public
        topic map identifier. default: tbd
      * Use *Property: dc:identifier* for one or more (qualified,
        public) identifiers including urls
      * Use *Property: rdf:ID* for overriding the ID generated for the
        page's RDF Description. default: #{{FULLPAGENAMEE}}
      * Use *Property: xml:id* for overriding the id generated for a
        page's XML datastream. default: {{FULLPAGENAMEE}}

    Container properties

      * *Property: halo:Part of bundle* = a package installation name
        that administratively works well enough. default: {{.halo:Part
        of bundle}}


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user