test 2
let's try that attachment again 04-rif-irc.txt Description: application/scribe
Programmable XML Fallback and Impact Mechanism (PXFIM)
Ok, so here's what I end up with from the day's discussions. It's a fairly-small generalization from what we're talking about for RIF (that the WG seems pretty comfortable with), to cover all (namespaced) XML. Obviously this is quick-and-dirty write-up, but maybe it gets the idea across. Maybe the abstract enough - s /== Programmable XML Fallback and Impact Mechanism (PXFIM) == Abstract == PXFIM provides forward compatiblity for XML-based languages deployed on the Web, allowing them to evolve in place and to be extended by users independently. It does this by allowing creators of extensions, new languages, and new language versions to publish fallback information, including impact data. This information is used by PXFIM processors to translate documents from new (unimplemented) formats into old (implemented) ones as needed. == Operational Model == Conceptually, a PXFIM processor is a frontend, in front of normal XML-consuming software. Before the regular software consumes any XML document, the PXFIM processor has a chance to transform the document. When deployed, the PXFIM processor is configured with a set of XML Schemas for validating the documents it is allowed to pass to the backend. These schemas communicate to PXFIM which XML languages the backend implements. They should be written tightly, so they do *not* accept anticipated future versions the languages. The PXFIM processor is also configured with a table of weights for different kinds of impacts. This table will be application specific, as detailed [below]. == The Algorithm == Here's what a PXFIM processor must do: 1. Try to validate the input document against each of the backend schemas. If it validates against any of them, pass it through and we're done. Otherwise: 2. Parse the input document for any PXFIM declarations and PXFIM import-control information. 3. If there is no PXFIM import-control information, or if there is and it allows it, dereference all the namespaces used in the document. [@@ some issues about rdf-style URIs, but this is close enough for now.] The returned content should contain more PXFIM declarations or be (somehow) linked to other documents which do. 4. Use these PXFIM declarations [ and maybe others? ] to find the minimal-impact fallback path from the input to one of the backend acceptable schemas.Each step on the fallback path is an XSLT which transforms a document from a new format to an old one, possibly changing the meaning or other characterisitcs. These changes indicated by the associated impact information. 5. If there is such a path, perform the fallbacks, and pass the result to the backend along with the accumulated impact flags. If there is not one, let the backend know that fallback is not possible for this document. == Example Scenario == A new XML language, PianoML is developed for communicating information about pianos. The first version, 1.0, is adopted by several organizations that buy and sell pianos, as well as music schools, moving companies, and a few musicians. It allows them to pass around information about specific pianos (eg Steinway piano #212640, which has alligatored finish and curve-tapered legs). Their inventory systems and various other software is modified to read and write this format. [ It took me several tries to come up with a FooML that didn't really exist. :-) ] After some time, it becomes clear that some useful fields were left out. In version 1.0, there was a one-bit flag saying whether the tuning pegs tended to slip. For version 1.1, some users wanted detailed information about which pegs tended to slip, and how strong the tendency was. This could easily be added, but how would the software written to handle PianoML 1.0 files respond? Some systems would probably fail, some would ignore the new information, some might do other odd things. Fortunately, the PianoML 1.0 specification mandated PXFIM processors for PianoML consumers. Because of this, the creators of PianoML 1.1 could publish PXFIM declarations linked from the PianoML 1.1 namespace document and reasonably expect them to followed. These declarations were written to include a fallback procedure which removed the detailed information about pegs slipping, and set the some-pegs-slip flag if one or more of them were stated as slipping with a tendency of more than 20%. Late on, some moving companies realized it would be helpful to them to further extend PianoML with information helpful to them about which kind of bolts needed to be removed to remove the piano's legs. The other communities using PianoML were resistant to this information being included -- it was of no interest to them. However, the moving companies were free to include it, written in their own extension (in their own namespace), because they also published PXFIM
Re: Announcement: Cool URIs for the Semantic Web - W3C SWEO IG Note
In this particular case, I speculate DCMI thought it was getting around that issue by using purl.org which issues a 302 instead of a 303, thinking it would be cached, but doesn't appear to happen in my browser. If purl.org were returning a 303, the point I make would be more obvious. (historical aside) That's a clever speculation, but I don't think that's what actually happened. purl.org and dcmi long predate the idea of using 303 See Other for this application. (303 for the semweb was my idea (circa 2003); purl.org and dcmi'a use of it were due largely to Eric Miller (in the 90's); when I suggested to Eric to use 303, he said it sounded like a good idea, but he wasn't involved in running them any more.) -- Sandro
Re: Biological Taxonomy Vocabulary 0.1
[to a much-smaller list] Suffice to say, the new namespace URI is: http://purl.org/NET/biol/ns# I can't imagine many people have had time to implement it yet, given that I only posted about it about 16 hours ago, but for what it's worth, I'll keep the old documents at the old URI for the next week or so, to allow any early adopters to catch up. Consider using /additional/ versioned URIs, e.g. http://purl.org/NET/biol/20080510/ns# http://purl.org/NET/biol/20080921/ns# from which people can access the previous versions of your ontology. The version-free URI, which you have chosen now, will always refer to the latest of these versioned ontologies. The URI of the ontology, which is used within the ontology header, will always be the version-free one. But you may, as a hint to people, add an 'owl:versionInfo' annotation property to the ontology header, which points to the respective versioned URI: owl:Ontology rdf:about=http://purl.org/NET/biol/ns; owl:versionInfo rdf:resource=http://purl.org/NET/biol/20080510/ns; / /owl:Ontology I think this is probably a good approach, but I'd refine it a little bit and say that the main namespace should not so much dereference to the latest ontology, as the latest release. There can (and probably should) be alpha- and beta-test versions which are later but not (yet) suitable replacements. Make sense?(I've never done this with ontologies -- there could be a problem with it -- but i think it's right.) -- Sandro
Re: scribing in the new regime
Argh. Got 223 errors. What kind of errors? Were they are hard to fix? Shouldn't the formatter crush out Zakim stuff? I've done it manually, but it's a real pain. I don't know which Zakim stuff you mean. Sure, the formatter should do whatever we want it to do. What do you want it to do? 5. Eventually use the Save button on the generated version. But not until approved, right? No, you save it when it's ready for review. You can save multiple times./me ponders how to make that more clear. - s
Re: scribing in the new regime
Argh. Got 223 errors. What kind of errors? Were they are hard to fix? Any mention of Zakim seemed to generate an error. /me looks back through old version of the minutes on the wiki. Ah. You (sort of understandably) included Zakim, RRSAgent, and trackbot in the list of people present at the meeting. That confused the system, making the names ambiguous, since the system has hardcoded that there are bots by those names. I've modified the code so that run with your earlier version it now says: Scribe Error: the name 'RRSAgent' looks too much like the name of one of the common bots. The bots should not be listed among the meeting attendees. I've also reworded some other messages. You can run it on that old version of the chatlog like this: http://www.w3.org/2008/06/wiki_scribe/?source=http%3A%2F%2Fwww.w3.org%2F2007%2FOWL%2Fwiki%2FChatlog_2008-06-18%26oldid%3D8734 Shouldn't the formatter crush out Zakim stuff? I've done it manually, but it's a real pain. I don't know which Zakim stuff you mean. Sure, the formatter should do whatever we want it to do. What do you want it to do? Questions to and replies from Zakim seemed to generate errors. 5. Eventually use the Save button on the generated version. But not until approved, right? No, you save it when it's ready for review. You can save multiple times./me ponders how to make that more clear. Well, I'm then confused as to how others can make changes. I don't really understand your question. I've added some explanitory text in the Save box: http://www.w3.org/2008/06/wiki_scribe/?source=http://www.w3.org/2007/OWL/wiki/Chatlog_2008-06-18 ... does that explain it? PS: I also don't know how to comment out stuff. Hmmm. I don't either. Can you give me example of why you want to do that? -- Sandro
Re: scribing in the new regime
5. Eventually use the Save button on the generated version. But not until approved, right? No, you save it when it's ready for review. You can save multiple times./me ponders how to make that more clear. Well, I'm then confused as to how others can make changes. I don't really understand your question. I've added some explanitory text in the Save box: http://www.w3.org/2008/06/wiki_scribe/?source=http://www.w3.org/2007/OW L/wiki/Chatlog_2008-06-18 ... does that explain it? Nope. How can non-scribers fix minor issues with the minutes (as has happened quite often in the past)? I've rephrased the explanation on saving, adding the text, This applies to both the scribe and anyone else who edits the minutes on the wiki. Does that do it? PS: I also don't know how to comment out stuff. Hmmm. I don't either. Can you give me example of why you want to do that? So that stuff that the scribe thinks should be removed can instead be commented out so that other WG members can more easily add it back in. Ahh, makes sense. How about OMIT: at the start of the text on irc? -- Sandro
Re: scribing in the new regime
I implemented/installed OMIT: and linkifying http/issues/actions. - s
options for RDF language-tagged literals
I don't remember how much you've heard of this idea of merging RDF's language-tagged literals into datatype literals. The idea RIF-WG and OWL-WG are working with is a kind of hack of inventing a datatype whose lexical space contains a string with an @ and a language tag appended. So: [EMAIL PROTECTED]^^rif:text == chat@fr As I say, it's a sort of a hack, but it works for getting RDF down to having just one kind of literal, which is a big win for folks building semantics around it, eg RIF and OWL.(Maybe some distinction still needs to be kept between foo and foo^^xs:string. I'm fuzzy on that issue.) Axel Polleres just had another suggestion, though, which is: chat^^lang:fr == chat@fr which really seems a lot better. It also seems like something RDF Core would have considered. (Along with chat^lang:fr, I imagine.) Can you remember any of why it was not chosen? If you don't, I guess I'll ask Brian and Graham next -- from the minutes I see, they seem to be the most interested in the subject. -- Sandro ---BeginMessage--- Phillips, Addison wrote: Hi, Would you consider including I18N WG in your joint task force? These issues seem to arise fairly frequently. We'd like to see consistent solutions develop. Addison Sure! As for the namespace, I personally prefer rdf: sharing jos' arguments here that it is in my opinion NOT problematic to do so. Several rdf: namespaced properties already do not have a specified formal semantics (the reification having been mentioned already, so what). My point is rather that our intention was what we wanted to reflect is the lang tagged literals from RDF from the beginning, realizing that there is some un-uniformity with these compared with other (typed) literals. However, your raised concerns, issues make we shift a bit towards a completely different proposal, which at first glance, seems much much cleaner to me. As for you proposal/issues: 1) subtags: if we stick with the current understanding that we talk about a single datatype with pairs in its lexical space, I am not sure whether this needs to be semantically reflected... do you mean to say that e.g. a fact message(Hello@en-US^^owl:internationalizedString) should in our semantics also imply message(Hello@en^^owl:internationalizedString) ??? In RDF's semantics this is certainly not the case now and I think it would complicate things there ... A probably more feasible solution would be to do a real type hierarchy, for language tags and - instead of a datatype owl:internationalizedString or rif:text which has pairs of strings and language tags as lexical space - define separate datatypes and (subtypes) for each lang-tag, ie. use: message(Hello^^lang:en-US) where e.g. lang:en-US is a subtype of lang:en, i.e. that would also imply message(Hello^^lang:en) (just as xsd:integer is a subtype of xsd:integer of xsd:decimal in the XML Schema type hierarchy, see http://www.w3.org/TR/xmlschema-2/#built-in-datatypes) Anything wrong with that? To me this seems much cleaner than this fiddling around with pairs of strings and lang-tags. The new lang: namespace could then be something in the control of our task force and define a datatype-IRI for each of the lang-tags defined in BCP 47. Anything wrong with that??? Seems simpler than what we are into now and feasible to me. The problem of addressing our concerns would then boil down to deriving a type hierarchy from the BCP 47 document, rather than defining a single datatype... and defining the lang: namespace. which could in its namespace-URI somehow refer to BCP 47. This said, summarizing: If that works, I am in faor of an own new namespace above rif or owl, I guess. If there is some issue problem with that and we want to stick with the current pairs in the lex space, I am in favor of the rdf namespace. 2) As for your second issue, i.e. to add several language tags in a priority list... I am not sure how/whether we could address this or whether this is really in the scope of what we want to define. We are talking a bout typed constants which belong to a certain language or not, also, it would complicate things probably... unless we define in the lang-type hierarchy that e.g. a type en,fr would be implicitly a supertype of both en and fr... would that work? example: metal(Gold^^lang:en,de) would imply both metal(Gold^^lang:de) metal(Gold^^lang:en) Does that make sense? I am not sure whether I understand your issue well enough though and what more complications such an extension would bring. Still, it looks to me as if this considerably complicates things. best, Axel Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jie Bao Sent: Wednesday, July 09, 2008 11:33 AM To: Phillips, Addison Cc: [EMAIL PROTECTED];
mailing list for rdf:text, namespace use
All, I don't think there is a need to continue cc'ing the comments lists for all the WGs on this thread. I'd like to consider this a task force of RIF, OWL, and I guess I18N, let you guys do the work and then report back to the WGs. OK? Ooops, yeah. I've added www-archive to the cc list, so the e-mail is properly archived *somewhere*, at least. Shall I request a new mailing list for this? [EMAIL PROTECTED], I guess? One odd thing that occured to me (during my sleep, I think) about using the RDF namespace is that the rdf:text datatype will never be used in (existing) RDF serializations, because they already have a way to serialize such data. Happily, this lets us avoid worrying about the constraint in RDF Syntax [1], Any other names [in the RDF namespace] are not defined and SHOULD generate a warning when encountered. We should note this in the spec, I think. Note also that future RDF serializations might choose to use this, so they don't have to special-case language-tagged strings. -- Sandro [1] http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#section-Namespace
Re: mailing list for rdf:text, namespace use
A mailinglist would indeed make life easier. I did request a mailing list. I'm not sure how long it will take. The person who used to do this (usually within the hour) left a few weeks ago, so they may be disorganized. -- Sandro
please review application/rif+xml
The following media type registration is currently published as part of a W3C Last Call Working Draft [1] and will soon be submitted to the IESG for review, approval, and registration with IANA (as per [2]). At this point, we would appreciate comments on this registration information. If you see any problems, please let us know. (It's tempting to say a few words about RIF here, but I suppose I should let the registration stand on its own. It does includes links to the specification and to the Working Group home page.) -- Sandro [1] http://www.w3.org/TR/2008/WD-rif-bld-20080730/#Appendix:_RIF_Media_Type_Registration [2] http://www.w3.org/2002/06/registering-mediatype Type name: application Subtype name: rif+xml Required parameters: none Optional parameters: charset, as per RFC 3023 (XML Media Types) Encoding considerations: same as RFC 3023 (XML Media Types) Security considerations: Systems which consume RIF documents are potentially vulnerable to attack by malicious producers of RIF documents. The vulnerabilities and forms of attack are similar to those of other Web-based formats with programming or scripting capabilities, such as HTML with embedded Javascript. Excessive Resource Use / Denial of Service Attacks Full and complete processing of a RIF document, even one conforming to the RIF-BLD dialect, may require unlimited CPU and memory resources. Through the use of import, it may also require arbitrary URI dereferencing, which may consume all available network resources on the consuming system or other systems. RIF consuming systems SHOULD implement reasonable defenses against these attacks. Exploiting Implementation Flaws RIF is a relatively complex format, and rule engines can be extremely sophisticated, so it is likely that some RIF consuming systems will have bugs which allow specially constructed RIF documents to perform inappropriate operations. We urge RIF implementors to make systems which carefully anticipate and handle all possible inputs, including those which present syntactic or semantic errors. External (Application) Functions Because RIF may be extended with local, application defined datatypes and functions, arbitrary vulnerabilities may be introduced. Before being installed on systems which consume untrusted RIF documents, these external functions should be closely reviewed for their own vulnerabilities and for the vulnerabilities that may occur when they are used in unexpected combinations, like cross-site scripting attacks. In addition, as this media type uses the +xml convention, it shares the same security considerations as other XML formats; see RFC 3023 (XML Media Types). Interoperability considerations: This media type is intended to be shared with other RIF dialects, to be specified in the future. Interoperation between the dialects is governed by the RIF specifications. Published specification: RIF Basic Logic Dialect W3C Working Draft (Recommendation Track) http://www.w3.org/TR/rif-bld/ This media type is intended to be shared with other RIF dialects, to be specified in the future. Applications that use this media type: Unknown at the time of this draft. Multiple applications are expected, however, before the specification reaches W3C Proposed Recommendation status. Additional information: Magic number(s): As with XML in general (See RFC 3023 (XML Media Types)), there is no magic number for this format. However, the XML namespace http://www.w3.org/2007/rif#; will normally be present in the document. It may theoretically be missing if the document uses XML entities in an obfuscatory manner. The hex form of that namespace will depend on the charset. For utf-8, the hex is: 68 74 74 70 3a 2f 2f 77 77 77 2e 77 33 2e 6f 72. File extension(s): .rif (or .xml) Macintosh file type code(s): TEXT (like other XML) Person email address to contact for further information: Sandro Hawke, [EMAIL PROTECTED] Please send technical comments and questions about RIF to [EMAIL PROTECTED], a mailing list with a public archive at http://lists.w3.org/Archives/Public/public-rif-comments/ Intended usage: COMMON Restrictions on usage: None Author: The editor and contact for this media type registration is Sandro Hawke, [EMAIL PROTECTED] Change
Re: minutes - wiki magic?
[cc'd www-archive, in case others get interested] [You write about perhaps using the scribe tools OWL-WG is using] Sure, I'd be happy to have you guys as the second users. (Eric just grabbed me in the hall to talk about it.) Is your wiki up and running? Where in web space do you want minutes to appear? For OWL, the chatlogs, which start as IRC logs and are then cleaned up are named like: http://www.w3.org/2007/OWL/wiki/Chatlog_2009-02-23 and the formatted minutes are named like this: http://www.w3.org/2007/OWL/meeting/2009-02-23 You'll also need a wiki page like: http://www.w3.org/2007/OWL/wiki/Participants2 which doesn't exactly match the other databases of participants because: - it needs to list all the irc names used for people which can not be derived by the algorithm - it needs to list everyone who has attended any meeting, including guests and part-participants (One of the current bugs in the system is around the handling of the participant list. The list really needs to have a transaction-log style, so that we can tell who the participants (really attendees) were at any given point in time. If that list changes later, then a name might BECOME ambiguous after-the-fact, which would make old minutes harder to work with. So, for now you can use the Participants2 style, and expect at some point we'll have to upgrade this to a transaction-log style.) BTW, the script has a clear object model of MeetingEvents which could be dumped in RDF/XML easily. I was going to dump them all into virtuoso at one point, but never quite got there. Of course I'm not sure it would be socially good to have it easy to datamine the meeting records. -- Sandro
Re: minutes - wiki magic?
http://www.w3.org/2009/02/24-sparql-irc.txt http://www.w3.org/2009/02/24-sparql-minutes.html What next? :) I'll try to take care of it today... - s
Re: minutes - wiki magic?
I've got the copy-to-wiki 90% automated. I ran it to produce http://www.w3.org/2009/sparql/wiki/Chatlog_2009-03-03 and then made a Present: line by hand, based on what Zakim said. Several names still don't match; I'd imagine Participants2 is missing some folks. Let me know how it goes. -- Sandro Sandro Hawke wrote: [cc'd www-archive, in case others get interested] Great. [You write about perhaps using the scribe tools OWL-WG is using] Sure, I'd be happy to have you guys as the second users. (Eric just grabbed me in the hall to talk about it.) Is your wiki up and running? Yes, it's at http://www.w3.org/2009/sparql/wiki/ though it's still sparse. Where in web space do you want minutes to appear? For OWL, the chatlogs, which start as IRC logs and are then cleaned up are named like: http://www.w3.org/2007/OWL/wiki/Chatlog_2009-02-23 and the formatted minutes are named like this: http://www.w3.org/2007/OWL/meeting/2009-02-23 We're pretty much duplicating the Web-space structure that OWL WG is using, so I'd imagine chat logs at: http://www.w3.org/2009/sparql/wiki/Chatlog_%-%mm-%dd with formatted minutes at: http://www.w3.org/2009/sparql/meeting/%-%mm-%dd I was a bit confused by http://www.w3.org/2007/OWL/wiki/Minutes_Review_Conventions which suggests that the minutes are on the wiki and editable by any WG member when, in fact, that's not the case? You'll also need a wiki page like: http://www.w3.org/2007/OWL/wiki/Participants2 which doesn't exactly match the other databases of participants because: - it needs to list all the irc names used for people which can not be derived by the algorithm - it needs to list everyone who has attended any meeting, including guests and part-participants OK, I have an initial stab at this at: http://www.w3.org/2009/sparql/wiki/Participants2 (One of the current bugs in the system is around the handling of the participant list. The list really needs to have a transaction-log style, so that we can tell who the participants (really attendees) were at any given point in time. If that list changes later, then a name might BECOME ambiguous after-the-fact, which would make old minutes harder to work with. So, for now you can use the Participants2 style, and expect at some point we'll have to upgrade this to a transaction-log style.) OK. Out first meeting's logs were at http://www.w3.org/2009/02/24-sparql-irc.txt http://www.w3.org/2009/02/24-sparql-minutes.html What next? :) Lee BTW, the script has a clear object model of MeetingEvents which could be dumped in RDF/XML easily. I was going to dump them all into virtuoso at one point, but never quite got there. Of course I'm not sure it would be socially good to have it easy to datamine the meeting records.
Re: vCard - Old vs. New?
The problem with Member Submissions and W3C Notes is an unclear update mechanism and a lack of maintenance. Vocabs will evolve, and I'm not sure if the Rec model really works for them. The Note model works even less, with the Note being published once and then generally sticking around forever. Some modification of the Rec model that's a bit more loose will probably work. Why more loose? It seems to me that if folks are going to invest heavily in an ontology, they don't want anyone playing fast-and-loose with it. To put it differently, if I were building my business around an ontology, I'd want something very much like the W3C Recommendation-Track Process to govern its evolution and makes sure no one recklessly broke it. That said, many ontologies are not at that stage yet. Specs aren't suppposed to reach Recommendation until there's something rather like a global consensus on them. At earlier stages, something like a succession of Working Drafts makes a lot more sense. Or, maybe there's a completely different appoach. I've been wondering lately whether the current state of the net (cf crowdsourcing) hasn't rewriten the foundational notions of IT standards. For data formats and their underlying ontologies, maybe it's now practical/sufficient/best to have dyanmic translation shim code between the different ones, and let them all bloom. I think this might work, but it's somewhat less proven than the W3C Recommendation-Track approach (which is unproven for ontologies, but seems to work pretty well for data formats in general.) -- Sandro
please review text/rif+xml media type registration
in an obfuscatory manner. The hex form of that namespace will depend on the charset. For utf-8, the hex is: 68 74 74 70 3a 2f 2f 77 77 77 2e 77 33 2e 6f 72. File extension(s): .rif (or .xml) Macintosh file type code(s): TEXT (like other XML) Person email address to contact for further information: Sandro Hawke, san...@w3.org. Please send technical comments and questions about RIF to public-rif-comme...@w3.org, a mailing list with a public archive at http://lists.w3.org/Archives/Public/public-rif-comments/ Intended usage: COMMON Restrictions on usage: None Author: The editor and contact for this media type registration is Sandro Hawke, san...@w3.org. Change controller: RIF is a product of the Rule Interchange Format (RIF) Working Group of the World Wide Web Consortium (W3C). See http://www.w3.org/2005/rules/wg for information on the group. The W3C (currently acting through this working group) has change control over the RIF specification.
SPARQLProxy
[cc www-archive] We talked about this the other day; I don't think there was a conclusion. I want a way to find one or more SPARLQ end points who can answer queries about some RDF graph, for when the graph is very large. Folks providing large graphs may choose to provide this service; folks using such graphs may choose to use it. If they both use it, and the graph is large, there may be significant performance gains. I propose the following practice: 1. Optionally, provide an HTTP header (in response to GET and HEAD): SPARQL-Proxy: ...url-of-endpoint... Clients may choose to do a HEAD first, or to do the GET and simply abort the connection and switch to using SPARQL when they notice this header. The choice to switch to SPARQL might be based in part on the value of the Content-Length header, if present. (I don't remember the current political climate around making up HTTP headers like that. My sense is it's okay.) 2. Optionally, near the begining of an RDF graph, include a triple: ns:SPARQLProxy ...url-of-endpoint... This functions just like the HTTP header on a GET request; you're getting the graph transmitted to you, but if it's big, you'll see this before you get it all, and then you can abort the connection. The idea here is that the named endpoint would have this graph (called above) as one of its named graphs. It might or might not be the background graph. In style-2, there might be some metadata about the endpoint BEFORE this triple, such as how to turn on inference, or something. I'm not trying to address that here. I think this is a very simple and harmless approach, and meets my needs well enough. Do you see any problem with it? Any suggestions for the namespace to use? -- Sandro
Links from 14 August Cambridge Semantic Web Gathering
Links from Tom's Talk: Linked Open Data Cloud: http://thedatahub.org/group/lodcloud 5 Stars of Open Linked Data: http://www.w3.org/DesignIssues/LinkedData.html LOD Cloud Vocabulary Statistics: http://www4.wiwiss.fu-berlin.de/lodcloud/state/#terms 5 Stars of Open Linked Vocabularies: http://blog.hubjects.com/2012/02/is-your-linked-data-vocabulary-5-star_9588.html Linked Open Vocabularies: http://labs.mondeca.com/dataset/lov/index.html NCBO Bioportal: http://bioportal.bioontology.org Open PHACTS overview: http://www.slideshare.net/open_phacts/rsc-cicag-28-nov-2011-open-phacts-kidd, slide 34 Open PHACTS Milestone 3: http://www.openphacts.org/documents/Milestones/M3_First%20working%20release%20demonstrate%20use,%20associate%20partners%20enlisted%20and%20integrated.pdf W3C HCLS IG: http://www.w3.org/blog/hcls/ Other 'Shout-outs' Pistoia Alliance: http://www.openbel.org/ Open BEL: http://www.openbel.org/ Cambridge Semantics: http://www.cambridgesemantics.com/ Concept Maps (CMAP): http://cmap.ihmc.us/
testing attachments
what's the mime type? @prefix alice: http://alice.example.com/foaf#. @prefix foaf: http://xmlns.com/foaf/0.1/. alice:Alice foaf:knows alice:Bob.
Re: rdfs:Graph ? comment on http://www.w3.org/TR/rdf11-concepts/#section-dataset and issue 35
off-list but public response, so we can continue informally for a bit.
(this is what I should have done the first time, given the current
rather strict rules about public-rdf-comments, because it had gotten out
of control.)
On 07/15/2013 11:14 AM, Jeremy J Carroll wrote:
Hi Sandro
to reply, in turn informally
I think you have largely understood my position, although - without introducing
time, I have difficulty seeing much difference between your two concepts:
rdf:WebviewDataset and rdf:DirectDataset.
Equality is another perfectly good way to distinguish them (we don't
need time).
It follows from this dataset:
a rdf:DirectDataset.
GRAPH _:a { s p o }
GRAPH _:b { s p o }
that _:a = _:b. Each blank node denotes the same g-snap, therefore
they must be equal.
In contrast, this is totally different:
a rdf:WebviewDataset.
GRAPH a { s p o }
GRAPH b { s p o }
Here we've said that a and b are each Web Resources (g-boxes) that
happen to have the same triples. There's no reason to think they are equal.
Since RDF is known not to do time very well, it doesn't surprise me that there
may be difficulties in thinking about changes in the graph content in a
dataset. I am really not expecting RDF semantics to address that.
I am expecting RDF to allow me to describe resources - specifically resources
introduced by RDF; I am not expecting RDF to provide me the ability to make
paradoxical statements about resources (which an overly excessive version of
the rdf:DirectDataset view risks, see:
http://lists.w3.org/Archives/Public/www-rdf-logic/2004Apr/0029
)
I want to say simple stuff like who wrote a graph named in the dataset. The
easiest way to do this is to attach the metadata to the name.
So, given this dataset:
a rdf:DirectDataset.
a rdf:WebviewDataset.
GRAPH _:a { s p o }
GRAPH _:b { s p o }
GRAPH a { s p o }
GRAPH b { s p o }
_:a dc:creator Alice.
a dc:creator Bob.
it follows that
_:b dc:creator Alice.
it does NOT follow that:
b dc:creator Bob.
Kind of important difference, right? And you can see why people would
want both kinds of semantics.
(and they tell me the also want other things, like entailments within
the named graphs, although I'm not convinced that's worth it.)
This currently is not supported by RDF and I would like to have a clear technical
explanation as to why, rather than a political rationale (which is of course totally
understandable) we didn't pick a semantics for datasets, because there are so many
different ones out there already, so nothing we could pick wouldn't cause someone
problems.
Is the above convincing? I agree there should be some kind of
rationale in the documents, if possible.
-- Sandro
Jeremy J Carroll
Principal Architect
Syapse, Inc.
On Jul 11, 2013, at 5:59 PM, Sandro Hawke san...@w3.org wrote:
On 07/11/2013 03:06 PM, Jeremy J Carroll wrote:
Hello
This is a formal comment on
http://www.w3.org/TR/rdf11-concepts/#section-dataset, and it appears a comment
on
https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-schema/index.html
and quite possibly on the RDF Semantics ….
This is a brief, informal reply to both the message I'm replying to [1] and
your following message [2].
The short answer is: we didn't pick a semantics for datasets, because there are
so many different ones out there already, so nothing we could pick wouldn't
cause someone problems. So we say that datasets, on their own, have a minimal
semantics plus application-specific semantic extensions. If you want
interoperability between application, you need to indicate your semantic
extensions. You can do that out-of-band (in some way you figure out) or in
band, by putting some metadata in the dataset saying which semantic extensions
you're using.
We are hoping to produce a NOTE which provides some options, so people don't
have to start from scratch with these indicators. We don't think the subject
is mature enough yet to put designs in a Recommendation, though.
My current thinking, which the group hasn't really talked about, is:
a rdf:WebviewDataset (Or ResourceStateDataset or GraphStoreSnapshot)
would provide the semantics I think you want, where a URL graph name is
associated with the graph you'd get if you dereferenced that URL. You might
think of the URLs as denoting the Web Resource whose state is represented by
the associated graph. My sense from your examples is that's how you're
thinking about datasets.
a rdf:DirectDataset
would provide the semantics some other folks want, where the graph names
actually denote the associated graphs (the pure mathematical set of triples,
not a thing which can change over time).This is what people are used to
from N3 and (I think) from most provenance work.
I'm inclined to say DirectDataset only constrains name/graph pairs where the
graph names are blank nodes and WebviewDataset only constrains name/graph pairs
where
Re: rdfs:Graph ? comment on http://www.w3.org/TR/rdf11-concepts/#section-dataset and issue 35
On 07/16/2013 10:37 AM, Jeremy J Carroll wrote:
OK - I am getting started on this …
Thanks for helping me think this through
how about this dataset:
a rdf:DirectDataset.
GRAPH _:a { _:a _:a _:a }
GRAPH _:b { _:b _:b _:b }
does _:a = _:b?:
No.
background: The strings _:a and _:b are blank node labels. Within
any one TriG document, each blank node label corresponds 1-1 to a blank
node.
When I said _:a = _:b I meant that in all interpretations, the
denotation of the blank node that is labeled _:a in this document is
the same as the denotation of the blank node labeled _:b in this
document.
So the first named graph in your example is different from the second
named graph in your example, because the repeated term in it uses a
different blank node label and is thus a different blank node. The
denotations of those blank nodes might turn out to be the same (eg if we
also are told _:a owl:sameAs _:b), but they are still different blank
nodes. Thus the graphs are different. So we can not infer _:a =
_:b. In fact, if we were told _:a owl:sameAs _:b, then we'd have an
inconsistent dataset.
Or this one
a rdf:DirectDataset.
GRAPH _:a { s p o }
GRAPH _:b { s p o }
GRAPH _:c { _:a _:a _:a }
GRAPH _:d { _:b _:b _:b }
does _:c = _:d ?
Nope.
(Of course, this is generalized RDF, because you're using a blank node
predicate. I'm fine with that.)
What is the definition of two graphs being equal in this view?
Maybe I should say identical here, instead of equal, to avoid this
denotation step, above.
I'd say it follows from RDF Concepts that two graphs are identical (the
same graph) if they contain exactly the same triples. Triples are
identical (the same triple) if their subject, predicate, and object
terms are identical. I believe term identity is spelled out in
concepts -- it gets a little tricky on language tags -- but it's clear
enough for blank nodes, I hope.
Here is one:
two graphs g and h within a dataset are equal if there exists an
automorphism of the dataset mapping each ground node to itself, and
inducing a bijection over the set of blank nodes such that the
automorphism maps g to h.
(That isn't quite what is intended - since it does not make A and
B equal in this case:
a rdf:DirectDataset.
GRAPH A { s p o }
GRAPH B { s p o }
)
Sorry, automorphism is over my head. I can look it up and try to
figure it out if you want, but hopefully that's not necessary.
In my view what you call the WebviewDataset is the natural model on
the Web,
I agree it's a very natural model, but I think there are lots of things
one might like to do with datasets, like express an RDF Update, that
can't be done very naturally with that model.
and if this is not to be 'the' way of understanding named graphs
because of some other view, I would like that view to be articulated
rather than only exemplified.
Is it okay if it's in one or more WG Notes that come out in the next few
months, instead of in RDF Concepts or RDF Semantics?
I mean, we'd all like that, we're just finding it impossible to get WG
consensus on putting it in a REC.
-- Sandro
Jeremy J Carroll
Principal Architect
Syapse, Inc.
On Jul 15, 2013, at 5:39 PM, Sandro Hawke san...@w3.org
mailto:san...@w3.org wrote:
It follows from this dataset:
a rdf:DirectDataset.
GRAPH _:a { s p o }
GRAPH _:b { s p o }
that _:a = _:b.
Re: rdfs:Graph ? comment on http://www.w3.org/TR/rdf11-concepts/#section-dataset and issue 35
On 07/16/2013 03:45 PM, Jeremy J Carroll wrote:
On Jul 16, 2013, at 8:39 AM, Sandro Hawke san...@w3.org
mailto:san...@w3.org wrote:
Or this one
a rdf:DirectDataset.
GRAPH _:a { s p o }
GRAPH _:b { s p o }
GRAPH _:c { _:a _:a _:a }
GRAPH _:d { _:b _:b _:b }
does _:c = _:d ?
Nope.
Oh that one surprise me, I would have thought with graph literals that
this would be the case:
with each being just syntax for
{ { s p o } { s p o }**{ s p o } }
The graph itself is just a structure. Whatever interpretations you
might give to it, equality, etc, doesn't change the structure itself.
And the dataset is just concerned with the structure. The graph name is
attached to the graph (a structure), not the logical meaning of the
graph, or the consequences of that meaning, or something like that.
-- Sandro
Re: rdfs:Graph ? comment on http://www.w3.org/TR/rdf11-concepts/#section-dataset and issue 35
On 07/17/2013 11:27 PM, Peter F. Patel-Schneider wrote:
Aside from any issues that I have with semantics, the ability to infer
equality would produce a very big change in RDF reasoning.
True, but it seems to me that in practice, people pick and choose the
bits of the reasoning they want to do.owl:sameAs (etc) are right
there, if they want to use them.
-- Sandro
peter
On Jul 15, 2013, at 5:39 PM, Sandro Hawke san...@w3.org
mailto:san...@w3.org wrote:
It follows from this dataset:
a rdf:DirectDataset.
GRAPH _:a { s p o }
GRAPH _:b { s p o }
that _:a = _:b.
Re: rdfs:Graph ? comment on http://www.w3.org/TR/rdf11-concepts/#section-dataset and issue 35
On 07/26/2013 12:37 PM, Jeremy J Carroll wrote:
I slept on Eric's question for several days ….
I ended up realizing that another aspect of the current drafts that I
feel should change a bit is:
https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html#rdf-datasets
When a graph name is used inside RDF triples in a dataset it may or
may not refer to the graph it names. The semantics does not require,
nor should RDF engines presume, without some external reason to do so,
that graph names used in RDF triples refer to the graph they name.
I would like some mechanism which indicates clearly that in my case it
MAY refer to the graph it names,
Surely the above text makes it clear it MAY. What you're looking for is
a way in indicate the situations in which it MUST (or simple does).
and I am proposing that
uuu rdf:type rdfs:Graph
be such a mechanism, and this be understood with intensional semantics
like rdfs:Class rather than with extensional semantics like
owl:Restriction
i.e. if in any graph in a dataset, there is such a triple, and we have
an interpretation of that graph, and that the dataset does include a
graph named uuu then it is pretty clear that the intent is that I am
talking about the graph, and I would like the recommendations to say
that in such interpretation it is this graph that we are talking about.
It should probably be rdf:Graph (not rdfs:Graph), but otherwise I'm
happy with this, in broad strokes. It'll need a second last call for
Semantics and/or Concepts, unless we put it into some other Rec-Track
document.
I'd also suggest that use of a blank node as a graph name implies
(entails) such a triple for that blank node. No need to specify it,
since there's no other likely meaning. That would definitely need a
second last call for Semantics and/or Concepts.
What about Peter's concern, that this is a backdoor to equality? Perhaps
intensionality solves this; I'm not understanding that part. Test case:
# s1,s2 a rdf:Graph (please, can I have this syntax? never mind)
s1 a rdf:Graph.
s2 a rdf:Graph.
s1 p 1.
GRAPH s1 { a b c }.
GRAPH s2 { a b c }.
Does that entail
s2 p 1.
? If not, how can it not? If IRIs s1 and s2 denote the same thing,
then it must follow, mustn't it? If so, is that a problem?
Jeremy, thinking about using this in practice: are you using resolvable
URLs as names for graphs? Do you have some mechanism for handling the
situation where dereference gives different triples for those URLs that
some dataset does?Like put a hash of the graph into the text of the
URLs, so systems can tell if they're getting the right data? Or just
trust everything will always be in sync?
-- Sandro
Jeremy J Carroll
Principal Architect
Syapse, Inc.
On Jul 19, 2013, at 9:06 PM, Eric Prud'hommeaux e...@w3.org
mailto:e...@w3.org wrote:
On Jul 19, 2013 2:10 PM, Jeremy J Carroll j...@syapse.com
mailto:j...@syapse.com wrote:
Sorry, I am failing to be brief ...
On Jul 19, 2013, at 9:35 AM, Jeremy J Carroll j...@syapse.com
mailto:j...@syapse.com wrote:
[[[
rdfs:Graph
rdfs:Graph is the class of graphs. All instances
of rdfs:Graph correspond to the RDF model of a graph described in the
RDF Concepts specification [RDF-CONCEPTS].
An instance of rdfs:Graph MAY also be described in an RDF
dataset, in which case the triples in the graph SHOULD/MUST be the
triples as specified in the dataset.
]]]
(I would be happy with either SHOULD or MUST)
looking again, MUST is too strong - since this would allow anyone
to modify anyone's else's intent. We need to qualify which RDF
datasets and reduce the MUST down to SHOULD.
e.g. MAY also be described in a related RDF dataset, ….. SHOULD
…. with the complete modified suggested text as
[[[
rdfs:Graph
rdfs:Graph is the class of graphs. All instances
of rdfs:Graph correspond to the RDF model of a graph described in the
RDF Concepts specification [RDF-CONCEPTS].
An instance of rdfs:Graph MAY also be described in a related RDF
dataset, in which case the triples in the graph SHOULD be the triples
as specified in the dataset.
]]]
Sorry to be dim here, but does the triples as specified in the
dataset indicate a truth predicate of some sort (in which case I
would have expected indicated instead of specified). Or maybe I'm
misinterpreting a signal that another graph (probably the default
graph) includes all of the triples in the identified graph.
Re: rdfs:Graph ? comment on http://www.w3.org/TR/rdf11-concepts/#section-dataset and issue 35
On 07/26/2013 06:21 PM, Jeremy J Carroll wrote: Ah, and I just came across some other relevant text: http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#namedGraphs The |FROM NAMED| syntax suggests that the IRI identifies the corresponding graph, but the relationship between an IRI and a graph in an RDF dataset is indirect.*The IRI identifies a resource, and the resource is represented by a graph (or, more precisely: by a document that serializes a graph).* Given that the text in bold is already normative, Normative for SPARQL UPDATE is not the same as normative for RDF ... am I detecting some part of the RDF WG that somehow wishes to go back on that. I'm not sure we're going back on that so much as noticing how vague that text is. It doesn't rule out that the resource is the graph (as in the case you are maybe saying you want). I do not believe that my ideal outcome would be no more than the text in bold. I can't understand your double negative, sorry. -- Sandro Jeremy J Carroll Principal Architect Syapse, Inc. On Jul 26, 2013, at 9:37 AM, Jeremy J Carroll j...@syapse.com mailto:j...@syapse.com wrote: I slept on Eric's question for several days …. I ended up realizing that another aspect of the current drafts that I feel should change a bit is: https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html#rdf-datasets When a graph name is used inside RDF triples in a dataset it may or may not refer to the graph it names. The semantics does not require, nor should RDF engines presume, without some external reason to do so, that graph names used in RDF triples refer to the graph they name. I would like some mechanism which indicates clearly that in my case it MAY refer to the graph it names, and I am proposing that uuu rdf:type rdfs:Graph be such a mechanism, and this be understood with intensional semantics like rdfs:Class rather than with extensional semantics like owl:Restriction i.e. if in any graph in a dataset, there is such a triple, and we have an interpretation of that graph, and that the dataset does include a graph named uuu then it is pretty clear that the intent is that I am talking about the graph, and I would like the recommendations to say that in such interpretation it is this graph that we are talking about. Jeremy J Carroll Principal Architect Syapse, Inc. On Jul 19, 2013, at 9:06 PM, Eric Prud'hommeaux e...@w3.org mailto:e...@w3.org wrote: On Jul 19, 2013 2:10 PM, Jeremy J Carroll j...@syapse.com mailto:j...@syapse.com wrote: Sorry, I am failing to be brief ... On Jul 19, 2013, at 9:35 AM, Jeremy J Carroll j...@syapse.com mailto:j...@syapse.com wrote: [[[ rdfs:Graph rdfs:Graph is the class of graphs. All instances of rdfs:Graph correspond to the RDF model of a graph described in the RDF Concepts specification [RDF-CONCEPTS]. An instance of rdfs:Graph MAY also be described in an RDF dataset, in which case the triples in the graph SHOULD/MUST be the triples as specified in the dataset. ]]] (I would be happy with either SHOULD or MUST) looking again, MUST is too strong - since this would allow anyone to modify anyone's else's intent. We need to qualify which RDF datasets and reduce the MUST down to SHOULD. e.g. MAY also be described in a related RDF dataset, ….. SHOULD …. with the complete modified suggested text as [[[ rdfs:Graph rdfs:Graph is the class of graphs. All instances of rdfs:Graph correspond to the RDF model of a graph described in the RDF Concepts specification [RDF-CONCEPTS]. An instance of rdfs:Graph MAY also be described in a related RDF dataset, in which case the triples in the graph SHOULD be the triples as specified in the dataset. ]]] Sorry to be dim here, but does the triples as specified in the dataset indicate a truth predicate of some sort (in which case I would have expected indicated instead of specified). Or maybe I'm misinterpreting a signal that another graph (probably the default graph) includes all of the triples in the identified graph.
Re: rdfs:Graph ? comment on http://www.w3.org/TR/rdf11-concepts/#section-dataset and issue 35
[moved to www-archive and cc Pat for now]
On 09/16/2013 08:19 PM, Jeremy J Carroll wrote:
On Sep 11, 2013, at 8:14 PM, Sandro Hawke san...@w3.org
mailto:san...@w3.org wrote:
On 09/11/2013 06:21 PM, Jeremy J Carroll wrote:
This section defines a vocabulary item rdf:Graph in addition to
those in [RDF-SCHEMA].
This is the class of resources that are RDF graphs. If a resource in
this class is identified by an IRI, and that IRI is used to name a
graph in a dataset, then within that dataset the resource SHOULD
correspond to the named graph.
Does it not follow from this definition that:
PREFIX :http://example.org/#
PREFIX rdf:http://www.w3.org/1999/02/22-rdf-syntax-ns#
:g1 :p 1.
:g1 a rdf:Graph.
:g2 a rdf:Graph.
GRAPH :g1 { :a :b :c }
GRAPH :g2 { :a :b :c }
entails:
:g2 :p 1.
(assuming the SHOULD is taken as something we can count on) ?
Hi Sandro
this is an excellent question, and one that I takes motivates your
discussion of box-model on the WG mailing list.
I am not very comfortable with a YES, but, given the text I suggested
a YES it would be.
In essence I think I want an intensional semantics rather than an
extensional semantics, suggested text below; I start with
philosophical discussion.
In maths, we typically refer to Sets with intensional semantics, in
RDF we refer to classes with extensional semantics.
So if I have a class
jjc:Friends rdf:type rdfs:Class ;
rdfs:comment Jeremy's friends .
and also a class
jjc:SandrosFriends rdfs:type rdfs:Class ;
rdfs:comment Sandro's friends .
in the unlikely event that we have exactly the same friends, RDF
semantics does not confuse the intent.
I'm with you so far, sort of.
A view would be that RDF Semantics achieves this by moving the
semantic intent more to the property rdf:type …
Really? I haven't thought about this in a long time, but I think I
axiomatized it easily enough for my rdfs reasoner back in 2003.
So, we could scrub the idea of having a class, and instead define a
property.
An alternative proposed modification, which clarifies my desired NO to
your entailment
This is a magic property, right? It's not a normal property in the RDF
semantics, something in the domain of IEXT, because if it were it would
have extensional semantics
[[
3.7 The rdf:namesGraph property
This section defines a vocabulary item rdf:namesGraph in addition to
those in [RDF-SCHEMA].
rdf:namesGraph is an instance of rdf:Property that is used to state
that a resource is a name for a graph.
A triple of the form:
R rdf:namesGraph G
states that G is an RDF graph and R is a name for the graph G.
In normal RDF semantics, the property has no access to the term R, just
to I(R).The truth of triple is unchanged if you replace the subject
with a different subject denoting the some thing.The truth of :a :b
:c is the same as the truth of :a2 :b :c if I(:a) = I(:a2).
But rdf:namesGraph is special -- it somehow reaches around I and IEXT to
get directly at the subject term itself?
If R is an IRI, and that IRI is used to name a graph in a dataset,
then within that dataset the resource G SHOULD correspond to the named
graph.
I don't understand why you keep using SHOULD.I don't see semantics
as the kind of place for SHOULDs.
The rdfs:domain of rdf:namesGraph is rdfs:Resource. No rdfs:range is
specified.
]]
===
With this my particular use case to add metadata about the graph as an
intensional as opposed to an extensional object would be addressed as
follows.
PREFIX : http://example.org/#
PREFIX rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#
GRAPH :g1 { :g1 rdf:namesGraph _:g ; rdfs:comment An example graph }
At first I thought you meant:
GRAPH :g1 { :g1 rdf:namesGraph _:g. _:g rdfs:comment An example
graph }
But now I see you don't actually want the comment on the graph, you want
it on the graph name or something, so that it's not shared with other
graphs that happen to be identical.
That is:
:g1 :p 1.
:gn1 :p 1.
GRAPH :gn1 { :a :b :c }
GRAPH :gn2 { :a :b :c }
:gn1 rdf:namesGraph :g1
:gn2 rdf:namesGraph :g2
entails
:g2 :p 1# since :g1 and :g2 both denote the same RDF Graph
but does NOT entail
:gn2 :p 1
so you're okay with your metadata.
But, but ... in that case you don't need rdf:namesGraph at all. Since
you're not actually using _:g, just put your properties on :gn1 and
you're fine.
Does that not do what you want? (True there's no semantic connection
to the triples, but why do you need one? Since you're not using _:g, I
claim that means you don't need the rdf:namesGraph triple at all.)
-- Sandro
Jeremy J Carroll
Principal Architect
Syapse, Inc.
Re: rdfs:Graph ? comment on http://www.w3.org/TR/rdf11-concepts/#section-dataset and issue 35
, as a child, had RAM from 0x to 0x9FFF and then ROM from 0xA000 to 0x, as I recall), but I'll admit that's not the mainstream notion of a box. So, I'll stop here and wait for feedback that we're on the same page about this, before thinking about what to do about it. -- Sandro There are (speaking intuitively) RDF graphs all over the internet, represented using RDF surface syntaxes. RDF/XML documents, Trig documents, quad stores, etc. etc.. But these things are not, strictly speaking, graphs, even if we ignore the fact that they can be modified. Lets assume that they are all cast in stone, so they are not g-boxes. Still, they aren't graphs, because two of them can be different and yet describe the very same graph. So what are they, exactly? They are things that bear the same relation to graphs that a token of the letter A bears to the first letter of the English alphabet. Or, they are things that bear the same relation to graphs that actual physical copies of Moby Dick bear to the novel written by Melville. Or, they are things that bear the same relation to graphs that RDF classes bear to the sets that are their extensions. To all intents and purposes, they are just like the the more abstract things, but there can be many of them corresponding to each one of those. They are exemplars, tokens, concretions, intensions, representations, ... choose your favorite analogy... of graphs. When we wote the named graph paper, we wanted the names to name these things rather than abstract graphs, because these are the things that one can store, transmit, copy and generally do processing on. These are the actual RDF data, and the RDF graphs are a kind of abstraction of them, something like the parse tree of a sentence as opposed to a copy of the sentence in an actual document. So we needed a way to define these things, but it wasnt easy to do that in a philosophically elegant way. So we used the quick and slightly dirty construction of pairing the graph with its name to represent the particular thing that the name names. This way, one can have two or more named graphs which are distinct, each has its own name distinct from the other names, but they are all copies of (tokens of, intensions of) the same actual graph. And this simple trick avoids the consequence that we wanted to avoid, and which your example illustrates, which is that if we really were naming the graphs, then my name for my graph would also become a name for your graph if you happened to have a copy of my graph. Which does not sit well with the idea of having deferencable names like URLs. So, to emphasize, this is not going all the way to g-boxes. The idea was not to give a name to a box which just kind of happens to have a graph in it, or something with a state which can be changed with time. It was to give a name to the actual graph-like things, but with the understanding that we are talking about something more like actual datastructures, or actual documents, than mathematical abstractions. Things that can be put on websites, stored in a file at at an address, given copy protections and pointed at using IRIs. Those are the graph-things that the names of named graphs were supposed to be naming. Given the g-box discussion, we could identify these things with 'fixed' g-boxes whose state is not allowed to change, but I am less happy with this convention, as the g-box idea introduces the whole business of temporality, state change and so on, which is a huge can of worms that really is not relevant to the intensional notion that Jeremy is talking about here. So to introduce all this, then to immediately cancel it by saying the box if 'fixed', is confusing, and conceptual overkill. Personally, I like the letter-A analogy, and would be very happy to have the notion of a token of a graph, being any datastructure or document which encodes or parses to the graph. But not something with a state, not labile or dynamic, just as fixed and eternal as any other RDF notion. And if we do this, then we have a three-way relationship between a name, the graph token it names, and the graph exemplified by the graph token, and we can run your account of datasets without mentioning boxes or implying anything about change and time. Just replace g-box with graph token (or whatever we decide to call it. It is, of course, a named graph using the conventions from the original paper.) And then your g1/g2 example entailment does not hold, as I think it should not. Pat On Sep 16, 2013, at 5:19 PM, Jeremy J Carroll wrote: On Sep 11, 2013, at 8:14 PM, Sandro Hawke san...@w3.org wrote: On 09/11/2013 06:21 PM, Jeremy J Carroll wrote: This section defines a vocabulary item rdf:Graph in addition to those in [RDF-SCHEMA]. This is the class of resources that are RDF graphs. If a resource in this class is identified by an IRI, and that IRI is used to name a graph in a dataset, then within that dataset the resource
Re: rdfs:Graph ? comment on http://www.w3.org/TR/rdf11-concepts/#section-dataset and issue 35
On 09/17/2013 12:35 PM, Jeremy J Carroll wrote:
Some in line responses ...
On Sep 16, 2013, at 6:37 PM, Sandro Hawke san...@w3.org
mailto:san...@w3.org wrote:
[moved to www-archive and cc Pat for now]
So, we could scrub the idea of having a class, and instead define a
property.
An alternative proposed modification, which clarifies my desired NO
to your entailment
This is a magic property, right? It's not a normal property in the
RDF semantics, something in the domain of IEXT, because if it were it
would have extensional semantics….
No - the property does have extensional semantics, and so the
relationship between the name and the graph becomes intensional
related by the names graph property.
[[
3.7 The rdf:namesGraph property
This section defines a vocabulary item rdf:namesGraph in addition to
those in [RDF-SCHEMA].
rdf:namesGraph is an instance of rdf:Property that is used to state
that a resource is a name for a graph.
A triple of the form:
R rdf:namesGraph G
states that G is an RDF graph and R is a name for the graph G.
In normal RDF semantics, the property has no access to the term R,
just to I(R).The truth of triple is unchanged if you replace the
subject with a different subject denoting the some thing.The
truth of :a :b :c is the same as the truth of :a2 :b :c if I(:a) =
I(:a2).
But rdf:namesGraph is special -- it somehow reaches around I and IEXT
to get directly at the subject term itself….?
No - this is just a perfectly normal property we are actually talking
about ( I( R ) , I(G) ) in IEXT(I(rdf:namesGraph)). The form of the
text is copied exactly form RDF Vocabulary: there have not been
comments on that document suggesting that the form contradicts the
semantics document, so I felt it safe and consistent to stick with
that form.
Oh, okay. So, test case:
:gn1 rdf:namesGraph :g1;
owl:sameAs :gn2.
GRAPH :gn1 { :a :b :c }.
entails
:gn2 rdf:namesGraph :g1;
Yes?
Are there any cardinality constraints?I think you're saying it's a
functional property, so
:gn1 rdf:namesGraph :g1a, :g1b.
:g1a :p :o.
entails
:g1b :p :o.
If R is an IRI, and that IRI is used to name a graph in a dataset,
then within that dataset the resource G SHOULD correspond to the
named graph.
I don't understand why you keep using SHOULD.I don't see
semantics as the kind of place for SHOULDs.
I am not suggesting any change to the semantics document.
I would be quite happy with a MUST, but a SHOULD is fine if other
people wish to do things different, or are already doing things different.
I think a MUST is definitely arguable - if you use an IRI twice in the
same document (or dataset) then it seems to me to be Web 101 that you
are talking about the same thing in the two places.
However in the formal semantics unless we are wanting to define
genuinely magic properties about the math to do with graphs, then we
do not need a MUST. (e.g. rdf:isIsomorphicTo, e;g; rdf:tripleCount)
are properties that we could choose to define, but it does not really
seem to be using RDF for its core mission of describing resources.
The rdfs:domain of rdf:namesGraph is rdfs:Resource. No rdfs:range is
specified.
]]
===
With this my particular use case to add metadata about the graph as
an intensional as opposed to an extensional object would be
addressed as follows.
PREFIX : http://example.org/#
PREFIX rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#
GRAPH :g1 { :g1 rdf:namesGraph _:g ; rdfs:comment An example graph }
But, but ... in that case you don't need rdf:namesGraph at all.
Since you're not actually using _:g, just put your properties on :gn1
and you're fine.
I am only using rdf:namesGraph to convey the semantic intent that the
subject really is a graph name, since the working group resists making
that a general rule
It resists making it a general rule, because there's no consensus, when
you get into the details, what it means. Everyone is fine with the
general idea, sure, of course, that's the graph name and that's the
graph, and (waving hands) in some sense that graph name is naming that
graph. But when you try to figure out details like entailments,
disagreement start to arise that would break interoperability.We
don't want to hand out directions to where the party is unless we can
actually write directions that will get everyone to the same spot.So
far, no one's been able to write directions that get even the folks in
the WG to the same spot.
(which I see as broken: if you use the same IRI twice in the same
document then it seems to me to be Web 101 that you are talking about
the same thing in the two places) but still
That's settled by the RDF 1.1 specs.RDF terms used as graph names
denote exactly the same as they do as RDF terms anywhere else.
What's not clear is the relationship between the thing the graph name
denotes and the associated graph
defn of Named Graph
Following that epiphany I had at the end of my last email, here's what
I'd love to see everyone agree on, more or less:
== Named Graphs
An RDF Named Graph is similar to an RDF Graph, but different in one
important way.Because RDF Graphs are defined as being mathematical
sets of RDF Triples, any two RDF Graphs which happen to contain the same
RDF Triples are, by definition, the same thing. This means that
statements made about any RDF Graph, such as metadata about provenance
and licenses, necessarily apply wherever the same set of RDF Triples
occurs. This is not always the desired intent, and Named Graphs
provide an alternative.
Like an RDF Graph, an RDF Named Graph contains zero or more RDF
Triples. Unlike an RDF Graph, an RDF Named Graph has an identity
distinct from those triples. That is, two Named Graphs remain distinct
and distinguishable entities even if they happen to contain exactly the
same RDF Triples.
The term Named Graph has historically caused some confusion, as some
people have read the phrase to mean an RDF Graph which happens to have
a name. This reading is not correct, since RDF Named Graphs are not
RDF Graphs at all. They might reasonably have been called
Identifiable Graphs, which contrasts them to RDF Graphs in the same
way that a counterfeit dollar bill is not technically a dollar bill.
As in the dollar bill analogy, RDF Named Graphs and RDF Graphs have a
lot in common, but in some circumstances it is critical to distinguish
between them.Other names that have been suggested for Named Graphs
include surfaces and g-boxes, but named graph has been cemented by
its use in the SPARQL syntax.
Names Graphs also provide a useful semantics for RDF Datasets. Some RDF
Datasets, hereafter NG Datasets, have this intended meaning: each
(_name_, _graph_) pair is a statement that _name_ is a Named Graph which
contains exactly the triples in _graph_.The class rdf:NGDataset is
defined for signalling these are the intended Dataset semantics.
The class rdf:NamedGraph is defined for use in declaring the domain and
range of predicates which relate Named Graphs. For example:
a rdf:NGDataset
GRAPH :g1 { :MtEverest :heightFeet 29002 }
GRAPH :g2 { :MtEverest :heightFeet 29029 }
:g1 :claimedBy :BritishIndiaSurveyOffice.
:g2 :claimedBy :IndiaSurveyOffice.
Here, the domain of :claimedBy is rdf:NamedGraph, and it might be
defined in English as x :claimedBy y means that all the triples in the
Named Graph x are claimed to be true by the social entity y.
The greatest differences between RDF Graphs and RDF Named Graphs appear
when one considers the possibility of them changing over time.It is
nonsensical to consider an RDF Graph changing over time, just like it
makes no sense to talk about the value of some integer, say seven,
changing over time. In contrast, it makes perfect sense to consider
Named Graphs changing: at one point in time the identifiable thing that
is a certain Named Graph contains some triples and at another point in
time it might contain different triples. As of RDF 1.1, however, the
formal specifications for RDF do not provide any specific support for
handling changing data.
==
That's simple and clear enough, isn't it? ( ... he says, clinging to
perhaps his last shred of hope. )
-- Sandro
Re: defn of Named Graph
On 09/18/2013 04:29 AM, Gregg Reynolds wrote:
On Tue, Sep 17, 2013 at 4:51 PM, Sandro Hawke san...@w3.org
mailto:san...@w3.org wrote:
Following that epiphany I had at the end of my last email, here's
what I'd love to see everyone agree on, more or less:
== Named Graphs
An RDF Named Graph is similar to an RDF Graph, but different
in one important way.
This just does not work. What you're effectively trying to do is
redefine the English language.
There are lots of words and phrases in English that mean something
different from what the words, taken literal and individually, should mean.
They suck, but they exist, and this would be adding one more. Pat tried
to call it a Surface. I tried to call it a Layer or a G-Box. But the
world calls it a Named Graph.
We all know what a named X is - it's an X that happens to bear a name.
Compare:
A named function is similar to a function, but different in one
important way.
Nobody would agree to this.
1. λx.x+1
2. f(x) = x+1
Without question, f names the same graph named by the lambda
expression in 1.
1. {1,2,3}
2. S = {1,2,3}
Again, S names the same set named by the extension expression in 1.
The point, which is easy to overlook, is that RDF graph expressions -
the stuff we write down - are just like lambda expressions or set
extension expressions. They are names. Coining additional names
(synonyms) via equations does not change the thing named.
...
Like an RDF Graph, an RDF Named Graph contains zero or more RDF
Triples. Unlike an RDF Graph, an RDF Named Graph has an identity
distinct from those triples. That is, two Named Graphs remain
distinct and distinguishable entities even if they happen to
contain exactly the same RDF Triples.
The suggestion that a pair of mathematical entities with exactly the
same extension are not equal doesn't help - it reads like an attempt
to redefine mathematics.
I think I see what you're trying to accomplish, but in my opinion this
is not a good way to do it. There is no need to invent a new blob of
metaphysics called an RDF Named Graph in order to accomodate the way
named graphs are handled in the wild. You just need clear language -
see below.
The term Named Graph has historically caused some confusion, as
some people have read the phrase to mean an RDF Graph which
happens to have a name. This reading is not correct, since RDF
Named Graphs are not RDF Graphs at all.
At this point you have completely lost this reader, and I suspect
virtually every other reader who is not intimately involved in the
discussions of the very, very small group of technical experts trying
to figure out what Named Graphs are.
Maybe.
Names Graphs also provide a useful semantics for RDF Datasets.
Some RDF Datasets, hereafter NG Datasets, have this intended
meaning: each (_name_, _graph_) pair is a statement that _name_ is
a Named Graph which contains exactly the triples in _graph_.
Since _name_ is an IRI, this would mean that a Named Graph is (I think
you mean denotes?) an IRI value (in IR), unless you're abandoning
RDF Semantics.
Right, a Named Graph is in IR. We need some term for the class of
things (in IR) which are denoted by the IRIs used as graph names in
dataset. What would you propose to call that class of things?
Above you said that an RDF Named Graph contains zero or more RDF
Triples. But the values in IR are logical individuals with no
substantive properties. In particular, they are not RDF Triples. So
at this point we do not know what RDF Named Graph is supposed to mean.
...
The greatest differences between RDF Graphs and RDF Named Graphs
appear when one considers the possibility of them changing over
time.It is nonsensical to consider an RDF Graph changing over
time, just like it makes no sense to talk about the value of some
integer, say seven, changing over time. In contrast, it makes
perfect sense to consider Named Graphs changing: at one point in
time the identifiable thing that is a certain Named Graph contains
some triples and at another point in time it might contain
different triples.
To me, at least, it makes no sense to consider RDF Named Graphs as
any more mutable thatn RDF Graphs. They're either mathematical
objects or not; if they are - and they must be - they are immutable.
To me the problem with Named Graphs is primarily a matter of getting
clear on terminology. I suppose we're stuck with Named Graph, but
there is no requirement that name be construed as a synonym for
denote. There are lots of ways of referring to things that can
loosely be considered as kinds of naming; we can think of these in
terms of modes of referring or the like.
In particular, there is one mode of referring that seems to capture
more or less perfectly what is wanted with Named Graphs: metonymy. It
already
Re: defn of Named Graph
On 09/19/2013 04:01 AM, Dan Brickley wrote:
On 18 September 2013 19:33, Jeremy J Carroll j...@syapse.com
mailto:j...@syapse.com wrote:
Something of an aside …
On Sep 18, 2013, at 1:29 AM, Gregg Reynolds d...@mobileink.com
mailto:d...@mobileink.com wrote:
The suggestion that a pair of mathematical entities with exactly
the same extension are not equal doesn't help - it reads like an
attempt to redefine mathematics.
Gregg
I think you misunderstand mathematics ...
I attach two pictures.
The first is my copy, of Jones' copy of a diagram in a book in the
vatican library which is a tenth century, maybe fifth generation,
copy of a diagram drawn by Pappus of Alexandria in the 4th
century, which may in turn have been a (n-th generational) copy of
a diagram drawn by Euclid a few hundred years earlier.
The copy in the vatican library, has, according to Jones, got a
mistake in it: which he corrected, assuming it to be a copyist's
error and not an error of Pappus or Euclid.
All these copies will have minor variations .. such as angles and
distances and sizes being slightly different [...]
Thanks - you confirm a hunch I had earlier in this thread. I started a
mail but couldn't find a way to make it clear: these distinctions
we're drawing around graphs echo very similar concerns people have for
bibliographic modeling of intellectual works, their literary
expressions, manifestations and tangible representation as items - to
use the FRBR terminology. This is not to suggest for a moment that
FRBR is the best conceptualization of graph change, state, and
versioning; only that perhaps it might help to see this as not a
distinctively RDF-oriented problem.
http://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records
Yeah, I think that observations was probably made before about g-snaps,
g-boxes, and g-texts, but it was forgotten.
It's nice to hear, in a way, because it excused our difficulty in
solving this problem.We might say that httpRange-14 and dataset
semantics are FRBR-complete or FRBR-hard problems --- that is, if you
could solve this, you could make a decent FRBR solution and/or if there
were a decent FRBR solution, you could solve this.
My hope is that we could solve this more easily than FRBR, since we have
running code.
But it's not clear the running code matters very much, alas, for these
use cases.
In my proposal starting this thread, I handwaved over why you might ever
want to have metadata about some collection of triples which is
independent of the the triples in it. For instance, in my head, I have
no idea whether dc:creator, cc:license, dc:date, etc, make more sense
applied to the g-box or the g-snap. (I hope you'll tolerate my using
those place-holder terms for clarity.) Until people need to change
the triples, though, I can't really tell.
I mean, if I copyright a certain 5000 character string, and you
independently copyright the same 5000 character string, how does the law
deal with that? I guess it doesn't care that in a sense they are
different strings -- the law probably treats them as the same, and the
chonologically-second one is infringing.So for copyright law,
cc:license and dc:creator and dc:date are properties of a g-text. That
might extend to the g-snap that is essentially the parse-tree of that
g-text. It doesn't matter which g-boxes might be involved.
I tried to skirt that using the idea of coincidentally having the same
triples, but that's maybe too theoretical and unlikely to be helpful.
So, I hereby propose we give up on all this until after we solve the
change-over-time problem for RDF.I'm happy for us to talk that out
amongst ourselves, or to do it in a community group, or... I dunno.
But obviously it's not an RDF WG thing.
As a first draft, I might state that problem as:
Sometimes people write context-sensitive RDF like { :Alice :age 10
}, instead of decontextualized RDF like { :Alice :born 1852 }. It
would be helpful to have a standard way to indicate and reason about
the intended context of context-sensitive graphs. (In this case,
the context of the first graph would have to be 1862 for both graphs
to be true, give or take time-of-year factors.)
Meanwhile, even RDF which is not inherently context-sensitive (like
the above graph using the :age predicate), often turns out to be
context-sensitive because it conveys something about the state of
the world, and the state of the world sometimes changes. For
instance, a foaf:name triple might turn out to be true for only
certain years, if the subject changes their name. And a foaf:mbox
triple is true only when the subject has the given email address.
Finally, even when an RDF graph contains information that in theory
never changes, like birth dates or molecular weights of chemicals,
in
Re: defn of Named Graph
On 09/20/2013 04:44 AM, Pat Hayes wrote:
On Sep 19, 2013, at 9:52 AM, Sandro Hawke wrote:
So, I hereby propose we give up on all this until after we solve the
change-over-time problem for RDF.
Well, I do have other things to do in my life
Sorry Hopefully you at least find this satisfying, enjoyable, or
entertaining from time to time.
, but I think this is a very bad stance to take. The change-over-time-problem is not ever
going to be solved. it is not a problem with a solution. If it were, there
would be one accepted tense logic and one accepted semantic theory for programming
languages.
To me, it would be solved if there was a way to handle
change-over-time that worked for my applications and that you didn't
think was broken wrt RDF Semantics.Hopefully other members of the
community would like it, too. I don't think we need the perfect
solution, or even consensus at this point. Just something that some of
us can use in our software with some reasonable hope it'll function as
expected, and not violate the specs in any problematic way.
But this type/token business does not require us to solve it. It is a much
simpler, more basic kind of clarification that does not depend in ANY WAY on
the change-over-time issue. With the greatest respect, Sandro, your obsession
with time and change has, I believe, hindered progress here. You keep going
back to that issue, even when we have finally managed to agree (at least I
thought we had) that the surface/token/named-graph vs. abstract graph
distinction did not depend upon time or change, or even involve it.
I come back to it obsessively because there is such a dirth of other use
cases. (Perhaps I have a bias of wanting to solved for other uses
cases; I'm trying hard to keep that in check.) In recent weeks, I
tried to keep this discussion to being just about identity without
touching on change-over-time, but frankly I don't find the use cases
compelling.
I'm now confident that you and I (and Jeremy) agree the problem we're
trying to solve in this thread is this: people seem to want to have
different properties on one graph than on another, even when the
graphs happen to have the same triples.
But why do they want this? As I poke at that problem, either it turns
out this functionality doesn't actually matter to them, or they need it
because they are actually dealing with graphs which could at least
potentially change over time.
Do you have a use case (involving RDF on computers) for having different
properties on different graphs (which happen to have the same
triples), and which does not involve graphs changing over time?
(the rest of this email is beside the point, just some inline responses
to your comments.)
I'm happy for us to talk that out amongst ourselves, or to do it in a
community group, or... I dunno. But obviously it's not an RDF WG thing.
As a first draft, I might state that problem as:
Sometimes people write context-sensitive RDF like { :Alice :age 10 }, instead
of decontextualized RDF like { :Alice :born 1852 }. It would be helpful to
have a standard way to indicate and reason about the intended context of
context-sensitive graphs. (In this case, the context of the first graph would
have to be 1862 for both graphs to be true, give or take time-of-year factors.)
Meanwhile, even RDF which is not inherently context-sensitive (like the above
graph using the :age predicate), often turns out to be context-sensitive
because it conveys something about the state of the world, and the state of the
world sometimes changes.
No. That the world changes state is true. That this implies, or requires, that
RDF must be contextual, is false. Thinking that the first entails the second,
is one of the most stubborn mistakes that people make when thinking about this
stuff.
I'd like to understand this, but let's wait on that until you actually
want to talk about the change-over-time problem.
For instance, a foaf:name triple might turn out to be true for only certain
years, if the subject changes their name. And a foaf:mbox triple is true only
when the subject has the given email address.
Finally, even when an RDF graph contains information that in theory never
changes, like birth dates or molecular weights of chemicals, in practice it
might change because of errors being corrected or the truth becoming known with
more precision. For example, with a little historical research we might
learn that the girl who inspired Alice in Wonderland was 10 in 1862, and put
that in an RDF Graph. With more research, we might discover her actually
birthdate was 4 May 1852, and update our RDF database accordingly.
True, but irrelevant. Updating errors can happen with any data; it does not
make the data itself contextual. That is not information changing with time
because it does not imply that the information is about the 'present'.
It's data changing
Re: defn of Named Graph
On 09/24/2013 09:38 AM, Dan Brickley wrote:
Do you have a use case (involving RDF on computers) for having different
properties on different graphs (which happen to have the same triples),
and which does not involve graphs changing over time?
(jumping in here...)
Related to change over time, but not quite the same: description of
Actions that may never happen, e.g. possible events (alongwith URLs +
info etc. that could be used to make them happen).
Dan
Can you give me a little more detail there?
Maybe we're doing meeting scheduling, and the meeting might be at 9am in
the Star room or might be at 10am in the Patel room, like this:
GRAPH :g1 { :staffMtg83 :start 2013-09-24T09ET; :location :Star }
GRAPH :g2 { :staffMtg83 :start 2013-09-24T10ET; :location :Patel }
:staffMtg83 :option :g1, :g2.
Something like that?
I agree that's a very interesting use case for datasets.
I don't think it's one that motivates having different properties on the
same group of triples. At least not as far as I can see.
-- Sandro
tentative actions, endorsement
On 09/24/2013 09:53 AM, Dan Brickley wrote:
On 24 September 2013 14:51, Sandro Hawke san...@w3.org wrote:
On 09/24/2013 09:38 AM, Dan Brickley wrote:
Do you have a use case (involving RDF on computers) for having different
properties on different graphs (which happen to have the same
triples),
and which does not involve graphs changing over time?
(jumping in here...)
Related to change over time, but not quite the same: description of
Actions that may never happen, e.g. possible events (alongwith URLs +
info etc. that could be used to make them happen).
Dan
Can you give me a little more detail there?
Maybe we're doing meeting scheduling, and the meeting might be at 9am in the
Star room or might be at 10am in the Patel room, like this:
GRAPH :g1 { :staffMtg83 :start 2013-09-24T09ET; :location :Star }
GRAPH :g2 { :staffMtg83 :start 2013-09-24T10ET; :location :Patel }
:staffMtg83 :option :g1, :g2.
Something like that?
I agree that's a very interesting use case for datasets.
I don't think it's one that motivates having different properties on the
same group of triples. At least not as far as I can see.
It's for schema.org; we defined http://schema.org/Action recently,
including a variety of sub-types. These work as-is in triples for
actions that have happened.
We have discussed using actionStatus=tentative properties of an
Action, but that is non-ideal since that triple could always drop off,
leaving the impression the action wasn't tentative (esp. if date is in
the past, which ties back to the date issue of course).
Right, it's a common problem with RDF on the Web. You want to attach
some important metadata to some of the triples, like I'm just kidding,
or tentative, was true for the 1988-1989 school year.
You could put that data inside the graph (sometimes), inside another
graph, or make it part of the arc linking to that data source. And you
might set the data aside by putting it in a different web page from
some more main page, or by putting it inside a named graph inside a
Web page, instead of directly in a Web page.
I'm sure what users want is to just put it inside the graph.They
want to say:
a :Tentative thing
or
dc:temporal :schoolYear1988-1989
But that goes against the RDF Semantics and the common practice of
querying a graph. As you say, that triple might be dropped.
So, I think the safest way to do it is make it part of the arc leading
to the graph.if :t1 is the graph with the tentative knowledge (a
named graph, a web page URL, whatever), it's only reachable from
endorsed content via a link like { :t1 a :TentativeSource }.
This requires some notion of endorsed content.Clearly Google has a
fuzzy notion of this, and for this system to work, it kind of has to be
smart about this. The presence of the url :t1 in endorsed content does
not mean that the graph :t1 is endorsed.
But maybe this is pushing water uphill. Maybe we need a way to say {
a :TentativeSource. }. Somehow we handle this in human systems all
the time. I think the human process is something like: assume a
document is true and about the current context until/unless something
raises doubt about that, then try to figure out if it's untrue or true
of a different context.Maybe we can formalize that process -- you
find some RDF in the wild, so you tentatively assume it's true in the
universal context, then do some reasoning, looking for signs it might
not really be. If it's not, then you try to figure out what its real
status is. dc:temporal is pretty clear about this. If this is too
hard, then perhaps you shouldn't be looking for RDF in the wild. :-)
-- Sandro
Re: The Movie of the Book: Re: defn of Named Graph
On 09/24/2013 01:07 PM, Jeremy J Carroll wrote: On Sep 24, 2013, at 6:31 AM, Sandro Hawke san...@w3.org mailto:san...@w3.org wrote: I'm now confident that you and I (and Jeremy) agree the problem we're trying to solve in this thread is this: people seem to want to have different properties on one graph than on another, even when the graphs happen to have the same triples. I am sorry, I actually don't agree. The phrase '''even when the graphs happen to have the same triples.''' indicates that any actual example is likely to be contrived and artificial. The point about these contrived and artificial examples is that they demonstrate that my use cases for graph naming (i.e. the use cases that matter to me) tend to be about referring to the graph as a representation of a resource, where there is one step of remove. To totally abuse RDF we might agree a new mechanism for publishing novels. A novel might be published as a single triple RDF graph with a blank subject, predicate being rdf:value and the object being the text of the novel. The participants of this thread might each independently come up with the following earth-shattering great novel [ rdf:value Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END! ]. And once the movie of the book grosses many millions, we all end up in court, arguing over who wrote the novel - contradicting the penultimate sentence. Sandro produces his dataset with eg:Sandro dc:creator Sandro Hawke. eg:Sandro [ rdf:value Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END! ]. I produce mine with eg:Jeremy dc:creator Jeremy Carroll. eg:Jeremy [ rdf:value Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END! ]. etc., so that the court is presented with a merge of datasets: eg:Jeremy dc:creator Jeremy Carroll. eg:Sandro dc:creator Sandro Hawke. eg:Dan dc:creator Dan Brickley. eg:Pat dc:creator Pat Hayes. eg:Gregg dc:creator Gregg Reynolds. eg:Jeremy [ rdf:value Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END! ]. eg:Sandro [ rdf:value Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END! ]. eg:Pat [ rdf:value Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END! ]. eg:Gregg [ rdf:value Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END! ]. eg:Dan [ rdf:value Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END! ]. I really don't think there is any contradiction here, even if dc:creator is a functional property. The court would have to fall back onto precedence, and I would produce this e-mail from www-archive and win the case! http://lists.w3.org/Archives/Public/www-archive/2013Sep/0053.html My point with this example is that the identity condition that Sandro is asking for is contrived; I'm confused, since the point I was trying to make is that the identity conditions are contrived (ie lack real use cases) unless we bring in change-over-time. but my use case is of a publishing system where the data being published is in the form of an RDF graph, and there is metadata is data about that graph - but not really stuff about the graph itself but more about the pair - the naming of the graph. So let's go back to that.Give me an example that shows three things: the triples happen to be the same, the metadata must remain distinct, and there is no change over time.As I think about it now, I'm beginning to think it's impossible. -- Sandro Jeremy
Re: The Movie of the Book: Re: defn of Named Graph
On 09/24/2013 05:32 PM, Dan Brickley wrote:
On 24 September 2013 19:15, Sandro Hawke san...@w3.org wrote:
So let's go back to that.Give me an example that shows three things: the
triples happen to be the same, the metadata must remain distinct, and there
is no change over time.As I think about it now, I'm beginning to think
it's impossible.
How about any difference of opinion on factual matters, e.g. birther
conspiracy theorists might believe: obama placeOfBirth kenya. Others
might not and each could cite URLs in support of their viewpoint?
I don't see how this would meet my criteria and motivate distinct
graphs without involving change-over-time.
I'd address the use case like this:
GRAPH :g1 { :Obama :placeOfBirth :Kenya }
GRAPH :g2 { :Obama :placeOfBirth :Hawaii }
:Trump :believes :g1.
:Biden :believes :g2.
and I guess we can meet my first criterion by adding
GRAPH :g3 { :Obama :placeOfBirth :Hawaii }
:Romney :believes :g2.
So we have three graphs, two with the same triples. (Criterion 1
met.) We have no change over time (alas! :-).(Criterion 3 met.)
But are there any properties you could sensibly put on :g2 that wouldn't
also apply to :g3? I can't think of any.
-- Sandro
Dan
Re: defn of Named Graph
Pat Hayes pha...@ihmc.us wrote: On Sep 24, 2013, at 8:31 AM, Sandro Hawke wrote: On 09/20/2013 04:44 AM, Pat Hayes wrote: On Sep 19, 2013, at 9:52 AM, Sandro Hawke wrote: So, I hereby propose we give up on all this until after we solve the change-over-time problem for RDF. Well, I do have other things to do in my life Sorry Hopefully you at least find this satisfying, enjoyable, or entertaining from time to time. , but I think this is a very bad stance to take. The change-over-time-problem is not ever going to be solved. it is not a problem with a solution. If it were, there would be one accepted tense logic and one accepted semantic theory for programming languages. To me, it would be solved if there was a way to handle change-over-time that worked for my applications and that you didn't think was broken wrt RDF Semantics.Hopefully other members of the community would like it, too. I don't think we need the perfect solution, or even consensus at this point. Just something that some of us can use in our software with some reasonable hope it'll function as expected, and not violate the specs in any problematic way. But this type/token business does not require us to solve it. It is a much simpler, more basic kind of clarification that does not depend in ANY WAY on the change-over-time issue. With the greatest respect, Sandro, your obsession with time and change has, I believe, hindered progress here. You keep going back to that issue, even when we have finally managed to agree (at least I thought we had) that the surface/token/named-graph vs. abstract graph distinction did not depend upon time or change, or even involve it. I come back to it obsessively because there is such a dirth of other use cases. (Perhaps I have a bias of wanting to solved for other uses cases; I'm trying hard to keep that in check.) In recent weeks, I tried to keep this discussion to being just about identity without touching on change-over-time, but frankly I don't find the use cases compelling. I'm now confident that you and I (and Jeremy) agree the problem we're trying to solve in this thread is this: people seem to want to have different properties on one graph than on another, even when the graphs happen to have the same triples. But why do they want this? As I poke at that problem, either it turns out this functionality doesn't actually matter to them, or they need it because they are actually dealing with graphs which could at least potentially change over time. Do you have a use case (involving RDF on computers) for having different properties on different graphs (which happen to have the same triples), and which does not involve graphs changing over time? Sure, the use case that was the primary motivation for the original named-graph proposal, which was publishing RDF with a 'warrant' of authenticity, in the form of a robust digital signature, and allowing one of these to mention another using an IRI link. All this secure fixing of provenance and authentication is meaningless if the final contents can be changed at will; and yet it is also meaningless if understood as applying to an abstract set. I believe that use case can also be addressed by I(n)=g.There is no metadata about one of these graphs that doesn't transfer to all other ones with the same triples, so they can just be ordinary RDF Graphs. - Sandro Pat IHMC (850)434 8903 home 40 South Alcaniz St.(850)202 4416 office Pensacola(850)202 4440 fax FL 32502 (850)291 0667 mobile (preferred) pha...@ihmc.us http://www.ihmc.us/users/phayes -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: defn of Named Graph
Jeremy J Carroll j...@syapse.com wrote: I feel that Sandro's text has asked the WG for too much and is motivated by the insoluble use case of dealing with time. A shorter proposal, motivated by other intensional use cases, such as Pat's signing, but any involving stating some intent about a graph, rather than some mathematical property of th graph. Here is a very short use case: [[ I wish to publish a dataset involving three graphs - one create by Adam, the second created by Bettie and the third created by Charles. I wish to use dc:creator to convey this. ]] Note that the three graphs will generally be different, but could be the same. This use case can be addressed by I(n)=g. If some of the graph contents turn out to be the same, that's fine. If Adam and Bettie created the same RDF triples, then it's fine to say they created exactly the same thing. That is, there is one thing and they both created it.(I put l created in quotes because in a sense all RDF graphs already exist. But in the same sense all character strings already exist, so I'm not exactly creating this message.) - Sandro And the a short proposed text is to suggest using interpretations where I(uuu) = uuu, ggg where uuu names ggg in a dataset How to say that with buy-in is the question - it has the 'right' semantic consequences It could be with MUST force, SHOULD force or MAY force. -- Only saying something in Concepts leaves a mess in the Semantics section that deals with named graphs; so the smallest possible edit is to change that section in semantics only Jeremy J Carroll Principal Architect Syapse, Inc. On Sep 27, 2013, at 11:46 AM, Pat Hayes pha...@ihmc.us wrote: On Sep 24, 2013, at 8:31 AM, Sandro Hawke wrote: On 09/20/2013 04:44 AM, Pat Hayes wrote: On Sep 19, 2013, at 9:52 AM, Sandro Hawke wrote: So, I hereby propose we give up on all this until after we solve the change-over-time problem for RDF. Well, I do have other things to do in my life Sorry Hopefully you at least find this satisfying, enjoyable, or entertaining from time to time. , but I think this is a very bad stance to take. The change-over-time-problem is not ever going to be solved. it is not a problem with a solution. If it were, there would be one accepted tense logic and one accepted semantic theory for programming languages. To me, it would be solved if there was a way to handle change-over-time that worked for my applications and that you didn't think was broken wrt RDF Semantics.Hopefully other members of the community would like it, too. I don't think we need the perfect solution, or even consensus at this point. Just something that some of us can use in our software with some reasonable hope it'll function as expected, and not violate the specs in any problematic way. But this type/token business does not require us to solve it. It is a much simpler, more basic kind of clarification that does not depend in ANY WAY on the change-over-time issue. With the greatest respect, Sandro, your obsession with time and change has, I believe, hindered progress here. You keep going back to that issue, even when we have finally managed to agree (at least I thought we had) that the surface/token/named-graph vs. abstract graph distinction did not depend upon time or change, or even involve it. I come back to it obsessively because there is such a dirth of other use cases. (Perhaps I have a bias of wanting to solved for other uses cases; I'm trying hard to keep that in check.) In recent weeks, I tried to keep this discussion to being just about identity without touching on change-over-time, but frankly I don't find the use cases compelling. I'm now confident that you and I (and Jeremy) agree the problem we're trying to solve in this thread is this: people seem to want to have different properties on one graph than on another, even when the graphs happen to have the same triples. But why do they want this? As I poke at that problem, either it turns out this functionality doesn't actually matter to them, or they need it because they are actually dealing with graphs which could at least potentially change over time. Do you have a use case (involving RDF on computers) for having different properties on different graphs (which happen to have the same triples), and which does not involve graphs changing over time? Sure, the use case that was the primary motivation for the original named-graph proposal, which was publishing RDF with a 'warrant' of authenticity, in the form of a robust digital signature, and allowing one of these to mention another using an IRI link. All this secure fixing of provenance and authentication is meaningless if the final contents can be changed at will; and yet it is also meaningless if understood as applying to an abstract set. Pat IHMC
Re: defn of Named Graph
Jeremy J Carroll j...@syapse.com wrote: I also wish to use dcterms:issued Adam and Bettie issued the graph for different purposes on different dates, and the issued property is really about the named graph and not about the graph per se. Okay, so it's enough to use creator and date. Adam created it on Jan 1, Bettie created it on Jan 2. So the it has to be two different things.Or creator and comment, if we want to avoid time entirely. I see one could model that in RDF such that one would want different identity for the same triples.But that's not a very compelling case for me, because it strikes me as bad modeling.What was issued was perhaps a proclamation, and the content of that proclamation was this RDF Graph... Same issue with if they both issued/created the same string on different days. Still, yes, it is a use case, thanks. - Sandro Jeremy J Carroll Principal Architect Syapse, Inc. On Sep 27, 2013, at 2:34 PM, Sandro Hawke san...@w3.org wrote: Jeremy J Carroll j...@syapse.com wrote: I feel that Sandro's text has asked the WG for too much and is motivated by the insoluble use case of dealing with time. A shorter proposal, motivated by other intensional use cases, such as Pat's signing, but any involving stating some intent about a graph, rather than some mathematical property of th graph. Here is a very short use case: [[ I wish to publish a dataset involving three graphs - one create by Adam, the second created by Bettie and the third created by Charles. I wish to use dc:creator to convey this. ]] Note that the three graphs will generally be different, but could be the same. This use case can be addressed by I(n)=g. If some of the graph contents turn out to be the same, that's fine. If Adam and Bettie created the same RDF triples, then it's fine to say they created exactly the same thing. That is, there is one thing and they both created it.(I put l created in quotes because in a sense all RDF graphs already exist. But in the same sense all character strings already exist, so I'm not exactly creating this message.) - Sandro And the a short proposed text is to suggest using interpretations where I(uuu) = uuu, ggg where uuu names ggg in a dataset How to say that with buy-in is the question - it has the 'right' semantic consequences It could be with MUST force, SHOULD force or MAY force. -- Only saying something in Concepts leaves a mess in the Semantics section that deals with named graphs; so the smallest possible edit is to change that section in semantics only Jeremy J Carroll Principal Architect Syapse, Inc. On Sep 27, 2013, at 11:46 AM, Pat Hayes pha...@ihmc.us wrote: On Sep 24, 2013, at 8:31 AM, Sandro Hawke wrote: On 09/20/2013 04:44 AM, Pat Hayes wrote: On Sep 19, 2013, at 9:52 AM, Sandro Hawke wrote: So, I hereby propose we give up on all this until after we solve the change-over-time problem for RDF. Well, I do have other things to do in my life Sorry Hopefully you at least find this satisfying, enjoyable, or entertaining from time to time. , but I think this is a very bad stance to take. The change-over-time-problem is not ever going to be solved. it is not a problem with a solution. If it were, there would be one accepted tense logic and one accepted semantic theory for programming languages. To me, it would be solved if there was a way to handle change-over-time that worked for my applications and that you didn't think was broken wrt RDF Semantics.Hopefully other members of the community would like it, too. I don't think we need the perfect solution, or even consensus at this point. Just something that some of us can use in our software with some reasonable hope it'll function as expected, and not violate the specs in any problematic way. But this type/token business does not require us to solve it. It is a much simpler, more basic kind of clarification that does not depend in ANY WAY on the change-over-time issue. With the greatest respect, Sandro, your obsession with time and change has, I believe, hindered progress here. You keep going back to that issue, even when we have finally managed to agree (at least I thought we had) that the surface/token/named-graph vs. abstract graph distinction did not depend upon time or change, or even involve it. I come back to it obsessively because there is such a dirth of other use cases. (Perhaps I have a bias of wanting to solved for other uses cases; I'm trying hard to keep that in check.) In recent weeks, I tried to keep this discussion to being just about identity without touching on change-over-time, but frankly I don't find the use cases compelling. I'm now confident that you and I (and Jeremy) agree the problem we're trying to solve in this thread is this: people seem to want to have different properties
rdf comments
As Guus mentioned, we're out of time. At this point I'm really liking Pat's plan [1] to leverage the term RDF Source [2] to address the kinds of use cases we've been talking about, and write a WG Note to explain how to do it and define a class of Datasets (or Dataset Sources?) that are snapshots of sources. Given the discussions we've had, is there an alternative design that you think is significantly better, that you'd like the WG to consider as an alternative path forward at tomorrow's meeting? -- Sandro [1] http://lists.w3.org/Archives/Public/public-rdf-wg/2013Sep/0148 [2] http://www.w3.org/TR/rdf11-concepts/#change-over-time
Re: rdf comments
On 10/01/2013 02:16 PM, Jeremy J Carroll wrote: I think my view is that the smallest amount of normative change to the text that actually addresses my comment would be: 1: change in semantics concerning having interpretations that conform with the named graph mapping of a dataset 2: change in semantics giving MAY or SHOULD or MUST force to 1 3: small consequential changes to concepts I will suggest text later today Thanks. Personally, I strongly suggest you avoid use of the term named graph in the text, given apparent disagreement about what it means. -- Sandro Jeremy J Carroll Principal Architect Syapse, Inc. On Oct 1, 2013, at 10:25 AM, Sandro Hawke san...@w3.org wrote: As Guus mentioned, we're out of time. At this point I'm really liking Pat's plan [1] to leverage the term RDF Source [2] to address the kinds of use cases we've been talking about, and write a WG Note to explain how to do it and define a class of Datasets (or Dataset Sources?) that are snapshots of sources. Given the discussions we've had, is there an alternative design that you think is significantly better, that you'd like the WG to consider as an alternative path forward at tomorrow's meeting? -- Sandro [1] http://lists.w3.org/Archives/Public/public-rdf-wg/2013Sep/0148 [2] http://www.w3.org/TR/rdf11-concepts/#change-over-time
Re: rdfs:Graph ? comment on http://www.w3.org/TR/rdf11-concepts/#section-dataset and issue 35
David Booth da...@dbooth.org wrote: Pat or Sandro, Regarding this discussion: [[ On 09/12/2013 12:33 AM, David Booth wrote: [Let's move this discussion to www-archive@w3.org please, as it isn't relevant to Jeremy's comment. All follow-ups there please.] On 09/11/2013 10:32 PM, Pat Hayes wrote: [ . . . ] But each IRI denotes one thing, in all possible interpretations. No, in *each* possible interpretation, not in *all* possible interpretations. I.e., For any interpretation I and URIs U1 and U2, (U1=U2) = (I(U1) = I(U1)) NOT: For any interpretations II and I2, and URIs U1 and U2, (U1=U2) = (I1(U1) = I2(U2)) I.e., the uniqueness does not hold *across* interpretations. It only holds within *each* interpretation individually. (The current RDF 1.1 semantics socument makes thie very explicit, by the way.) Yes, I noticed that, and the current wording is *incorrect*. It needs to be fixed, as it wrongly implies that RDF may only be viewed from the perspective of a single RDF interpretation, and that is simply *wrong*. ]] In looking for the offending statement in the current RDF Semantics draft I am not currently able to find it. So I'm wondering if the draft was changed since I noticed the problem. How can I view previous versions of the editor's drafts? Editor's drafts are all in mercurial. Browse from dvcs.w3.org, but it's not easy. Maybe you just want to like at the tr versions. - Sandro Thanks, David -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: RDF Semantics - Intuitive summary needs to be scoped to interpretations (ISSUE-149)
Pat Hayes pha...@ihmc.us wrote: Hi David This is NOT an official WG response, but only an informal note to explain some of the background thinking and discussions behind some of the decisions we took. Please don't copy this to the public comments list. I added Sandro to the CC list as he seems interested in this stuff. The 2004 semantics document tried to do (at least) two things at once. It is a formal, normative description of the semantics, but it also tried to be a tutorial in various places, including in the section you refer to and the extended glossary. This introductory material has gotten some good reviews (thanks) but also has gotten some criticism, especially with regard to its appropriateness for inclusion in a normative standard document. And for sure, it made the document a lot longer than it would have been without it, and the sheer length of the RDF specs has come in for a lot of criticism. And for some readers, it is an irritating distraction. Early in this WG, after some extended discussions, we decided that the public interest would be better served by separating the explanatory/tutorial/introductory material from the formal technical normative material, and moving the former to a different document, a kind of introduction/tutorial/primer document that is yet to be written, and thereby making the normative technical document shorter and crisper. This sacrifices readability for precision and exactness, but there was a consensus in the WG that at this time in the evolution of RDF, precision and exactness (and comparative brevity) were more important than introductory exposition, in the actual normative specification. This is why the material that you now miss, is missing. (You may also notice that the RDF1.1 Concepts document is also much shorter and brisker than the 2004 version, for the same reasons.) As I say, the plan was (and still is) to move this all to a 'primer' document rather than abandon it entirely, but this is why its not in the actual semantics document. The short intuitive summary section on which you commented earlier represented an editorial lapse on my part when drafting the new document, where my old teaching instincts overwhelmed my responsibility as WG editor. Your comment made me realize the error of my ways. Pat +1 - Sandro On Oct 9, 2013, at 10:16 PM, David Booth wrote: Hi Pat (and others), I would not raise an objection to deleting the Intuitive Summary, but I think there would be a loss to the public in deleting it. I also really liked the explanation of interpretations that you included in the 2004 version, and miss it in the current draft. It really gave very good insight into the concept. So personally, I think a better solution would be to add back your explanation of interpretations and tweak the Intuitive Summary section as needed. You mentioned this concern: [[ Consider: An RDF graph is true under a given interpretation exactly when: 1. the IRIs and literals in subject or object position in the graph all refer to things, But suppose that they refer to things that are not in the universe of the given interpretation, then this is false. ]] But AFAICT that is impossible, because refer is defined in sec. 4 to be relative to an interpretation: In the above sentence, I was using the word refer in its normal English usage, informally. But in any case, the point still stands: they might be referring to things in the universe of a different interpretation. http://www.w3.org/TR/2013/WD-rdf11-mt-20130723/#notation [[ The words denotes and refers to are used interchangeably as synonyms for the relationship between an IRI or literal and what it refers to **in a given interpretation** . . . . ]] (my emphasis). And the wording that I suggested makes clear what interpretation is intended I don't accept that it does make this clear. , so the IRIs and literals *cannot* refer to things outside of that interpretation's universe. Also, I don't know what you mean when you wrote: [[ No doubt David would respond, but readers should be *obliged* to think about interpretations, and then my reply would be, OK, but if so then this section is inappropriate in the first place, so let us delete this section. ]] Why would that section be inappropriate if readers are obliged to think about interpretations? It seems to me to give a fairly concise summary of the formal approach taken. Finally, at the risk of restating the potentially obvious, I do not see how anyone could possibly understand the formal semantics without understanding the idea of interpretations, since they are so central to the semantics. The notions of reference (what a name refers to, or denotes) and truth are pre-theoretic. They are part of our ordinary understanding of the world. Interpretations simply formalize (if one can call such a simple construct a 'formalization) this intuition so that one can do some mathematics with it. The idea
Re: rdfs:Graph ? comment on http://www.w3.org/TR/rdf11-concepts/#section-dataset and issue 35 (ISSUE-142)
Jeremy J Carroll j...@syapse.com wrote:
Hi Peter
thank you and the WG for the time spent considering my issue.
I am sorry that you have failed to reach a satisfactory response, and
understand the difficulties involved.
My current intent is to raise a formal objection for consideration by
the director during the transition review.
I will be clear in that objection that I do not agree with Sandro
http://lists.w3.org/Archives/Public/public-rdf-wg/2013Oct/0075.html
that I am in a Solomon and the Baby situation, and that I do not
believe it is best that the specification dies; however, I do believe
that asking the director to consider whether asking the WG to actually
resolve this issue is appropriate.
What other option do you see? The charter expires in about 10 weeks now. If
we're not at PR then, I think the spec dies
- Sandro
I will be drafting the objection in the next 2 weeks: if the WG would
like me to accelerate that process please let me know.
Jeremy J Carroll
Principal Architect
Syapse, Inc.
On Oct 11, 2013, at 1:03 PM, Peter F. Patel-Schneider
pfpschnei...@gmail.com wrote:
Dear Jeremy:
This is a second official response to your message about rdfs:Graph
and
RDF datasets,
http://lists.w3.org/Archives/Public/public-rdf-comments/2013Jul/0021.html,
which is being tracked as ISSUE-142.
The first official response from the working group was
http://lists.w3.org/Archives/Public/public-rdf-comments/2013Aug/0050.html
which stated that the working group was unable to agree on any
proposal
for RDF datasets that goes beyond the very minimal proposal in its
current
documents. You responded, in
http://lists.w3.org/Archives/Public/public-rdf-comments/2013Sep/0005.html,
that you were not satisfied with this situation.
The working group again discussed RDF datasets and was again unable
to come
up with any viable solution. The only resolution that was acceptable
was a
negative one - the RDF working group will leave further semantics of
datasets and named graphs to some future working group. Hopefully at
that
time there will be one or more communities of practice using aspects
of RDF
datasets and named graphs that can be used as the starting point for
portions of a W3C recommendation.
The working group realizes that the current situation is not totally
satisfactory to you, but the working group has expended a lot of
effort on
this topic already and has been unsuccessful. There are no
forseeable
possibilities of a breakthrough here and thus the working group will
be
concentrating its efforts in other areas so as to finish the work it
needs
to do.
Please indicate whether you wish to pursue this issue further, or
whether
leaving the situation unchanged in this area is acceptable to you.
Thank
you for your concerns on this topic.
Yours sincerely,
Peter F. Patel-Schneider
for the RDF Working Group
On 07/11/2013 12:06 PM, Jeremy J Carroll wrote:
Hello
This is a formal comment on
http://www.w3.org/TR/rdf11-concepts/#section-dataset, and it appears a
comment on
https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-schema/index.html
and quite possibly on the RDF Semantics ….
It seems to be a suggestion to reopen issue 35
http://www.w3.org/2011/rdf-wg/track/issues/35
which points to
http://www.w3.org/TR/sparql11-service-description/
hence I am CC-ing dawg.
The last part of this message discusses problems in using service
description to meet my use case: to me, this is not a comment on DAWG's
work, but a comment that RDF Core cannot use DAWG's work of more
limited scope to duck the issue.
Summary: I would like to use rdf to describe graphs in a dataset,
e.g. to say who the author was.
as a simple example
my:graph {
my:graph dc:creator Jeremy J. Carroll .
}
I cannot see how to do this with the current drafts, editors drafts,
etc.
A possible approach would be to reopen issue 35 and have a class
rdfs:Graph, s.t. for a URI used as the name of a graph in a dataset
the triple
URI rdf:type rdfs:Graph
holds.
More weakly, I would be satisfied with such a concept being added to
the RDF vocabulary, without the implication above holding, but a
suggested usage pattern.
Also, I basically finished this message before finding issue 35 and
it's superficially reasonable resolution that sd:Graph may meet my
needs. This suggests that some documentation link from either RDF
Concepts or RDF Schema or RDF Semantics to SPARQL Service Description
would be helpful ….
However, the Service Description doc
http://www.w3.org/TR/sparql11-service-description/
ducks on the issue of whether the name denotes the graph, and so
does not give me a clear place to put such metadata.
I think if the RDF WG tried writing such documentation, they would
discover that the resolution of issue 35 would unravel - the trick is
to allow such unravelling without having too much of the named graphs
work unravel.
Here is my actual use
(please ignore)
(just testing something about the mailing list archives)
