Re: [Semediawiki-user] Semantic naming best practices?

[badon <fas...@gm...>]

I had no idea that there was such a thing as a "standard vocabulary", but I'm
finding it quite useful. Thank you very much for the specific info you
shared. It's going to lead to insights in how I handle this, and how I write
up my solutions.




CW Dillon wrote:
> 
> Hi Badon,
> In my experience, property naming can be pretty haphazard and still work
> *some* or even *most* of the time, depending on how complicated your site
> becomes.  Commonly, when things go wrong it's because the data structure
> is
> not very "object- oriented" and the solution is to go back and restructure
> the page properties.  (The good news is that there are some good tools out
> there to make it pretty easy.)
> 
> Increasingly often, I find it useful to do some research and find a
> vocabulary that has been put together by an "ontologist" or "knowledge
> engineer". For example, we are converting all of our vocabularies about
> online resources to comply with the Dublin Core and I use the contact
> information structure from the FOAF vocabulary for user pages.  I think
> this
> is a good idea because, in most cases, these standardized vocabularies
> reflect the expertise of a community of experts; they seem more complete
> and
> are less prone to needing fancy solutions, like internal objects or
> templated sub-queries (though these are sometimes still necessary--I'm
> glad
> these options exist).  These vocabularies indicate which terms in your
> wiki
> are categories (classes) and which are properties (attributes).  In my
> opinion, it's better to adapt the "standardized" terms to fit your user
> community: you don't have to use "Category:Persons" if you'd rather use
> "Category:People", for example. (I still always make my categories plural,
> however.)
> 
> When there is no ISO-approved standard vocabulary to follow, I don't mind
> making stuff up. I generally treat terms of the form "is an instance" as
> category tags and terms of the form "has attribute" as properties. In my
> experience, Yaron's advice on the SF page to have your properties "point
> up"
> to parents instead of "point down" to children is good advice.
> 
> In cases like your original post, I think the first example is more
> correct.
>  I would make the properties about the page fit the category of the page
> and
> make the possible values for those properties, themselves be pages in an
> appropriate category, like this:
> 
> [[Has color::{{{Color|}}}]]  <--the form will only accept values from
> category=Colors-->
> [[Part of::{{{Set|}}}]] <--taken from W3C RDF Rec-->
> 
> [[Category:Cities]]
> 
> But there are also quite a few resources available to help you make your
> own
> structures. Check out these:
> 
> http://www.w3.org/wiki/PartWhole
> http://www.w3.org/TR/rdf-primer/
> http://books.google.com/books?id=RnFjZTfPILcC&pg=PA134&lpg=PA134&dq=RDFs+%22PartOf%22&source=bl&ots=IBrtfeW1ho&sig=vv2AaHKk94GCsPfVFOABzqF6YrI&hl=en&ei=i21uTtarH9HUgAfN2cWNBg&sa=X&oi=book_result&ct=result&resnum=6&ved=0CDcQ6AEwBQ#v=onepage&q&f=false
> 
> R,
> Clarence
> 
> On Mon, Sep 12, 2011 at 2:44 AM, Krabina Bernhard <kr...@kd...>
> wrote:
> 
>> Hi,
>>
>> I agree with Chris. I wasn't sure how to go about it in my first wikis
>> and
>> the developers did not have a clear way to go for that, though some of
>> the
>> arguments in your mail seem quite obvious.
>>
>> For me the "has" and "is" version seems to come from the semantic world.
>> A
>> lot of people using my wikis do not have any clue about semantics, my
>> wikis
>> are often just a web database, so the "has" and "is" version is not very
>> intuitive for them. An in German, for me it feels even more odd to have
>> these types of names for properties...
>>
>> regards,
>> Bernhard
>>
>> ----- Ursprüngliche Mail -----
>> > I'm ambivalent. In many ways, each wiki is unique with respect to the
>> > user base and how they will expect properties and template parameters
>> > to be named. Furthermore, the admins may have different
>> > thoughts/expectations as to naming conventions based on the subject.
>> > For many Semantic Wikis, there may be forms that hide the raw
>> > wikitext
>> > from ever being seen by the vast majority of the users, so whatever
>> > makes the templates and properties easiest to understand and work
>> > with
>> > for the people who will be maintaining them will be the ideal
>> > solution.
>> >
>> > I guess my feelings on the matter can be summed up in two words: It
>> > Depends
>> >
>> > just my $.02
>> >
>> > -Chris
>> >
>> > On Sun, Sep 11, 2011 at 2:27 PM, badon <fas...@gm...>
>> > wrote:
>> > >
>> > > I'm surprised no one has commented on this. Is it because everyone
>> > > agrees
>> > > with my conclusion, or has no one read this yet?
>> > >
>> > >
>> > >
>> > >
>> > > badon wrote:
>> > >>
>> > >> OK, there's a few things we have to name:
>> > >>
>> > >> * Template call parameters
>> > >> * Properties (in the template definition)
>> > >>
>> > >> The template call, with parameters, looks like this:
>> > >>
>> > >> {{My semantic template call
>> > >> |Property1=My property 1
>> > >> |Property2=My property 2
>> > >> |Property3=My property 3
>> > >> }}
>> > >>
>> > >> The template definition for "My semantic template call" would have
>> > >> properties that look like this:
>> > >>
>> > >> [[Property1::{{{Property1|}}}]]
>> > >> [[Property2::{{{Property2|}}}]]
>> > >> [[Property3::{{{Property3|}}}]]
>> > >>
>> > >> My question is, what should those look like? Let's say that:
>> > >>
>> > >> * Property1 is a color
>> > >> * Property1 is a city
>> > >> * Property1 is a set
>> > >>
>> > >> So, I THINK I should name the properties like this, respectively:
>> > >>
>> > >> * Has color
>> > >> * Is city
>> > >> * Belongs to set
>> > >>
>> > >> In the template call, the parameters would be named like this:
>> > >>
>> > >> {{My semantic template call
>> > >> |Color=My property 1
>> > >> |City=My property 2
>> > >> |Set=My property 3
>> > >> }}
>> > >>
>> > >> with the qualifiers ""Has", "Is", and "Belongs to" being
>> > >> semantically
>> > >> unnecessary.
>> > >>
>> > >> The template definition for "My semantic template call" would have
>> > >> properties named like this:
>> > >>
>> > >> [[Has color::{{{Color|}}}]]
>> > >> [[Is city::{{{City|}}}]]
>> > >> [[Belongs to set::{{{Set|}}}]]
>> > >>
>> > >> Does that look correct?
>> > >>
>> > >> I did some reading about parts of speech to figure out what
>> > >> exactly to
>> > >> call this:
>> > >>
>> > >> http://en.wikipedia.org/wiki/Part_of_speech
>> > >>
>> > >> My conclusion is that "it" ("Has", "Is", "Belongs to", etc) can be
>> > >> many
>> > >> different parts of speech, but they're always of the form:
>> > >>
>> > >> Qualifier-object
>> > >>
>> > >> So, I've decided to just call each part exactly that, either a
>> > >> "qualifier"
>> > >> or an "object". For example, in "Has color", the qualifier is
>> > >> "Has" and
>> > >> the object is "color".
>> > >>
>> > >> At first the importance of this naming convention was not apparent
>> > >> to me.
>> > >> In a discussion I had with Yaron, he pointed out that there is
>> > >> ambiguity
>> > >> in referring only to an object called "City". Does your property
>> > >> have a
>> > >> city, is it a city, does it belong to a city? And so forth...
>> > >>
>> > >> I discovered another instance where unambiguous naming can be
>> > >> important.
>> > >> Let's say you have a property called "Color", but you realize that
>> > >> you
>> > >> need to change them all to "Has color" so you can add new
>> > >> properties
>> > >> called "Is color" (red, blue, etc) and "Has particle color"
>> > >> (particle
>> > >> physics "colors").
>> > >>
>> > >> So, you decide to use the Replace Text extension to change them
>> > >> all from
>> > >> "Color" to "Has color", but your wiki is already full of
>> > >> references to the
>> > >> other types of "color". If you try to replace only the properties
>> > >> named
>> > >> "Color" in your wiki, you will probably also accidentally change
>> > >> every
>> > >> instance of the word "color", even when it's not even a property.
>> > >>
>> > >> If you had begun your wiki with a best-practice naming convention
>> > >> that was
>> > >> unique to properties, such as always putting them in the form
>> > >> Qualifier-object, then you'll have more luck doing mass changes
>> > >> without
>> > >> accidentally changing something that wasn't supposed to be
>> > >> changed.
>> > >>
>> > >> Does this make sense? If so, then perhaps the template call should
>> > >> instead
>> > >> look like this, with qualifiers:
>> > >>
>> > >> {{My semantic template call
>> > >> |Has color=My property 1
>> > >> |Is city=My property 2
>> > >> |Belongs to set=My property 3
>> > >> }}
>> > >>
>> > >> And the template definition's properties and parameters should be
>> > >> identical, using same Qualifier-object form:
>> > >>
>> > >> [[Has color::{{{Has color|}}}]]
>> > >> [[Is city::{{{Is city|}}}]]
>> > >> [[Belongs to set::{{{Belongs to set|}}}]]
>> > >>
>> > >> In short, maybe EVERYTHING involving properties should be in the
>> > >> Qualifier-object form, just to always be semantically clear that
>> > >> it is
>> > >> something involving semantic properties. Thoughts? Does it look
>> > >> like I've
>> > >> got this correct? Should I write it up as best-practice
>> > >> documentation now?
>> > >> Is there anything missing, or something I haven't considered?
>> > >>
>> > >
>> > > --
>> > > View this message in context:
>> > >
>> http://old.nabble.com/Semantic-naming-best-practices--tp32421403p32443991.html
>> > > Sent from the Semantic Mediawiki - User mailing list archive at
>> > > Nabble.com.
>> > >
>> > >
>> > >
>> ------------------------------------------------------------------------------
>> > > Using storage to extend the benefits of virtualization and iSCSI
>> > > Virtualization increases hardware utilization and delivers a new
>> > > level of
>> > > agility. Learn what those decisions are and how to modernize your
>> > > storage
>> > > and backup environments for virtualization.
>> > > http://www.accelacomm.com/jaw/sfnl/114/51434361/
>> > > _______________________________________________
>> > > Semediawiki-user mailing list
>> > > Sem...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>> > >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Using storage to extend the benefits of virtualization and iSCSI
>> > Virtualization increases hardware utilization and delivers a new
>> > level of
>> > agility. Learn what those decisions are and how to modernize your
>> > storage
>> > and backup environments for virtualization.
>> > http://www.accelacomm.com/jaw/sfnl/114/51434361/
>> > _______________________________________________
>> > Semediawiki-user mailing list
>> > Sem...@li...
>> > https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Doing More with Less: The Next Generation Virtual Desktop
>> What are the key obstacles that have prevented many mid-market businesses
>> from deploying virtual desktops?   How do next-generation virtual
>> desktops
>> provide companies an easier-to-deploy, easier-to-manage and more
>> affordable
>> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
>> _______________________________________________
>> Semediawiki-user mailing list
>> Sem...@li...
>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>>
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop 
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops?   How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more
> affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Semediawiki-user mailing list
> Sem...@li...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
> 
> 

-- 
View this message in context: http://old.nabble.com/Semantic-naming-best-practices--tp32421403p32475334.html
Sent from the Semantic Mediawiki - User mailing list archive at Nabble.com.