rdfs using owl

[Bohms, H.M. (Michel)]

Dear Irene, David

 

We got the following question on our EU standard proposal:

 

Why are you using owl in your rdfs spec (for owl:Ontology and owl:imports).

 

Isn’t this simply best practice?

Could you do without ie be RDFS pure?

 

But how then do you specify the graph uri and how to deal with imports??

 

Thx for your views, 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.

 

[Holger Knublauch]

owl:imports is the only feature of OWL that even SHACL mentions because there is no real alternative, and it is quite harmless.

Holger

--
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/16aed2c420a14a8eae0a9fc7db8b772a%40tno.nl.

[David Price]

On 15 Jun 2021, at 14:07, Holger Knublauch <hol...@topquadrant.com> wrote:

owl:imports is the only feature of OWL that even SHACL mentions because there is no real alternative, and it is quite harmless.

Holger

I was writing something which I guess explains Holger's “no real alternative” statement. Modularization of RDF-based ontologies and data is the business use case being supported and it cannot be done in formally defined, not implementation-specific way using only RDF and RDFS.

TBC uses owl:import to define the graph closure for a domain of interest.

RDFS says zero about named graphs, depending on RDF. RDF talks about RDF Datasets and the default graph which is the union of everything visible to the RDF tool (as far as I can interpret it) but the spec says nothing about how the “collection of RDF graphs” is defined or located. It also says nothing about how the “set of RDF Triples” that constitute the RDF Graph is defined or located.

Give that neither the “set of triples” or “collection of graphs” is formally defined, it’s easy to argue that the SPARQL GRAPH keyword actually has little or no formal meaning (does one graph need another and if so how is that relation specified?).

OWL introduces a more powerful way to manage and relate named graphs and TBC takes advantage of that so users can control what triples are visible where. Technically I think that is what the RDF spec means by “RDF source” and I think that equates to the Ontology Document idea in the OWL2 spec.

Anyway … RDFS purists can simply ignore (or remove) anything in the OWL namespace if they have some other way to build RDF Datasets and Named Graphs and graph relations in their tooling. In a way the OWL simply provides hints about what the graph URIs are and how they are related to other graphs for humans when ignored by the tool. In your standards case, you started with OWL and “dumbed down" everything you could into RDFS leaving only what formally defines the named graph closure.  Note that the OSLC which produces RDFS standard ontologies uses owl:Ontology to manage named graphs, so TBC is also just following industry usage patterns (as are you).

WRT “best practice” I do sometimes find RDFS that has nothing defining how the named graphs relate, sometimes with multiple named graphs in the same RDF/XML or TTL file. Usually what you find is that the developers of that content actually manage everything separately and then concatenate it into a singe TTL at the end. It seems they assume whatever triples they produce is *all* the triples and/or can be concatenated with anything else - IMO very odd indeed and not nearly as useful to others as having the original separate files.

Not sure if that helps the EU, but explains how TBC works and why. 

Cheers,

David

On 15/06/2021 10:23 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users wrote:

Dear Irene, David

 

We got the following question on our EU standard proposal:

 

Why are you using owl in your rdfs spec (for owl:Ontology and owl:imports).

 

Isn’t this simply best practice?

Could you do without ie be RDFS pure?

 

But how then do you specify the graph uri and how to deal with imports??

 

Thx for your views, 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/16aed2c420a14a8eae0a9fc7db8b772a%40tno.nl.

-- 
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/3ea7c130-956a-b9bf-ae03-679b73dd3773%40topquadrant.com.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

Thank you Holger, David

 

Very useful arguments we can use in our justification for choices,

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/F23EDF2A-6EE4-42E3-9B92-43536AEB72BD%40topquadrant.com.

[robatki...@gmail.com]

On the subject of

 " WRT “best practice” I do sometimes find RDFS that has nothing defining how the named graphs relate, sometimes with multiple named graphs in the same RDF/XML or TTL file. Usually what you find is that the developers of that content actually manage everything separately and then concatenate it into a singe TTL at the end. It seems they assume whatever triples they produce is *all* the triples and/or can be concatenated with anything else - IMO very odd indeed and not nearly as useful to others as having the original separate files."

This "flattening of imports in a selective way that suits some specific needs I have.. " is a very common pattern (and IMHO an anti-pattern that loses information about interoperability intent ..)

Having come across this repeatedly when trying to determin or check the scope of application of standardised models,  I generated a "little" tool that addressed a few other issues as well, including non-resolution of identifiers for vocabularies only accessible via idiosyncratic repository interfaces...

Its at https://github.com/RDFLib/profilewiz

my hope is to be able to incorporate some of this in future into the TQ environment to support interoperable interfaces to graph using JSON-LD with controlled JSON schemas.  I can imagine using an EDG instance to support the SHACL generation component and validation services as well as publishing the results.