OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (OSLCCORE-47) Cardinality of properties (oslc:occurs)

    [ https://issues.oasis-open.org/browse/OSLCCORE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61245#comment-61245 ] 

Martin Pain commented on OSLCCORE-47:

My view (if trying to keep it simple) is that resource shapes are constraints on representations, not resources, so inferred triples would not be included in the oslc:occurs count.

(Part of the reason for this is that representations are always kind of closed-world - either a triple is in the representation or not - whereas the resource's "true state" ought to be open-world, being RDF - any other resource or even server can include triples about it.)

However, on reading the specs they do give the impression that these shapes are constraining the "true (complete) state" of the resource. Or, that servers may apply that constraint to the *storage* of the resource, not just its representation in HTTP (as indeed storage is a form of representation, just not a REST representation). In which case they would need to make a call as to whether they are storing implied triples and therefore whether the oslc:occurs value applies to it. I think it's fine for implementations to apply the shapes to their storage of the resources, but ought to exclude inferred triples fro that - (unless perhaps the implementors know for sure (from out-of-band information) that the inference was intended to be included).

I think that perhaps we should state that when resource shapes are used in ways defined in OSLC specs (e.g. on creation factories, query capabilities, instanceShape links, etc) then they don't include implied triples. But that we don't prohibit implementations including implied triples when shapes are used in other ways. (However that we also suggest that any other uses exclude implied triples unless they really need to include them.) I think this approach would make things simple for basic OSLC usage, but allow the greatest re-use.

> Cardinality of properties (oslc:occurs)
> ---------------------------------------
>                 Key: OSLCCORE-47
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-47
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: Nick Crossley
>            Assignee: James Amsden
>            Priority: Minor
> The oslc:occurs value in a property definition indicates the cardinality of that property. It is not clear if that includes inferred triples, and no guidance is provided about whether clients should assume resources follow the cardinality constraint.
> Where inference is being used, and where shapes or properties include rdfs:subClassOf, rdfs:subPropertyOf, or owl:sameAs, a resource may have inferred triples that do not follow the cardinality rules for a shape, even though the explicitly provided triples do follow those rules. Should the OSLC specification provide any guidance in such cases?

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]