Define an easier profile of RDF

[dbooth-boston]

"We could probably put together a profile that disallows certain
RDF usages and encourages certain idioms"
https://lists.w3.org/Archives/Public/semantic-web/2018Nov/0216.html

[azaroth42]

Suggest that this could be a tag in its own right for issues to discuss what should be in the easy profile and what not

[dbooth-boston]

@azaroth42, I am willing to create a tag for this purpose, but I wonder if it might be clearer if we explicitly list candidate profile features here, and reference the related issues.

[azaroth42]

Okay, I'll start ...

Every resource should have exactly one class, given with rdf:type

[namedgraph]

Wouldn't that give users the idea that RDF is like object-oriented model, where an object is an instance of a single class? If you take inference into account, I would say there are basically no RDF datasets that fit this if profile. If a resource description uses more than one property with ranges that are different types, you already got 2 types for that resource.

[HughGlaser]

It's a great idea to just gather profile things, possibly without lots of discussion on each.
I wonder if there is such a list somewhere in tutorial material, but maybe the lack of such a list is why we need this activity?
Interestingly, I'm not quite sure about your first item, @azaroth42 , as it can be hard and useless to do when acquiring stuff from large and diverse sources.
But that is probably the way of the list - nothing will be universal, but it is good practice to do it if you can.
But I do wonder about subClass - do I have to use rdfs:subClass if I want a resource to be both a foaf:Person and a mySchema:Woman.
I guess I am allowed to ask for clarification in this thread?

[azaroth42]

@namedgraph It would make it easier for people who understand object-oriented programming and do not have a strong grasp of RDF (e.g. the target audience) to work with the data, as they could easily make an ORM that turned RDF classes into OO classes and instantiated RDF resources using those OO classes. I agree that if you turn on inferencing, you will never satisfy this constraint, and thus you should not turn on inferencing.

@HughGlaser If you want the class of the instance to be eg:Woman then yes, you would need to construct it as a subClass of foaf:Person. Then the ORM would know that it was a Person by inheritance.

@dbooth-boston And that the first one generated two comments in under two hours I think validates the need for a separate tag with separate issues.

[HughGlaser]

Yes, @azaroth42 , I think @namedgraph 's comment is instructive.
We should be very happy for people to get the "wrong" idea about RDF, if the gives them quick entry and enables them to do what they want with it.

On subClass, I'm going to live with that :-)
We can say you should only have one rdf:type per resources (and should have it).
Like everything else that will appear here, it is guidance, and if you do something else, you do it knowingly.
So I would aim to only have things be foaf:Person (and put their gender in) or mySchema:Woman.

[namedgraph]

@azaroth42 from my experience, ORM is absolutely the wrong approach for RDF. It is a subject to both impedance mismatch and leaky abstractions.
RDF is more flexible at modeling, and methods can simply be replaced by state changes. That way RDF software can eliminate the domain-specific OO layers completely, leaving only the generic API for graph management and queries.
If anything, OO model should be more like RDF, not the way around.

[dbooth-boston]

@azaroth42, I think I previously misunderstood your suggestion for a new tag. Now I think you meant a tag to act as a new issue category, which I have now created: "Category: easier profile". See https://github.com/w3c/EasierRDF/labels
I hope that's what you meant. We can give it a try and see how it works out. I will update the home page accordingly.

[HughGlaser]

Which brings to another point ... :-)
I think we should be looking for syntactic things, not semantic.
Syntax things are (I think) much easier to understand than semantic, and also easier to specify.
And syntactic rules are easier to check and provide analysis and understandable suggestions about.

So I read
"Every resource should have exactly one class, given with rdf:type"
as saying the resource should have one and only one type-defining triple.
That does not mean that it only has one type.
If you agree, @azaroth42 , you would like to re-word a bit?

[azaroth42]

@namedgraph I think you're missing the point of this exercise.

Per @HughGlaser:

We should be very happy for people to get the "wrong" idea about RDF, if the gives them quick entry and enables them to do what they want with it.

💯!

@HughGlaser I do agree. The intent is that there should be a trivial way to take the properties of the resource and construct an in-memory instance of a class, that can manage properties, functions and so forth.

@dbooth-boston Thanks! Will create a new issue with that label for this discussion

[chiarcos]

Not sure where this thread is going, but when designing a simpler profile, the first thing would be to identify potential use cases.
I basically see three use cases for a simpler profile:

(1) didactic (basically a learning tool, identifying most essential vocabulary elements but leaving out less intuitive parts),
(2) for data providers (possibly coupled with a recommended syntax, maybe TTL, because of its similarity with SPARQL),
(3) for data consumers (in fact, this might be a simpler SPARQL profile, instead)

I think (3) and (2) would be most essential, and the following possible simplifications would be in line with that:

• motivate the profile as a graph syntax (for use case (1)), use one recommended serialization (say, Turtle or JSON), use a query language that matches this serialization (say, SPARQL or GraphQL)
• (assuming Turtle:) restricted vocabulary for lists (using only () notation for use case 2 and only rdf:rest*/rdf:first property paths for use case 3)
• ? closed world assumption (makes life easier for consumers, but not for producers) -- if so, we don't need rdf:nil here
• beyond the vocabulary elements mentioned before, cover only rdf:type, rdfs:Class, rdfs:subClassOf, rdfs:subPropertyOf, owl:ObjectProperty, owl:DatatypeProperties, rdf:rest, rdf:first, rdf/rdfs datatype properties
• a uniform "lite" namespace for rdf and rdfs vocabulary elements (grounded by owl:sameAs into rdf and rdfs)
• no reification
• no RDFS inference
• no XMLLiterals
• no blank nodes
• ? no language tags, no explicit types (makes life easier for producers, but not for consumers)

This would be a cut, deep into the core of the SW, but I am not suggesting to abandon inferences (nor anything else). Instead, I'm suggesting to reserve this for advanced users. This Lite profile would be a plain graph format, then. I would not like to see the one type per representation, because then, this profile has no advantage anymore in comparison to XML or plain JSON other than being upward-compatible with proper RDF and RDFS.

Wth these or similar specification, the spec for the profile would become short and neat ;) The semantics would be extremely shallow, but it would allow newbies to both populate ABoxes and to access end points (regardless of whether the triples they find are inferred or explicit).