Soory to drag on, but also of note is that /[[propname@ :: value]]/
could default to the wiki's language, this being another option for
undefined properties... Any property names with a trailing ampersand
could default to /[[Has type::text]]/, and values of any defined /[[Has
type::text]]/ property when used without an ampersand default to the
wiki's language. Syntactically this seems like the most practical way to
handle iso languages for text properties. Undefined /[[Has type::code]]/
properties can get similar syntactic sugar.
That brings up /[[Has type::page]]/, making me wonder about the special
property /Has subobject/ ... what is its type? Not a 'wiki page', it's a
subobject. Both must be exported in RDF (eventually) as legitimate
targets of an /owl:ObjectProperty/ named something like
/smw:Has_subobject/ to associate named-subobjects.
To apply the above method to undefined properties as to whether they
point to pages or subobjects, suggests that property names that begin
with a hash character can default to /[[Has type::subobject]]/ otherwise
default to /[[Has type::page]]/. Multilingual relations should be
possible too: /[[MyProperty::pgnm]]/ defaults to wiki's language and
/[[MyProperty@es::spanish-pgnm]]/ and /[[#MyProperty@de ::
german-subobjname]]/ operate as above. With the expectation that
subobject links are resolved at some point in the process via
/{{#subobject: subobjectname}}/. The big impact on queries might be via
a dot operator, to specify a predicate property within a certain named
subobject, say in a Concept
eg /[[
MyProperty#subobject-name-or-pattern@za.subobject-property-name@za ::
property-value-or-pattern ]]/.
Maybe some formulation works with /[[ Has subobject ::~
{{FULLPAGENAME}}#mypattern ]]/ that doesn't involve arrays but I don't
see how. But if it's okay to mark a pattern with a tilde character then
we have terrific shorthand for pagenames and objectnames as predicate
values. To select all pages named with an index suffix, e.g. could be
/[[~pgnm*]]/. To select all subpages is even simpler: /[[~pgnm/*]]/.
Similarly to select subobjects on these pages could get as complicated
as /[[~pgnm*#objname*]]/ but more usual would be just /[[~pgnm#objname*]]/.
On 11/19/2013 5:43 PM, John McClure wrote:
Maybe we should think about a fork called Semantic Web Mediawiki (SWM)
hehe. Seriously though this moment I'm interested in what people think
of indicating language in SMW syntax by using the ampersand character,
eg /property-name@language-code/ - would this be a too-complex change
to SMW, and can this supported by the Ask library?
I don't like property names like "Description - English" but that's
all there is in today's SMW to support wikis used by multilingual
communities -- while perfectly legal its stupidly mechanical to define
properties this way. How do people feel about any value for a
type:text property, say /Property:Description/, can be annotated with
its language such as
(1) [[Description@es::spanish-text]]
(2) {{#set:Description@es=spanish-text}}
(3) {{#ask: [[Description@es::+]]
|?Description@en=english-label|?Description@es=spanish-label}}
(4) any others?
Properties of type:code would not have this capacity of course. And
this way, RDF exports -- which from the note below have ongoing
importance? -- can properly indicate the language of a text-string.
How diffiucult a change is this? I don't see it having any worrisome
perfomance problem at all, and it would be immensely useful for
multi-lingual communities.
Thanks/john
On 11/19/2013 2:03 PM, Yaron Koren wrote:
Hi John,
I just wanted to respond to one part:
Surely you're aware the community so highly esteems your
contributions to OWL specifications, that it has a directly
consequent,
unflinching & justifiable belief that SMW is a /faithful RDF
implementation/.
I don't believe this is true. To recap, what you're saying is: (a)
most users of SMW care about RDF and the like, (b) developers of SMW
are guided by SMW standards, (c) Markus's involvement in OWL makes
people think that SMW similarly is a Semantic Web-based project, (d)
as a result, SMW users/developers are going to be disappointed that
it doesn't adhere to all the RDF conventions.
I'm pretty sure none of the above are true. This is not to denigrate
any part of the Semantic Web, but I think it's safe to say that the
average SMW user is unconcerned about RDF and the like, and that the
average SMW developer views RDF as a storage/output format, not
something that guides how SMW should operate. So I'd say that you're
in the minority on this one. Not that there's anything wrong with
holding minority opinions (I've certainly been in that situation),
but I think you'd be better off arguing your case on the technical
merits, rather than on an appeal to people's expectations.
-Yaron
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
