Unclear applicability of prefix declarations

[wouterbeek]

The SHACL standard introduces support for representing prefix declarations.

According to the standard, these prefix declarations can be used on any node (not only ontologies):

The recommended subject for values of sh:declare is the IRI of the named graph containing the shapes that use the prefixes. These IRIs are often declared as an instance of owl:Ontology, but this is not required.

But the vocabulary contains the following assertion (requiring everything for which a prefix is declared to be an ontology):

sh:declare rdfs:domain owl:Ontology.

What is the intended utility of SHACL prefix declarations? Are they intended to be generic? Users would be able to represent prefix declarations for dataset and queries, among other things. Or are they intended to only apply to ontologies?

[HolgerKnublauch]

The rdfs:domain assertion does not "require everything for which a prefix is declared to be an ontology". This is RDFS, so it would only ever be an inference. The statement was meant to be a hint for tools that rely on RDFS/OWL to suggest that owl:Ontologies are a good place to store sh:declare triples. The reason why we recommend owl:Ontologies is that those also carry the owl:imports statements, and those are automatically followed when prefixes are resolved. Basically, whenever someone publishes a vocabulary, it would be a nice gesture to also declare the preferred prefix for that namespace at the owl:Ontology (or other resource that has the URI of the graph itself). However, you can theoretically also place them at non-Ontology resources, if you have use cases for that.

[wouterbeek]

There are indeed properties that are used to provide domain hints. An example of this is sdo:domainIncludes which indicates that a property may be used on instances of a certain class.

But rdfs:domain is not such a property at all. p rdfs:domain C. states that everything with property p is also an instance of C. That's just the way it is according to the RDF standard.

Indeed, from p rdfs:domain C and s p o the entailment s a C follows, but this is only a syntactic derivation. s is already an instance of C semantically. Entailment only makes the implicit knowledge explicit.

I must be overlooking something here, since you are obviously aware of these standards as well :-/

[HolgerKnublauch]

Yes I believe I understand these standards :)

I am aware of various tools that use rdfs:domain as a hint for forms. It is much more widely used than sdo:domainIncludes, even if this approach can be considered a historical hack.

In any case, has the original question been answered?

[wouterbeek]

Sorry Holger, I'm not sure how to explain my question further... The way I understand the RDF standards, sh:declare cannot be used on anything that is not an OWL ontology. Apparently there are two readings of rdfs:domain in the SW community:

1. The semantics of rdfs:domain are determined by tools. E.g., one tool may derive that all subject terms of sh:declare are OWL ontologies, while another tool may merely suggest that these term could denote OWL ontologies. The meaning of datasets that use rdfs:domain depends on the tools that you use.
2. The semantics of rdfs:domain are determined by standards. Specifically, all subjects terms of sh:declare must be OWL ontologies. sh:declare cannot be used on things that are not OWL ontologies.

I strongly believe that (2) is the correct reading, but if I understand your replies correctly then authors of the SHACL standard (also a W3C document) seem to believe that (1) is the correct reading.

I'm not sure what to make of this :-(. TWISI reading (1) breaks the fundamental idea of the SW: that meaning can be portably encoded.

I'm a bit worried now. Is this change in direction from W3C documented somewhere? This would be the end of the original SW idea.

[HolgerKnublauch]

The semantics of rdfs:domain are determined by the RDFS standard. And according to this standard, the meaning is that if some subject has a sh:declare then it will be inferred that the subject is an instance of owl:Ontology. This is as intended, and I don't believe your strict interpretation of RDFS above is correct. Using rdfs:domain doesn't forbid anything.

Whether some tools also use rdfs:domain to derive hints for a UI is up to them, but not part of the RDFS standard.

[wouterbeek]

It's strange that we do not have the same understanding about the RDF standard :-/ For me the following is very clear:

If < x,y > is in IEXT(I(rdfs:domain)) and < u,v > is in IEXT(x) then u is in ICEXT(y).

