label position

[Bohms, H.M. (Michel)]

Dear All,

We use the pattern:

 

sml-term:Activity

  a skos:Concept ;

  skos:broader sml-term:Entity ;

  skos:definition "An activity is something possibly or actually happening in space and time"@en ;

  skos:prefLabel "Activity"@en ;

.

 

sml:Activity

  a rdfs:Class ;

  rdfs:isDefinedBy sml-term:Activity ;

  rdfs:subClassOf sml:Entity ;

.

 

But this means that the label is only indirectly available for sml:Activity (via “isDefinedBy.prefLabel”)

 

Is this an issue? (many tools like to have a direct label for their classes)

Better solutions?

(I’d like to define only once, not double; label feels naturally close to definition; maybe only prefLabel to rdfs-variant and leave altLabel/definition at skos?)

 

Thx for advice,

Michel

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location   This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

[David Price]

On 29 Jun 2021, at 08:46, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Dear All,

We use the pattern:

 

sml-term:Activity

  a skos:Concept ;

  skos:broader sml-term:Entity ;

  skos:definition "An activity is something possibly or actually happening in space and time"@en ;

  skos:prefLabel "Activity"@en ;

.

 

sml:Activity

  a rdfs:Class ;

  rdfs:isDefinedBy sml-term:Activity ;

  rdfs:subClassOf sml:Entity ;

.

 

But this means that the label is only indirectly available for sml:Activity (via “isDefinedBy.prefLabel”)

 

Is this an issue? (many tools like to have a direct label for their classes)

I imagine tools will use one of the local name or perhaps URI or perhaps prefixed name. Being an issue depends on use case (i.e. no problem at all if for data exchange but perhaps for a human looking at a UI).

Better solutions?

(I’d like to define only once, not double;

Not possible.

label feels naturally close to definition; maybe only prefLabel to rdfs-variant and leave altLabel/definition at skos?)

There are two different things with different URIs. They do not “share” properties. That’s just how RDF and RDFS/OWL and SKOS work, so will not surprise anyone or any tool. It’s unclear if you expect them to ever be used together, but as SKOS is an OWL ontology and the other seems RDFS I imagine not.

A Concept and a Class are not the same thing at all. An RDFS Class (data modelling artefact) has members/class extension that are resources, while a SKOS Concept (e.g. a library science artefact) does not as it’s main purpose is as the Web identifier for the variety of labels/definitions in multiple languages and flexible, not-formally-defined relations that it holds.

Note that the SKOS crew do want it used in a manner like this, but not with the specific approach being taken above:

Looking to the future, SKOS occupies a position between the exploitation and analysis of unstructured information, the informal and socially-mediated organization of information on a large scale, and the formal representation of knowledge. By making the accumulated experience and wisdom of knowledge organization in the library and information sciences accessible, applicable and transferable to the technological context of the Semantic Web, in a way that is complementary to existing Semantic Web technology (and in particular formal systems of knowledge representation such as OWL), it is hoped that SKOS will enable many new and valuable applications, and will also lead to new integrative lines of research and development in both technology and practice.

Every class and property should have its own label and more importantly its own local definition. Note that formal class definitions often place the class in the class hierarchy (i.e. a <class> is a <superclass> that <further membership criteria distinguishing class from other subclasses of superclass> ) whereas a concept definition would not do so. Concept labels/defs are for all humans, and those for Classes are aimed at software developers - or at least that IMO is the best practice of using these two together.

Cheers,

David

 

Thx for advice,

Michel

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

<image001.gif>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

-- 
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/65077d500edc4a6bb4f8289d08326df2%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

Hi David

 

I see your point: “better use skos only separate from rdfs/owl/shacl”

 

But ok we said it would be handy to combine (many parties already did in NL like Cadastre).

 

But then it seems we have to double….which goes a bit against the principle of separation of concerns….

 

Ie also (red):

 

sml:Activity

  a rdfs:Class ;

  rdfs:isDefinedBy sml-term:Activity ;

  rdfs:subClassOf sml:Entity ;

  skos:definition "An activity is something possibly or actually happening in space and time"@en ;

  skos:prefLabel "Activity"@en ;

.

 

I hoped for less doubling like:

 

sml:Activity

  a rdfs:Class ;

  rdfs:isDefinedBy sml-term:Activity ;

  rdfs:subClassOf sml:Entity ;

  skos:prefLabel "Activity"@en ;

.

 

Isn’t the skos:definition also for human interpretation only so that it can stays at skos-side?

 

Wrt tools expecting labels..if I rember right edg also likes/needs labels right?

 

If edg has no issue I might stay with the current approach (only having uris/names) for rdfs/owl/shacl side.

 

