guidocecilio / neologism

Automatically exported from code.google.com/p/neologism
3 stars 1 forks source link

Support RDFS+ #113

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Supporting constructs that are subsumed as RDFS-Plus would cover most
things people want to express in their leightweight ontology. (TopQuadrant
state in "semantic web for the working ontologist, that identified the most
useful construct from an informal poll and called it RDFS+)

For this RDFS+ subset of constructs we'd additionally need:
transitive properties
symmetric properties
sameAs
equivalent properties and classes

I'd especially vote for the first two - we'd need just two more checkboxes
(that could be hidden in a collapsed section along with FP, IFP, inverse). 

Original issue reported on code.google.com by tom.scha...@gmail.com on 27 Jan 2010 at 10:51

GoogleCodeExporter commented 8 years ago
What would you do regarding sameAs? I believe you're not supposed to use it on 
classes and properties.

Could this be addressed by adding custom triples to the vocab output (see Issue 
112)?
http://code.google.com/p/neologism/issues/detail?id=112

Original comment by richard....@gmail.com on 30 Jan 2010 at 9:05

GoogleCodeExporter commented 8 years ago
Right, sameAs probably won't make sense in Neologism and equivalence probably is
better solved by using imported classes in the first place.

But for transitive and symmetric:
I don't see why we'd have inverseOf, but not have symmetric and transitive. To 
me
they seem to be naturally belonging together.

Also in "SemWeb f.t.working Ontologist" it is argued, that RDFS-plus constructs 
have
considerable utility while only adding little complexity and that they are 
often used
in informaion integration projects TQ do.

Arguing differntly: why not have inverseOf as custom triples? 
(btw. generally speaking the custom triple feature is very desierable)

Original comment by tom.scha...@gmail.com on 30 Jan 2010 at 12:40

GoogleCodeExporter commented 8 years ago
We included inverseOf because it is quite prominent in SIOC and FOAF, while the 
other RDFS+ features are 
not.

The main problem with including more expressive constructs is that it makes the 
algorithms for determining 
the possible choices in each widget even more complicated.

A second problem is screen real estate. Each class/property selection widget 
takes quite some space and 
bloats the page.

But undeniably RDFS+ support is desirable to some people. Perhaps let's wait 
till a few more people are using 
Neologism and we see what they need most.

Original comment by richard....@gmail.com on 1 Feb 2010 at 6:37

GoogleCodeExporter commented 8 years ago
I see the danger of the GUI becoming too crowded, especially with the new 
widgets
taking much space (but they are useful of course)
But transitive and symmetric are only checkboxes and might be hidden away with
inverse, FP and IFP in a section collapsed by default.

Would transitive and symmetric have any influences on the algorithms you 
mentioned? 

Transitive is also very important in the new SKOS version (that's why having
transitive might be important for use cases at the SWC) and there are also some
transitive constructs in SIOC now.

that concludes my argument :-)

Original comment by tom.scha...@gmail.com on 1 Feb 2010 at 8:37

GoogleCodeExporter commented 8 years ago
I agree that Transitive and Symmetric aren't a problem from the UI side. 
Unfortunately Symmetric does affect the 
algorithms. Transitive does not if I'm not mistaken.

(The issue is that domain and range become identical if a property is 
symmetric. An example of the effect: If the 
classes chosen for domain and range are declared as disjoint, then it should be 
impossible to make the property 
symmetric, because then any graph that uses the property would be inconsistent.)

Original comment by richard....@gmail.com on 1 Feb 2010 at 9:03

GoogleCodeExporter commented 8 years ago
Support for equivalentClass/equivalentProp has been requested by Chris Bizer. 
Use case: expressing mappings between vocabularies.

I guess the main problem is that our big tree widgets are not really good for 
defining a lot of different relationships. We should think about different 
widget possibilities: small widgets that look just like a text box and have 
good autocompletion; or tree widgets that allow configuring several 
relationships (subclass, disjoint, equivalentclass) in a single widget; or ...

Original comment by richard....@gmail.com on 14 Mar 2011 at 6:14