(Source: https://www.w3.org/TR/rdf11-mt/)

^ This is independent of which tools somebody uses, e.g., whether they use a reasoner or a hint-giving system or no tool at all. The semantics of rdfs:domain stay the same.

It would also be good to have somebody else from W3C / SHACL standardization take a look at this, since the two of us are a bit at a semantic stalemate here :-P

[TallTed]

@wouterbeek --

(Please note that both @HolgerKnublauch and I were members of the W3C WG that produced the SHACL Recommendation.)

In an RDF Ontology, you can declare the Range and Domain of a Property -- but they have no enforcement. RDF has no concept of "referential integrity" which is how other database standards (primarily e.g., SQL) enforce the ideas of Range and Domain (which have different names in the other standards).

Range and Domain may be used as hints when inputting instance data that is meant to conform to an Ontology. According to the authors of the Ontology, a Subject which has that Property is meant to be an instance of the declared Domain, and an Object of that Property is meant to be an instance of the declared Range. In a perfect world, each of these instances would be declared to be such -- e.g.,

{ :instance1 rdf:type :domain1 . 
  :instance2 rdf:type :domain2 
  :instance3 rdf:type :range1
  :instance4 rdf:type :range2
}

When the instances found in Subject or Object position of triples with those Properties/Predicates are not explicitly declared to be of any particular Type, Range and Domain may also be used as hints, suggesting that those instances are members of the Range or Domain. In other words, the Type of an instance in the Subject position with that Property/Predicate may be inferred to be (or implicitly typed as) the declared Domain. The Type of an instance in the Object position with that Property/Predicate may be inferred to be (or implicitly typed as) the declared Range.

All that said, dirty data exists everywhere. There is no guarantee that any instance data conforms to any ontology, even if that is the goal, stated or implied, by the curators of that data. Hints like the Range and Domain declared in any given Ontology give you an idea of what is intended to be in the Subject and Object positions with a given Predicate/Property -- and thus give you an idea of what sorts of tests (expressed in SHACL, for instance) to run against that instance data to confirm whether the instances conform to the Ontology.

The results of those tests can then give you an idea whether the Ontology needs revision, or the data set, or the tools operating against that data...

Maybe this helps clarify things a bit?

[wouterbeek]

@TallTed Thanks for clarifying. It is now clear to me that the reply by @HolgerKnublauch is not idiosyncratic and is apparently a/the new W3C direction for linked data (at least in the context of the SHACL WG).

I of course disagree with this new direction, since it moves the determination of meaning from standards (= the original SW vision) to applications.

According to the standards, the meaning of:

sh:declare rdfs:domain owl:Ontology.

ex:myQuery sh:declare [ ... ].

is very clear:

If < x,y > is in IEXT(I(rdfs:domain)) and < u,v > is in IEXT(x) then u is in ICEXT(y).

(Source: https://www.w3.org/TR/rdf11-mt/)

^ ex:myQuery is an OWL ontology (which is not intended / what prompted me to create this issue in the first place). This is independent of which application I use, and independent of whether I may or may not have made a mistake in my sh:declare assertion (the 'dirty data' point that Ted mentions). This is the original, standards-based semantics,

According to the new W3C / SHACL WG direction, whether ex:myQuery is an OWL ontology or not is determined by applications. One application can deduce that ex:myQuery is an OWL ontology, another application can indicate ('hint') that ex:myQuery is likely to be an OWL Ontology (whatever that may mean), and a third application can do something different as well, etc. This is a completely new approach that I call application-based semantics.

This is a very significant shift from the original SW vision. This radical shift should be communicated with the community much more broadly. It feels wrong that this is introduced through a property (sh:declare) in SHACL.

[azaroth42]

:+1: to @wouterbeek's disagreement.

One might now say that owl:sameAs owl:sameAs skos:exactMatch -- that the subject and object of the owl:sameAs predicate can be deduced to be the same entity in some application contexts.

Easier would be to issue an errata for SHACL that walks back the use of rdfs:domain for the sh:declare predicate. It seems especially odd that a standard focused on precision and validation should be treat one of the core axioms of rdfs so loosely. I'm interested to know if ShEX (for example) also has this explicit vagueness, @gkellogg?

[white-gecko]

Referring to the Standard documents It might be relevant to take "RDF Schema 1.1" (https://www.w3.org/TR/2014/REC-rdf-schema-20140225/) into account.

3.2 rdfs:domain

rdfs:domain is an instance of rdf:Property that is used to state that any resource that has a given property is an instance of one or more classes.

A triple of the form:

P rdfs:domain C 

states that P is an instance of the class rdf:Property, that C is a instance of the class rdfs:Class and that the resources denoted by the subjects of triples whose predicate is P are instances of the class C.

Where a property P has more than one rdfs:domain property, then the resources denoted by subjects of triples with predicate P are instances of all the classes stated by the rdfs:domain properties.

The rdfs:domain property may be applied to itself. The rdfs:domain of rdfs:domain is the class rdf:Property. This states that any resource with an rdfs:domain property is an instance of rdf:Property.

The rdfs:range of rdfs:domain is the class rdfs:Class. This states that any resource that is the value of an rdfs:domain property is an instance of rdfs:Class.

(https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_domain)

and

4. Using the Domain and Range vocabulary

This section is non-normative.

This specification introduces an RDF vocabulary for describing the meaningful use of properties and classes in RDF data. For example, an RDF vocabulary might describe limitations on the types of values that are appropriate for some property, or on the classes to which it makes sense to ascribe such properties.

RDF Schema provides a mechanism for describing this information, but does not say whether or how an application should use it. For example, while an RDF vocabulary can assert that an author property is used to indicate resources that are instances of the class Person, it does not say whether or how an application should act in processing that range information. Different applications will use this information in different ways. For example, data checking tools might use this to help discover errors in some data set, an interactive editor might suggest appropriate values, and a reasoning application might use it to infer additional information from instance data.

RDF vocabularies can describe relationships between vocabulary items from multiple independently developed vocabularies. Since IRIs are used to identify classes and properties on the Web, it is possible to create new properties that have a domain or range whose value is a class defined in another namespace.

(https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_domainrange)

[white-gecko]

Looking at

If < x,y > is in IEXT(I(rdfs:domain)) and < u,v > is in IEXT(x) then u is in ICEXT(y)

(https://www.w3.org/TR/2014/REC-rdf11-mt-20140225/#rdfs-interpretations)

(even though I'm not that convenient with the notation) in my eyes this is an implication/logical consequence/entailment

If a and b then c (a ∧ b → c)

if it rains the streets get wet, it is not a precondition, that the street is wet or a restriction, that the street has to be wet, so that it can rain, but it follows from the rain that that the street gets wet.

so from x rdfs:domain y and u x v can be implied that u rdf:type y.

I think this is also supported by

_	If S contains:	then S RDFS entails recognizing D:
rdfs2	aaa rdfs:domain xxx . yyy aaa zzz .	yyy rdf:type xxx .

(https://www.w3.org/TR/2014/REC-rdf11-mt-20140225/#patterns-of-rdfs-entailment-informative)

Now looking at

2. The semantics of rdfs:domain are determined by standards. Specifically, all subjects terms of sh:declare must be OWL ontologies. sh:declare cannot be used on things that are not OWL ontologies.

I would rephrase it that “All subject terms of sh:declare can be implied to be OWL ontologies”.

This looking at

1. The semantics of rdfs:domain are determined by tools. E.g., one tool may derive that all subject terms of sh:declare are OWL ontologies, while another tool may merely suggest that these term could denote OWL ontologies. The meaning of datasets that use rdfs:domain depends on the tools that you use.

Tools can now decide what to do with this additional information that the subjects of sh:declare are OWL ontologies. But looking at all of the other surrounding text of the RDFS Standard I can not see that there is anything that a tool MUST do with this information.

[timbl]

@wouterbeek You seem to confuse everyone when you suggest there are two different things going on which are inconsistent. They are both going on but they are consistent.

1. The semantics of rdfs:domain are determined by standards. Specifically, all subjects terms of sh:declare must be OWL ontologies. sh:declare cannot be used on things that are not OWL ontologies.

Well, I would prefer to say "if sh:declare is used on something then you know it is an ontology"

2. The semantics of rdfs:domain are determined by tools. E.g., one tool may derive that all subject terms of sh:declare are OWL ontologies, while another tool may merely suggest that these term could denote OWL ontologies. The meaning of datasets that use rdfs:domain depends on the tools that you use.

NO - the semantics are not based on tools, but tools use the extra knowledge they get from the domain statements (etc) to typically make like easier for the users, like

• if the developer is making editor for ontologies, suggest adding a form field for a prefix
• If the user wants to provide an ontology, add the thing in question to the pool of things you suggest
• if the user is viewing something which has a prefix, then default to the Ontology editor for it

So tools can be smart by using the extra information in the domain statement to do things better. But you can't force a tool builder to do that. But the things tool builders do are all consistent with the RDFS semantics. They are not different semantics for RDFS.

(For example a lot of my code uses RDF and all the properties in the store and all the range and and domain triples it knows to generate a set of classes we know the thing to be in, and then dispatches the view renderer as a function of the most specific class.)

That responds to your message half way down. If your original issue was that you want to be able to use the shex:prefix predicate on things which are not ontologies, like you want to be able to give person a prefix, then you can suggest the domain statement be removed as an issue. But don't suggest the whole of the semantic web wold is crumbling around us.

[gkellogg]

I see this debate/misconception in the light of the decision by schema.org to abandon rdfs:domain/range in favor of sod:domainIncludes/rangeIncludes because typically what is expected is to give guidance for checkers and web forms. My own Structured Data Linter is an example of such a tool which will use RDFS inference to add such an inferred type triple, and to give a warning when the declared type of the subject/object clearly is inconsistent with the stated domain or range. (It takes further license with domainIncludes/rangeIncludes in the case that only a single IRI is declared, but that's another matter).

I think what we're seeing is the evolution of the logical concepts from a strict interpretation/inference of meaning towards guidance for such checkers and form generators. This seems evident in this debate, and is a big reason that shape specs and tools seem to be the direction forward for many, perhaps relegating some of the more gnarly aspects of OWL academic Ontologists.

The fact is, data is what exists or is generated on the web, not necessarily what we want it to be. To the degree that the semantics and/or shape specs such as SHACL and ShEx support this, RDF is a viable platform. I believe it is because of some perceived mismatch (or complexity) that the informal Property Graph movement came about (for which RDF* is trying to close the gap). If practice is inconsistent with the specs, then we either need to adapt and change or become irrelevant.

As was said, just because data can be inferred doesn't necessarily related to the authors intention; I think it's proper to give feedback when there is such an inconsistency.

In the case of using sh:declare for something that is not necessarily an ontology, the fact that you can infer that it is an ontology does not, in and of itself, create any problem. It's only when the properties of such an ontology are in conflict with other statements in the data graph that an issue arises.

Particularly as non-native users of Linked Data/SemWeb technologies are increasingly adopting tools which support this in order to further their business purposes, I think it's important for the community to recognize and support this. That may mean revisiting some of the semantics to clarify any discrepancy between conventional and formal usage, if only in an informative Note.

[pjhayes]

Someone asked me to join this discussion in my role as coauthor of the RDF semantics.

Rather than pick on particular pieces of wording, I will try to (re)state some of the relevant basics.

1. The RDF semantics spec is normative. It allows RDF applications - semantic extensions - to add (well-documented, hopefully) semantic constraints but not to remove or change any. So the entailment
   A rdf:domain B . , X A Y . |= X rdf:type B is a valid entailment in any use of RDF.

2. RDF engines are not obliged to draw valid RDF entailments, nor are they prohibited from using RDF in ways that amount to non-valid entailments. The only constraint that the semantics applies is that non-validly-entailed conclusions might not preserve truth. It does not prohibit or mandate any operations or actions by software.

3. Nevertheless, it would be bad form to systematically use something in the RDF namespace in a way that seemed to presume a semantics which was at odds with the normative semantics, as this would at least generate confusion about the intended meanings specified by the published semantics. And as the main (only?) reason to publish a formal semantics as a normative part of the specification was to pre-emptively avoid such confusion, this would be regrettable.

4. That said, I must agree with Greg Kellogg: "data is what exists or is generated on the web, not necessarily what we want it to be. ... If practice is inconsistent with the specs, then we either need to adapt and change or become irrelevant." Ultimately, the meaning of any piece of text used on the public web is determined by its actual use, and if this starts to be both widespread, widely accepted and diverges from its original published intended meaning (as with, notoriously, owl:sameAs) then it behooves the publishers to do their best to adapt their formal declarations to try to conform to this actual usage. I don't believe this rather idealistic observation applies to the present case, however.

Pat Hayes

[pjhayes]

Oh, one more: some people have referred to THE domain of a property (my emphasis). Bear in mind that in RDF a property can have many domains. If you are used to thinking in classical mathematical terms, then 'the' ('the real') domain would be a subset of the intersection of all the RDF domains.

Pat

[wouterbeek]

Thank you @timbl @pjhayes and others, I'm following your advice:

you can suggest the domain statement be removed as an issue

I've opened a new issues that proposes the removal of this particular triple: #131

[wouterbeek]

No, we're not quite there yet... In #131 @HolgerKnublauch still maintains that the sh:declare rdfs:domain owl:Ontology assertion in the SHACL vocabulary "may cause an undesired inference" and "what specific problems does the inference of rdf:type owl:Ontology cause to anyone?" (my emphasis).

This relegation from standards-based semantics to application-based semantics is my main concern. (I can create my own prefix declaration property; that's not the point.) The whole topic of inference is not even to the point in this regard: inference only makes implicit meaning explicit (through an application). According to standards-based semantics the meaning of rdfs:domain is determined as follows:

If < x,y > is in IEXT(I(rdfs:domain)) and < u,v > is in IEXT(x) then u is in ICEXT(y).

^ This is independent of which applications I use: whether I use a reasoner to materialize the semantics through inference, or a hint-giving system, or no application at all, or an application that does not follow W3C standards yet misleadingly uses the rdfs:domain term, etc. As @pjhayes says:

The entailment A rdf:domain B . , X A Y . |= X rdf:type B is a valid entailment in any use of RDF.

^ If I want to use RDF and publish a best practice dataset that uses the SHACL vocabulary, then I cannot chose to disregard sh:declare rdfs:domain owl:Ontology. I cannot do what SHACL authors @HolgerKnublauch and @TallTed claim and use rdfs:domain as a mere hint.

How would users of my dataset containing ex:myQuery sh:declare [...] understand that ex:myQuery does not belong to the extension of OWL ontologies? How are they to deduce that I intended sh:declare rdfs:domain owl:Ontology only to be a hint? This is something the W3C authors who support application-based semantics have not yet explained: how do I transmit meaning to others, if others are using different applications than me? (E.g., what is a hint in my application may not be a hint in your application.) This is the main problem that standards-based semantics solves. This is a core feature of the Semantic Web.

And what if I were to use a standards-compliant inference application? How does my standards-compliant reasoner determine that this particular rdfs:domain assertion in the SHACL vocabulary should not be used for reasoning, but only for hints? The arguments from the proponents of application-based semantics are rather weak: there is dirty data (owl:sameAs) on the web anyway, so my reasoner should not trust the rdfs:domain assertion by W3C anyway. But we are talking about a vocabulary from the standardization organization itself. The fact that somebody else does not follow best practices and publishes 'dirty data' does not give carte blanche for the inclusion of rdfs:domain assertions in W3C vocabularies that do not follow the RDF standard.

I hope that I have clarified my worries a bit further. I really believe that this is a fundamental issue (the standardized transmission of meaning). I am really surprise that this is so broadly disputed.

[klinovp]

Correct me if I am wrong but you seem to be saying that since your dataset uses some RDFS vocabulary (either directly or via owl:imports), every tool should process it under the RDFS semantics (eg. SPARQL with RDFS Entailment Regime rather than SPARQL with simple entailment). That seems odd and contrary to my experience.

Having said that, I agree that if you know that the semantics of rdfs:domain causes unwanted entailments in your data, you may want to declare that your dataset should not be processed under the RDFS entailment. That seems reasonable to me (though I'd also prefer that the offending rdfs:domain axiom weren't used at all). I am not aware of any standard means to communicate that.

The most problematic case is when a tool tries to apply RDFS entailment to some axioms/triples in the data but not others. That seems like a can of worms.

[wouterbeek]

if you know that the semantics of rdfs:domain causes unwanted entailments in your data, you may want to declare that your dataset should not be processed under the RDFS entailment

@klinovp But notice that the meaning of rdfs:domain is independent of whether or not I choose to also use entailment to make this meaning explicit.

For me it is clearer to think about meaning, and how that is standardized. When I read some of these comments, I think that entailment may have muddied the discussion.

Since entailment requires an application, most of the discussion is now about whether an application is allowed to use rdfs:domain to give hints, whether an application should 'clean' incorrect uses of rdfs:domain on the web, etc. This relegation from standards-based semantics (which are very clear, see @pjhayes post) to application-based semantics (which are very unclear: who is going to determine whether meaning in my application equals meaning in your application?) is what worries me.

[klinovp]

The RDFS semantics is indeed independent of whatever you choose to do with your data. I don't think anybody disagrees with that. However, as a publisher of a dataset, you cannot force any data consumers to process it under the RDFS semantics. It's their choice and always has been. They can always treat it as simple RDF.

PS. entailment does not require an application. It's perfectly possible to talk which entailments hold in a particular dataset under particular semantics without any reference to any particular application. Tons of papers do that.

[white-gecko]

Sure, you need some application in the widest sense to materialize implicit statements. (application in the widest sense can also be human interpreting the existing statements and materializing the implicit statements.) But the meaning of rdfs:domain is independent of whether or not I explicitly write down the additional triple.

If @wouterbeek has a use case in which instances of a class that is disjoint with owl:Ontology should be the subject of a triple including sh:declare as a property. I think this is a valid point towards removing the domain-axiom.

I personally also don't like the idea of using rdfs:domain and rdfs:range as a hint for users or applications as this does not really follow from the definition of rdfs:domain and rdfs:range. As we are speaking about SHACL, I think SHACL is much more suited for applications and users to be guided in constructing a meaningful graph. Why not adding something like:

ex:declareHint a sh:PropertyShape ;
    sh:inversePath sh:declare ;
    sh:optional true ;
    sh:class owl:Ontology .

or

ex:declareRestriction a sh:PropertyShape ;
    sh:inversePath sh:declare ;
    sh:or (
        [
            sh:class owl:Ontology ;
        ]
        [
            sh:class … some other class … ;
        ]
    ) .

[jaw111]

@white-gecko said:

Why not adding something like:

ex:declareHint a sh:PropertyShape ;
  sh:inversePath sh:declare ;
  sh:optional true ;
  sh:class owl:Ontology .

Worth to note:

sh:optional
    a rdf:Property ;
    rdfs:label "optional"@en ;
    rdfs:comment "Indicates whether a parameter is optional."@en ;
    rdfs:domain sh:Parameter ;
    rdfs:range xsd:boolean ;
    rdfs:isDefinedBy sh: .

Entails:

ex:declareHint a sh:Parameter .

Though not sure it is correct to use sh:optional in this context.

[white-gecko]

I don't know, if this is ok, … but in the document is says

The class sh:Parameter is defined as a SHACL subclass of sh:PropertyShape

So the sh:PropertyShape and sh:Parameter are related …

[TallTed]

The issue here has been discussed in much more detail in #131, and appears to have come down to a misunderstanding of the English language used in the SHACL specification, which led to a misuse of the sh:declare predicate in @wouterbeek's instance data, which has led to issues with some application or use of that instance data.

The best options for @wouterbeek appear to me to be to either:

1. correct their instance data (optimal)

or

2. use a local copy of the SHACL ontology in which they change one instance of rdfs:domain to <https://schema.org/domainIncludes>

[wouterbeek]

@TallTed is correct: I misunderstood the natural language section from the SHACL standard :-/

As @TallTed indicates his second solution is not optimal, since modifying the SHACL vocabulary locally makes it difficult for users of my data to correctly interpret it. (After all, they too should modify their local copies of the SHACL vocabulary, significantly complicating the portability of meaning.)

I'm now following his first solution, using tp:prefixDeclaration to assert prefix declarations for queries (and other resources that prefix declarations can legitimately be asserted for, yet are not OWL ontologies).

[TallTed]

@pfps - Would you mind explaining your "thumbs down"? I don't know what you mean by it, especially given @wouterbeek's closing comment.

[pfps]

The SHACL ontology document at https://www.w3.org/ns/shacl.ttl contains

sh:declare
    a rdf:Property ;
    rdfs:label "declare"@en ;
    rdfs:comment "Links a resource with its namespace prefix declarations."@en ;
    rdfs:domain owl:Ontology ;
    rdfs:range sh:PrefixDeclaration ;
    rdfs:isDefinedBy sh: .

So, according to W3C Semantic Web standards this document is stating that the denotation of the subject of a triple with sh:declare as predicate is an OWL ontology. This statement is independent of any tool or inference process. This statement is also independent of whether there is a triple anywhere that directly states that the subject denotion is an OWL ontology. This statement is also independent of whether SHACL (or indeed any other tool or formalism) is using any particular kind of entailment or even no entailment.

To think otherwise is to deny the W3C Semantic Web standards. Of course, any document is free to do so, with a notable exception of W3C standards documents absent some very strong wording in the document to the effect that there is something wrong in the W3C standard that is being used.

Many postings in this thread appear to not buy into this argument.

[wouterbeek]

@pfps You voice exactly my worry: it seems that a large part of the Semantic Web community no longer supports the original, standards-based semantics. Or that at the very least it takes a lot of explaining to get to a point where we can reach common ground on the standard-based semantics being in effect at all.

[rubenw]

The whole thing sounds like "the web is full of dirty data anyway, so it doesn't matter that standards are dirty as well"... which to me does feel like "the whole of the semantic web world is crumbling around us".

[TallTed]

@rubenw

The standards being discussed here aren't actually dirty. There was an english sentence in one spec which was misinterpreted. We (the SHACL WG) had hoped that the accompanying ontology would help to clarify such misinterpretations more quickly.

That said, the web is full of dirty data, so consideration and discussion of how to work with that dirty data, including possible errors in standards documents, is worthwhile.

[wouterbeek]

@HolgerKnublauch We still disagree on this fundamental part:

I didn't see harm in the extra inference, but it seems to bother people. (#131)

My issue is not with inference specifically. Even if a user does not use inference, or switches it off in their toolchain etc., the SHACL vocabulary still states that every IRI that appears in the subject position of a triple with sh:declare as its predicate denotes an OWL ontology. (@pfps expressed this more clearly then I did, see his comment above.) The denotation is determined by the standards (standard-based semantics), not by reasoners that may or may not make some particular denotations explicit (application-based semantics).

I use the word "determine" on purpose: you, and many others in this conversation, seem to consistently maintain that rdfs:domain assertions are things that RDF users can opt out of by using different tools (e.g., a tool that gives hints based on rdfs:domain statements). But tools cannot override, or otherwise change, the RDF semantics laid out for rdfs:domain in the standards. (Tools are of course free to not follow the RDF standards at all, and users are of course free to not follow the RDF standards either, and some users may make mistakes when they publish their data; but neither of us is arguing on behalf of such tools or such users.)

I hope this clarifies our respective positions further.

[wouterbeek]

@timbl You emphasize that there is not a new direction in the way in which W3C seeks to standardize meaning on the web.

At the same time, @pfps observes that "Many postings in this thread appear to not buy into this argument." ← Where “this argument” refers to the standards-based semantics of rdfs:domain, also reiterated by @pjhayes.

If a very large part of the community does not buy into the traditional standards-based semantics of a fundamental property like rdfs:domain, then I think that we could potentially be looking at a new Semantic Web direction after all.

Especially since the part of the community that no longer seems to buy into this argument includes very significant Semantic Web experts, including leading authors of W3C standards.

My main concern is that if we do not discuss our fundamental disagreement about whether, and if so how, meaning is determined by RDF expressions, that this may affect standardization moving forward.

[HolgerKnublauch]

@wouterbeek sorry, you have lost me here. I have said I am OK with removing the rdfs:domain statement that seem to have caused issues. So all that the SHACL spec is saying is that the owl:Ontology is a good (recommended) place for the sh:declare triples. I have no clue where you derive a fundamental new direction of the Semantic Web from any of this.

If others want to continue having debates about "denotation" they are free to do so. The semantic-web@w3.org mailing list might be a better place to continue those topics. This is the data-shapes git repo, not a general semantic web discussion forum. I honestly prefer talking about things that have tangible computational consequences, such as specific inference rules, for the SHACL standard.