michel

 

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/A427481B-4F29-4C2A-95BA-8822183EE5B5%40topquadrant.com.

[Irene Polikoff]

I will answer this question from two perspectives:

1. Standards

2. TopBraid EDG

1. From the standards perspective, rdfs:isDefinedBy is a utility property that has no standard semantics.

It is typically used to connect a resource to its “home” vocabulary (a graph). This is the use case specifically mentioned by the RDFS specification and this is how it is typically used in practice.

Not having standard semantics means that users are generally free to use it in any way they want - with an understanding that there is no standard treatment of it by tools. A tool could decide to do something special when they see this property - or not. Most (all?) tools don’t.

Thus, if your intended semantics (meaning) is that the object of a triple with rdfs:isDefinedBy predicate carries a label and a definition for the subject of that triple, it is up to you to implement software that will understand this semantics and will act on it. You can’t expect that a standards compliant tools will understand this.

2. How TopBraid EDG will treat this information

As per above, by default, TopBraid EDG will simply treat a triple with rdfs:isDefinedBy predicate the same ass any other triple. It will not mean anything special to EDG - unless you tell EDG that it has a special meaning.

You can define inference rules to give rdfs:isDefinedBy a special meaning. For example, the property value rule below will automatically infer skos:definition for sml:Activity from sml-term:Activity.

Or, more generally, for any class from any concept connected to it by rdfs:isDefinedBy.

owl:Class

  sh:property owl:Class-definition ;

sh:property owl:Class-isDefinedBy ;

.

owl:Class-isDefinedBy

  a sh:PropertyShape ;

  sh:path rdfs:isDefinedBy ;

  sh:class skos:Concept ;

owl:Class-definition

  a sh:PropertyShape ;

  sh:path skos:definition ;

  sh:values [

      sh:path skos:definition ;

      sh:nodes [

          sh:path rdfs:isDefinedBy ;

        ] ;

    ] ;

.

Note: You can do this for any property except for the rdfs:label/skos:prefLabel. EDG uses special indexing and algorithms for these labels and their values need to be asserted directly for each resource.

<image001.gif>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

[Bohms, H.M. (Michel)]

Thx Irene

 

Following offline discussion with David I guess we better split the 2 worlds (skos versus non-skos (ie rdfs/owl/shacl)):

• No import of skos scheme in rdfs ont
• Copy prefLabel, altLabel, definition also to rdfs items (satisfying your note in the end)
• Keep the isDefinedBy, doing no harm, expecting no special semantics just a common way to be able to navigate from rdfs to skos where there could be more (more languages, broaders, groupings, examples, …)

Gr michel

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/635E061F-7D01-4786-9506-597AFB7249E3%40topquadrant.com.

[Bohms, H.M. (Michel)]

Thx will adapt (import out at rdfs & copy preflabel/definition also to rdfs)

isDefinedBy can as I see the definition also be used for elements of ontologies (domain and ranges are resource in general). It feels a bit more semantic then seeAlso… 😊

but now that part of that definition is copied to rdfs, seeAlso becomes an alternative option.

(lets further discuss among ourselves in nen2660/sml)

 

gr Michel

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

Van: Sander Stolk <sande...@semmtech.nl>
Verzonden: woensdag 30 juni 2021 08:38
Aan: Bohms, H.M. (Michel) <michel...@tno.nl>
CC: topbrai...@googlegroups.com; benno.k...@rws.nl
Onderwerp: Re: [topbraid-users] label position

 

Dear all,

 

I concur with David's view on the matter. SKOS and RDFS or OWL worlds are best kept separate. The import, too, is best left out.

 

Referring to one or the other 'world' via rdfs:isDefinedBy or rdfs:seeAlso is certainly an option. 

From practice, I see rdfs:isDefinedBy mostly used for indicating the ontology itself that has defined the term/URI.

e.g.,   <https://example.org/Activity>  rdfs:isDefinedBy  <https://example.org> .

Therefore, I wonder whether rdfs:seeAlso would not be preferable over rdfs:isDefinedBy when linking a SKOS perspective to an RDFS one. In fact, considering the SKOS version will, as Michel just mentioned, not truly contain any additional information compared to the RDFS version, perhaps it is better to leave such cross-references out altogether.

 

Best wishes,

Sander

 

Op di 29 jun. 2021 om 16:01 schreef Bohms, H.M. (Michel) <michel...@tno.nl>:

 

--

 

T M W

Sander Stolk  Head of Innovation  In office on Monday, Tuesday, Friday +316 142 750 66  sande...@semmtech.com www.semmtech.com

The information in this message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it.